라이브러리/SDK 의존성에서 PQC 리스크 찾기: OpenSSL·BoringSSL·Java 기준

PQC 전환은 알고리즘만 바꾸는 일이 아니라, OpenSSL·BoringSSL·Java 같은 “의존성 체인”을 끝까지 추적하는 일이다. 지금 쓰는 TLS/서명 경로에 PQC가 끼어들 틈이 있는지, 반대로 숨어 있는 리스크는 없는지 점검 포인트를 정리한다. 지금 많은 조직의 PQC 리스크는 “암호 라이브러리 버전”이 아니라 “어떤 코드 경로가 실제로 그 라이브러리를 호출하느냐”에서 터진다. 특히 TLS는 브라우저·프록시·SDK가 묶여 움직여서, 한쪽만 바꿔도 호환성 문제가 난다. 그래서 OpenSSL·BoringSSL·Java를 기준으로 의존성에서 리스크를 찾는 순서를 잡아두면 전환이 빨라진다. 1) PQC 리스크가 ‘의존성’에서 생기는 이유 PQC는 이제 표준이 생긴 상태다. NIST는 ML-KEM(키 캡슐화)과 ML-DSA(전자서명)를 FIPS 203/204로 확정했고, 이것이 시장의 기준점이 됐다. 문제는 대부분 서비스가 암호를 직접 구현하지 않고, 라이브러리(OpenSSL/BoringSSL)나 런타임(Java)와 그 위의 프레임워크를 통해 쓴다는 점이다. 즉 “PQC를 지원하는 의존성이 있다”와 “내 트래픽이 PQC 경로로 실제 협상된다”는 완전히 다르다. 또한 TLS 하이브리드 키 교환은 Kyber 기반에서 ML-KEM 기반으로 빠르게 이동하면서(코드포인트/그룹 변경), 구형 구현은 그대로 두면 ‘연결은 되는데 PQC는 안 됨’ 같은 상태가 된다. 그래서 의존성 점검은 버전 확인을 넘어 실제 협상 결과를 확인하는 쪽으로 가야 한다. 2) OpenSSL 의존성에서 PQC 리스크 찾는 법 OpenSSL은 1.1.1 계열과 3.x 계열의 성격이 다르다. 3.x는 Provider 아키텍처를 중심으로 알고리즘 구현을 분리하고, 애플리케이션이 어떤 API(EVP 경유 vs 저수준 함수)를 쓰는지에 따라 교체 난이도가 갈린다. 리스크 패턴은 보통 세 가지다. 첫째, OpenSSL 3를 쓰지만 EVP를 안 타는 코드 경로가 있어 Provider 전환...

소프트웨어 업데이트 체인 보안: 서명 알고리즘 교체 체크포인트

소프트웨어 업데이트 체인 보안에서 서명 알고리즘 교체는 배포 신뢰의 뿌리를 바꾸는 작업이다. 코드 서명, 메타데이터, 키 회전, 검증 클라이언트까지 체크포인트를 정리한다.

업데이트는 취약점을 고치지만, 공격자에게는 배포 경로를 타는 가장 큰 기회가 되기도 한다. 그래서 소프트웨어 업데이트 체인 보안의 핵심은 “무엇을, 누가, 어떤 키로 서명했고, 사용자가 어떻게 검증하느냐”를 끝까지 일관되게 만드는 것이다. 특히 서명 알고리즘 교체는 단순 라이브러리 교체가 아니라, 루트 오브 트러스트와 운영 절차를 같이 바꾸는 일이므로 체크포인트가 필요하다.

서명 알고리즘 교체

1) 업데이트 체인에서 “서명”이 맡는 역할 다시 정의하기

소프트웨어 업데이트 체인 보안에서 서명은 무결성만이 아니라 출처를 고정한다. 패키지나 바이너리 자체 서명에 더해, 업데이트 메타데이터(버전, 대상, 만료, 해시, 배포 정책)까지 서명하는 구조가 되면 저장소나 CDN이 뚫려도 피해를 줄일 수 있다. 이런 설계를 대표적으로 체계화한 것이 TUF이며, 역할별 키(루트, 타깃, 스냅샷, 타임스탬프)와 만료, 키 회전, 임계값 서명을 통해 “키/서버 일부가 털려도 복구 가능”을 목표로 한다.

이 관점에서 서명 알고리즘 교체 체크포인트 첫 줄은 “어떤 객체를 서명하고 있는가”다. 산출물(아티팩트)만 서명 중이면 메타데이터 서명까지 확대할지, 이미 메타데이터를 쓰고 있다면 만료와 회전이 실제로 강제되는지부터 점검해야 한다.

2) 서명 알고리즘 교체 체크포인트: 호환, 키, 정책을 같이 바꾸기

교체는 보통 RSA/ECDSA/Ed25519 같은 기존 알고리즘 간 전환이거나, 장기적으로는 PQC(예: NIST 표준의 ML-DSA, SLH-DSA 등) 대비까지 포함한다. NIST는 2024년에 PQC 표준(FIPS 203/204/205)을 발표했고, 연방 관보에도 효력 발생이 공지됐다.

실무 체크포인트는 세 갈래로 보자.

첫째, 호환성. 검증 주체가 클라이언트(에이전트/업데이터/부트로더/패키지 매니저)라면 “새 알고리즘을 검증할 수 있는 최소 버전”이 생긴다. 그래서 전환 기간에는 이중 서명(구 알고리즘 + 신 알고리즘)을 지원하거나, 메타데이터에 허용 알고리즘 목록을 넣고 단계적으로 끄는 방식이 안전하다. 자동 업데이트는 구버전 클라이언트를 한 번에 올리기 어렵기 때문에, 검증 실패 시 복구 경로(이전 메타데이터로 롤백, 오프라인 복구키로 재서명)까지 문서화해야 한다.

둘째, 키 관리. 알고리즘을 바꾸면 키 길이/형식/저장 방식이 달라지고, HSM·KMS·서명 서비스가 그대로 지원하는지도 갈린다. 루트 키는 오프라인 보관, 하위 키는 짧은 수명과 빠른 회전, 임계값(예: 2-of-3) 같은 운영 원칙을 알고리즘 교체와 동시에 재정의하는 편이 낫다. TUF나 유사한 역할 분리가 있다면, 특히 루트 역할 키 교체 절차(교차 서명, 새 루트 배포, 구 루트 폐기 시점)가 가장 큰 사고 지점이다.

셋째, 정책과 증거. 최근엔 “서명했다”만으로 부족하고, 어떻게 만들어졌는지까지 남기는 흐름이 강하다. SLSA 1.0은 빌드, 소스, 의존성 등 트랙별 요구사항을 제시했고, 단순 규정이 아니라 증적을 남기도록 유도한다. Sigstore는 키를 오래 들고 있지 않는 키리스 서명(짧은 수명 인증서)과 투명성 로그로 서명 이벤트를 추적 가능하게 만드는 접근을 제공한다. CI에서 서명 주체를 사람 키가 아니라 워크플로 정체성으로 묶을 때 특히 유용하다. in-toto의 어테스테이션 프레임워크는 “어떤 과정이 수행됐다”를 표준 형태로 표현하려는 흐름과 연결된다. 알고리즘 교체 시에는 “서명 알고리즘, 키 ID, 서명 주체, 빌드 환경”이 한 덩어리로 추적되게 스키마와 저장 위치를 확정해 두는 게 체크포인트다.

3) 배포 사고를 막는 전환 루틴: 점진 적용과 실패 설계

서명 알고리즘 교체는 성공 루트보다 실패 루트를 먼저 설계해야 한다. 추천 루틴은 이렇다. 먼저 개발/스테이징에서 이중 서명과 검증을 강제하고, 검증 실패를 관측 가능한 지표로 만든다(예: 실패율, 특정 OS/아키텍처 편중, 프록시 환경). 다음으로 카나리 배포에서 “구 알고리즘만 가능한 클라이언트”가 어느 정도 남아 있는지 실제 데이터로 확인한 뒤, 컷오버 날짜를 정한다. 마지막으로 폐기 단계에서는 구 알고리즘 서명을 완전히 끄기 전에, 구버전 클라이언트용 최종 안전 버전(마지막 이중 서명 릴리스)을 남겨 복구 지점을 만든다.

여기에 NIST SSDF는 개발부터 릴리스까지 보안 활동을 체계화하는 권고를 제공하므로, 알고리즘 교체를 일회성 작업이 아니라 표준 변경 관리로 넣어 운영하는 근거로 쓰기 좋다. 펌웨어/IoT까지 포함한다면, IETF의 SUIT 아키텍처와 매니페스트 모델처럼 “매니페스트가 무엇을 검증하고 설치하는지”를 구조적으로 다루는 문서가 힌트가 된다.

4) 결론

소프트웨어 업데이트 체인 보안에서 서명 알고리즘 교체는 암호 모듈만 바꾸는 일이 아니라, 어떤 것을 서명하고 어떤 절차로 회전하며 무엇을 증거로 남길지를 다시 합의하는 작업이다. 체크포인트는 메타데이터 서명 구조, 클라이언트 호환과 이중 서명 전략, 루트 키 교체 및 복구 절차, 빌드·서명 증적의 표준화로 정리된다. TUF, SLSA, Sigstore, in-toto 같은 프레임워크를 참고하면 “공격을 완벽히 막기”보다 “부분 침해에도 복구 가능” 쪽으로 설계를 이동시킬 수 있다. 마지막으로 전환은 점진 적용과 실패 설계를 중심에 두고, 관측 지표로 컷오버를 결정하는 게 안전하다.