Merkle Tree Certificatesによるポスト量子認証局の構築

ブラウザにアドレスを入力するとき、接続先が正しいウェブサイトであることをどのように確認できるのでしょうか。Web Public Key Infrastructure（Web PKI）は、不正なウェブサイトや悪意あるウェブサイトへ誘導されていないことを信頼できるよう支援する、複雑かつ分散したポリシープロトコルインフラ事業者のエコシステムです。過去数十年で、このエコシステムは大きく変化しました。そのひとつが透明性の追加です。すべての証明書を公開の証明書透明性ログに記録することが、現在では必須要件となっています。そして今、新たな課題に直面しています。量子コンピュータの到来が迫っており、2029年までにポスト量子（PQ）暗号への移行が求められています。

この移行は単純ではありません。ポスト量子暗号をインターネット規模の証明書にそのまま適用するだけでは、許容できないパフォーマンスの低下を招きます。この局面は、Web PKIへの新しいアプローチを必要としています。透明性を後付けではなく第一級の特性として扱い、ポスト量子署名を効率よくスケールさせる新しいシステムを設計するアプローチです。

業界全体で幅広い支持を得たのち、Merkle Tree Certificates（MTC）が進むべき道として浮上しました。今年、Chromeとの実験的な展開を成功させたCloudflareは、MTCの推進に全力で取り組んでいます。

本日、Cloudflareが認証局（CA）になるという発表をうけ、このCAがMTCの発行をサポートし、2027年初頭に向け、Chromeが新たに立ち上げたQuantum-resistant Root Storeへの組み込みを目指すことをお知らせできることを嬉しく思います。より良いインターネットの構築を支援するという使命の一環として、また最強の暗号化を無償で提供するというCloudflareの伝統に従い、標準的なMTC発行を無償で提供します。クラシック証明書とMTC発行の両方をサポートするCAを持つことで、デフォルトで利用可能な最も安全な認証方式を採用し、インターネット全体の大部分に対してスムーズかつ高性能なPQアップグレードパスを提供できます。

現在の信頼エコシステム

MTCがどのようにゲームを変えているかを理解するために、まず今日のウェブにおける信頼の仕組みについて説明します。

クライアント側では、ブラウザ（この場合「TLSクライアント」）がルートプログラムを維持しており、CAが信頼されるために従わなければならないポリシーのセットを規定しています。サーバー側では、CAが信頼されたゲートキーパーとして機能し、ドメインの所有権を検証し、ドメイン名とその所有権を示す公開鍵の結びつきを証明する証明書発行インフラを運用しています。

しかし、CAがルールを守っているかどうかをどのように確認するのでしょうか。ここで登場するのが証明書透明性（CT）です。CTは証明書の発行を公開的に監査可能にします。CAが証明書を発行する際、少なくとも2つの公開ログにその証明書を提出しなければなりません。Cloudflareは2016年からCTログのNimbusファミリーを運用しており、新たに静的CTログの新ファミリーであるRaioを立ち上げています。

CTエコシステムが証明書を公開閲覧可能にしていても、それが正しく発行されているとか安全に使用できるということを意味するわけではありません。モニタリングはこれを助け、ログの記録とドメイン所有者が期待するものを比較し、不審な活動を報告します。Cloudflareは2019年にCertificate Transparency Monitoringを開始し、最近一般提供を開始しました。また、Radar（旧称：Merkle Town）のCertificate Transparencyページで証明書に関する大規模な測定値を公開しています。

組織がPQ認証を使用するためにサーバーのアップグレードを開始するにつれ、証明書透明性モニタリングはポスト量子ダウングレードの可能性を検出するうえでさらに重要な役割を担うようになります。ドメインをポスト量子認証にアップグレードしたドメイン所有者は、クライアントが悪意あるダウングレードパスに陥らないよう、予期せず発行されたレガシー証明書がないかCTログを監視する必要があります。

この現在のシステムの問題の一部は、透明性が後付けで追加されたことで、スケーリングの問題が生じている点です。証明書は複数のログを通じて異なる形式で繰り返し記録されることが多く、モニターはすべてのログをダウンロードして処理しなければ発行の見逃しが生じます。これにはコストがかかり、インターネット規模で多様なログ事業者を増やすことを難しくします。当社の試算では、PQ署名によってCTログが保存しなければならないデータ量は40倍に膨らむ見込みです。このスケーリングの課題とそれに伴うインセンティブの不整合が、ポスト量子スケーリング問題の核心にあります。

ポスト量子のスケーリング問題

当社はポスト量子暗号のスケーリングの課題について詳しく論じてきましたが、要約すると、インターネット規模でサーバー認証をサポートするために、Web PKIはすべてのクライアントにすべてのサーバーの公開鍵を事前に読み込むことなく、約10億のTLSサーバーを認証しなければなりません。従来、CAは証明書チェーンを信頼配布メカニズムとして使うことでこの問題に対処してきました。しかし時間の経過とともに、鍵の失効チェックや証明書透明性といった追加要素が公開鍵と署名を増やし、一般的なTLSハンドシェイクで5つの署名と2つの鍵が必要となっています。PQ署名はクラシック署名の約40倍大きく、クライアント・CA・ログ・モニターが規模を拡大する際にコストのかかる大きなオーバーヘッドを生み出します。

Merkle Tree Certificates（MTC）が登場します。IETF PLANTSワーキンググループのドラフト仕様で、コンパクトかつ効率的なポスト量子証明書のアーキテクチャを記述しています。MTCは証明書を追記専用のMerkleツリーにまとめ、CAが多数の個別証明書ではなくそのツリーのルートに署名できるようにします。これにより、ブラウザやその他のクライアントは各証明書を個別に検証するのではなく、コンパクトな包含証明（暗号ハッシュのシーケンス）を用いて、署名されたツリーヘッドに対して証明書を検証できます。MTCの核心的なアイデアは「発行したものをログに記録するのではなく、ログに記録することで発行する」というものです。発行とログ記録を結びつけることで、透明性は後付けではなく運用上の必須要件となります。

再設計されたPKIにおける認証局の役割

当社は、CloudflareのCA創設の不可欠な一部として、MTC発行能力の構築を進めています。これは、新しいPQルートプログラムの要件を把握し、伝統的なCAの設備・運用・コンプライアンス機能を構築しながら、同時に発行とミラーリングのソフトウェアスタックを開発するという、決して小さくはない取り組みです。

利点は、この新しいポスト量子PKIの要件とアーキテクチャを初日から優先できることです。Cloudflareの価値観とグローバルネットワークにふさわしい形でセットアップを構築し、この新しい旅に踏み出す中で可能な限り透明であることを目指します。

MTCに向けて更新されたアーキテクチャを見てみましょう：

これを従来のCAエコシステムと比較すると、CAの責務はほぼ同じであることがわかります。ドメインの制御を検証し、公開鍵に結びつけ、証明書を発行することです。主な違いは、MTCエコシステムでは証明書に直接署名してからログに記録するのではなく、CAがMerkleツリーによって支えられた透明性ログを維持し、証明書がツリーに確かに含まれているという包含証明が信頼アンカーとして機能する点です。CAはまた、発行ログのコピーを保存し、その追記専用の一貫性を検証し、より広いエコシステムに対してこれらのログの透明性と可用性を確保するミラーリング共同署名者も運用します。

MTCの発行

MTCには2つの形式があり、いずれも今日のクライアントソフトウェアが認識するX.509証明書フォーマットでエンコードできます。ただし「特殊な」署名アルゴリズムを使用します。スタンドアロン形式では、証明書の署名値に発行ログの共同署名されたツリーヘッドと、証明書がそのログに含まれていることを示す包含証明（ハッシュのシーケンス）が含まれます。クライアントが帯域外で共同署名されたツリーヘッドを取得できる場合（例：ブラウザのアップデート機能を通じて）、証明書は代わりにランドマーク相対形式で提供でき、署名値は重いポスト量子署名を一切含まない軽量な包含証明だけで構成されます。

簡単のため、スタンドアロン証明書の発行例を見てみましょう。ウェブサイトがドメインの証明書を必要とする場合、証明書リクエスト・ドメイン制御検証・発行ワークフローを処理するAutomatic Certificate Management Environment（ACME）プロトコルを通じてCAにリクエストできます。CloudflareのACMEインフラは、Let's Encryptを動かす広く展開され実績のあるACMEソフトウェアBoulderのフォークになります。Let's EncryptはBoulderで積極的にMTCサポートを開発しており、当社はこれらのアップストリームの変更とCloudflare固有の修正を取り込んだ独自のフォークを維持し、可能な限りアップストリームに貢献する予定です。

MTC CAが証明書発行リクエストを受け取ると、CAのACMEサーバーがサーバーが実際にドメインを管理していることを確認します。これらの確認が通過すると、CAはそのデータをシリアライズして追記専用ログに追加します。

MTCエントリを発行ログに追加した後、CAはログの更新された状態を計算し、その状態に対してチェックポイントに署名します。このチェックポイントは、CAがその時点までにログのMerkleツリーに含まれるすべてのエントリを発行したことを証明します。

次にCAは、更新されたログの状態と新しいチェックポイントを信頼できる共同署名者に送ります。共同署名者はCAの発行ログのコピーを永続的に保存し、各新しい状態が追記専用であること、前のツリーと一貫していること、正しく形成されていることを確認します。この追加の共同署名により、クライアントとモニターは別の信頼できる当事者が同じログの状態を観察し、CAがエコシステムの異なる部分に発行の異なるビューを提示していないことを検証したという確信を得られます。また、CAの発行ログが利用できない場合でも発行された証明書がモニタリングに利用できることを保証します。

ChromeのQuantum-resistant Root Programドラフトポリシーでは、少なくとも2つの共同署名が義務付けられています。1つは独立した組織が運営するChrome認定のミラーリング共同署名者からのもの、もう1つは発行するMTC CA自身からのものです。そのため、当社は他のパイロットCAのミラーを運用し、自分たちが発行した証明書に対して少なくとも1つの独立した共同署名を要求します。

Cloudflareは、オープンソースのRustベース透明性ログであるAzulにミラーリング共同署名者を実装し、最大限の相互運用性を実現するためにc2spのtlogミラープロトコルを実装します。

最終的に、ミラーリング共同署名者から共同署名を正常に受け取った後、CAは共同署名・サーバーの公開鍵・包含証明を含むMTCを構成します。そのMTCをサーバーに送信し、サーバーはそれ以降TLSに使用できます。

PQ署名の効率的な配信：ランドマーク最適化

スタンドアロン証明書は機能しますが、TLSハンドシェイクでまだ大きなPQ署名を送信するため、効率が制限されます。MTCの設計が提供する真のパフォーマンス向上は、ランドマーク相対証明書にあります。

すべての証明書に共同署名を送信する代わりに、CAはログ内のすべてのアクティブな証明書をカバーするサブツリーのシーケンスをランドマークとして指定します。それらのサブツリー（それらを認証するデータとともに）は、帯域外更新サービスを通じてクライアントに配布することが可能です。TLSハンドシェイク中、サーバーへの実際の認証は、ブラウザがサーバーの証明書データ（ドメイン名と公開鍵を含む）がCAのログの信頼されたサブツリーに現れているかを確認することで行われます。包含証明がその証明書を共同署名されたランドマークに接続し、公開鍵がTLSハンドシェイク中に所有権を証明すると、クライアントは正しいサーバーと通信していることを確認できます。

これらの署名とツリーのメタデータをTLSクライアントに定期的に帯域外で送信することで、少数のMTCバッチ署名で特定のCAが発行した数十億の証明書を効率的にカバーできます。ランドマークは規模においてより効率的ですが、スタンドアロンMTCの必要性をなくすわけではありません。クライアントが新しくインストールされた場合や、オフラインの場合、または関連するランドマークの更新がない場合があります。そのため、サーバーがスタンドアロン証明書のフォールバックを保持することが重要です。

実際のMTC：Chromeとの実験結果

今年、当社はクライアントとサーバー間のMTCの実現可能性をテストするためにChromeとの実験を実施しました。Cloudflareの「無料」プランのCloudflareドメインの選択に対してトラジショナルな証明書チェーンによって支えられたMTCを発行する「ブートストラップCA」（発行パイプラインをスタブ化したフェイクCA）を運用し、ChromeBeta146の50%のユーザーに提供しました。実験の過程で、当社は数十億のMTCを正常に提供しました。

TLSについては、一般的なケースがかなり効率的であることがわかりました。ランドマーク相対証明書では、ハンドシェイクは1つの公開鍵、1つの署名、1 kB未満の包含証明だけを送信する必要があります。実験では、クライアントとランドマーク相対証明書を交渉できなかった場合に、スタンドアロン証明書を提供する代わりにトラジショナルな証明書チェーンにフォールバックしました。CT側では、MTCは透明性のスケーリング特性も変えます。ログは公開鍵のハッシュのみを保持する必要があり、エントリごとの署名はなく、ツリーヘッドの署名がログ全体をカバーします。これにより証明書の爆発が防がれます。CAの発行ログがCAが発行するすべての証明書の真実の源であり、ログの消費者は各証明書の単一のコピーを取得するだけで済むからです。

結果：MTCは本当に機能します！中央値では、ランドマークMTCを使用することはクラシック署名チェーンよりも9%高速です（確かに、このパフォーマンス利点の大部分は中間省略によるものです）。クラシック署名でMTCをテストしたため、ポスト量子署名ではさらに大きな改善が期待されます。これらの結果と、IETFのPLANTSWGでのMTCに関する業界横断的なコラボレーションに満足し、先月（2026年8月）に実験の終了を開始しました。

MTCの今後の展望

Chromeとの実験がMTCが実際に機能することを示したことを嬉しく思い、実際のCAとして証明書を発行できることに特に興奮しています。

しかし、PKIエコシステム全体でこの大きな実験を実施することでしか答えられない、より広い疑問が残っています。独立したモニターは本番規模でMTC発行ログを消費・検証 できるでしょうか。複数のCAと共同署名者が登場し、システムに回復力のために必要な多様性をもたらすでしょうか。ブラウザはコンパクトなランドマークMTCのパフォーマンス上の利点と、新鮮なランドマークがないクライアントに必要なフォールバックパスをどのようにバランスさせるべきでしょうか。MTCはポスト量子認証の権威ある設計として浮上しましたが、本番のインターネット規模で証明するには、多様なルートプログラム・ブラウザベンダー・CA・ミラー・モニター・より広いコミュニティの参加が必要です。

当社はWeb PKIのこの次のフェーズに参加する機会を名誉と考え、CAインフラを運営する責任を真剣に受け止めています。CAは信頼エコシステムにおいて特権的な位置を占めており、ブラウザ・ドメイン所有者・一般の人々は、アイデンティティを正確に検証し、署名鍵を保護し、ポリシーを遵守し、信頼性を持って運用することに依存しています。CloudflareのCAがMTCを発行するためにブラウザから信頼される前に、ChromeのQuantum Resistant Root Storeへの申請と厳格な評価プロセスを経る必要があります。当社はその精査を歓迎し、インターネットの安全を支援するために信頼されている他のどのCAとも同じ高い基準を自分たちに課すことを期待しています。他のCAがMTCの採用をサポートするために登場することを望んでおり、MTCを展開したいすべてのブラウザとの協力を楽しみにしています。