TLS にポスト量子暗号を実装する上で考慮すべき事項
目次
2025 年 6 月 30 日、Akamai は、Transport Layer Security（TLS）バージョン 1.3 を使用した Ghost to Origin（G2O）接続でポスト量子暗号（PQC）のサポートを開始しました。現在、この新機能の可用性は限られています。早期に導入したお客様は、Akamai とオリジンサーバー間の接続を Harvest Now, Decrypt Later（HNDL）の脅威から保護する機能をご利用いただけます。
この機能は、2025 年 10 月 31 日に予定されている一般リリースで、すべてのオリジン TLS 接続で有効にする予定です。このリリースの準備として、実装について詳しくご説明します。Akamai が目指すのは、お客様が量子耐性のある未来への旅を始めるにあたり、どのような検討事項が役立つかを共有することで、お客様が未来に備え、この情報を有効活用していただけるよう支援することです。
ライブラリとツール
クライアント側またはサーバー側で相互運用する PQC を導入するためには、従来のポスト量子ハイブリッド方式を使用した最新の TLS 1.3 ハイブリッド鍵交換をサポートする TLS ライブラリまたはフレームワークが必要です。
OpenSSL のような一般的な暗号ライブラリが、新たに標準化されたポスト量子アルゴリズムのサポートを受けるようになったのはごく最近のことです。Akamai は独自の PQC プロバイダーを開発しただけでなく、同時にプラットフォーム全体のアップグレードに投資して、全体的に高度なクリプトアジリティを実現しました。
PQC を導入し、HNDL のアクティブな脅威に対抗するためには、柔軟性が不可欠です。同様に、必要なライブラリの更新を特定するために、インフラを評価する必要があります。
このブログ記事では、TLS 1.3 のハイブリッド鍵交換を採用する際の一般的な実装上の課題をいくつか紹介します。最新の OpenSSL ライブラリと BoringSSL ライブラリを例として使用しますので、量子耐性のある未来に備えるために役立てていただければと思います。
TLS 1.3 のハイブリッド鍵交換
このシリーズの以前のブログ記事では、次の内容を共有しました。
米国国立標準技術研究所（NIST）は、新しいポスト量子モジュール格子ベース・キー・カプセル化方式（ML-KEM）をどのように標準化したか
インターネット技術タスクフォース（IETF）は TLS 1.3 における導入の基礎をどのように構築したか
IETF は、主に X25519MLKEM768 グループを使用して、ハイブリッド ECDHE-MLKEM 鍵の契約を定めるドラフトをどのように採用したか
しかし、ハイブリッド鍵交換とは、実際にはどのようなものなのでしょうか。また、クライアントやサーバーの動作にどのような影響を与えるのでしょうか。PQC を導入する際には、従来のハンドシェイクとの比較や、クライアントとサーバーの間における動作の違いを理解することが重要です。
サンプル環境
ネットワーク上の TLS パケットを観察するためには、PQC をサポートする HTTP サーバーが必要です。Akamai では、Ubuntu Linode で nginx を使用して PQC を設定する方法を簡潔に説明したガイドをすでに公開しています。このガイドは、まさにその目的のための参考資料です。
このガイドに従って、サンプルサイト（https://pqc.example.com）を設定し、次に tcpdump と openssls_client コマンドを使用して TLS ハンドシェイクを調べることができます。
$ sudo tcpdump -w pqc.pcap host pqc.example.com >/dev/null 2>&1
$ </dev/null openssl s_client -tls1_2 -connect pqc.example.com:443
[...]
$ </dev/null openssl s_client -connect pqc.example.com:443
[...]
ここでは TLS ハンドシェイクのみに焦点を当てているため、実際の HTTP リクエストを行う必要はありません。2 回連続して接続し（1 回目は TLS 1.2 を使用し、次にデフォルトの TLS 1.3 を使用）、キャプチャされたパケットを調べて、鍵交換の違いを確認することができるようになりました。
TLS 1.2 と TLS 1.3 の鍵交換の違い
従来の TLS 1.2 ハンドシェイクでは、最初の openssl 呼び出しと同様、クライアントは TLS ClientHello でサポートされているすべての暗号スイートを示します。これには、各暗号スイートで使用される鍵交換アルゴリズムも含まれます。
たとえば、暗号スイート ECDHE-ECDSA-AES256-GCM-SHA384 は、鍵交換に Elliptic Curve Diffie-Hellman（ECDH）を使用することを指定します。一方、DHE-RSA-AES256-GCM-SHA384 の場合は、オリジナル（Finite Field）Diffie-Hellman の使用を指定します。supported_groups 拡張機能は、適切な鍵グループをアドバタイズしますが、それ以降の Client Key Exchange メッセージでは適切な公開鍵のみを送信します（図 1）。
Fig. 1: This Wireshark screenshot shows the details of the Client Key Exchange packets of a TLS 1.2 handshake, highlighting the public key provided by the client
対照的に、TLS 1.3 ハンドシェイクでは、鍵交換アルゴリズムの選択は暗号スイートの認証アルゴリズムから分離されます。クライアントは、ClientHello に key_hare 拡張子の一部として公開鍵を提供します（図 2）。
Fig. 2: This Wireshark screenshot shows the details of a TLS 1.3 handshake, highlighting the different key groups indicated alongside the two key shares immediately supplied in the key share extension
TLS ClientHello 互換性
上記のパケット分析では、クライアントが X25519MLKEM768 を使用して PQC をサポートし、スタンドアロンの X25519 鍵とハイブリッド鍵の両方を含むことがわかります。後者は、別の X25519 公開鍵と ML-KEM 公開鍵を連結したものです。 （私の個人的なブログでは、ハイブリッド鍵交換について詳細に説明しています。）
この鍵の組み合わせにより、ClientHello のバイト数が従来のアルゴリズムと比較して増加します（表）。
アルゴリズム |
公開鍵（バイト） |
|---|---|
X25519 |
32 |
RSA-2048 |
256 |
ML-KEM768 |
1,184 |
X25519MLKEM768 |
1,216 |
表：公開鍵サイズの比較
このようなサイズの拡大は、独自の課題を生み出します。特定の状況では、障害のあるサーバー実装が ClientHello を拒否することがあります。また、ClientHello ごとにこの大きなハイブリッド鍵を生成して送信することは、リモートサーバーが PQC をサポートしていない場合、CPU 使用率と帯域幅を浪費することになります。
このような非効率性を回避する方法の 1 つは、クライアントが両方の鍵グループをアドバタイズすることですが、ClientHello には 1 つの鍵共有のみを含めます。たとえば、クライアントが X25519 と X25519MLKEM768 の両方をアドバタイズするが、X25519 鍵共有のみを提供するとします。サーバーが PQC に対応しない場合は、提供された X25519 鍵を使用して接続を確立します。それ以外の場合は、 HelloRetryRequest を開始して、X25519MLKEM768 を選択し、追加のラウンドトリップを実行する必要があります。
または、クライアントがハイブリッド共有鍵のみを提供した場合、PQC をサポートしていないサーバーは X25519 コンポーネントを抽出し、従来の鍵交換に使用することはできないでしょうか？一見合理的なソリューションに思えるかもしれませんが、これは、特定のプリミティブは、その意図されたコンテキストでのみ使用するという暗号化の原則に違反することになります。ハイブリッド鍵共有のみを提供するクライアントとのクラシック鍵交換だけをサポートするサーバーは、クライアントからスタンドアロン X25519 鍵を要求するために HelloRetryRequest をトリガーする必要があります。
図 3 と図 4 の両方のオプションを並べて比較できます。
Fig. 3: Client-server communication requiring a HelloRetryRequest to use X25519MLKEM768 after the client only included the X25519 key share
Fig. 4: Client-server communication requiring a HelloRetryRequest to use X25519 after the client only included the X25519MLKEM768 key share
これらの問題を緩和するためには、拡大した ClientHello と、HelloRetryRequest を介して発生する追加のラウンドトリップの間のトレードオフとして、適切なアプローチを決定する必要があります。ブラウザーなどの一般的なクライアントでは、ClientHello を大きくすることを犠牲にして接続時間を短くすることを好みますが、これはアプリケーションに最適なアプローチではない可能性があります。
たとえば、長期間の永続的な接続を使用しているが、実際に PQC をサポートするサーバーが少ない場合、単一のクラシック鍵のみを提供し、サーバーが HelloRetryRequest を開始すると、ハイブリッド鍵グループをサポートすることもできます。これは、PQC サポートを明示的に示さないお客様のための G2O 接続に対する Akamai の長期的なアプローチです。
または、交信先のサーバーが PQC をサポートしていることがわかっている場合は、ClientHello でただちに X25519MLKEM768 のみを提供できます。これは Akamai の限定的な可用性フェーズでのアプローチであり、PQC サポートが一般的に利用可能になると、PQC サポートを明示的に示すお客様へのアプローチとなります。
openssl s_client コマンドを使用すると、これらのシナリオを簡単にシミュレートできますが、TLS ライブラリのマニュアルページをよく読んで、グループ設定の指定方法を把握しておくようにしてください。たとえば、OpenSSL の SSL_CTX_Set1_curves(3) では、X25519:X25519MLKEM768 を指定するとクライアントは X25519 鍵（ただし、その両方をアドバタイズする）のみを含む一方、X25519:*X25519MLKEM768（* を参照）には PQC ハイブリッド鍵のみが含まれます。両方を含めるには、*X25519:*X25519MLKEM768 を使用する必要があります。
一方、BoringSSL では、-curves オプションで指定されたすべての鍵が ClientHello に含まれます。つまり、コマンドラインクライアントは複数の鍵グループのアドバタイズをサポートしていませんが、1 つの鍵共有のみをサポートしています。
違いを確認するためには、次のコマンドを実行します。
$ sudo tcpdump -w pqc.pcap host pqc.example.com >/dev/null 2>&1
$ </dev/null openssl s_client -groups "X25519:X25519MLKEM768" \
-connect pqc.example.com:443
$ </dev/null openssl s_client -groups "X25519:*X25519MLKEM768" \
-connect pqc.example.com:443
$ </dev/null openssl s_client -groups "*X25519:*X25519MLKEM768" \
-connect pqc.example.com:443
$ </dev/null bssl client -curves "X25519:X25519MLKEM768" \
-connect pqc.example.com:443
結果のパケットキャプチャーで、最初の接続時にトリガーされた HelloRetryRequest が検出されますが、後続の接続では X25519MLKEM768 が ClientHello に即座に含まれます。最後の 2 つの接続には、両方の鍵グループが含まれます。
サーバーの場合、動作は再度異なります。サーバーはクライアントに応答しますが、不必要に鍵共有を送信しなくてもよいため、代わりに鍵グループを指定することで、ラウンドトリップを回避する優先順位のリストを伝えることができます。
このように、特定の環境に固有に構成されたクライアントまたはサーバーは、汎用クライアント（ブラウザーなど）やサーバー（CDN エッジサーバーなど）とは異なる優先順位と互換性モデルを持つ場合があります。
鍵交換を検証する
設定オプションとソフトウェア／ライブラリの組み合わせが非常に多いため、特定の接続でハイブリッド鍵交換が使用されているかどうかを簡単に識別できます。
クライアントを検証する
サーバーに接続しているクライアントが X25519MLKEM768 ハイブリッド鍵交換を使用していることを検証するために、サーバーは使用されている鍵交換アルゴリズムを抽出、記録、および反映することができます。これはサーバーによって異なり、さらに特定の TLS ライブラリによって異なります。
たとえば、nginx では、 $ssl_curve パラメータを FastCGI スクリプトに公開できます。OpenSSL ベースまたは BoringSSL ベースのサーバーでは、ssl_get_negotiated_group(3) 関数を使用できます。ただし、Python や Go などの一部の言語では、この情報は必ずしもすぐに利用できるとは限りません。
サーバーを検証する
特定のサーバーが PQC をサポートしているかどうかを確認する最も簡単な方法は、X25519MLKEM768 のみを使用して接続を試みることです。これには、上記の openssl s_client コマンドなど、鍵交換メカニズムの指定をサポートするクライアントが必要です。
詳細出力には、Negotiated TLS 1.3 Group が表示されます。
$ printf "GET / HTTP/1.1\r\nHost: pqc.example.com\r\nConnection: close\r\n\r\n" |
openssl s_client -ign_eof -curves X25519MLKEM768 \
-connect pqc.example.com:443
[...]
Peer signing digest: SHA256
Peer signature type: rsa_pss_rsae_sha256
Negotiated TLS1.3 group: X25519MLKEM768
[...]
New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
Protocol: TLSv1.3
[...]
同様に、普遍的な curl コマンドでは、--curves オプションを使って、使用する鍵交換メカニズムを指定できます。ただし、動作の詳細は、どの TLS ライブラリの curl に対して作成されたかによって異なります。
もちろん、PQC 接続を確認する最も簡単な方法は、ブラウザーを使用することだけです。2025 年 8 月現在、Firefox と Chrome の両方がデフォルトで X25519MLKEM768 をサポート、有効化、および提供しています。Safari はまだ PQC をサポートしていませんが、Apple は最近、macOS Tahoe 26 および iOS 26（2025 年秋にリリース予定）が PQC をサポートすることを発表しました。
鍵交換グループを表示するためには、［Developer Tools］→［Privacy and Security in Chrome］（図 5）、または Firefox の［Web Developer Tools］→［Network］→［Security］（図 6）を使用して TLS 接続の詳細を表示します。
Fig. 5: Chrome Developer Tools showing the use of X25519MLKEM768
Fig. 6: Firefox Web Developer Tools showing the use of X25519MLKEM768 by listing the keys in the order in which the hybrid key is constructed
飛躍的に安全な未来への移行
クライアントおよびサーバーアプリケーションで新しい TLS 1.3 ハイブリッド鍵交換を使用して PQC を実装する場合は、明らかに考慮すべき点が多くあります。
これらの課題の一部をサードパーティプロバイダーにオフロードできるかもしれませんが、それぞれの環境で新しい PQC 機能を検証およびテストできることが依然として重要です。この記事で紹介した例は、お客様とお客様のユーザーのデータを現在の量子脅威から守るのに役立ちます。Akamai は、G2O PQC の導入と活用をサポートし、お客様が飛躍的に安全な未来へ進んで行くお手伝いをします。
Akamai の段階的アプローチ：次のステップ
フェーズ 1：Akamai からオリジンへ
2025 年 6 月 30 日現在、Akamai は、X25519MLKEM768 ハイブリッド鍵共有によって HTTP/1 と HTTP/2 を使用するオリジンサーバーへの PQC をサポートしています。お客様は、アカウントチームを通じて Enhanced TLS ホスト名を選択できるようになりました。（HTTP/3 から顧客へのオリジンにおける PQC のサポートは、今後、限定的可用性フェーズで追加されます）。
この機能は、すべての Akamai Ion および（Enhanced TLS の）配信ユーザーは追加料金なしで利用でき、2025 年 10 月 31 日からは一般への提供が開始されます。
すべてのお客様に、自社のオリジンまで PQC のご利用をお勧めします。
フェーズ 2：クライアントから Akamai へ
2025 年 9 月 1 日に、クライアントブラウザーから Akamai サービスへの PQC サポートの提供を開始する予定です。この限定的可用性オプトイン機能は、幅広いサポート対象の X25519MLKEM768ハイブリッド鍵共有により、早期にユーザーが Akamai のエッジに接続できるようにする機会を提供します。
この機能は、Akamai Ion および Akamai Dynamic Site Accelerator のすべてのお客様（Enhanced TLS）が追加コストなしで利用できます。
フェーズ 3：Akamai から Akamai へ
2025 年第 4 四半期から 2026 年第 1 四半期まで、Akamai のすべてのネットワークで中間層接続の PQC 更新を完了する予定です。これはすべてのお客様に完全に透明なものとなります。Akamai から Akamai へのすべての接続は、クライアントと Akamai の間の接続設定や Akamai とオリジンの間の接続設定に関係なく、量子耐性があり安全です。
今後の展望
Akamai は、世界中のお客様とさまざまな市場で事業を展開しているグローバル企業です。量子コンピューティングの革命と、それがもたらすデータへの脅威は、国境を越えています。また、大規模なインターネットコミュニティで開発されるソリューションや防御策は、世界中のユーザーを保護する必要があります。
次の記事では、政府がそれぞれの市場や管轄区域でコンプライアンス要件をどのように定義しているかを取り上げ、古典的な暗号から PQC へのコンプライアンス移行に関するガイダンスを共有します。また次回お会いしましょう！
その他の詳細について
その他の情報やご質問については、アカウント担当者までお問い合わせください。