本ブログは 2023 年 6 月 13 日に公開された AWS Blog “ Post-quantum hybrid SFTP file transfers using AWS Transfer Family ” を翻訳したものです。 2025 年 9 月 5 日: AWS Transfer Family は、ポスト量子ハイブリッド鍵交換のサポートを、Kyber から NIST が FIPS 203 で標準化した ML-KEM にアップグレードしました。ML-KEM によるポスト量子鍵交換をサポートする SSH ポリシーは TransferSecurityPolicy-2025-03 と TransferSecurityPolicy-FIPS-2025-03 です。これらのポリシーに含まれるポスト量子 SSH 鍵交換方式は、 ポスト量子ハイブリッド SSH 鍵交換のドラフト仕様 で定義されている mlkem768nistp256-sha256 、 mlkem1024nistp384-sha384 、 mlkem768x25519-sha256 です。詳細については、「 AWS Transfer Family announces ML-KEM quantum-resistant key exchange for SFTP 」を参照してください。 以下の記事の例で使用されている 2023 年当時の実験的ポリシー ( TransferSecurityPolicy-PQ-SSH-Experimental-2023-04 および TransferSecurityPolicy-PQ-SSH-FIPS-Experimental-2023-04 ) と SSH メソッド名には、ML-KEM の標準化前バージョンである Kyber が含まれていました。これらのポリシーを使用している SFTP エンドポイントについては、対応する SFTP クライアントがまだ ML-KEM にアップグレードされておらず、引き続き Kyber を使用している場合を除き、 TransferSecurityPolicy-2025-03 and TransferSecurityPolicy-FIPS-2025-03 に更新してください。 Amazon Web Services (AWS) は、セキュリティ、プライバシー、パフォーマンスを最優先としています。暗号化はプライバシーの重要な要素です。暗号化されたデータを長期にわたって保護するために、AWS はお客様が使用する一般的なトランスポートプロトコルに耐量子鍵交換を導入してきました。本記事では、Secure Shell (SSH) プロトコルにおける Kyber を使用したポスト量子ハイブリッド鍵交換について紹介します。Kyber は、米国国立標準技術研究所 (NIST) が選定した耐量子鍵カプセル化アルゴリズムです。ポスト量子ハイブリッド鍵交換が重要な理由を解説し、AWS のファイル転送サービスである AWS Transfer Family の Secure File Transfer Protocol (SFTP) で使用する方法を紹介します。 SSH でポスト量子ハイブリッド鍵確立を使用する理由 現時点では実用化されていませんが、暗号解読能力を持つ量子コンピュータ (CRQC) が実現すれば、現在使用されている標準的な公開鍵アルゴリズムを理論的に破ることが可能になります。現在のネットワークトラフィックを記録しておき、将来 CRQC で復号するという脅威も想定されます。これは harvest-now-decrypt-later (今収集して後で復号する攻撃) と呼ばれています。 こうした懸念を踏まえ、米国議会は Quantum Computing Cybersecurity Preparedness Act に署名し、ホワイトハウスは耐量子暗号への適切かつ公平な移行に備えるための国家安全保障覚書 ( NSM-8 、 NSM-10 ) を発行しました。米国国家安全保障局 (NSA) も CNSA 2.0 リリース で耐量子アルゴリズムの要件とタイムラインを公表しています。 カナダ 、 ドイツ 、 フランス をはじめとする多くの政府や、ISO/IEC、 IEEE などの標準化団体も、耐量子暗号技術への備えと実証を優先的に進めています。 AWS はポスト量子暗号への移行を積極的に推進しています。 AWS Key Management Service (AWS KMS) 、 AWS Certificate Manager (ACM) 、 AWS Secrets Manager の TLS エンドポイントでは、楕円曲線 Diffie-Hellman (ECDH) と Kyber を使用した ポスト量子ハイブリッド鍵確立が既にサポート されています。Kyber は、 NIST のポスト量子暗号 (PQC) プロジェクト で選定された鍵カプセル化メカニズム (KEM) です。ポスト量子ハイブリッド TLS 1.3 鍵交換は大きな注目を集めていますが、SSH に関する取り組みはこれまで限定的でした。 SSH は、マシン間のファイル転送から Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの管理まで、AWS のお客様に幅広く使用されているプロトコルです。SSH プロトコルの重要性、広範な利用状況、転送されるデータの性質を考慮し、AWS は SSH にも Kyber を使用したポスト量子ハイブリッド鍵交換を導入しました。 Transfer Family SFTP におけるポスト量子ハイブリッド鍵交換の仕組み AWS は、2023 年 6 月に AWS Transfer Family の SFTP ファイル転送におけるポスト量子鍵交換のサポートを発表 しました。Transfer Family は、SFTP やその他のプロトコルを使用して、AWS Storage サービスへの企業間ファイル転送を安全にスケールするサービスです。SFTP は SSH 上で動作する File Transfer Protocol (FTP) のセキュアバージョンです。Transfer Family がポスト量子鍵交換をサポートすることで、SFTP 経由のデータ転送のセキュリティが向上します。 SSH におけるポスト量子ハイブリッド鍵確立では、ポスト量子 KEM を従来の鍵交換と組み合わせて使用します。クライアントとサーバーは引き続き ECDH 鍵交換 を行います。さらに、サーバーはクライアントが SSH 鍵交換メッセージで提示したポスト量子 KEM 公開鍵を用いて、ポスト量子共有シークレットをカプセル化します。この方式は、従来の鍵交換の高い信頼性とポスト量子鍵交換によるセキュリティを組み合わせたもので、ECDH またはポスト量子共有シークレットのどちらか一方が安全である限り、ハンドシェイクは保護されます。 具体的には、Transfer Family のポスト量子ハイブリッド鍵交換 SFTP サポートは、ポスト量子 Kyber-512、Kyber-768、Kyber-1024 と、ECDH (楕円曲線 P256、P384、P521、Curve25519) を組み合わせた方式に対応しています。対応する SSH 鍵交換方式は、 ecdh-nistp256-kyber-512r3-sha256-d00@openquantumsafe.org、ecdh-nistp384-kyber-768r3-sha384-d00@openquantumsafe.org、ecdh-nistp521-kyber-1024r3-sha512-d00@openquantumsafe.org 、および x25519-kyber-512r3-sha256-d00@amazon.com で、 ポスト量子ハイブリッド SSH 鍵交換のドラフト仕様 で定義されています。 Kyber を採用した理由 AWS は標準化された相互運用可能なアルゴリズムのサポートに取り組んでおり、SSH には Kyber を導入しました。Kyber は、NIST の ポスト量子暗号 (PQC) プロジェクト で標準化の対象として選定されたアルゴリズムです。複数の標準化団体が、既にさまざまなプロトコルへの Kyber の統合を進めています。 また、AWS は相互運用性の促進にも取り組んでおり、SSH 向けに Kyber と NIST 標準の楕円曲線 (P256 など) を組み合わせた ドラフト仕様 を策定・公開し、標準化に向けて提出しました。SFTP および SSH におけるポスト量子鍵交換の AWS 実装は、お客様のセキュリティ強化のため、このドラフト仕様に準拠しています。 相互運用性 新しい鍵交換方式 ( ecdh-nistp256-kyber-512r3-sha256-d00@openquantumsafe.org、ecdh-nistp384-kyber-768r3-sha384-d00@openquantumsafe.org、ecdh-nistp521-kyber-1024r3-sha512-d00@openquantumsafe.org 、および x25519-kyber-512r3-sha256-d00@amazon.com ) は、Transfer Family の 2 つの新しい セキュリティポリシー でサポートされています。これらの方式名やポリシーは、ドラフト仕様の標準化の進展や NIST による Kyber アルゴリズムの正式承認に伴い、変更される可能性があります。 ポスト量子ハイブリッド SSH 鍵交換と FIPS 140 などの暗号要件への適合性 FIPS 準拠が必要なお客様向けに、Transfer Family ではオープンソース暗号ライブラリである AWS-LC を使用して SSH の FIPS 暗号を提供しています。Transfer Family の TransferSecurityPolicy-PQ-SSH-FIPS-Experimental-2023-04 ポリシーでサポートされるポスト量子ハイブリッド鍵交換方式は、 SP 800-56Cr2 (section 2) に記載のとおり、引き続き FIPS 要件を満たしています。ドイツ連邦情報セキュリティ庁 ( BSI ) やフランス国家情報システムセキュリティ庁 ( ANSSI ) も、このようなポスト量子ハイブリッド鍵交換方式を推奨しています。 Transfer Family でポスト量子 SFTP をテストする方法 Transfer Family でポスト量子ハイブリッド SFTP を有効にするには、SFTP 対応エンドポイントに、ポスト量子ハイブリッド鍵交換をサポートする 2 つのセキュリティポリシー のいずれかを適用する必要があります。セキュリティポリシーは、 ドキュメント に記載のとおり、Transfer Family で新しい SFTP サーバーエンドポイントを作成する際に選択できます。また、既存の SFTP エンドポイントの [Cryptographic algorithm options] を編集して変更することもできます。以下の図 1 に、 AWS マネジメントコンソール でセキュリティポリシーを更新する画面の例を示します。 図 1: コンソールから Transfer Family エンドポイントにポスト量子ハイブリッドセキュリティポリシーを設定する Transfer Family でポスト量子鍵交換をサポートするセキュリティポリシー名は、 TransferSecurityPolicy-PQ-SSH-Experimental-2023-04 と TransferSecurityPolicy-PQ-SSH-FIPS-Experimental-2023-04 です。Transfer Family のポリシーの詳細については、「 Security policies for AWS Transfer Family 」を参照してください。 SFTP の Transfer Family エンドポイントで適切なポスト量子セキュリティポリシーを選択したら、 前述のドラフト仕様 のガイダンスに従い、ポスト量子ハイブリッド鍵交換をサポートする SFTP クライアントを使用して、Transfer Family でのポスト量子 SFTP を検証できます。AWS は、 NIST NCCOE Post-Quantum Migration プロジェクト の協力者でもある OQS OpenSSH および wolfSSH の SSH 実装と、Transfer Family のポスト量子ハイブリッド鍵交換 SFTP との相互運用性をテストし、確認しています。 OQS OpenSSH クライアント OQS OpenSSH は、liboqs を使用して SSH に耐量子暗号を追加する OpenSSH のオープンソースフォークです。 liboqs は、耐量子暗号アルゴリズムを実装するオープンソースの C ライブラリです。OQS OpenSSH と liboqs は、いずれも Open Quantum Safe (OQS) プロジェクト の一部です。 OQS OpenSSH を使用して Transfer Family SFTP でポスト量子ハイブリッド鍵交換をテストするには、まずプロジェクトの README の手順に従って OQS OpenSSH をビルドします。次に、以下のコマンドのように、ポスト量子ハイブリッド鍵交換方式を指定して SFTP クライアントを実行し、AWS SFTP エンドポイント (例: s-9999999999999999999.server.transfer.us-west-2.amazonaws.com ) に接続します。 &lt;user_priv_key_PEM_file&gt; はユーザー認証に使用する SFTP ユーザーの PEM エンコード秘密鍵ファイルに、 &lt;username&gt; はユーザー名に置き換えてください。また、SFTP 対応エンドポイントは Transfer Family で作成したものに更新してください。 ./sftp -S ./ssh -v -o \ KexAlgorithms=ecdh-nistp384-kyber-768r3-sha384-d00@openquantumsafe.org \ -i &lt;user_priv_key_PEM_file&gt; \ &lt;username&gt; @s-9999999999999999999.server.transfer.us-west-2.amazonaws.com wolfSSH クライアント wolfSSH は、暗号処理に wolfCrypt を使用する SSHv2 クライアントおよびサーバーライブラリです。詳細とダウンロードリンクについては、 wolfSSL の製品ライセンス情報 を参照してください。 wolfSSH を使用して Transfer Family SFTP でポスト量子ハイブリッド鍵交換をテストするには、まず wolfSSH をビルド します。耐量子暗号アルゴリズムを実装するオープンソースライブラリ liboqs を使用してビルドすると、wolfSSH は自動的に ecdh-nistp256-kyber-512r3-sha256-d00@openquantumsafe.org をネゴシエートします。以下のコマンドのように SFTP クライアントを実行して AWS SFTP サーバーエンドポイントに接続します。 &lt;user_priv_key_DER_file&gt; はユーザー認証に使用する SFTP ユーザーの DER エンコード秘密鍵ファイルに、 &lt;user_public_key_PEM_file&gt; は対応する SSH ユーザーの PEM 形式公開鍵ファイルに、 &lt;username&gt; はユーザー名に置き換えてください。また、SFTP エンドポイント s-9999999999999999999.server.transfer.us-west-2.amazonaws.com は Transfer Family で作成したものに更新してください。 ./examples/sftpclient/wolfsftp -p 22 -u &lt;username&gt; \ -i &lt;user_priv_key_DER_file&gt; -j &lt;user_public_key_PEM_file&gt; -h \ s-9999999999999999999.server.transfer.us-west-2.amazonaws.com 耐量子の将来に向けた移行が進むにつれ、SSH 向けに標準化されたポスト量子ハイブリッド鍵交換をサポートする SFTP および SSH クライアントは今後ますます増えていくと見込まれます。 SFTP でポスト量子ハイブリッド鍵交換を確認する方法 Transfer Family への SFTP 用 SSH 接続でポスト量子ハイブリッド鍵交換が使用されたことを確認するには、クライアントの出力を確認するか、パケットキャプチャを使用します。 OQS OpenSSH クライアント クライアントの出力 (関連のない情報は省略) は以下のようになります。 $./sftp -S ./ssh -v -o KexAlgorithms=ecdh-nistp384-kyber-768r3-sha384-d00@openquantumsafe.org -i panos_priv_key_PEM_file panos@s-9999999999999999999.server.transfer.us-west-2.amazonaws.com OpenSSH_8.9-2022-01_p1, Open Quantum Safe 2022-08, OpenSSL 3.0.2 15 Mar 2022 debug1: Reading configuration data /home/lab/openssh/oqs-test/tmp/ssh_config debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling debug1: Connecting to s-9999999999999999999.server.transfer.us-west-2.amazonaws.com [xx.yy.zz..12] port 22. debug1: Connection established. [...] debug1: Local version string SSH-2.0-OpenSSH_8.9-2022-01_ debug1: Remote protocol version 2.0, remote software version AWS_SFTP_1.1 debug1: compat_banner: no match: AWS_SFTP_1.1 debug1: Authenticating to s-9999999999999999999.server.transfer.us-west-2.amazonaws.com:22 as 'panos' debug1: load_hostkeys: fopen /home/lab/.ssh/known_hosts2: No such file or directory [...] debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: ecdh-nistp384-kyber-768r3-sha384-d00@openquantumsafe.org debug1: kex: host key algorithm: ssh-ed25519 debug1: kex: server-&gt;client cipher: aes192-ctr MAC: hmac-sha2-256-etm@openssh.com compression: none debug1: kex: client-&gt;server cipher: aes192-ctr MAC: hmac-sha2-256-etm@openssh.com compression: none debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: SSH2_MSG_KEX_ECDH_REPLY received debug1: Server host key: ssh-ed25519 SHA256:BY3gNMHwTfjd4n2VuT4pTyLOk82zWZj4KEYEu7y4r/0 [...] debug1: rekey out after 4294967296 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey in after 4294967296 blocks [...] Authenticated to s-9999999999999999999.server.transfer.us-west-2.amazonaws.com ([xx.yy.zz..12]:22) using "publickey".s debug1: channel 0: new [client-session] [...] Connected to s-9999999999999999999.server.transfer.us-west-2.amazonaws.com. sftp&gt; この出力から、ポスト量子ハイブリッド方式 ecdh-nistp384-kyber-768r3-sha384-d00@openquantumsafe.org を使用した鍵交換のネゴシエーションが行われ、SFTP セッションが正常に確立されたことがわかります。 ネゴシエートされたポスト量子ハイブリッド鍵をさらに確認するには、 Wireshark などのネットワークトラフィック分析ツールでパケットキャプチャを使用します。クライアントが提案する鍵交換方式のネゴシエーションは以下のように表示されます。 図 2: Wireshark でクライアントが提案するポスト量子ハイブリッド鍵交換方式を確認する 図 2 は、クライアントがポスト量子ハイブリッド鍵交換方式 ecdh-nistp384-kyber-768r3-sha384-d00@openquantumsafe.org を提案していることを示しています。Transfer Family SFTP サーバーは同じ方式をネゴシエートし、クライアントはポスト量子ハイブリッド公開鍵を提案します。 図 3: クライアントの ECDH P384 および Kyber-768 公開鍵を確認する 図 3 に示すように、クライアントはポスト量子ハイブリッド公開鍵として 1,281 バイトを送信しています。これは、ECDH P384 の 92 バイトの公開鍵、1,184 バイトの Kyber-768 公開鍵、および 5 バイトのパディングで構成されています。サーバーのレスポンスも同様のサイズで、92 バイトの P384 公開鍵と 1,088 バイトの Kyber-768 暗号文が含まれています。 wolfSSH クライアント クライアントの出力 (関連のない情報は省略) は以下のようになります。 $ ./examples/sftpclient/wolfsftp -p 22 -u panos -i panos_priv_key_DER_file -j panos_public_key_PEM_file -h s-9999999999999999999.server.transfer.us-west-2.amazonaws.com [...] 2023-05-25 17:37:24 [DEBUG] SSH-2.0-wolfSSHv1.4.12 [...] 2023-05-25 17:37:24 [DEBUG] DNL: name ID = unknown 2023-05-25 17:37:24 [DEBUG] DNL: name ID = unknown 2023-05-25 17:37:24 [DEBUG] DNL: name ID = ecdh-nistp256-kyber-512r3-sha256-d00@openquantumsafe.org 2023-05-25 17:37:24 [DEBUG] DNL: name ID = unknown 2023-05-25 17:37:24 [DEBUG] DNL: name ID = unknown 2023-05-25 17:37:24 [DEBUG] DNL: name ID = unknown 2023-05-25 17:37:24 [DEBUG] DNL: name ID = unknown 2023-05-25 17:37:24 [DEBUG] DNL: name ID = unknown 2023-05-25 17:37:24 [DEBUG] DNL: name ID = diffie-hellman-group-exchange-sha256 [...] 2023-05-25 17:37:24 [DEBUG] connect state: SERVER_KEXINIT_DONE [...] 2023-05-25 17:37:24 [DEBUG] connect state: CLIENT_KEXDH_INIT_SENT [...] 2023-05-25 17:37:24 [DEBUG] Decoding MSGID_KEXDH_REPLY 2023-05-25 17:37:24 [DEBUG] Entering DoKexDhReply() 2023-05-25 17:37:24 [DEBUG] DKDR: Calling the public key check callback Sample public key check callback public key = 0x24d011a public key size = 104 ctx = s-9999999999999999999.server.transfer.us-west-2.amazonaws.com 2023-05-25 17:37:24 [DEBUG] DKDR: public key accepted [...] 2023-05-25 17:37:26 [DEBUG] Entering wolfSSH_get_error() 2023-05-25 17:37:26 [DEBUG] Entering wolfSSH_get_error() wolfSSH sftp&gt; この出力から、クライアントがポスト量子ハイブリッド方式 ecdh-nistp256-kyber-512r3-sha256-d00@openquantumsafe.org をネゴシエートし、耐量子 SFTP セッションが正常に確立されたことがわかります。このセッションのパケットキャプチャは前述のものとほぼ同様です。 まとめ 本記事では、ポスト量子暗号への移行と、標準化されたアルゴリズムおよびプロトコルの採用が重要な理由を紹介しました。また、SSH にポスト量子ハイブリッド鍵交換を導入する AWS のアプローチと、Transfer Family の SFTP での利用方法についても説明しました。AWS は暗号技術の専門家と協力して、ポスト量子ハイブリッド SSH 鍵交換のドラフトを策定しています。Transfer Family はこの ドラフト仕様 に準拠しています。 Transfer Family でのポスト量子鍵交換の使用方法についてご質問がある場合は、 Transfer Family for SFTP フォーラム で新しいスレッドを開始してください。AWS のポスト量子暗号について詳しく知りたい場合は、 ポスト量子暗号チーム にお問い合わせください。 本記事に関するご質問は、 AWS Security, Identity, &amp; Compliance re:Post で新しいスレッドを開始するか、 AWS サポート までお問い合わせください。 AWS セキュリティに関するその他のニュースは、 Twitter でフォローしてください。 Panos Kampanakis Panos は AWS Cryptography 組織の Principal Security Engineer です。サイバーセキュリティ、応用暗号技術、セキュリティ自動化、脆弱性管理に関する豊富な経験を持っています。サイバーセキュリティに関する出版物を共同執筆しており、セキュリティ情報の共有や暗号技術、PKI のための相互運用可能なプロトコルおよび言語の策定に取り組むさまざまなセキュリティ標準化団体に参加してきました。現在は、エンジニアや業界の標準化パートナーと協力し、暗号実装、プロトコル、標準の策定に取り組んでいます。 Torben Hansen Torben は AWS Cryptography チームの暗号技術者です。暗号ライブラリの開発とデプロイに注力しており、AWS 全体にわたる暗号ソリューションの設計と分析にも貢献しています。 Alex Volanis Alex は AWS の Software Development Engineer で、分散システム、暗号技術、認証、ビルドツールの経験があります。現在は AWS Transfer Family チームと協力し、社内外のお客様向けにスケーラブルで安全かつ高パフォーマンスなデータ転送ソリューションを提供しています。コーディングと問題解決に情熱を注いでおり、スキーの腕前も相当なものです。 Gerardo Ravago Gerardo は AWS Cryptography 組織の Senior Software Development Engineer で、ポスト量子暗号と Amazon Corretto Crypto Provider の開発に貢献しています。以前は AWS で Storage Gateway と DataSync に携わっていました。仕事以外では、旅行を通じて世界各地の食、芸術、文化、歴史の探求を楽しんでいます。 <!-- '"` --> 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2025 年 7 月 24 日に公開された AWS Blog “ Post-quantum TLS in Python ” を翻訳したものです。 Amazon Web Services (AWS) では、セキュリティが最優先事項です。データの機密性を維持することは、AWS とお客様の運用環境セキュリティにおいて重要な要素です。まだ実現していませんが、暗号解読能力を持つ量子コンピュータ (CRQC: cryptographically relevant quantum computer) が登場すれば、現在使用されている公開鍵アルゴリズムを破り、データの機密性を脅かす可能性があります。こうした脅威に備えるため、米国国立標準技術研究所 (NIST) は 2016 年にCRQC に耐性のある新しい暗号アルゴリズムの 標準化に取りかかりました 。2024年8月、暗号コミュニティによる8年間の厳密な審査を経て、NIST は従来の公開鍵アルゴリズムを補完し、最終的に置き換えるための3つのポスト量子暗号 (PQC) 標準を選定しました。その中には FIPS 203 の ML-KEM が含まれています。 最近のいくつかの AWS Blog 記事では、AWS における PQC、特に ML-KEM を使用したポスト量子 TLS について説明しています。 ポスト量子 TLS とは何か、どのように機能するか ポスト量子 TLS パフォーマンスの詳細 AWS SDK for Java v2 でのポスト量子 TLS の使用 AWS PQC 移行計画 この記事では、Python アプリケーションでポスト量子 TLS をテストする方法を紹介します。 Python でのポスト量子 TLS のテスト 別の記事 で詳しく説明されているように、AWS は現在、データの機密性に対する多層防御を提供するため、従来の鍵交換と ML-KEM を併用するハイブリッド構成でポスト量子 TLS を提供しています。ML-KEM は従来の方式よりもはるかに大きな鍵を使用するため、ハイブリッド TLS ハンドシェイクでは接続確立時により多くのデータを送受信します。他のプロトコル更新と同様に、セキュリティアプライアンスやネットワークデバイスがこれらの接続を適切に処理できることを検証するために、ネットワークでハイブリッド TLS をテストすることが重要です。このようなテストに、AWS が提供するサンプルをぜひご活用ください。 ハイブリッド TLS をネゴシエートするには、接続の 両端 (クライアントとサーバー) にポスト量子対応ソフトウェアが必要です。AWS は現在、サーバー側でハイブリッド TLS の 導入を進めています 。クライアント側では、ハイブリッド TLS を有効にする方法は SDK の言語 ごとに若干異なります。 AWS SDK for Python (Boto3) は、TLS に Python インタープリターの ssl モジュールを使用しており、このモジュールはオペレーティングシステムの暗号ライブラリを使用します。ほとんどの Linux ディストリビューションでは、これは OpenSSL です。OpenSSL は最近、ハイブリッド TLS のサポートを 発表 し、バージョン 3.5 ではデフォルトで有効になっています。ただし、OpenSSL 3.5 はまだほとんどのオペレーティングシステムディストリビューションでデフォルトになっていません。 テストを可能にするため、標準の Python ディストリビューションと一緒に OpenSSL 3.5 をインストールする Dockerfile を提供しています。これにより、Python アプリケーションでポスト量子ハイブリッド TLS 接続を実行できます。この Dockerfile には、 boto3 や requests などの一般的なパッケージもインストールされています。AWS サービス ( boto3 と AWS コマンドラインインターフェイス (AWS CLI) を使用)、任意の HTTPS エンドポイント ( requests を使用)、TLS で保護された TCP サーバー (Python の標準ライブラリ ssl モジュールを使用) との基本的なやり取りを行うサンプル Python コードを提供しています。 以下のセクションでは、この Dockerfile を使用して Python アプリケーションから AWS サービスへのポスト量子 TLS 接続をテストする方法を説明します。 コンテナのビルド このコンテナはローカルマシンでビルドすることも、 Amazon Elastic Compute Cloud (Amazon EC2) や AWS CloudShell などのクラウド環境でビルドすることもできます。なお、お使いのマシンと AWS 間のネットワークパスを検証したい場合は、コンテナをローカルでビルドして実行する必要があります。コンテナをビルドするための唯一の前提条件は、Docker (または同等のコンテナツール) がインストールされていることです。簡単にするため、以下の手順では主に Linux CloudShell 環境でこれらのコマンドを実行することを想定しています。 サンプルリポジトリ をクローンします。 git clone https://github.com/aws-samples/sample-post-quantum-tls-python サンプルのディレクトリに移動し、以下のコマンドを実行してコンテナをビルドします。 cd sample-post-quantum-tls-python &amp;&amp; docker build . -t pq-tls-python コンテナの実行 前述のサンプルを実行するには、以下のコマンドを実行します。 docker run --rm \ -e AWS_ACCESS_KEY_ID=$(aws configure get aws_access_key_id) \ -e AWS_SECRET_ACCESS_KEY=$(aws configure get aws_secret_access_key) \ -it pq-tls-python \ test.sh 上記のコマンドは、 AWS Secrets Manager の ListSecrets API を呼び出す権限を持つ AWS CLI のデフォルトプロファイルが設定されていることを前提としています。この権限があれば、Secrets Manager のポスト量子対応 API エンドポイントに対して、機密情報やシークレット値を返さない基本的な読み取り専用のテスト呼び出しを行うことができます。CloudShell では、 aws configure でアクセスキーとシークレットキーの値を設定する必要があります。Amazon EC2 では、 インスタンスプロファイルを設定 して、アクセスキーとシークレットキーの環境変数を不要にできます。 Python が使用する暗号ライブラリの名前とバージョンを出力した後、 test.sh は以下の順序でハイブリッド TLS 接続をテストします。 Python の socket モジュールと ssl モジュールを使用した TCP ソケット通信 requests ライブラリを使用した HTTP リクエストの実行 boto3 と AWS CLI を使用した AWS API リクエストの実行 テストが成功すると、以下の出力が表示されます。 Crypto library: OpenSSL 3.5.0 8 Apr 2025 Testing ssl socket... ok Testing requests... ok Testing boto3... ok Testing AWS CLI... ok 必要に応じて、 tests/ ディレクトリ内のサンプルを確認、変更、拡張できます。提供されている test.sh スクリプトを実行する代わりに、以下のコマンドで対話型シェルにアクセスできます。 docker run --rm -it pq-tls-python テスト用にファイルを追加または変更した場合は、必ずコンテナを再ビルドしてください。 ポスト量子 TLS ネゴシエーションの確認 ポスト量子ハイブリッド TLS がネゴシエートされたことを確認するには、サンプルの TLS ハンドシェイクを検査して、ポスト量子ハイブリッド TLS 鍵交換が実行されたことを確認します。これを行うには、ホストのネットワークトラフィックをキャプチャする必要があります。CloudShell では、以下のコマンドを使用してキャプチャできます。 sudo tcpdump -A -i docker0 -w pq_tls.pcap このコマンドにより、Docker のネットワークインターフェイス docker0 上のトラフィックがキャプチャされます。コンテナをローカルで実行している場合は、Linux の docker0 や MacOS の en0 などのローカルネットワークインターフェイスで Wireshark の GUI を使用してパケットキャプチャを実行することもできます。 次に、別のターミナルで「 コンテナの実行 」セクションの Docker run コマンドを使用してテストスイートを実行します。前述と同様に、ターミナルに成功メッセージが表示され、 tcpdump を使用している場合は pq_tls.pcap という名前の新しいファイルが作成されます。このファイルを CloudShell から ダウンロード して、ローカルの Wireshark で表示できます。具体的には、クライアントまたはサーバーの Hello ハンドシェイクメッセージ内の key_share 拡張を確認します。Wireshark を使用してパケットキャプチャを表示する場合は、表示フィルター tls.handshake を指定して、ハンドシェイクメッセージのみを表示できます。パケットキャプチャは図 1 のようになります。 図 1: Wireshark でのパケットキャプチャ表示 図 1 では、サーバーの Hello ハンドシェイクメッセージで X25519MLKEM768 が選択されており、ポスト量子ハイブリッド TLS が正常にネゴシエートされたことがわかります。 まとめ この記事では、Dockerfile を使用して Python でポスト量子ハイブリッド TLS をテストする方法を紹介しました。この AWS サンプル を使用すると、以下の通信でポスト量子ハイブリッド TLS 接続をテストできます。 boto3 または AWS CLI を使用した AWS API リクエスト requests を使用した一般的な HTTPS リクエスト Python の socket モジュールと ssl モジュールを使用した TLS で保護された TCP ソケット通信 今後のポスト量子ハイブリッド TLS 移行に備えて、この AWS サンプルを使用してネットワークと Python アプリケーションの検証を開始することをお勧めします。AWS はお客様の移行をサポートすることに尽力しており、ポスト量子ハイブリッド TLS も例外ではありません。 この記事についてご質問がある場合は、 AWS サポート にお問い合わせください。 Will Childs-Klein Will は AWS Cryptography のシニアソフトウェアエンジニアで、暗号ライブラリの開発、ソフトウェアパフォーマンスの最適化、ポスト量子暗号の実用化に注力しています。以前は AWS で Storage Gateway、Elastic File System、DataSync などのデータストレージおよび転送サービスに携わっていました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2022 年 7 月 5 日に公開された AWS Blog “ How to tune TLS for hybrid post-quantum cryptography with Kyber ” を翻訳したものです。 2024 年 1 月 30 日: このブログ記事の API は、AWS CRT Client の新しいバージョンで変更されました。 詳細についてはこちらのページを参照してください 。 2023 年 1 月 25 日: AWS KMS、ACM、Secrets Manager の TLS エンドポイントは、NIST のラウンド 3 で選定された KEM である Kyber のみをサポートするように更新されました。 s2n-tls と s2n-quic も Kyber のみをサポートするように更新されました。標準化の進行に伴い、BIKE やその他の KEM が追加される可能性があります。 2022 年 8 月 3 日: この記事は Secrets Manager の情報を含むように更新されました。 AWS は、 AWS Key Management Service (AWS KMS) 、 AWS Secrets Manager 、 AWS Certificate Manager (ACM) への接続に Kyber を使用したハイブリッドポスト量子 TLS を提供しています。このブログ記事では、ハイブリッドポスト量子 Kyber 実装のパフォーマンス特性を紹介し、Maven プロジェクトでの設定方法を説明し、Kyber ポスト量子暗号 (PQC) に向けた接続設定の準備について解説します。 学術機関、暗号コミュニティ、 米国国立標準技術研究所 (NIST) のパートナーによる 5 年間の集中的な研究と暗号解析を経て、NIST はポスト量子鍵カプセル化メカニズム (KEM) の標準化に Kyber を選定しました。これは次世代の公開鍵暗号の幕開けを意味します。やがて、RSA や楕円曲線暗号 (ECC) など現在使用されている従来の鍵確立アルゴリズムは、量子耐性のある代替手段に置き換えられることになります。AWS Cryptography チームは、NIST 選定プロセスの各ラウンドを通じて候補 KEM の研究と分析を行ってきました。AWS は ラウンド 2 から Kyber のサポートを開始し、現在もそのサポートを継続しています。 RSA や ECC を解読できる暗号解読能力を持つ量子コンピュータはまだ存在しません。しかし、AWS は現在 Kyber を使用したハイブリッドポスト量子 TLS を提供しています。これにより、お客様は PQC のパフォーマンスの違いがワークロードにどのような影響を与えるかを確認できます。また、PQC を使用することで、 AWS KMS 、 Secrets Manager 、 ACM への接続における既に高いセキュリティ基準がさらに向上するため、長期的な機密性を必要とするお客様にとって特に有効な機能となっています。 (訳注：本ブログ執筆時点では Kyber は標準化前でしたが、2024 年 8 月に NIST により ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, FIPS 203) として正式に標準化されました。AWS KMS、ACM、Secrets Manager は現在、標準化された ML-KEM をサポートしています。詳細は「 ML-KEM post-quantum TLS now supported in AWS KMS, ACM, and Secrets Manager 」を参照してください。) Kyber を使用したハイブリッドポスト量子 TLS のパフォーマンス ハイブリッドポスト量子 TLS は、従来の暗号のみと比較してレイテンシーと帯域幅のオーバーヘッドが発生します。このオーバーヘッドを定量化するために、 s2n-tls がハイブリッドポスト量子 (ECDHE + Kyber) 鍵確立と ECDHE 単独のネゴシエーションにかかる時間を測定しました。テストは、米国東部 (バージニア北部) AWS リージョンの Amazon Elastic Compute Cloud (Amazon EC2) c6i.4xlarge インスタンス上で Linux perf サブシステムを使用して実施し、一般的なインターネットレイテンシーを含めるために米国西部 (オレゴン) リージョンで稼働するテストサーバーに 2,000 回の TLS 接続を開始しました。 図 1 は、従来の ECDHE とハイブリッドポスト量子 (ECDHE + Kyber) 鍵確立を使用した TLS ハンドシェイクのレイテンシーを示しています。列は、クライアントとサーバーが消費した CPU 時間と、ネットワーク経由でのデータ送信に費やした時間を比較できるように分けて表示しています。 図 1: 従来の TLS ハンドシェイクとハイブリッドポスト量子 TLS ハンドシェイクのレイテンシー比較 図 2 は、従来の ECDHE とハイブリッドポスト量子 (ECDHE + Kyber) 鍵確立の両方について、クライアント側で測定した TLS ハンドシェイク中の送受信バイト数を示しています。 図 2: 従来の TLS ハンドシェイクとハイブリッドポスト量子 TLS ハンドシェイクの帯域幅比較 このデータから、ハイブリッドポスト量子鍵確立を使用した場合のオーバーヘッドは、クライアント側で 0.25 ms、サーバー側で 0.23 ms、ネットワーク上で 2,356 バイトが追加されることがわかります。リージョン内テストではネットワークレイテンシーはより低くなります。レイテンシーは、ネットワーク状況、CPU パフォーマンス、サーバー負荷、その他の変数によっても異なる場合があります。 結果は、Kyber のパフォーマンスが優れていることを示しています。追加のレイテンシーは、 以前のブログ記事 で分析した NIST PQC 候補の中でトップクラスです。実際、これらの暗号のパフォーマンスは最新のテストで向上しています。これは、x86-64 アセンブリ最適化バージョンの暗号が利用可能になったためです。 Maven プロジェクトでハイブリッドポスト量子 TLS を設定する このセクションでは、Kyber を使用したアセンブリ最適化済みのハイブリッドポスト量子 TLS を設定するための Maven 設定とコード例を紹介します。 Maven プロジェクトでハイブリッドポスト量子 TLS を設定するには AWS SDK for Java 2.x 用 AWS Common Runtime HTTP クライアント のプレビューリリースを取得します。Maven の依存関係設定では、以下のコードサンプルに示すようにバージョン 2.17.69-PREVIEW 以降を指定する必要があります。 &lt;dependency&gt; &lt;groupId&gt;software.amazon.awssdk&lt;/groupId&gt; aws-crt-client &lt;version&gt;[2.17.69-PREVIEW,]&lt;/version&gt; &lt;/dependency&gt; コードの初期化時に目的の暗号スイートを設定します。以下のコードサンプルは、最新のハイブリッドポスト量子暗号スイートを使用するように AWS KMS クライアントを設定する方法を示しています。 // Check platform support if(!TLS_CIPHER_PREF_PQ_TLSv1_0_2021_05.isSupported()){ throw new RuntimeException("Hybrid post-quantum cipher suites are not supported."); } // Configure HTTP client SdkAsyncHttpClient awsCrtHttpClient = AwsCrtAsyncHttpClient.builder() .tlsCipherPreference(TLS_CIPHER_PREF_PQ_TLSv1_0_2021_05) .build(); // Create the AWS KMS async client KmsAsyncClient kmsAsync = KmsAsyncClient.builder() .httpClient(awsCrtHttpClient) .build(); これで、AWS KMS クライアントで行われるすべての呼び出しがハイブリッドポスト量子 TLS を使用するようになります。上記の例と同様に、 AcmAsyncClient または AWSSecretsManagerAsyncClient を使用することで、ACM や Secrets Manager でも最新のハイブリッドポスト量子暗号スイートを使用できます。 ハイブリッドポスト量子 TLS の接続設定をチューニングする ハイブリッドポスト量子 TLS は初回ハンドシェイク時にレイテンシーと帯域幅のオーバーヘッドが発生しますが、そのコストは TLS セッションの期間全体で分散でき、接続設定を微調整することでさらに削減できます。このセクションでは、ハイブリッド PQC が TLS 接続に与える影響を軽減する 3 つの方法として、接続プーリング、接続タイムアウト、TLS セッション再開について説明します。 接続プーリング 接続プールは、サーバーへのアクティブな接続数を管理します。接続を閉じて再度開くことなく再利用できるため、接続確立のコストを時間の経過とともに分散できます。接続セットアップ時間の一部は TLS ハンドシェイクであるため、接続プールを使用することでハンドシェイクレイテンシーの増加による影響を軽減できます。 これを説明するために、テストサーバーに対して毎秒約 200 トランザクションを生成するテストアプリケーションを作成しました。HTTP クライアントの最大同時接続数設定を変更し、テストリクエストのレイテンシーを測定しました。AWS CRT HTTP クライアントでは、これは maxConcurrency 設定です。接続プールにアイドル状態の接続がない場合、リクエストレイテンシーには新しい接続の確立時間が含まれます。Wireshark を使用してネットワークトラフィックをキャプチャし、アプリケーションの実行期間中に発生した TLS ハンドシェイクの数を観察しました。図 3 は、 maxConcurrency 設定を増加させた場合のリクエストレイテンシーと TLS ハンドシェイク数を示しています。 図 3: 同時接続プールサイズの増加に伴うリクエストレイテンシーの中央値と TLS ハンドシェイク数 最も大きなレイテンシー改善は、 maxConcurrency 値が 1 より大きい場合に発生しました。それ以上では、レイテンシーの改善効果は頭打ちになりました。 maxConcurrency 値が 10 以下のすべてのケースで、接続内で追加の TLS ハンドシェイクが発生しましたが、レイテンシーの中央値にはあまり影響しませんでした。これらの変曲点はアプリケーションのリクエスト量によって異なります。重要なポイントは、接続プーリングにより接続を再利用でき、TLS ネゴシエーション時間の増加コストを多くのリクエストに分散できるということです。 maxConcurrency オプションの使用方法の詳細については、 AWS SDK for Java API リファレンス を参照してください。 接続タイムアウト 接続タイムアウトは接続プーリングと連携して機能します。接続プールを使用していても、アイドル状態の接続がプールによって閉じられるまでの時間には制限があります。この時間制限を調整することで、接続確立のオーバーヘッドを削減できます。 この設定を視覚化する良い方法は、バースト的なトラフィックパターンを想像することです。接続プールの同時接続数をチューニングしても、バースト期間がアイドル時間制限より長いため、接続が閉じ続けてしまいます。最大アイドル時間を増やすことで、バースト的な動作にもかかわらず、これらの接続を再利用できます。 接続タイムアウトの影響をシミュレートするために、10 個のスレッドを起動し、それぞれが 1 分間にわたって 5 秒ごとの定期スケジュールで同時にアクティブになるテストアプリケーションを作成しました。各スレッドが独自の接続を持てるように maxConcurrency を 10 に設定しました。AWS CRT HTTP クライアントの connectionMaxIdleTime を最初のテストでは 1 秒に、2 番目のテストでは 10 秒に設定しました。 最大アイドル時間が 1 秒の場合、各バースト間の時間中に 10 個すべてのスレッドの接続が閉じられました。その結果、テスト期間中に合計 100 個の接続が形成され、リクエストレイテンシーの中央値は 20.3 ms になりました。最大アイドル時間を 10 秒に変更すると、最初の 10 個の接続が後続の各バーストで再利用され、リクエストレイテンシーの中央値は 5.9 ms に減少しました。 アプリケーションに適した connectionMaxIdleTime を設定することで、TLS ネゴシエーション時間を含む接続確立のオーバーヘッドを削減し、アプリケーションのライフサイクル全体で時間を節約できます。 connectionMaxIdleTime オプションの使用方法の詳細については、 AWS SDK for Java API リファレンス を参照してください。 TLS セッション再開 TLS セッション再開により、クライアントとサーバーは新しい共有シークレットを確立するために通常実行される鍵合意をバイパスできます。代わりに、以前にネゴシエートされた共有シークレット、または以前のシークレットから派生した共有シークレットを使用して通信を迅速に再開します (実装の詳細は使用している TLS のバージョンによって異なります)。この機能はクライアントとサーバーの両方がサポートしている必要がありますが、利用可能な場合、TLS セッション再開により、ハイブリッドポスト量子 TLS に関連するハンドシェイク時間と帯域幅の増加を複数の接続のライフサイクル全体で分散できます。 まとめ この記事で説明したように、Kyber を使用したハイブリッドポスト量子 TLS は AWS KMS、Secrets Manager、ACM で利用可能です。この新しい暗号スイートによりセキュリティ基準が向上し、ワークロードをポスト量子暗号に備えることができます。ハイブリッド鍵合意は従来の ECDHE と比較して追加のオーバーヘッドがありますが、接続プーリング、接続タイムアウト、TLS セッション再開などの接続設定をチューニングすることで、これらの増加を軽減できます。 AWS KMS 、 Secrets Manager 、 ACM で今すぐハイブリッド鍵合意の使用を開始しましょう。 Brian Jarvis Brian は AWS Cryptography のシニアソフトウェアエンジニアです。ポスト量子暗号と暗号ハードウェアに関心を持っています。以前は AWS Security で、社内全体で使用される内部サービスの開発に携わっていました。Brian は Vanderbilt University で学士号を、George Mason University でコンピュータエンジニアリングの修士号を取得しています。「いつか」博士号を取得する予定です。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。