Google과 NIST, IETF, NSA를 포함한 많은 조직은 암호학적으로 유의미한 양자 컴퓨터(CRQC)가 초래할 커다란 위험 때문에 양자 내성 암호(Post-Quantum Cryptography, PQC)로의 전환이 중요하다고 믿고 있습니다. 지난 8월, 저희는 새로운 형태의 하이브리드 양자 내성 암호 키 교환 방식인 Kyber(ML-KEM)[^1]를 활용하여 미래의 양자 컴퓨터 위험으로부터 사용자를 보호하려는 Chrome 보안팀의 노력에 대해 포스팅한 바 있습니다. 그리고 오늘, Chrome 124 버전부터 모든 데스크톱 플랫폼의 TLS 1.3 및 QUIC에 최신 Kyber 드래프트 규격을 기본적으로 활성화했다는 기쁜 소식을 전해드립니다.[^2] 이 과정에서 기존의 여러 TLS 미들박스(middlebox) 제품에서 발견되지 않았던 버그들이 드러나기도 했습니다. 이러한 문제의 수정을 돕기 위해 Chrome은 일시적으로 기업용 정책을 통해 이를 비활성화(opt-out)할 수 있는 옵션을 제공하고 있습니다.
기회주의적(opportunistic) 양자 내성 키 교환을 출시하는 것은 Google의 전반적인 전략의 일부입니다. 이 전략은 미래에 공격자가 양자 컴퓨터를 사용할 수 있게 될 때 위험에 처할 수 있는 시스템에 대해 오늘날 양자 내성 암호를 우선적으로 배포하는 것을 목표로 합니다. 저희는 드래프트 버전을 구현하고 구현자 및 초기 도입자들의 피드백을 바탕으로 반복 개선함으로써, 실제 경험을 토대로 표준화 작업에 기여하는 것이 중요하다고 믿습니다. 이러한 반복적 접근 방식은 QUIC과 TLS 1.3을 개발할 때도 핵심적인 역할을 했습니다. 이는 저희가 이번 Kyber 드래프트 버전을 출시한 이유이기도 하며, 향후 양자 내성 암호 계획의 근간이 됩니다.
Chrome의 양자 내성 전략은 HTTPS에서의 양자 내성 키 교환과 웹 PKI 인증서의 유연성(Agility) 강화에 우선순위를 두고 있습니다. PKI 유연성이 다소 동떨어진 이야기처럼 들릴 수 있지만, 과거 암호화 전환기마다 유연성의 부재는 심각한 지연을 초래해 왔으며, 이 분야에서 실행 가능한 해결책을 찾을 때까지 그 영향은 계속될 것입니다. 웹에서 양자 내성 암호로의 안전하고 신뢰할 수 있는 전환을 위해서는 더욱 유연한 웹 PKI가 필수적입니다.
이를 이해하기 위해 HTTPS와 양자 내성 암호의 현재 상태를 살펴보겠습니다. HTTPS 맥락에서 암호화는 주로 세 가지 방식으로 사용됩니다.
- 대칭 암호화/복호화: HTTP는 AES-GCM과 같은 인증된 암호(AEAD)를 사용하여 TLS 연결 내부에서 데이터로 전송됩니다. 이러한 알고리즘은 양자 암호 해독에 대해 대체로 안전하다고 간주되므로 그대로 유지될 수 있습니다.
- 키 교환: 대칭 암호화에는 비밀키가 필요합니다. 키 교환은 두 당사자가 공개된 채널을 통해 공유 비밀키를 상호 생성할 수 있도록 하는 비대칭 암호화의 한 형태입니다. 이 비밀키는 이후 대칭 암호화 및 복호화에 사용됩니다. 현재 TLS에서 사용하도록 표준화된 모든 형태의 비대칭 키 교환은 양자 암호 해독에 취약합니다.
- 인증: HTTPS에서 인증은 주로 디지털 서명을 통해 이루어지며, 이는 서버의 신원 확인, 핸드셰이크 인증 및 인증서 발급의 투명성을 전달하는 데 사용됩니다. TLS에서 인증을 위해 표준화된 모든 디지털 서명 및 공개 키 알고리즘은 양자 암호 해독에 취약합니다.
결과적으로 HTTPS에는 두 가지 별개의 양자 위협이 존재하게 됩니다.
첫 번째는 현재 생성되는 트래픽에 대한 위협입니다. 공격자는 지금 암호화된 트래픽을 저장해 두었다가, 나중에 실용적인 CRQC가 등장하면 이를 사용하여 트래픽을 복호화할 수 있습니다. 이는 흔히 ‘지금 수집하고 나중에 해독하기’(store-now-decrypt-later) 공격으로 알려져 있습니다. 이 위협은 CRQC가 언제 실용화되는지와 관계없이 공격자가 지금 암호화된 데이터를 저장하는 것에서 비롯되므로 매우 시급한 문제입니다. 이 공격을 방어하려면 키 교환이 양자 내성을 갖춰야 합니다. Chrome에서 Kyber를 출시함으로써 서버는 ‘지금 수집하고 나중에 해독하기’ 공격을 완화할 수 있게 되었습니다.
두 번째 위협은 미래의 트래픽이 양자 컴퓨터에 의한 사칭에 취약해진다는 점입니다. 일단 CRQC가 실제로 존재하게 되면, HTTPS 인증에 사용되는 비대칭 암호화를 깨는 데 사용될 수 있습니다. CRQC의 사칭 공격을 방어하려면 인증에 사용되는 모든 비대칭 암호화를 양자 내성 변형으로 마이그레이션해야 합니다. 그러나 인증 체계가 깨지는 것은 CRQC가 가용해진 이후에 생성되는 트래픽에만 영향을 미칩니다. 이미 기록된 트래픽의 인증을 깨는 것은 공격자가 어느 쪽 당사자도 사칭할 수 없게 하기 때문입니다. 대화는 이미 끝난 상태니까요.
즉, 인증에 있어서는 ‘지금 수집하고 나중에 해독하기’에 해당하는 위협이 없습니다. 따라서 키 교환과 인증을 모두 양자 내성 방식으로 전환하는 것이 모두 중요하지만, 인증 마이그레이션은 키 교환보다 상대적으로 덜 급박합니다. 이는 다행스러운 일인데, 양자 내성 인증으로의 전환에는 다양한 과제가 존재하기 때문입니다. 특히 ‘크기’ 문제가 큽니다.
양자 내성 암호는 HTTPS에서 사용되는 기존 암호 알고리즘에 비해 크기가 큽니다. Kyber 키 교환은 피어당 약 1KB를 전송하는 반면, X25519 키 교환은 피어당 32바이트에 불과하여 30배 이상의 차이가 납니다. Kyber의 실제 키 교환 연산 자체는 매우 빠르지만, Kyber 키를 전송하는 것은 상당히 느립니다. Kyber의 추가된 크기로 인해 TLS ClientHello가 두 개의 패킷으로 나뉘게 되며, 이로 인해 Chrome 데스크톱의 모든 TLS 핸드셰이크에서 중앙값 기준 4%의 지연 시간이 증가합니다. 데스크톱 플랫폼에서는 HTTP/2 및 HTTP/3 연결 재사용 덕분에 Core Web Vitals에서 눈에 띄는 수준은 아닙니다. 안타깝게도 인터넷 연결 대역폭이 낮고 지연 시간이 긴 경우가 많은 Android에서는 이 영향이 눈에 띄게 나타나고 있으며, 이 때문에 Android에서는 아직 출시하지 않았습니다.
인증의 경우 크기 문제는 더욱 심각합니다. ML-DSA(Dilithium) 키와 서명은 ECDSA 키와 서명보다 약 40배 더 큽니다. 오늘날 일반적인 TLS 연결은 모든 인증 요구 사항을 충족하기 위해 두 개의 공개 키와 다섯 개의 서명을 사용합니다. 단순히 이를 ML-DSA로 교체하면 TLS 핸드셰이크에 약 14KB가 추가됩니다. Cloudflare는 지연 시간이 20~40% 증가할 것으로 예상하며, 저희는 단 1KB의 추가만으로도 영향이 있음을 확인했습니다. 대신, 우리는 필요한 속성을 제공하면서도 전송되는 서명과 공개 키의 수는 더 적은 HTTPS 인증에 대한 대체 접근 방식이 필요합니다.
저희는 HTTPS에서 양자 내성 인증을 위한 중요한 다음 단계가 **트러스트 앵커 유연성(trust anchor agility)**을 확보하는 데 집중하는 것이라고 생각합니다. 역사적으로 공개 웹 PKI는 새로운 알고리즘을 신속하게 배포할 수 없었습니다. 이는 대부분의 사이트 운영자가 지원되는 모든 클라이언트와 브라우저를 위해 단일 인증서를 제공하기 때문입니다. 이 인증서는 사이트 운영자가 지원하는 모든 브라우저 또는 클라이언트가 신뢰하는 신뢰 계층 구조(trust hierarchy)에서 발행되어야 하며, 각 클라이언트와 호환되어야 합니다.
단일 인증서 모델은 웹 PKI의 진화를 어렵게 만듭니다. 보안 요구 사항이 변화함에 따라, 사이트 운영자는 배포된 클라이언트가 신뢰하는 인증서, 새로운 클라이언트가 신뢰하는 인증서, 배포된 클라이언트가 지원하는 알고리즘, 새로운 클라이언트가 지원하는 알고리즘 사이에서 접점을 찾지 못할 수도 있습니다(여기에 각기 다른 브라우저와 루트 저장소까지 고려해야 합니다). 이러한 클라이언트는 다양한 브라우저부터 업데이트를 받지 못하는 구형 버전, 스마트 TV나 결제 단말기의 애플리케이션에 이르기까지 매우 다양합니다. 요구 사항이 갈라짐에 따라 사이트 운영자는 새로운 클라이언트를 위한 보안과 구형 클라이언트를 위한 호환성 사이에서 선택을 강요받게 됩니다.
이러한 갈등은 결과적으로 새로운 클라이언트가 양자 내성 전환과 같은 사용자 보안 개선을 위한 PKI 변경을 진행하는 것을 제한합니다. 단일 인증서 배포 모델 하에서는 최신 클라이언트가 구형 클라이언트와 너무 많이 동떨어질 수 없으며, 그렇지 않으면 서버 운영자는 호환성을 유지할 방법이 없게 됩니다. 저희는 서버에 여러 인증서를 프로비저닝하고 각 클라이언트에 올바른 인증서를 자동으로 보내는 다중 인증서 배포 모델로 이동하여 이 문제를 해결할 것을 제안합니다. 이를 통해 트러스트 앵커 유연성이 확보되고 클라이언트가 각기 다른 속도로 진화할 수 있습니다. 최신 상태를 유지하고 안정적으로 업데이트를 받는 클라이언트는 업데이트를 받지 않는 오래된 클라이언트에 얽매이지 않고 인터넷 진화에 가장 적합한 인증 메커니즘을 사용할 수 있게 됩니다. 인증 기관(CA)과 트러스트 스토어(trust store)는 가장 느린 행위자가 지원을 추가할 때까지 기다릴 필요 없이 새로운 양자 내성 트러스트 앵커를 도입할 수 있습니다. 이는 실험적인 양자 내성 인증 방법을 사용하는 계층 구조를 원활하게 추가하고 제거할 수 있게 하므로 양자 내성 전환을 대폭 단순화할 것입니다.
언뜻 보기에 TLS는 **교차 서명(cross-signatures)**과 **서명 알고리즘 협상(signature algorithm negotiation)**을 통해 이미 트러스트 앵커 유연성을 갖춘 것처럼 보일 수 있습니다. 그러나 이 두 메커니즘 중 어느 것도 진정한 트러스트 앵커 유연성을 제공하지 못하며, 그럴 의도로 만들어진 것도 아닙니다.
교차 서명이란 CA가 단일 주체 및 공개 키 쌍에 대해 발급자와 서명이 서로 다른 두 개의 인증서를 생성하는 것을 말합니다. 첫 번째 인증서는 평소와 같이 CA 자체에 의해 발행 및 서명됩니다. 두 번째는 종종 다른 조직에 의해 다른 신뢰 계층 구조에서 발행 및 서명됩니다. 예를 들어, 초기 Let's Encrypt 중간 인증서는 두 가지 형태로 존재했습니다.[^3] "일반" 중간 인증서는 Let's Encrypt 루트에 의해 서명된 반면, "교차 서명된" 중간 인증서는 IdenTrust에 의해 서명되었습니다. 새로운 PKI 계층 구조를 더 오래되고 널리 사용 가능한 PKI 계층 구조로 교차 서명하는 이 방식은 새로운 CA가 구형 기기에서 신뢰를 구축할 수 있게 해줍니다(구형 기기가 해당 서명 알고리즘을 지원하는 한). 하지만 교차 서명은 종종 경쟁 관계에 있는 CA들 간의 긴밀한 협력에 의존하며, 서로 다른 클라이언트가 서로 다른 요구 사항을 가질 때는 적합하지 않을 수 있습니다. 이는 사이트 운영자가 교차 서명을 사용할 수 있는 경우를 제한합니다. 또한 새로운 알고리즘을 지원하지 않는 기기는 교차 서명 여부와 관계없이 새로운 인증서에 사용된 새로운 서명 알고리즘을 사용하기 위해 여전히 업데이트가 필요합니다.
서명 알고리즘 협상을 통해 TLS 피어는 핸드셰이크 서명에 사용할 알고리즘에 합의할 수 있습니다. 이 알고리즘은 인증서에 사용된 키 유형과 일치해야 합니다. 엔드포인트는 상대방이 핸드셰이크 서명을 위해 ECDSA와 같은 알고리즘을 지원한다면 ECDSA 인증서도 지원할 것임을 추론할 수 있습니다. 이 값은 RSA 기반 체인과 더 작은 ECDSA 기반 체인 사이를 다중화하는 데 사용될 수 있습니다. 예를 들어, Google의 RSA 기반 호환 체인은 인증서 4개로 약 4.1KB인 반면, 가장 짧은 ECDSA 기반 체인은 인증서 3개로 약 1.7KB에 불과합니다.[^4]
서명 알고리즘 협상은 트러스트 앵커 유연성을 제공하지 않습니다. 서명 알고리즘 정보가 알고리즘 지원 여부를 암시하기는 하지만, 클라이언트가 실제로 어떤 트러스트 앵커를 신뢰하는지에 대한 정보는 제공하지 않습니다. 클라이언트가 ECDSA를 지원하더라도 특정 CA의 최신 ECDSA 루트 인증서를 가지고 있지 않을 수 있습니다. 사용되는 트러스트 스토어가 매우 다양하기 때문에 많은 조직은 여전히 ECDSA 인증서를 제공할 때 보수적일 수밖에 없으며, 최대의 호환성을 위해 교차 서명된 긴 체인을 제공해야 할 수도 있습니다.
교차 서명이나 서명 알고리즘 협상 모두 인증을 위한 양자 내성 암호 마이그레이션의 해결책이 아닙니다. 교차 서명은 새로운 알고리즘 도입에 도움이 되지 않으며, 서명 알고리즘 협상은 오로지 알고리즘 협상에 관한 것이지 트러스트 앵커에 대한 정보를 제공하는 것이 아닙니다. 저희는 양자 내성 암호로의 전환이 점진적으로 이루어질 것으로 예상합니다. 서명 알고리즘 협상 결과로부터 트러스트 스토어의 내용에 대한 정보를 추론하는 것은 단순히 알고리즘 협상을 위해 사용되는 대신 특정 버전의 특정 트러스트 스토어에 고착화(ossification)될 위험이 있습니다.
대신, TLS에 유연성을 도입하려면 클라이언트와 서버가 어떤 인증서를 사용할지 효율적으로 결정할 수 있도록 하는 명시적인 트러스트 앵커 협상(trust anchor negotiation) 메커니즘이 필요합니다. 2023년 11월 프라하에서 열린 IETF 회의에서 Chrome은 TLS에서의 트러스트 앵커 협상 메커니즘으로 "Trust Expressions"를 제안했습니다. Chrome은 현재 IETF 프로세스를 통해 Trust Expressions에 대한 커뮤니티의 의견을 구하고 있습니다. 저희는 다양한 클라이언트를 처리하기 위해 여러 인증서를 깔끔하게 배포할 수 있도록 하는 목표가 제안의 구체적인 메커니즘보다 훨씬 더 중요하다고 생각합니다.
이를 바탕으로 Merkle Tree Certificates와 같이 서버를 인증하는 더 효율적인 방법들을 탐구할 수 있습니다. 저희는 트러스트 앵커 유연성을 도입하는 것이 효율적인 양자 내성 인증을 위한 필수 요건이라고 봅니다. 제안이 개발됨에 따라 실험이 매우 중요할 것입니다. 또한 유연성은 최저 공통분모를 위해 추가 데이터를 전송하는 대신, 상황에 맞는 다양한 솔루션을 사용할 수 있게 해줍니다. Merkle Tree Certificates나 중간 인증서 생략(intermediate elision)과 같은 솔루션은 최신 상태의 클라이언트를 필요로 하기 때문입니다.
이러한 제약 사항, 우선순위 및 위험을 고려할 때, 현재 시점에서 양자 내성 PKI가 어떤 모습일지 정확히 정의하는 것보다 유연성을 확보하는 것이 더 중요하다고 믿습니다. 저희는 CA/Browser Forum을 통해 공개 웹 PKI용 X.509에 ML-DSA를 즉시 표준화하는 것에 반대합니다. NIST가 표준화를 완료하면 ML-DSA가 양자 내성 웹 PKI의 일익을 담당할 것으로 기대하지만, 저희는 우선 유연성에 집중하고 있습니다. 이는 인증서 크기, 핸드셰이크 지연 시간, 발급 투명성 및 관리되지 않는 엔드포인트에 대한 제약이 적고 보다 엄격한 양자 내성 타임라인을 가진 사설(Private) PKI에서 X.509의 옵션으로 ML-DSA를 도입하는 것을 배제하지는 않습니다.
궁극적으로 양자 내성 인증에 대한 모든 접근 방식에는 동일한 첫 번째 요구 사항, 즉 서버가 지원할 때 클라이언트가 양자 내성 보안 인증 메커니즘을 선택(opt-in)할 수 있는 마이그레이션 메커니즘이 필요하다고 생각합니다. 양자 내성 인증은 웹 생태계에 큰 도전 과제를 제시하지만, 트러스트 앵커 유연성이 이를 극복하고 더욱 안전하고 견고하며 성능이 뛰어난 양자 내성 웹으로 이끌어 줄 것이라 믿습니다.
참고 노트
[^1]: 드래프트 버전은 X25519Kyber768로, 기존 암호 알고리즘인 X25519와 양자 내성 알고리즘인 Kyber 768의 조합입니다. Kyber는 ML-KEM으로 명칭이 변경되고 있으나, 이 포스팅에서는 TLS를 위해 정의된 하이브리드 알고리즘을 지칭하기 위해 "Kyber"라는 용어를 사용합니다. [^2]: NIST와 IETF의 표준이 아직 완료되지 않았으므로, 이는 나중에 제거되고 최종 버전으로 교체될 예정입니다. 표준화의 현 단계에서는 얼리 어답터들만 이 기본 알고리즘을 사용할 것으로 예상합니다. [^3]: 실제로는 두 가지 이상의 형태로 존재하지만, 조직적 관점에서 볼 때 다른 Let's Encrypt 인증서에 의해 서명된 버전과 Let's Encrypt와는 완전히 별개의 인증 기관인 IdenTrust에 의해 서명된 버전이 존재합니다. [^4]: 체인 길이는 루트 인증서와 리프(leaf) 인증서를 포함합니다. 바이트 수는 네트워크를 통해 전송되는 크기이므로 리프 인증서는 포함되지만 루트 인증서는 포함되지 않습니다.
게시자: David Adrian, Bob Beck, David Benjamin, Devon O'Brien