Merkle Tree Certificates로 양자 내성 인증 기관 구축하기

브라우저에 주소를 입력할 때, 올바른 웹 사이트에 연결하고 있다는 것을 어떻게 알 수 있을까요? 웹 공개 키 인프라(Web PKI)는 잘못되거나 악의적인 웹 사이트로 유도되지 않는다고 신뢰할 수 있도록 도와주는, 정책, 프로토콜, 인프라 운영자들로 이루어진 복잡하고 분산된 에코시스템입니다. 지난 수십 년간 이 에코시스템은 큰 변화를 겪었습니다. 그중 하나는 투명성의 추가입니다. 모든 인증서를 공개 인증서 투명성 로그에 기록해야 한다는 의무 요건이 생겼습니다. 이제 또 다른 과제에 직면해 있습니다. 양자 컴퓨터의 등장이 임박함에 따라 Cloudflare는 2029년까지 양자 내성(PQ) 암호화로 업그레이드하기로 했습니다.

이 전환은 간단하지 않습니다. 인증서에 양자 내성 암호화를 인터넷 규모로 단순히 적용하면 허용할 수 없는 수준의 성능 저하가 발생합니다. 지금이야말로 Web PKI에 대한 새로운 접근이 필요한 때입니다. 투명성을 부가 기능이 아닌 기본 내장 속성으로 다루고, 양자 내성 서명을 효율적으로 확장할 수 있는 새로운 시스템을 설계해야 합니다.

업계 전반의 폭넓은 지지를 받은 끝에 Merkle Tree Certificates(MTC)가 앞으로 나아갈 길로 부상했습니다. 올해 Chrome과의 성공적인 실험적 배포를 마친 Cloudflare는 MTC 추진에 전력을 다하고 있습니다.

오늘 Cloudflare가 인증 기관(CA)이 된다는 발표와 함께, 이 CA가 MTC 발급을 지원할 것임을 알리게 되어 기쁩니다. 2027년 초 Chrome이 새로 출시한 Quantum-resistant Root Store에 포함되는 것을 목표로 하고 있습니다. 더 나은 인터넷 구축을 돕는다는 Cloudflare의 사명의 일환으로, 현재 사용할 수 있는 가장 강력한 암호화를 무료로 제공해 온 전통에 따라 Cloudflare는 표준 MTC 발급을 무료로 제공할 예정입니다. 클래식 인증서와 MTC 발급을 모두 지원하는 CA를 보유함으로써 기본적으로 가장 안전한 인증 방식을 채택하고, 인터넷의 많은 부분에 원활하고 성능이 뛰어난 PQ 업그레이드 경로를 제공할 수 있습니다.

현재의 신뢰 에코시스템

MTC가 어떻게 판도를 바꾸고 있는지 이해하기 위해, 오늘날 웹에서 신뢰가 어떻게 작동하는지 배경부터 살펴보겠습니다.

클라이언트 측에서 브라우저(이 경우 “TLS 클라이언트”)는 신뢰받기 위해 CA가 준수해야 하는 정책 세트를 규정하는 루트 프로그램을 유지합니다. 서버 측에서는 CA가 신뢰받는 게이트키퍼 역할을 합니다. CA는 도메인 소유권을 검증하고, 도메인 이름과 그 소유권을 증명하는 공개 키가 서로 연결되어 있음을 보증하는 인증서 발급 인프라를 운영합니다.

하지만 CA가 규칙을 잘 따르고 있는지 어떻게 확인할까요? 여기서 등장하는 것이 인증서 투명성(CT)으로, 인증서 발급을 공개적으로 감사할 수 있게 합니다. CA가 인증서를 발급하면 최소 두 개의 공개 로그에 해당 인증서를 제출해야 합니다. Cloudflare는 2016년부터 Nimbus CT 로그 패밀리를 운영해 왔으며, 새로운 정적 CT 로그 패밀리인 Raio를 출시하고 있습니다.

CT 에코시스템이 인증서를 공개적으로 볼 수 있게 하지만, 그렇다고 인증서가 올바르게 발급되었거나 안전하게 사용할 수 있다는 의미는 아닙니다. 모니터링은 해당 로그 기록을 도메인 소유자가 예상한 것과 비교하고 의심스러운 활동을 보고함으로써 이를 돕습니다. Cloudflare는 2019년에 Certificate Transparency Monitoring을 처음 선보였으며 최근 정식 출시했습니다. 또한 Radar의 Certificate Transparency 페이지(이전 명칭: Merkle Town)에서 인증서에 관한 대규모 측정 데이터를 공개합니다.

조직이 PQ 인증을 사용하기 위해 서버 업그레이드를 시작하면서, 인증서 투명성 모니터링은 양자 내성이 기존 방식으로 다운그레이드될 가능성을 감지하는 데 더욱 중요한 역할을 담당하게 됩니다. 도메인을 양자 내성 인증으로 업그레이드한 도메인 소유자는 클라이언트가 악의적인 다운그레이드 경로로 돌아가지 않도록 예상치 못하게 발급된 레거시 인증서를 CT 로그에서 모니터링해야 합니다.

현재 시스템의 문제 중 일부는 투명성이 나중에 추가된 기능이어서 확장성 문제가 발생한다는 점입니다. 인증서는 여러 로그에 걸쳐 다양한 형태로 여러 번 기록되는 경우가 많아, 모니터는 발급을 놓치지 않기 위해 모든 로그를 다운로드하고 처리해야 합니다. 이는 비용이 많이 들 수 있으며, 인터넷 규모에서 다양한 로그 운영자를 장려하기 어렵게 만듭니다. Cloudflare의 추정에 따르면, “PQ 서명은 CT 로그가 저장해야 하는 데이터 양을 40배로 늘릴 것”입니다. 이러한 확장성 과제와 그에 따른 인센티브 불일치가 양자 내성 확장성 문제의 핵심입니다.

양자 내성 확장성 문제

Cloudflare는 양자 내성 암호화 확장의 과제를 여러 차례 자세히 다뤄 왔습니다. 요약하자면 다음과 같습니다. 인터넷 규모에서 서버 인증을 지원하려면 Web PKI가 모든 클라이언트에 모든 서버의 공개 키를 미리 로드하지 않고도 약 10억 개의 TLS 서버를 인증해야 합니다. 전통적으로 CA는 인증서 체인을 신뢰 배포 메커니즘으로 사용하여 이 문제를 해결해 왔습니다. 그러나 시간이 지나면서 키 해지 확인 및 인증서 투명성 같은 추가 요소들이 더 많은 공개 키와 서명을 더했습니다. 일반적인 TLS 핸드셰이크에서 다섯 개의 서명과 두 개의 키가 필요합니다. PQ 서명은 클래식 서명보다 약 40배 크기 때문에, 클라이언트, CA, 로그, 모니터가 대규모로 처리하기에는 비용 부담이 큰 오버헤드가 발생합니다.

여기서 등장하는 것이 Merkle Tree Certificates(MTC)입니다. MTC는 IETF PLANTS 워킹 그룹의 초안 사양으로, 컴팩트하고 효율적인 양자 내성 인증서를 위한 아키텍처를 설명합니다. MTC는 인증서를 추가 전용 Merkle 트리에 일괄 처리하여, CA가 많은 개별 인증서 대신 해당 트리의 루트에 서명할 수 있게 합니다. 이를 통해 브라우저나 다른 클라이언트가 각 인증서를 개별적으로 검증하는 대신, 서명된 트리 헤드에 대해 컴팩트한 포함 증명(암호화 해시 시퀀스)을 사용하여 인증서를 검증할 수 있습니다. MTC의 핵심 아이디어는 “발급한 것을 기록하지 말고, 기록함으로써 발급하라”입니다. 발급과 로깅을 결합함으로써, 투명성은 부가 기능이 아닌 운영 요건이 됩니다.

재설계된 PKI에서 인증 기관의 역할

Cloudflare는 Cloudflare CA 창설의 핵심 과제로 MTC 발급 역량을 구축하고 있습니다. 이는 새로운 PQ 루트 프로그램 요건을 파악하고, 전통적인 CA의 시설, 운영, 컴플라이언스 기능을 구축하는 동시에 발급 및 미러링 소프트웨어 스택을 개발하는 것을 의미합니다. 결코 작은 일이 아닙니다!

장점은 처음부터 이 새로운 양자 내성 PKI의 요건과 아키텍처를 우선시하고, Cloudflare의 가치와 글로벌 네트워크에 부합하는 방식으로 설정을 구축할 수 있다는 것입니다. 이 새로운 여정을 시작하면서 가능한 한 투명하게 운영하는 것을 목표로 합니다.

MTC에 맞게 업데이트된 아키텍처를 살펴보겠습니다.

이것을 전통적인 CA 에코시스템과 비교하면, CA의 책임은 대체로 동일하게 유지됨을 알 수 있습니다. 도메인의 제어권을 검증하고, 공개 키에 바인딩하고, 인증서를 발급하는 것입니다. 주요 차이점은 MTC 에코시스템에서 CA가 인증서에 직접 서명한 후 기록하는 대신, 이제 Merkle 트리 기반의 투명성 로그를 유지한다는 것입니다. 인증서가 실제로 트리에 있다는 포함 증명이 신뢰 앵커 역할을 합니다. CA는 또한 발급 로그의 복사본을 저장하고, 추가 전용 일관성을 검증하며, 더 광범위한 에코시스템을 위해 이러한 로그의 투명성과 가용성을 보장하는 미러링 공동 서명자도 운영합니다.

MTC 발급

MTC는 두 가지 형태로 존재하며, 둘 다 오늘날 클라이언트 소프트웨어가 인식하는 X.509 인증서 형식으로 인코딩할 수 있습니다. 다만 “독특한” 서명 알고리즘을 사용합니다. 독립 실행형 형식에서는 인증서의 서명 값에 발급 로그의 공동 서명된 트리 헤드와 인증서가 해당 로그에 포함되어 있음을 증명하는 포함 증명(해시 시퀀스)이 포함됩니다. 클라이언트가 공동 서명된 트리 헤드를 대역 외 방식으로(예: 브라우저 업데이트 메커니즘을 통해) 얻을 수 있다면, 인증서는 대신 랜드마크 기준 형식으로 제공될 수 있습니다. 이 경우 서명 값은 무거운 양자 내성 서명이 전혀 없는 경량 포함 증명으로만 구성됩니다.

간단히 설명하기 위해 독립 실행형 인증서 발급 예시를 살펴보겠습니다. 웹 사이트가 도메인에 대한 인증서를 원할 때, 인증서 요청, 도메인 제어 유효성 검사, 발급 워크플로를 처리하는 Automatic Certificate Management Environment(ACME) 프로토콜을 통해 CA에 요청할 수 있습니다. Cloudflare의 ACME 인프라는 Let's Encrypt를 구동하는 광범위하게 배포되고 검증된 ACME 소프트웨어인 Boulder의 포크가 될 것입니다. Let's Encrypt는 Boulder에서 MTC 지원을 활발히 개발하고 있으며, Cloudflare는 이러한 업스트림 변경 사항과 Cloudflare 전용 수정 사항을 통합한 자체 포크를 유지하면서 가능한 경우 업스트림에 기여할 계획입니다.

MTC CA가 인증서 발급 요청을 받으면 CA의 ACME 서버는 요청한 서버가 실제로 해당 도메인을 제어하는지 확인합니다. 이러한 확인을 통과하면 CA는 해당 데이터를 직렬화하여 추가 전용 로그에 추가합니다.

MTC 항목을 발급 로그에 추가한 후, CA는 로그의 업데이트된 상태를 계산하고 해당 상태에 대한 체크포인트에 서명합니다. 이 체크포인트는 CA가 그 시점까지 로그의 Merkle 트리에 포함된 모든 항목을 발급했음을 증명합니다.

CA는 그런 다음 업데이트된 로그 상태와 새 체크포인트를 신뢰할 수 있는 공동 서명자에게 전송합니다. 공동 서명자는 CA의 발급 로그 복사본을 안정적으로 저장하고 각 새 상태가 추가 전용이며, 이전 트리와 일관성이 있고, 올바르게 형성되었는지 확인합니다. 이 추가적인 공동 서명은 클라이언트와 모니터에게 다른 신뢰할 수 있는 당사자가 동일한 로그 상태를 관찰했으며 CA가 에코시스템의 각 주체에게 서로 다른 발급 내역을 보여주고 있지 않음을 검증했다는 확신을 줍니다. 또한 CA 발급 로그를 사용할 수 없는 경우에도 발급된 인증서를 모니터링에 사용할 수 있도록 보장합니다.

Chrome의 Quantum-resistant Root Program 초안 정책은 최소 두 개의 공동 서명을 의무화합니다. 독립적인 조직이 운영하는 Chrome 인정 미러링 공동 서명자로부터 하나, 발급하는 MTC CA 자체로부터 하나입니다. 따라서 Cloudflare는 다른 파일럿 CA의 미러를 운영하고, Cloudflare가 발급하는 인증서에도 최소 한 개의 독립적인 공동 서명을 요구할 것입니다.

Cloudflare는 Cloudflare의 오픈 소스 Rust 기반 투명성 로그 Azul에 미러링 공동 서명자를 구현하고, 최대한의 상호 운용성을 위해 C2SP의 tlog 미러 프로토콜을 구현할 것입니다.

마지막으로 미러링 공동 서명자로부터 공동 서명을 성공적으로 수신한 후, CA는 공동 서명, 서버의 공개 키, 포함 증명으로 MTC를 구성합니다. 그런 다음 해당 MTC를 서버에 전송하고, 서버는 이후 이를 TLS에 사용할 수 있습니다!

PQ 서명의 효율적인 전달: 랜드마크 최적화

독립 실행형 인증서도 제대로 작동하지만, 여전히 TLS 핸드셰이크에서 큰 PQ 서명을 전송해야 하므로 효율성이 떨어집니다. MTC 설계가 제공하는 진정한 성능 개선은 랜드마크 기준 인증서에 있습니다.

모든 인증서에 공동 서명을 전송하는 대신, CA는 로그의 모든 활성 인증서를 포괄하는 하위 트리 시퀀스를 랜드마크로 지정하고, 대역 외 업데이트 서비스를 통해 해당 하위 트리(및 해당 하위 트리를 인증하기 위한 데이터)를 클라이언트에 배포할 수 있습니다. TLS 핸드셰이크 중 서버에 대한 실제 인증은 브라우저가 서버의 인증서 데이터(도메인 이름과 공개 키 포함)가 CA 로그의 신뢰할 수 있는 하위 트리에 나타나는지 확인함으로써 이루어집니다. 포함 증명이 해당 인증서를 공동 서명된 랜드마크에 연결하고, 공개 키가 TLS 핸드셰이크 중 키 소유를 증명하면, 클라이언트는 올바른 서버와 통신하고 있음을 알 수 있습니다.

이러한 서명과 트리 메타데이터를 대역 외로 TLS 클라이언트에 주기적으로 전송함으로써, 소수의 MTC 배치 서명만으로 특정 CA에서 발급한 수십억 개의 인증서를 효율적으로 커버할 수 있습니다. 랜드마크는 대규모 환경에서 더 효율적이지만, 독립 실행형 MTC의 필요성을 없애지는 않습니다. 클라이언트가 새로 설치되었거나 오프라인이거나 관련 랜드마크 업데이트가 없는 경우가 있기 때문입니다. 그래서 서버가 독립 실행형 인증서 폴백을 유지하는 것이 중요합니다.

실제 환경의 MTC: Chrome과의 실험 결과

올해 Cloudflare는 클라이언트와 서버 간 MTC의 실현 가능성을 테스트하기 위해 Chrome과 실험을 진행했습니다. Cloudflare의 Free 요금제를 사용하는 일부 Cloudflare 도메인에 대해 기존 인증서 체인 기반의 MTC를 발급하는 “부트스트랩 CA”(발급 파이프라인을 모의한 가짜 CA)를 운영하고, 발급된 MTC를 Chrome Beta 146 사용자의 50%에게 제공했습니다. 실험 과정에서 수십억 개의 MTC를 성공적으로 제공했습니다.

TLS의 경우, 일반적인 상황이 상당히 효율적임을 알았습니다. 랜드마크 기준 인증서를 사용하면 핸드셰이크는 하나의 공개 키, 하나의 서명, 1kB 미만의 포함 증명만 전송하면 됩니다. 실험에서 Cloudflare는 클라이언트와 랜드마크 기준 인증서를 협상할 수 없는 경우 독립 실행형 인증서를 제공하는 대신 전통적인 인증서 체인으로 폴백했습니다. CT 측면에서 MTC는 투명성의 확장성 속성도 변경합니다. 로그는 공개 키의 해시만 보유하면 되고, 항목별 서명이 없으며, 트리 헤드의 서명이 전체 로그를 커버합니다. CA 발급 로그가 CA가 발급하는 모든 인증서의 기준 원천이 되고 로그 소비자는 각 인증서의 사본 하나만 가져오면 되기 때문에 이 구조는 인증서 폭증을 방지합니다.

결과: MTC는 정말 작동합니다! 중앙값 기준으로 랜드마크 MTC는 클래식 서명 체인보다 9% 빠릅니다(물론 이 성능 향상의 대부분은 중간 인증서 생략 덕분입니다). 그리고 클래식 서명으로 MTC를 테스트했기 때문에, 양자 내성 서명을 사용하면 더 큰 개선이 기대됩니다. 이러한 결과와 IETF의 PLANTS 워킹 그룹(WG)에서 MTC에 대한 업계 전반의 협력 수준에 만족한 Cloudflare는 지난달(2026년 8월)부터 실험을 단계적으로 종료하고 있습니다.

MTC의 향후 전망

Chrome과의 실험이 MTC가 실제로 작동할 수 있음을 보여줬다는 것이 기쁘며, 실제 CA로서 인증서를 발급할 수 있게 되어 특히 기대가 큽니다.

그러나 전체 PKI 에코시스템으로 이 대규모 실험을 실행해야만 답할 수 있는 더 광범위한 질문들이 여전히 있습니다. 독립적인 모니터가 프로덕션 볼륨에서 MTC 발급 로그를 소비하고 검증할 수 있을까요? 시스템이 복원력에 필요한 다양성을 갖출 수 있도록 여러 CA와 공동 서명자가 등장할까요? 브라우저는 컴팩트한 랜드마크 MTC의 성능 이점과 최신 랜드마크가 없는 클라이언트에 필요한 폴백 경로 사이에서 어떻게 균형을 잡아야 할까요? MTC는 양자 내성 인증의 사실상 표준 설계로 부상했지만, 프로덕션 인터넷 규모에서 이를 입증하려면 다양한 루트 프로그램, 브라우저 벤더, CA, 미러, 모니터 , 더 광범위한 커뮤니티의 참여가 필요합니다.

Cloudflare는 Web PKI의 다음 단계에 참여할 기회를 영광으로 여기며, CA 인프라를 운영하는 책임을 진지하게 받아들입니다. CA는 신뢰 에코시스템에서 특권적인 위치를 차지합니다. 브라우저, 도메인 소유자, 일반 사용자 모두 CA가 신원을 올바르게 검증하고, 서명 키를 보호하며, 정책을 준수하고, 안정적으로 운영하리라 믿고 의지합니다. Cloudflare의 CA가 MTC를 발급하기 위해 브라우저로부터 신뢰받으려면, Chrome의 Quantum-resistant Root Store에 신청하고 엄격한 평가 과정을 거쳐야 합니다. Cloudflare는 이러한 검증을 환영하며, 인터넷 보안을 책임지는 다른 CA와 동일한 높은 기준을 스스로에게 적용할 것입니다. 다른 CA들이 MTC 채택을 지원하기 위해 등장하기를 바라며, MTC를 배포하려는 모든 브라우저와 협력하게 되기를 기대합니다.