ポスト量子暗号への移行におけるセキュアな TLS 接続の仕組みとクライアント設定ガイド

本ブログは 2024 年 10 月 3 日に公開された AWS Blog “Customer compliance and security during the post-quantum cryptographic migration” を翻訳したものです。

Amazon Web Services (AWS) は、サービスのセキュリティ、プライバシー、パフォーマンスを重視しています。AWS はクラウドと提供するサービスのセキュリティに責任を持ち、お客様はクラウドにデプロイまたは設定するホスト、アプリケーション、サービスのセキュリティに責任を持ちます。AWS は、長期的な機密性を確保するために、お客様が使用する一般的なトランスポートプロトコルに耐量子暗号鍵交換を導入してきました。このブログ記事では、クラウドへのセキュアな接続をポスト量子暗号へ移行する際に、お客様のコンプライアンスとセキュリティ設定の責任がどのように適用されるかを説明します。お客様は、AWS に接続するアプリケーションで耐量子アルゴリズムを有効にするか、デフォルトで有効にしているクライアントを使用する責任があります。また、サーバー側でサポートされている場合に、AWS がクライアントの選択した耐量子アルゴリズムを、多少の遅延が発生するとしても優先的に採用する仕組みについても説明します。

セキュアな接続

セキュリティとコンプライアンスは、AWS とお客様が共有する責任です。この責任共有モデルにより、お客様の運用負担が軽減されます。AWS がホストオペレーティングシステムや仮想化レイヤーから、サービスが稼働する施設の物理的なセキュリティに至るまで、運用、管理、制御を担当するためです。お客様は、ゲストオペレーティングシステムやその他の関連アプリケーションソフトウェア、および AWS が提供するセキュリティグループファイアウォール等の設定について責任と管理を担います。AWS は、主要なフレームワークのコンプライアンス要件が AWS サービスのセキュリティ推奨事項にどのようにマッピングされるかを、お客様、パートナー、監査人が理解できるよう、カスタマーコンプライアンスガイド (CCG) を公開しています。

セキュアな接続に関しては、AWS はサービスに接続するお客様向けに、暗号化プロトコル (TLS、SSH、VPN など) でセキュアなアルゴリズムを提供しています。AWS は、AWS クラウドへの接続において最新の暗号化を有効にし、優先的に提供する責任を負います。一方、お客様は AWS に接続する際に、これらのアルゴリズムを有効にしたクライアントを使用し、暗号スイートをネゴシエートします。接続時に使用するアルゴリズムとして、お客様が希望し信頼するもののみをネゴシエートするようクライアントを設定することは、お客様の責任です。

耐量子暗号とパフォーマンスのどちらを優先するか?

AWS は、AWS サービスへのネットワーク接続においてポスト量子暗号への移行を進めてきました。新しい暗号アルゴリズムは、将来の暗号解読能力を持つ量子コンピュータ (CRQC) から保護するように設計されています。CRQC は現在使用しているアルゴリズムを脅かす可能性があります。ポスト量子暗号では、TLS 1.3 や SSH/SFTP などのプロトコルにポスト量子ハイブリッド鍵交換を導入します。後方互換性のために従来型とポスト量子ハイブリッドの両方の交換をサポートする必要があるため、AWS はポスト量子ハイブリッドをサポートするクライアントにはポスト量子ハイブリッド交換を優先し、まだアップグレードされていないクライアントには従来型を優先します。クライアントがポスト量子のサポートをアドバタイズしている場合、従来型に切り替えることは望ましくありません。

ポスト量子ハイブリッドキー確立は、従来の鍵交換と組み合わせて使用される耐量子暗号の鍵カプセル化メカニズム (KEM) を活用します。クライアントとサーバーは引き続き ECDH 鍵交換を行い、対称鍵を導出する際に KEM の共有シークレットと組み合わせます。例えば、クライアントは AWS Certificate Manager (ACM)、AWS Key Management Service (AWS KMS)、AWS Secrets Manager に接続する際に、楕円曲線 P256 を使用した ECDH 鍵交換と NIST の PQC プロジェクト Round 3 のポスト量子 Kyber-768 (TLS グループ識別子 X25519Kyber768Draft00) を実行できます。

訳注: 本ブログの原文公開後、NIST により ML-KEM として標準化された方式が AWS KMS、ACM、Secrets Manager で利用可能になっています。詳細については Security Blog「AWS KMS、ACM、Secrets Manager で ML-KEM ポスト量子 TLS をサポート開始」を参照してください。

この戦略は、長年の実績がある従来の鍵交換の信頼性と、ポスト量子鍵交換の耐量子性を組み合わせることで、ECDH とポスト量子の共有シークレットの両方が破られない限り、ハンドシェイクが保護されます。ML-KEM アルゴリズムの導入により、転送されるデータが増加し (2.3 KB)、処理オーバーヘッドもわずかに増加します。処理オーバーヘッドは、長年ほとんどの TLS 接続で使用されてきた既存の ECDH アルゴリズムと同程度です。以下の表に示すように、ハイブリッド鍵交換の総オーバーヘッドは、インターネット上の一般的なハンドシェイクでは実質的に影響がないことが示されています。(出典: ブログ記事「Kyber を使用したハイブリッドポスト量子 TLS のチューニング方法」および「The state of the post-quantum Internet」)

新しい鍵交換では、これまでにはなかった設計上の判断が必要になり、ピア間で従来型のみのアルゴリズムがネゴシエートされてしまう可能性があります。これまで、暗号プロトコルの設定には、安全であると広く信頼されているアルゴリズムが含まれていました。クライアントとサーバーは選択したアルゴリズムの優先順位を設定し、ネゴシエートされた優先順位から最も適切なものを選択していました。現在、「信頼された従来型」と「信頼されたポスト量子」という 2 つのアルゴリズムファミリーがあります。CRQC が利用できない現状では、従来型とポスト量子の両方のアルゴリズムが安全と見なされています。そのため、「安全な従来型」または「安全なポスト量子」アルゴリズムに関して、ベンダーがクライアントとサーバーの設定でどちらを優先すべきかという判断を求めるパラダイムシフトが起きています。

図 1 は、TLS における典型的なポスト量子ハイブリッド鍵交換を示しています。

図 1: 典型的な TLS 1.3 ハンドシェイク

図 1 の例では、クライアントは楕円曲線 P256 を使用した ECDH と耐量子 ML-KEM-768、楕円曲線 P256 を使用した ECDH と耐量子 Kyber-512 Round 3、および楕円曲線 P256 を使用した従来型 ECDH によるポスト量子ハイブリッドアルゴリズムのサポートをアドバタイズしています。クライアントは、P256 を使用した従来型 ECDH、およびポスト量子ハイブリッド P256+MLKEM768 の Keyshare 値も送信します。Keyshare 値にはクライアントの公開鍵が含まれています。クライアントは P256+Kyber512 の Keyshare を含めていません。これは ClientHello のサイズを不必要に増加させるためです。また、ML-KEM-768 が Kyber Round 3 の批准版であるため、クライアントは P256+MLKEM768 の公開鍵のみを生成して送信することを選択しました。ここで、サーバーが楕円曲線 P256 を使用した ECDH とポスト量子ハイブリッド P256+Kyber512 をサポートしているが、P256+MLKEM768 をサポートしていないとします。クライアントが ClientHello に含めたグループと Keyshare 値を考慮すると、サーバーには次の 2 つのオプションがあります。

1. 図 1 に示すように、クライアントの P256 Keyshare を使用して従来型鍵交換をネゴシエートする。P256+Kyber512 Keyshare が耐量子鍵交換に使用できると思われるかもしれませんが、サーバーは P256 による従来型 ECDH 鍵交換のみをネゴシエートすることを選択でき、これは CRQC に対して耐性がありません
2. Hello Retry Request (HRR) を送信して、クライアントに新しい ClientHello で P256+Kyber512 のポスト量子ハイブリッド Keyshare を送信するよう指示する (図 2)。これによりラウンドトリップが発生しますが、ピア間で耐量子対称鍵をネゴシエートすることが強制されます

注: 一般的なインターネット接続では、ラウンドトリップに 30〜50 ミリ秒かかる場合があります。

以前は、一部のサーバーが Keyshare 値を使用して鍵交換アルゴリズムを選択していました (上記のオプション 1)。これにより、追加のラウンドトリップ (HRR) を必要としない高速な TLS 1.3 ハンドシェイクが可能でしたが、前述のポスト量子シナリオでは、両方のピアがサポートしているにもかかわらず、サーバーが耐量子アルゴリズムをネゴシエートしないことを意味します。

このようなシナリオは、クライアントとサーバーが新しいアルゴリズムの同じバージョンを同時にデプロイしない場合に発生する可能性があります。図 1 の例では、サーバーがポスト量子アルゴリズムの早期採用者であり、P256+Kyber512 Round 3 のサポートを追加した可能性があります。その後、クライアントが ML-KEM (P256+MLKEM768) を使用した批准済みポスト量子アルゴリズムにアップグレードした可能性があります。AWS はクライアントとサーバーの両方を常に制御できるわけではありません。一部の AWS サービスは Kyber の初期バージョンを採用しており、他のサービスは最初から ML-KEM-768 をデプロイしています。そのため、AWS がポスト量子移行フェーズにある間、このようなシナリオが発生する可能性があります。

注: これらのケースでは、接続の失敗は発生しません。副作用として、ポスト量子ハイブリッドをネゴシエートできたにもかかわらず、接続が従来型のみのアルゴリズムを使用することになります。

これらの複雑さは AWS に固有のものではありません。他の業界関係者もこれらの問題について検討しており、Internet Engineering Task Force (IETF) TLS ワーキンググループで議論のトピックとなっています。クライアントとサーバーが耐量子アルゴリズムをサポートしているにもかかわらず、従来型鍵交換をネゴシエートする可能性がある問題は、TLS Key Share Prediction draft (draft-davidben-tls-key-share-prediction) のセキュリティに関する考慮事項で議論されています。これらの懸念に対処するため、TLS 1.3 (RFC 8446) のドラフト更新版である Transport Layer Security (TLS) Protocol Version 1.3 draft (draft-ietf-tls-rfc8446bis) では、鍵交換グループの選択時のクライアントとサーバーの動作、および Keyshare 値の使用に関するテキストがセクション 4.2.8 に導入されています。TLS Key Share Prediction draft は、クライアントがサーバーがサポートする適切な Keyshare を使用するためのメカニズムとして DNS を提供することで、この問題に対処しようとしています。

耐量子性の優先

一般的な TLS 1.3 ハンドシェイクでは、ClientHello にクライアントの鍵交換アルゴリズムの優先順位が含まれています。ClientHello を受信すると、サーバーは自身の優先順位に基づいてアルゴリズムを選択して応答します。

図 2 は、前述のシナリオ (図 1) において、サーバーが P256+Kyber512 を使用した耐量子鍵のネゴシエーションを要求するために、クライアントに HelloRetryRequest (HRR) を送信する方法を示しています。このアプローチでは、ハンドシェイクに追加のラウンドトリップが発生します。

図 2: サーバーからクライアントへの HRR による、相互にサポートされた耐量子鍵のネゴシエーション要求

TLS 1.3 接続を終端する AWS サービスは、このアプローチを採用します。耐量子アルゴリズムのサポートをアドバタイズするクライアントに対して、耐量子性を優先します。AWS サービスが耐量子アルゴリズムを追加している場合、ハンドシェイクに追加のラウンドトリップが発生し、ポスト量子ハイブリッド鍵交換にわずかな処理オーバーヘッドが含まれる場合でも (ML-KEM は ECDH とほぼ同等のパフォーマンス)、クライアントがサポートするポスト量子鍵交換を尊重します。現在のリージョン化された TLS 接続における一般的なラウンドトリップは通常 50 ミリ秒未満であり、接続パフォーマンスに大きな影響を与えません。ポスト量子移行において、AWS は耐量子鍵交換のサポートをアドバタイズするクライアントを、CRQC リスクを真剣に捉えているクライアントと見なします。そのため、サーバーがアルゴリズムをサポートしている場合、AWS サーバーはその優先順位を尊重します。

Pull Request 4526 は、s2n-tls にこの動作を導入しています。s2n-tls は、OpenSSL libcrypto や AWS libcrypto (AWS-LC) などの他の暗号ライブラリ上に構築された、AWS のオープンソースで効率的な TLS ライブラリです。s2n-tls でビルドされた s2n-quic のハンドシェイクも同じ動作を継承します。s2n-quic は、QUIC プロトコルの AWS オープンソース Rust 実装です。

AWS のお客様がポスト量子鍵交換を検証する方法

この記事で説明した動作をすでに採用している AWS サービスには、AWS KMS、ACM、Secrets Manager の TLS エンドポイントがあります。これらは数年前からポスト量子ハイブリッド鍵交換をサポートしています。耐量子アルゴリズムをデプロイする他のエンドポイントも、同じ動作を継承します。

AWS サービスに導入された新しい耐量子アルゴリズムを活用したいお客様は、クライアント側またはお客様が管理するエンドポイントのサーバー側でそれらを有効にする必要があります。例えば、AWS SDK for Java v2 で AWS Common Runtime (CRT) HTTP クライアントを使用している場合、以下のようにポスト量子ハイブリッド TLS 鍵交換を有効にする必要があります。

SdkAsyncHttpClient awsCrtHttpClient = AwsCrtAsyncHttpClient.builder()
            .postQuantumTlsEnabled(true)
            .build();

AWS KMS および Secrets Manager のドキュメントには、ポスト量子 TLS をサポートする AWS エンドポイントへの耐量子接続を介して HTTP API 呼び出しを行うための AWS SDK の使用方法が詳しく記載されています。

サーバーエンドポイントがポスト量子アルゴリズムを適切に優先し、強制していることを確認するには、ポスト量子対応サーバーがサポートしていないポスト量子ハイブリッド Keyshare 値を送信する「古い」クライアントを使用できます。例えば、AWS-LC (耐量子 KEM をサポート) でビルドされた s2n-tls を使用できます。サーバーのポリシー (PQ-TLS-1-0-2021-05-24) よりも新しいクライアント TLS ポリシー (PQ-TLS-1-3-2023-06-01) を使用すると、以下に示すように、サーバーは HRR を通じてクライアントに P256+MLKEM768 を含む新しい ClientHello を送信するよう要求します。

./bin/s2nd -c PQ-TLS-1-0-2021-05-24 localhost 4444
sudo tcpdump port 4444 -w hrr-capture.pcap
./bin/s2nc localhost 4444 -c PQ-TLS-1-3-2023-06-01 -i

hrr-capture.pcap パケットキャプチャには、ネゴシエーションとサーバーからの HRR が表示されます。

サーバーエンドポイントがポスト量子ハイブリッド鍵交換を適切に実装していることを確認するには、鍵交換をサポートする最新のクライアントを使用してエンドポイントに接続します。例えば、AWS-LC (耐量子 KEM をサポート) でビルドされた s2n-tls クライアントを使用して、ポスト量子 TLS ポリシー (例: PQ-TLS-1-2-2023-12-15) で Secrets Manager エンドポイントに接続し、以下に示すように出力で使用されたポスト量子ハイブリッド鍵交換を確認できます。

./bin/s2nc -c PQ-TLS-1-2-2023-12-15 secretsmanager.us-east-1.amazonaws.com 443
CONNECTED:
Handshake: NEGOTIATED|FULL_HANDSHAKE|MIDDLEBOX_COMPAT
Client hello version: 33
Client protocol version: 34
Server protocol version: 34
Actual protocol version: 34
Server name: secretsmanager.us-east-1.amazonaws.com
Curve: NONE
KEM: NONE
KEM Group: SecP256r1Kyber768Draft00
Cipher negotiated: TLS_AES_128_GCM_SHA256
Server signature negotiated: RSA-PSS-RSAE+SHA256
Early Data status: NOT REQUESTED
Wire bytes in: 6699
Wire bytes out: 1674
s2n is ready
Connected to secretsmanager.us-east-1.amazonaws.com:443

代替手段として、Open Quantum Safe (OQS) for OpenSSL クライアントを使用することもできます。

別の例として、AWS Transfer Family で耐量子 SFTP 接続を介してファイルを転送する場合、AWS File Transfer SFTP エンドポイントにポスト量子暗号 SSH セキュリティポリシーを設定 (例: TransferSecurityPolicy-2024-01) し、SFTP クライアントで耐量子 SSH 鍵交換を有効にする必要があります。SSH/SFTP では、AWS サーバー側が耐量子スキームをより高い優先順位でアドバタイズしますが、鍵交換アルゴリズムを選択するのはクライアントであることに注意してください。そのため、ポスト量子暗号をサポートするクライアントは、(責任共有モデルで説明されているように) ポスト量子アルゴリズムをより高い優先順位で設定する必要があります。詳細については、AWS Transfer Family のドキュメントを参照してください。

まとめ

暗号移行は、クライアントとサーバー間の暗号ネゴシエーションに複雑さをもたらす可能性があります。移行フェーズにおいて、AWS サービスは、これらのアルゴリズムのサポートをアドバタイズするお客様に対してポスト量子アルゴリズムを優先することで、これらの複雑さのリスクを軽減します。初期ネゴシエーションでわずかな遅延が発生する場合でも、AWS はポスト量子アルゴリズムを優先します。ポスト量子移行フェーズにおいて耐量子性を有効にすることを選択したお客様は、CRQC リスクを真剣に捉えていると言えます。このリスクを軽減するため、サーバー側で耐量子性がサポートされている場合、AWS はネゴシエーション時にお客様が選択した耐量子アルゴリズムを優先的に使用します。

この記事についてご質問がある場合は、AWS Security, Identity, & Compliance re:Post で新しいスレッドを開始するか、AWS サポートにお問い合わせください。AWS の PQC への取り組みの詳細については、PQC ページを参照してください。