本ブログは 2026 年 4 月 24 日に公開された AWS Blog “ Protecting your secrets from tomorrow’s quantum risks ” を翻訳したものです。 AWS のポスト量子暗号 (PQC) 移行計画 で説明したとおり、 harvest now, decrypt later (今すぐ収集し、後で復号する) 攻撃 (HNDL) のリスクへの対処は、ポスト量子移行計画の重要な部分です。量子耐性のある機密性をサポートするためにワークロードのクライアント側をアップグレードすることは、 PQC 責任共有モデル においてお客様側が担う重要な側面です。PQC アップグレードの計画と実行のタイムラインは、リージョンや業界によって異なり、お客様自身のビジネスリスクプロファイルに依存します。詳細については、AWS の PQC に関するよくある質問 を参照してください。 AWS Secrets Manager は SSL/TLS を使用して AWS リソースと通信し、現在すべての AWS リージョンで TLS 1.2 と 1.3 をサポートしています。この機能をサポートするクライアントに対しては、ハイブリッドポスト量子鍵交換を使用した TLS 1.3 をサポートしています。 ハイブリッドポスト量子 アプローチは、従来の暗号 (X25519 など) とポスト量子アルゴリズム (ML-KEM) を組み合わせて TLS 接続を確立することで、現在の古典的な攻撃と将来の量子コンピュータの脅威の両方からシークレットを保護します。ワークロードが Secrets Manager にどのようにアクセスする場合でも、HNDL によるシークレットへのリスクに対処するために必要なのは、このクライアント側のソフトウェアアップグレードだけです。保管中のシークレットは、 AWS Key Management Service (AWS KMS) が管理するキーを使用して、すでに暗号化されています。適切に実装された対称暗号は量子耐性があると考えられていますが、非対称暗号は量子の脅威に直面しています。詳細については、 AWS re:Inforce 2025 – Post-Quantum Cryptography Demystified をご覧ください。 クライアント側のアップグレードにおける開発者の負担を軽減するため、以下の Secrets Manager クライアントが、Secrets Manager への接続を開始する際にポスト量子 TLS を有効化して優先するようになりました。対象となるのは、 Secrets Manager Agent ( v2.0.0 以降)、 AWS Lambda 拡張機能 (v19 以降)、 Secrets Manager CSI Driver ( v2.0.0 以降) です。SDK ベースのクライアントの場合、ハイブリッドポスト量子鍵交換はサポートされている AWS SDK で利用できます。有効化の要件は、言語、バージョン、オペレーティングシステムによって異なります。お使いの SDK クライアントについては、以下の表を参照してください。 このリリースは、システムをポスト量子暗号に移行し、お客様の移行も容易にするという AWS の継続的な取り組みの一環です。詳細については、 ポスト量子暗号 を参照してください。 クライアントのハイブリッドポスト量子鍵交換の要件 以下の表は、各クライアントの動作をまとめたものです。クライアントがハイブリッドポスト量子鍵交換をサポートするようにアップグレードされると、Secrets Manager のサービスエンドポイントは TLS ハンドシェイク中に自動的にこれを選択します。Secrets Manager API を呼び出す際にワークロードがハイブリッドポスト量子鍵交換を使用し始めるために必要なのは、表に記載されているバージョンへのアップグレードだけです。 クライアント 要件 Secrets Manager Agent TLS でのハイブリッドポスト量子鍵交換がデフォルトで優先されます ( v2.0.0 以降 ) AWS Lambda 拡張機能 TLS でのハイブリッドポスト量子鍵交換がデフォルトで優先されます (バージョン 19 以降) Secrets Manager CSI Driver TLS でのハイブリッドポスト量子鍵交換がデフォルトで優先されます ( v2.0.0 以降) AWS SDK for Rust TLS でのハイブリッドポスト量子鍵交換がデフォルトで優先されます ( 2025 年 8 月 29 日以降のリリース ) AWS SDK for Go TLS でのハイブリッドポスト量子鍵交換がデフォルトで優先されます ( Go v1.24 以降 ) AWS SDK for Node.js TLS でのハイブリッドポスト量子鍵交換がデフォルトで優先されます ( Node.js v22.20 および v24.9.0 以降 ) AWS SDK for Kotlin Linux で TLS でのハイブリッドポスト量子鍵交換がデフォルトで優先されます (v1.5.78 以降) AWS SDK for Python AWS SDK for Python (boto3) は、TLS に OS が提供する OpenSSL を使用します TLS でのハイブリッドポスト量子鍵交換には、 OpenSSL 3.5 以降がインストールされた システムでの実行が必要です AWS SDK for Java v2 AWS SDK for Java v2 では、 postQuantumTlsEnabled を使用して設定する場合に、PQ TLS をサポートする AWS CRT HTTP クライアントが必要です Secrets Manager キャッシュクライアント Secrets Manager キャッシュライブラリは AWS SDK 上に構築されており、その TLS 動作を継承します。Java に関する注意: TLS でのハイブリッドポスト量子鍵交換を有効にするには、 JDBC ドライバーフラグ と Java キャッシュフラグ を設定する必要があります Secrets Manager Agent、Lambda 拡張機能、または CSI Driver を使用している場合は、TLS でのハイブリッドポスト量子鍵交換をデフォルトとして使用するために、記載されているバージョンにアップグレードしてください。表に記載されているバージョンの AWS SDK for Rust、Go、または Node.js を使用しているお客様は、すでにアップグレード済みであり、追加のアクションは必要ありません。SDK が API コールに対してハイブリッドポスト量子鍵交換を選択します。AWS SDK for Python を使用しているお客様の場合、TLS でのハイブリッドポスト量子鍵交換には、ホストシステムに OpenSSL 3.5 以降が存在する必要があります。これを確認して有効化する方法については、 AWS Secrets Manager ドキュメント を参照してください。AWS SDK for Java v2 を使用しているお客様の場合、TLS でのハイブリッドポスト量子鍵交換には AWS CRT HTTP クライアントの使用が必要です。これを有効にするには、CRT クライアントで postQuantumTlsEnabled(true) を設定する必要があります。 クライアントのバージョンが表に記載されている要件を満たした後は、接続が実際にハイブリッドポスト量子鍵交換を使用していることを検証できます。 接続がハイブリッドポスト量子鍵交換を使用していることを検証する方法 ML-KEM を使用したハイブリッドポスト量子鍵交換が Secrets Manager クライアントでデフォルトで有効になったため (前述の表を参照)、ほとんどのお客様にとって、正しい動作の検証やリグレッションの検出のための継続的なモニタリングは不要です。ただし、セキュリティチームやコンプライアンス責任者は、Secrets Manager API コールがハイブリッド鍵交換をネゴシエートしていることを確認したい場合があります。サーバー側では、 AWS CloudTrail を使用して TLS でのハイブリッドポスト量子鍵交換を確認できます。クライアント側では、Wireshark などのユーティリティを使用するか、主要なウェブブラウザに組み込まれた開発者ツールを使用して、TLS ハンドシェイクの詳細を確認できます。 検証は 2 段階のプロセスです。まず、Secrets Manager クライアントを使用してシークレットを取得し、 GetSecretValue API コールを生成します。次に、 AWS CloudTrail で、そのコールがハイブリッドポスト量子鍵交換をネゴシエートしたことを確認します。 Secrets Manager クライアントを使用してシークレットを取得する 以下の例では、Secrets Manager Agent、Lambda 拡張機能、CSI Driver を使用してシークレットを取得する方法を示します。これらはいずれも、 GetSecretValue API を呼び出す際に自動的にハイブリッドポスト量子鍵交換をネゴシエートします。 EC2 インスタンスで Secrets Manager Agent を使用してハイブリッドポスト量子 TLS を検証するには: Amazon Elastic Compute Cloud (Amazon EC2) インスタンスにエージェントをインストールし、シークレットを取得するためのクライアントとして使用します。 AWS Secrets Manager Agent の手順に従います EC2 インスタンスプロファイルが、シークレットを取得するための secretsmanager:GetSecretValue 権限を持っていることを確認します プライベート EC2 インスタンス に接続します EC2 インスタンスにエージェントをインストールします エージェントを使用して シークレットを取得 します curl -H "X-Aws-Parameters-Secrets-Token: $(</tmp/awssmatoken)" localhost:2773/secretsmanager/get?secretId=<YOUR-SECRET-ARN> CloudTrail がログを配信するまで約 5 分間待ちます CloudTrail イベント履歴 に移動し、 GetSecretValue イベントを検索します Lambda 拡張機能を使用してハイブリッドポスト量子 TLS を検証するには: AWS パラメータおよび Secrets Manager Lambda 拡張機能を使用して、直接 API コールを介して Secrets Manager からシークレットを取得する Lambda 関数を作成します。 AWS パラメータおよびシークレット Lambda 拡張機能の使用 に従って、Lambda レイヤーと Lambda 関数を作成します 最新の拡張機能バージョンを選択します CloudTrail がログを配信するまで約 5 分間待ちます CloudTrail イベント履歴 に移動し、 GetSecretValue イベントを検索します Amazon EKS で CSI Driver を使用してハイブリッドポスト量子 TLS を検証するには: Amazon Elastic Kubernetes Service (Amazon EKS) クラスターで、 AWS Secrets Store CSI Driver プロバイダーを使用して Secrets Manager からシークレットを取得 し、Kubernetes ポッドで使用します。 インストールされているアドオンのバージョンが 2.0.0 以降であることを確認します eksctl get addon --cluster <CLUSTER-NAME> --name aws-secrets-store-csi-driver-provider シークレットをマウントするポッドを再起動するか、新しいポッドをデプロイして、シークレットの取得をトリガーします CloudTrail がログを配信するまで約 5 分間待ちます CloudTrail イベント履歴 に移動し、 GetSecretValue イベントを検索します CloudTrail を使用してハイブリッドポスト量子鍵交換を確認する CloudTrail ログ には、Secrets Manager API コールの tlsDetails フィールドが含まれています。TLS でのハイブリッドポスト量子鍵交換がアクティブな場合、 tlsDetails の keyExchange フィールドに X25519MLKEM768 が表示されます。各 CloudTrail レコードには、暗号スイートと、利用可能な場合は TLS ハンドシェイク中にネゴシエートされた鍵交換グループを含む tlsDetails フィールドが含まれています。 CloudTrail 用の AWS マネジメントコンソールまたは AWS コマンドラインインターフェイス (AWS CLI) を使用して、 CloudTrail イベント履歴 を操作できます。 コンソールを使用して CloudTrail イベントを検索するには: 正しい AWS リージョンにいることを確認します CloudTrail コンソールを開き、[イベント履歴] を選択します [ルックアップ属性] フィルターで、[イベント名] と [GetSecretValue] を選択します 図 1: イベント名で CloudTrail イベント履歴を検索 イベントを選択します 図 2: イベントを選択 ページの [イベントレコード] セクションで出力を表示します 図 3: CloudTrail – GetSecretValue イベント AWS CLI を使用して CloudTrail イベントを検索するには: AWS CLI を使用して、最新のイベントを選択し、出力を確認します。 aws cloudtrail lookup-events \ --lookup-attributes AttributeKey=EventName,AttributeValue=GetSecretValue \ --max-results 5 \ --region <YOUR-REGION> \ --query 'Events[0].CloudTrailEvent' \ --output text GetSecretValue API コールの CloudTrail イベントの例: 以下の例では、 userAgent フィールドは、Secrets Manager への接続にクライアントとして使用されたものを反映しています。 注 : userAgent の値は、使用するクライアントによって異なります。 { "eventVersion": "1.11", "userIdentity": { "type": "AssumedRole", "principalId": "AROA123456789EXAMPLE:i-0c1a23fc456b7ab89", "arn": "arn:aws:sts::111122223333:assumed-role/YOUR-EC2-INSTANCE-PROFILE/i-0c1a23fc456b7ab89", "accountId": "111122223333", "accessKeyId": "ASIAIOSFODNN7EXAMPLE", "sessionContext": { "sessionIssuer": { "type": "Role", "principalId": "AROA123456789EXAMPLE", "arn": "arn:aws:iam::111122223333:role/YOUR-EC2-INSTANCE-PROFILE", "accountId": "111122223333", "userName": "YOUR-EC2-INSTANCE-PROFILE" }, "attributes": { "creationDate": "2026-03-27T17:08:37Z", "mfaAuthenticated": "false" }, "ec2RoleDelivery": "2.0" }, "inScopeOf": { "issuerType": "AWS::EC2::Instance", "credentialsIssuedTo": "arn:aws:ec2:eu-west-2:111122223333:instance/i-0c1a23fc456b7ab89" } }, "eventTime": "2026-03-27T17:12:54Z", "eventSource": "secretsmanager.amazonaws.com", "eventName": "GetSecretValue", "awsRegion": "eu-west-2", "sourceIPAddress": "1.2.3.4", "userAgent": "aws-sdk-rust/1.3.14 os/linux lang/rust/1.94.1 aws-secrets-manager-agent/2.0.0", "requestParameters": { "secretId": "arn:aws:secretsmanager:eu-west-2:111122223333:secret:your-secret" }, "responseElements": null, "requestID": "027507ea-f377-43d9-bf2f-646d4dc19223", "eventID": "f9c3ed0f-81f5-450b-a561-2b9e54fa9e73", "readOnly": true, "resources": [ { "accountId": "111122223333", "type": "AWS::SecretsManager::Secret", "ARN": "arn:aws:secretsmanager:eu-west-2:111122223333:secret:your-secret" } ], "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "111122223333", "eventCategory": "Management", "tlsDetails": { "tlsVersion": "TLSv1.3", "cipherSuite": "TLS_AES_128_GCM_SHA256", "clientProvidedHostHeader": "secretsmanager.eu-west-2.amazonaws.com", "keyExchange": "X25519MLKEM768" } } keyExchange フィールドに X25519MLKEM768 が表示されている場合、TLS でのハイブリッドポスト量子鍵交換がアクティブです。 X25519 などの従来のアルゴリズムが表示されている場合は、クライアントが ML-KEM のサポートを通知していないため、クライアントのバージョンと設定を確認する必要があります。 トラブルシューティング クライアントを更新した後も Secrets Manager API コールが X25519MLKEM768 をネゴシエートしない場合は、この記事の冒頭付近にある クライアントのハイブリッドポスト量子鍵交換の要件 セクションに記載されているとおり、SDK バージョン、OpenSSL バージョン (Python)、ファイアウォールまたはプロキシの設定を確認してください。 次のステップ このリリースは、より広範な移行における 1 ステップです。AWS は、 AWS PQC 移行計画 のワークストリーム 2 の一環として、AWS サービスの HTTPS エンドポイント全体で ML-KEM のサポートを引き続き展開しており、パブリック AWS エンドポイント全体での完全なカバレッジを目指しています。 ML-KEM の標準化前の前身である CRYSTALS-Kyber のサポートは、2026 年に AWS エンドポイント全体で段階的に廃止されます。CRYSTALS-Kyber のサポートのみを通知する古い SDK バージョンを使用しているお客様は、廃止されたアルゴリズムをネゴシエートするのではなく、従来の TLS に適切にフォールバックします。このフォールバックを回避するには、この記事に記載されている SDK バージョンにアップグレードしてください。 PQC 移行の道のりは、転送中のデータの機密性にとどまりません。AWS の PQC への取り組みやお客様側の責任共有に関する最新の動向を把握するには、 AWS ポスト量子暗号 ページをフォローしてください。 まとめ AWS Secrets Manager は、シークレットの保護とコンプライアンスの取り組みのサポートに役立てるため、ML-KEM を使用したハイブリッドポスト量子鍵交換をデフォルトで有効にするようになりました。この更新は、最新のクライアントバージョンを使用しているお客様にとって、コード変更や設定の更新を必要としません。 この記事では、AWS Secrets Manager がハイブリッドポスト量子暗号を使用して TLS 接続を保護する方法、どのクライアントがこの機能をサポートしているか、そして harvest now, decrypt later 攻撃から接続が保護されていることを検証する方法について説明しました。 今回のリリースの恩恵を今すぐ受けるには、以下を実施してください。 Secrets Manager クライアント (Agent、Lambda 拡張機能、または CSI Driver) を利用可能な最新バージョンにアップグレードして、ML-KEM を使用したハイブリッドポスト量子鍵交換を有効にする ワークロードがキャッシュクライアントではなく AWS SDK を使用している場合は、AWS SDK と基盤となる依存関係を、この記事に記載されている最小バージョンにアップグレードする Secrets Manager API コールの CloudTrail tlsDetails の keyExchange フィールドを確認して、TLS でのハイブリッドポスト量子鍵交換がアクティブであることを検証する 企業のファイアウォールやプロキシを経由するネットワークパスを含め、環境内でエンドツーエンドのハイブリッドポスト量子鍵交換 TLS 接続をテストする AWS は引き続きポスト量子暗号のサポートを展開していきます。より広範な移行の取り組みについては、 AWS PQC 移行計画 を参照してください。また、より広範な環境の最新の暗号インベントリを維持して、移行が必要となる従来の公開鍵暗号の他の使用箇所を特定してください。 CISA Quantum-Readiness ガイダンス と AWS PQC 移行計画が、その良い出発点となります。 追加リソース AWS KMS、ACM、Secrets Manager で ML-KEM ポスト量子 TLS をサポート開始 ポスト量子 TLS を Python で実装・検証する方法 P. Stéphanie Mbappe Stéphanie は Amazon Web Services のセキュリティコンサルタントです。お客様のセキュリティの取り組みのあらゆる段階で支援することに喜びを感じています。学習や新しいソリューションの設計、そして自分の知識を他の人と共有することを楽しんでいます。 Tobias Nickl Tobias は Amazon Web Services のセキュリティコンサルタントで、セキュリティアーキテクチャとクラウド変革を専門としています。AWS のお客様と協力して、現在および新たに出現する脅威の両方に対処するセキュリティアーキテクチャを設計および実装しています。その活動を通じて、組織がクラウドの成熟度とともに進化するセキュリティ戦略を構築できるよう支援しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

こんにちは、クラウドエース株式会社 第一開発部のダッフィです。 近年、Web アプリケーションや業務システムを支える サーバー側のインフラ を、自社の機械室ではなくクラウドプロバイダ上に構築する事例が増えました。一方で、執務するオフィスの LAN や自宅の回線・Wi-Fi ルーターなど、足元のネットワークは今もオンプレミス（または契約プロバイダの設備）に依存しています。クラウド化されているのは主に「クラウド側に置く計算・ストレージ・仮想ネットワーク（VPC ネットワークなど）」をどう設計・運用するか の領域であり、コンソールからマルチリージョンの経路やファイアウォールを組める点は、その文

本ブログは 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 の 中島 章博 が翻訳しました。