セキュリティ15分で読める

Google Chromeに量子耐性証明書「Merkle Tree Certificates」導入へ

セキュリティChrome量子コンピュータ
加木谷 直俊ソース記事を見る

量子コンピュータの実用化が近づく中、Googleがインターネットのセキュリティ基盤を根本から作り変えようとしている。Google Chromeチームが開発したMerkle Tree Certificates（MTCs）は、現在のTLS/SSL通信で使われているX.509証明書の署名チェーンを、軽量なMerkle Tree証明に置き換えるという野心的なプロジェクトだ。現在Cloudflareとフェーズ1のテストを実施中で、2027年Q3に本格運用を目指している。さらにGoogleは**Android 17にもML-DSA（格子暗号ベースのデジタル署名）**を搭載する計画を発表しており、モバイルを含むエコシステム全体で量子耐性を確保する戦略を進めている。

量子コンピュータがなぜ「今」脅威なのか

量子コンピュータによる暗号解読というと、まだ遠い未来の話に思えるかもしれない。しかしセキュリティ専門家が警告するのは**「Harvest Now, Decrypt Later（今収集して、後で解読する）」攻撃**だ。

これは、国家レベルの攻撃者が暗号化された通信データを現時点で大量に収集・保存し、将来の量子コンピュータの実用化を待って一気に解読するという手法だ。銀行取引、政府の機密通信、企業の知的財産——これらの暗号化データは、収集された時点では安全でも、10〜15年後に量子コンピュータで解読される可能性がある。

NIST（米国国立標準技術研究所）の推定では、**2030年代前半には暗号学的に関連のある量子コンピュータ（CRQC）**が出現する可能性があるとされている。つまり、今日暗号化して送信したデータの「賞味期限」は、あと5〜10年ということになる。

現在の暗号基盤の脆弱性

暗号方式用途量子コンピュータへの脆弱性
RSA-2048TLS証明書の署名Shorのアルゴリズムで解読可能
ECDSA（P-256）TLS証明書の署名Shorのアルゴリズムで解読可能
ECDH（X25519）鍵交換Shorのアルゴリズムで解読可能
AES-256データ暗号化Groverのアルゴリズムで半減（128ビット相当）
SHA-256ハッシュGroverで半減するが実用上は安全

RSAやECDSAといった現在主流の公開鍵暗号は、Shorの量子アルゴリズムにより理論的に解読可能だ。このため、証明書の署名を量子耐性のあるアルゴリズムに移行する必要がある。

Merkle Tree Certificates（MTCs）とは何か

従来のX.509証明書の課題

現在、Webブラウザがサーバーの身元を確認するために使われているのがX.509証明書だ。これは認証局（CA）の階層的な署名チェーンで成り立っている。ルートCA → 中間CA → サーバー証明書という3段階以上の署名チェーンを検証することで、「このサーバーは本物である」と確認する仕組みだ。

問題は、量子耐性のある署名アルゴリズム（ポスト量子暗号、PQC）に移行すると、署名サイズが爆発的に大きくなる点だ。NISTが2024年に標準化したML-DSA-65（旧CRYSTALS-Dilithium）の署名サイズは約2,500バイトで、従来のECDSA（64バイト）の約39倍になる。TLSハンドシェイクで複数の証明書と署名を送受信する必要があることを考えると、通信の遅延が大幅に増加してしまう。

以下の図は、従来のX.509証明書チェーンとMerkle Tree Certificatesの構造的な違いを示しています。MTCsでは署名チェーンの代わりにハッシュベースのMerkle証明を使うことで、量子耐性を確保しつつデータサイズを大幅に削減しています。

従来のX.509証明書チェーン（RSA/ECDSA署名、量子耐性なし）とMerkle Tree Certificates（ハッシュベース、量子耐性あり、サイズ削減）の構造比較

MTCsの仕組み

Merkle Tree Certificates は、この問題をエレガントに解決する。基本的なアイデアは以下の通りだ。

1. バッチ発行: 認証局が一定期間（例: 1時間ごと）に発行した証明書をまとめてMerkle Treeに格納する

2. Merkle Root署名: Merkle Treeのルートハッシュにのみ認証局が署名する。個々の証明書への署名は不要

3. Inclusion Proof（包含証明）: 個々のサーバーは、自分の証明書がMerkle Treeに含まれていることを証明する短いハッシュパス（Inclusion Proof）をブラウザに送る

4. ブラウザでの検証: ブラウザはInclusion Proofを使ってMerkle Rootまでハッシュを辿り、事前に取得したMerkle Root（認証局が署名済み）と一致することを確認する

この仕組みにより、TLSハンドシェイクで送信するデータは数百バイトのハッシュパスのみとなり、巨大なPQ署名を毎回送信する必要がなくなる。ハッシュ関数（SHA-256など）は量子コンピュータに対しても十分な耐性を持つため、安全性も確保される。

証明書方式の技術比較

項目X.509 + RSA-2048X.509 + ML-DSA-65Merkle Tree Certificates
署名/証明サイズ256バイト~2,500バイト~数百バイト（ハッシュパス）
検証速度基準値3〜5倍遅い2倍以上高速
量子耐性なしありあり
帯域使用量中程度大（約10倍）小（最小）
CAの署名負荷証明書ごと証明書ごとバッチごと（大幅削減）
証明書透明性CT Log必要CT Log必要Merkle Tree自体が透明性を保証

Cloudflareとのフェーズ1テスト

Googleは現在、世界最大級のCDNプロバイダーであるCloudflareと共同でフェーズ1テストを実施中だ。Cloudflareは全インターネットトラフィックの約20%を処理しており、MTCsの実用性を検証するには最適なパートナーと言える。

テストの具体的な内容

  • **Chrome Canary（開発版）**でMTCsの検証ロジックを実装
  • Cloudflareが管理するドメインの一部でMTCsを試験的に発行
  • 従来のX.509証明書とのデュアル発行（両方の証明書を並行して発行し、対応ブラウザにはMTCsを、非対応ブラウザにはX.509を提供）
  • TLSハンドシェイクのレイテンシ、帯域使用量、エラー率を計測

Cloudflare CTO John Graham-Cummingは「MTCsは証明書の未来だと確信している。テスト結果は非常に有望で、レイテンシの削減効果は想定を上回っている」とコメントしている。

導入ロードマップ——2027年Q3に本格運用

以下の図は、Merkle Tree Certificatesの導入ロードマップを示しています。フェーズ1（テスト）からフェーズ3（本格運用）まで約1年半の計画で、段階的に対応範囲を拡大していきます。

Merkle Tree Certificates導入ロードマップ。2026年Q1-Q2でCloudflareとテスト、Q3-Q4で主要CAが参加しChrome安定版に実装、2027年Q1-Q3で本格運用開始

フェーズ1: テスト（2026年Q1〜Q2）

  • Cloudflareとの共同テスト
  • Chrome Canaryでの検証実装
  • パフォーマンスデータの収集と分析
  • IETF（インターネット技術タスクフォース）にドラフト仕様を提出

フェーズ2: パイロット（2026年Q3〜Q4）

  • Let's Encrypt、DigiCertなど主要認証局がMTC発行に対応
  • Chrome安定版にMTCサポートを実装（フラグ付き）
  • FirefoxおよびSafariの開発チームへ仕様を提案
  • WebPKI（Web Public Key Infrastructure）コミュニティでのレビュー

フェーズ3: 本格運用（2027年Q1〜Q3）

  • X.509証明書との並行運用を開始
  • Android 17にML-DSA署名検証を搭載
  • 全主要ブラウザでのMTCサポートを目標
  • 段階的にMTCs優先、X.509をフォールバックに移行

Android 17とML-DSAの統合

Googleの量子耐性戦略はブラウザだけにとどまらない。Android 17には**ML-DSA（Module-Lattice-Based Digital Signature Algorithm）**が搭載される予定だ。これにより、Androidスマートフォンでも量子耐性のある証明書検証が可能になる。

ML-DSAはNISTが2024年に標準化したポスト量子暗号署名アルゴリズムで、格子問題の計算困難性に基づいている。従来のRSAやECDSAとは異なり、量子コンピュータのShorアルゴリズムでは破れない。

Android 17での実装ポイントは以下の通りだ。

  • TLS 1.3のPQ鍵交換: ML-KEM（格子暗号ベースの鍵カプセル化）をサポート
  • PQ署名検証: ML-DSA-65によるサーバー証明書の署名検証
  • ハイブリッドモード: 従来のECDSAとML-DSAの両方で署名された証明書を検証可能
  • Conscrypt（AndroidのTLSライブラリ）のアップデート: PQC対応のBoringSSLバックエンドを統合

他ブラウザ・OSの動向

ブラウザ/OS量子耐性への対応状況MTCsへの対応
ChromeML-KEM鍵交換を実装済み、MTCs開発中フェーズ1テスト中
FirefoxML-KEM鍵交換をNightly版で実装仕様レビュー段階
SafariPQC対応はiOS 19/macOS 16で予定未対応（検討中）
EdgeChromiumベースのため、Chrome追従Chrome追従予定
AndroidAndroid 17でML-DSA搭載予定Chrome Android経由で対応
iOSiOS 19でPQC対応予定（Apple発表）Safari次第
WindowsWindows 12でPQC TLSサポート発表Edge経由で対応

日本ではどうなるか

日本のWeb環境への影響

日本のWeb環境にとって、MTCsの導入は以下の観点で大きな影響がある。

1. 認証局への影響: 日本国内の認証局（SECOM Trust Systems、JPRS、GlobalSignなど）は、MTCs対応のインフラ整備が必要になる。特にMerkle Treeのバッチ発行・管理システムの構築は大きな技術的課題だ。

2. 政府系システムの対応: マイナンバーカードのJPKI（公的個人認証サービス）はRSA-2048およびECDSAを使用している。量子耐性への移行は日本のデジタル庁にとって喫緊の課題となる。政府認証基盤（GPKI）も同様にPQC移行が求められる。

3. 金融システム: 全銀システムやFISCの安全対策基準はRSA/ECDSAベースの暗号を前提としており、PQC移行には基準改定が必要だ。メガバンクのオンラインバンキングも影響を受ける。

4. 企業のSSL/TLS証明書管理: 日本企業が利用しているSSL/TLS証明書の多くは年間更新だ。MTCs移行期間中は、従来の証明書とMTCsの両方に対応する必要があり、証明書管理コストが一時的に増加する可能性がある。

日本企業が今すべきこと

NISTのPQC標準化は2024年に完了しているが、日本国内ではまだ対応が進んでいない組織が多い。以下のステップで準備を始めるべきだ。

  1. 暗号資産の棚卸し: 自社システムで使用している暗号アルゴリズム（RSA、ECDSA、AESなど）を一覧化する
  2. 「Harvest Now, Decrypt Later」リスクの評価: 自社が扱うデータのうち、10年以上の機密性を求められるものを特定する
  3. PQC移行計画の策定: NISTが標準化したML-KEM、ML-DSAへの移行タイムラインを設定する
  4. ベンダーとの対話: SSL/TLS証明書ベンダー、クラウドプロバイダーに対し、MTCsおよびPQC対応の計画を確認する

まとめ——ポスト量子時代のWeb標準が動き出した

Googleが推進するMerkle Tree Certificatesは、「量子コンピュータの脅威に備える」という受動的なセキュリティ対策を超え、TLSの高速化とセキュリティ強化を同時に実現する革新的なアプローチだ。以下のアクションステップを参考にしてほしい。

  1. 情報追跡: Google Security Blog、Cloudflare Blog、IETF MTCsドラフトをウォッチリストに追加し、フェーズ2以降の進捗を追う
  2. 自社の暗号棚卸し: RSA/ECDSAに依存しているシステムの一覧を作成し、PQC移行の優先度を決める
  3. PQCテスト環境の構築: BoringSSLやOpenSSL 3.xのPQCブランチを使って、自社システムでのPQ鍵交換・署名検証をテストする
  4. ブラウザアップデートの確認: Chrome Canaryの最新版でMTCsの動作を確認し、自社サイトとの互換性を検証する
  5. 業界コミュニティへの参加: JPCERT/CC、CRYPTREC（暗号技術評価委員会）の情報を定期的にチェックし、日本国内のPQC移行ガイドラインに備える

量子コンピュータの実用化は「もし」ではなく「いつ」の問題だ。準備を始めるのは今しかない。

この記事をシェア

XはてブLinkedIn

「セキュリティ」カテゴリの記事

「セキュリティ」の記事をもっと見る

関連記事

新着記事