라이브러리/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 전환 효과를 못 보는 경우다. 둘째, OQS 같은 서드파티 Provider로 테스트만 하고 운영 배포(이미지/패키징)에서는 빠지는 경우다. 셋째, FIPS Provider 강제 정책 때문에 서드파티 Provider를 같이 못 쓰는 구성이라 운영에서 PQC를 켤 수 없는 경우다.
실전 점검은 “실제로 로딩되는 libssl/libcrypto 확정 → Provider 로딩 정책 확인 → EVP 경로 여부 확인 → TLS terminate 컴포넌트의 실제 TLS 스택 분리” 순서로 잡으면 삽질이 줄어든다.
3) BoringSSL·Java 의존성에서 PQC 리스크 찾는 법
BoringSSL은 특정 생태계 중심으로 움직이는 편이라, 포크/서브모듈/벤더 패치가 리스크의 핵심이다. ML-KEM 기반 하이브리드(X25519MLKEM768) 같은 변경이 들어간 시점과, Kyber 기반 코드포인트를 붙잡은 포크를 쓰는지 여부가 운영 안정성을 좌우한다.
Java는 JCA/JCE(알고리즘 API)와 JSSE(TLS)를 분리해서 봐야 한다. ML-KEM과 ML-DSA가 JEP 496/497로 들어와도, TLS 협상은 JEP 527 같은 별도 변화로 따라온다. 따라서 “자바가 PQC 알고리즘을 안다”와 “TLS가 PQC로 협상한다”를 분리해 점검해야 한다.
운영에서 흔한 함정은 버전 혼재다. 서버 JDK는 최신인데 사이드카/에이전트/클라이언트 SDK는 구 버전이면 협상이 깨진다. SBOM 단위로 런타임/JDK를 함께 잡는 방식이 효과적이다.
4) 결론
PQC 의존성 리스크는 ‘지원 여부’가 아니라 ‘실제 호출 경로’에서 판가름 난다. NIST 표준(ML-KEM/ML-DSA)과 TLS 하이브리드 전환(X25519MLKEM768 등)을 기준으로, OpenSSL은 Provider/EVP 경로를, BoringSSL은 포크·태그·코드포인트 변화를, Java는 JCA와 JSSE를 분리해 점검하면 된다. 마지막 테스트는 “버전 확인”이 아니라 “핸드셰이크/서명 검증이 정말 그 알고리즘으로 이루어졌는지”까지 로그/패킷/메트릭으로 닫아야 운영 리스크가 줄어든다.