要約

  • RFC 10024は、ML-KEMと従来型の楕円曲線鍵確立を組み合わせるTLS 1.3グループとして、X25519MLKEM768、SecP256r1MLKEM768、SecP384r1MLKEM1024を定義した。
  • 鍵合意が生成するセッション秘密と、証明書チェーンおよびCertificateVerify署名が示すサーバー認証は別の証拠である。前者の移行だけで後者は耐量子化されない。
  • Bas WesterbaanはKrzysztof Kwiatkowski、Panos Kampanakis、Douglas Stebilaとの共著者だ。このRFCは移行の一工程を検証可能にするもので、全経路の保証書ではない。

暗号移行の進捗を一つの百分率で示すと、最も早く導入できた部品がシステム全体を代表してしまう。TLSでは特に危険だ。一つのハンドシェイクに、鍵の確立、相手の認証、暗号化通信の開始が並ぶため、画面上は一度の成功に見えるからである。

2026年8月にIETF Proposed StandardとなったRFC 10024は、そのうち鍵合意を対象にする。X25519とML-KEM-768、secp256r1とML-KEM-768、secp384r1とML-KEM-1024をそれぞれ組み合わせ、クライアントとサーバーが二つの成分を含む共有秘密を得られるようにする。

想定する時間軸は長い。受動的な攻撃者は現在の暗号通信を保存し、将来、暗号学的に有効な量子計算機によって従来型の鍵確立を破れる日を待つかもしれない。PQ/Tハイブリッドは、セッション秘密の安全性を従来型または新しい耐量子成分の片方だけに依存させないための設計である。

ここまでが強い進歩であり、同時に境界でもある。

認証は同じハンドシェイクの別工程

TLS 1.3では、鍵交換の結果がキースケジュールに入り、通信鍵の材料になる。一方、証明書、信頼チェーン、CertificateVerify署名は、サーバーが信頼された証明書に対応する秘密鍵を持ち、ハンドシェイク記録を正しく署名したことを確認する。

同じtranscriptに結び付いていても、問いは異なる。「接続秘密をどの構成で作ったか」と「どの署名で誰を認証したか」は、同じ答えにならない。

RFC 9794は、この違いを用語の段階で固定している。PQ/Tハイブリッド鍵確立、ハイブリッドKEM、ハイブリッド公開鍵暗号、ハイブリッド電子署名は別々の方式群である。RFC 9935がML-KEM鍵のX.509識別子を定めても、それだけで証明書発行や信頼検証が普及するわけではない。KEMの識別子は署名アルゴリズムでもない。

攻撃者像も分ける必要がある。保存した通信を後日解読しようとする受動攻撃者には、ハイブリッド鍵合意が直接効く。将来、従来型署名を偽造してサーバーを装う能動攻撃者には、署名、証明書、発行、検証の移行が必要になる。量子時代という大分類は同じでも、対策の完了条件は異なる。

Westerbaanの仕事が示す段階性

Cloudflare ResearchはBas Westerbaanを、暗号エンジニアリングと標準化から大規模実験、導入まで、耐量子暗号の普及を進めるResearch Engineerと説明している。IETFの記録にはRFC 10024を含む耐量子関連の文書が並ぶ。

ただし、RFCの著者は一人ではない。Krzysztof Kwiatkowski、Panos Kampanakis、Douglas Stebilaも共著者であり、RFC 9954の一般的なハイブリッド交換設計、RFC 9794の用語、TLS 1.3、NIST FIPS 203のML-KEMに支えられている。Westerbaanを追う意味は、標準から実装・運用までの連続性を見ることであって、集団成果を個人に集約することではない。

Cloudflareが2025年9月に公表した導入記事は、段階移行を具体的に示した。同社ネットワークに届く人間生成トラフィックの3分の1超が、TLS 1.3のハイブリッド耐量子鍵合意を使っていた。その一方で、耐量子署名と証明書はTLSおよびインターネットPKIでの利用に向けて標準化中で、WARPは当時まだ導入していないと説明した。

この数字はCloudflare自身の時点付き観測であり、世界全体の普及率ではない。その後の全構成や内部経路を証明するものでもない。しかし、一つの暗号工程が大規模運用に達しても、隣の工程が従来型のまま残り得ることは明確に示す。

観測できたことを広げすぎない

クライアントがsupported_groupsにRFC 10024のグループを載せたなら、利用可能性や希望は分かる。実際に選択されたかは分からない。サーバーが選択したなら、観測した接続の合意内容は分かる。実装の欠陥、乱数、サイドチャネル、見えないフォールバックまでは分からない。

ハンドシェイク完了は、両端が使用可能な通信鍵を作ったという運用証拠を追加する。認証を評価するには証明書チェーンと署名方式が必要だ。経路を評価するにはTLS終端、リバースプロキシ、オリジン接続、セッション再開、0-RTT、トンネルを確認しなければならない。

復号後のデータはさらに別管理になる。ログ、データベース、キュー、バックアップは独自の鍵や保存期間を持つ。証明書失効、セッションチケット、アプリケーション秘密、保存時暗号化の復旧も、公開エンドポイントの鍵合意からは推定できない。

RFC 10024自身も、同じようなハイブリッド化を他プロトコルに移して安全だと仮定しないよう警告する。結合方法、長さ、順序、transcript、脅威モデルが安全性を左右する。二つのアルゴリズムを並べるだけでは標準の分析を再現できない。

またRFC 9851はTLS 1.2の機能追加を凍結し、新機能をTLS 1.3へ向ける。正しい世代へ移る方針は重要だが、証明書、ハードウェア、プロキシ、保存データを同時に更新するものではない。

「耐量子」を再現可能な記録にする

Heng LuのRunning-Code Primacyを当てはめると、宣言ではなく実際の結果を保存すべきだと分かる。必要なのは、クライアント、接続先、時刻、TLS版、提示・選択されたグループ、実装版、証明書チェーン、CertificateVerify署名方式、終端位置、再開、下流保護、平文になる境界を結んだ記録である。

測定方法と見えない範囲も欠かせない。外部プローブは内部のサービス間接続を見られない。エッジのログはクライアント実装を完全には証明しない。限界を書くことで、観測は将来再現できる。

責任の所在も明確になる。IETFは仕組みを定義し、ブラウザーと暗号ライブラリーは実装し、運用者は設定し、認証局は発行し、ネットワークは終端と中継を管理し、アプリケーションは保存し、インシデント対応は失効と復旧を担う。

RFC 10024は「どこまで終わったか」を具体的に言える標準である。その価値を守るには、「まだ終わっていないのはどこか」も同じ精度で言わなければならない。

出典