本ブログは 2025 年 11 月 17 日に公開された AWS Blog “ Post-quantum (ML-DSA) code signing with AWS Private CA and AWS KMS ” を翻訳したものです。 2025 年 6 月の AWS Key Management Service (AWS KMS) における ML-DSA サポートの発表 に続き、 AWS Private Certificate Authority (AWS Private CA) でもポスト量子 ML-DSA 署名のサポートが導入 されました。 AWS Private CA を使用すると、独自のプライベート公開鍵基盤 (PKI) 階層を作成、管理できます。今回の対応により、コード署名、デバイス認証、 AWS IAM Roles Anywhere を使用した AWS 外部のワークロード認証、IKEv2/IPsec や 相互 TLS (mTLS) などの通信トンネルといったユースケースにおいて、プライベート PKI を使用してお客様が管理する耐量子の信頼の基点を構築し利用できるようになります。 AWS の ポスト量子暗号移行計画 で述べているとおり、耐量子の信頼の基点を確立することは、長期間にわたってセキュリティを維持する必要があるシステムにとって極めて重要です。 FIPS 204 で標準化された署名方式である ML-DSA は、大規模な展開に必要なパフォーマンス特性を維持しながら、量子コンピュータへの耐性を実現します。 以前、AWS Private CA と AWS KMS を使用した コード署名の方法を紹介 しました。本記事では、AWS KMS が提供するポスト量子署名機能と AWS Private CA のポスト量子コード署名 PKI を組み合わせる方法を説明します。ポスト量子 PKI のルート証明書を事前にプロビジョニングしておくことで、署名済みコードの利用者は、暗号解読能力を持つ量子コンピュータ (CRQC) を利用した攻撃を受けても、ソフトウェアが改ざんされていないことを信頼できます。デモンストレーションとして、 AWS SDK for Java を使用するサンプルプログラム diy-code-signing-kms-private-ca を使用します。このコードは、PKI インフラストラクチャの作成、コード署名証明書の生成、バイナリコードへの署名、およびその署名の検証を行います。本記事では機能をわかりやすく説明するためにステップごとに分解していますが、 README ファイルに記載されているコマンドで Runner をそのまま実行して動作を確認することもできます。 本記事では、入力バイナリデータに対して生成された署名をカプセル化するために CMS (Cryptographic Message Syntax) 標準を使用します。CMS は、信頼を確立するために使用される署名、X.509 証明書、および証明書チェーンを格納します。この署名は デタッチド署名 と呼ばれ、元のデータを含みません。デタッチド署名は、署名された元のファイルと組み合わせることで、OpenSSL などの標準ツールを使用してファイルの真正性を検証できます。 ポスト量子 PKI 階層の作成 本記事では、AWS Private CA を使用して コード署名 PKI を構築します。この PKI は、ルート CA が下位 CA に署名し、下位 CA がコード署名証明書に署名するという構成です。チェーン全体が耐量子の ML-DSA 証明書で構成されます。 CA 階層の作成 まず、ML-DSA を使用してポスト量子 CA 階層を作成します。この例では、ポスト量子署名アルゴリズムの ML-DSA-65 バリアントを使用します。 Runner.java ファイルで示されているように、AWS Java SDK を使用して以下のように実行できます。 PrivateCA rootPrivateCA = PrivateCA.builder() .withCommonName(ROOT_COMMON_NAME) .withType(CertificateAuthorityType.ROOT) .withAlgorithmFamily(ML_DSA_65_ALGORITHM_FAMILY) .getOrCreate(); PrivateCA subordinatePrivateCA = PrivateCA.builder() .withIssuer(rootPrivateCA).withCommonName(SUBORDINATE_COMMON_NAME) .withType(CertificateAuthorityType.SUBORDINATE) .withAlgorithmFamily(ML_DSA_65_ALGORITHM_FAMILY) .getOrCreate(); コード署名の準備 コード署名には、非対称キーペアとコード署名証明書が必要です。非対称 ML-DSA キーペアは AWS KMS で生成し、コード署名証明書は AWS Private CA から発行します。 AWS KMS で ML-DSA キーペアを作成 まず、コード署名用の非対称キーペアを作成します。CA 階層の作成時と同様に、AWS Java SDK を使用してこの AWS KMS キー (キーペア) を作成できます。署名は、AWS KMS 内のキーペアのプライベートキーで行います。対応するパブリックキーは、下位 CA が署名するコード署名リーフ証明書に含まれます。これらの呼び出しは、 Runner.java ファイルの main メソッド内で実行されます。 AsymmetricCMK codeSigningCMK = AsymmetricCMK .builder().withAlias(CMK_ALIAS) .withAlgorithmFamily(ML_DSA_65_ALGORITHM_FAMILY) .getOrCreate(); また、Security Blog の 「AWS KMS と ML-DSA を使用してポスト量子署名を作成する方法」 で紹介されているように、 AWS マネジメントコンソール または AWS コマンドラインインターフェイス (AWS CLI) を使用して AWS KMS でキーペアを生成することもできます。 コード署名証明書の発行 AWS Private CA を使用した証明書署名リクエスト (CSR) の作成は、2 つのステップで行います。まず、ID (Subject) と先ほど作成した AWS KMS パブリックキーを含む CSR を作成します。 Runner.java 内の以下のコードスニペットで、この処理を行います。 String codeSigningCSR = codeSigningCMK .generateCSR(END_ENTITY_COMMON_NAME); CSR をディスク上の csr.pem に書き出した場合、OpenSSL 3.5 以降で以下のコマンドを使用して内容を確認できます。 openssl req -in csr.pem -inform pem -text -noout Certificate Request: Data: Version: 1 (0x0) Subject: CN=CodeSigningCertificate Subject Public Key Info: Public Key Algorithm: ML-DSA-65 ML-DSA-65 Public-Key: pub: <Public Key Data> Attributes: Requested Extensions: X509v3 Basic Constraints: CA:FALSE Signature Algorithm: ML-DSA-65 Signature Value: <Signature Data> CSR に ML-DSA-65 パブリックキーが含まれていることがわかります。対応するプライベートキーがコード署名に使用されます。 次に、この CSR を使用して下位 CA からコード署名証明書を発行します。 PrivateCA.java ファイル の IssueCertificate リクエストの templateArn にコード署名テンプレートが使用されている点に注目してください。このテンプレートを使用することで、CSR で提示された値に関係なく、AWS Private CA が正しい Key Usage (KU) と Extended Key Usage (EKU) の拡張値を持つ証明書を発行できるようになります。 IssueCertificateRequest issueCertificateRequest = IssueCertificateRequest.builder() .idempotencyToken(UUID.randomUUID().toString()) .certificateAuthorityArn(subordinatePrivateCA.arn()) .csr(SdkBytes.fromUtf8String(csr)) .signingAlgorithm(algorithmFamily.getPcaSigningAlgorithm()) .templateArn("arn:aws:acm-pca:::template/CodeSigningCertificate/V1") .validity(validity) .build(); IssueCertificateResponse issueCertificateResponse = client .issueCertificate(issueCertificateRequest); String certificateArn = issueCertificateResponse.certificateArn(); GetCertificateRequest getCertificateRequest = GetCertificateRequest.builder() .certificateAuthorityArn(ca.arn()) .certificateArn(certificateArn) .build(); レスポンスには ML-DSA-65 コード署名証明書が含まれます。証明書を code-signing-cert.pem というファイル名で保存した後、OpenSSL 3.5 以降を使用して内容を確認できます。 openssl x509 -in code-signing-cert.pem -inform pem -text -noout Certificate: Data: Version: 3 (0x2) Serial Number: 1a:15:af:1e:64:8d:cd:29:b4:dc:66:2a:8b:1e:ee:b0 Signature Algorithm: ML-DSA-65 Issuer: CN=CodeSigningSubordinate-MLDSA65 Validity Not Before: Sep 24 13:10:38 2025 GMT Not After : Sep 24 14:10:38 2026 GMT Subject: CN=CodeSigningCertificate Subject Public Key Info: Public Key Algorithm: ML-DSA-65 ML-DSA-65 Public-Key: pub: <Public Key Data> X509v3 extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Authority Key Identifier: B7:EF:2E:C9:7A:A8:7E:B5:D6:2D:9A:3F:C7:A7:F8:9D:74:01:6A:EF X509v3 Subject Key Identifier: 7F:63:35:0C:56:F8:ED:F1:2A:DF:B5:2E:7C:F1:2C:D9:A0:0E:63:B6 X509v3 Key Usage: critical Digital Signature X509v3 Extended Key Usage: critical Code Signing Signature Algorithm: ML-DSA-65 Signature Value: <Signature Data> 証明書にコード署名キーペアの ML-DSA-65 パブリックキーと、下位 CA による ML-DSA-65 署名が含まれていることがわかります。また、KU と EKU の値も確認でき、AWS Private CA テンプレートによってコード署名用の証明書として適切に発行されていることを示しています。 コードへの署名 ここまでで、コード署名 PKI のセットアップが完了しました。AWS Private CA が発行したコード署名証明書と、AWS KMS に保管されている対応する ML-DSA キーペアの準備が整っています。 Java SDK を使用して、コードのバイナリファイルに対する CMS 署名を生成できます。内部的には、 Runner.java に示すように、ML-DSA キーペアを指定して AWS KMS Sign API を呼び出すことで署名処理を行っています。以下は Java コードの一部です。最初のスニペットでは、証明書チェーンを構築し、コード署名用の AWS KMS キー、署名者の証明書、およびコードファイルのバイト配列表現である <DATA_TO_SIGN> と組み合わせて、CMS 構造のデタッチド署名を生成します。 // Parse code-signing certificate from PEM X509CertificateHolder signerCert = CertificateUtils .fromPEM(codeSigningCertificate.certificate()); Collection<X509CertificateHolder> chainCerts = CertificateUtils .toCertificateHolders(codeSigningCertificate.certificateChain()); // Build certificate chain including code-signing cert and intermediate certs Collection<X509CertificateHolder> certChain = new ArrayList<> (); certChain.add(signerCert); // Parse certificate chain for (X509CertificateHolder chainCert : chainCerts) { if (!chainCert.equals(signerCert)) { certChain.add(chainCert); } } // Create detached CMS signature CMSCodeSigningObject cmsCodeSigningObject = CMSCodeSigningObject .createDetachedSignature( codeSigningCMK, ML_DSA_65_ALGORITHM_FAMILY, <DATA_TO_SIGN>, signerCert, certChain); コード署名オブジェクトは signature-MLDSA65.p7s としてディスクに書き出されます。OpenSSL 3.5 以降で内容を確認できます。 openssl cms -cmsout -in signature-MLDSA65.p7s -inform DER -print CMS_ContentInfo: contentType: pkcs7-signedData (1.2.840.113549.1.7.2) d.signedData: version: 1 digestAlgorithms: algorithm: shake256 (2.16.840.1.101.3.4.2.12) parameter: <ABSENT> encapContentInfo: eContentType: pkcs7-data (1.2.840.113549.1.7.1) eContent: <ABSENT> certificates: d.certificate: cert_info: version: 2 serialNumber: 0xD0B2937F5BABC80AD55C0A90E1DE7057 signature: algorithm: ML-DSA-65 (2.16.840.1.101.3.4.3.18) parameter: <ABSENT> issuer: CN=CodeSigningSubordinate-MLDSA65 validity: notBefore: Oct 28 15:05:27 2025 GMT notAfter: Oct 28 16:05:26 2026 GMT subject: CN=CodeSigningCertificate key: X509_PUBKEY: algor: algorithm: ML-DSA-65 (2.16.840.1.101.3.4.3.18) parameter: <ABSENT> public_key:(0 unused bits) ... issuerUID: <ABSENT> subjectUID: <ABSENT> extensions: object: X509v3 Basic Constraints (2.5.29.19) critical: FALSE value: 0000 - 30 00 0. object: X509v3 Authority Key Identifier (2.5.29.35) critical: FALSE value: 0000 - 30 16 80 14 b7 ef 2e c9-7a a8 7e b5 d60.......z.~.. 000d - 2d 9a 3f c7 a7 f8 9d 74-01 6a ef-.?....t.j. object: X509v3 Subject Key Identifier (2.5.29.14) critical: FALSE value: 0000 - 04 14 7f 63 35 0c 56 f8-ed f1 2a df b5...c5.V...*.. 000d - 2e 7c f1 2c d9 a0 0e 63-b6.|.,...c. object: X509v3 Key Usage (2.5.29.15) critical: TRUE value: 0000 - 03 02 07 80.... object: X509v3 Extended Key Usage (2.5.29.37) critical: TRUE value: 0000 - 30 0a 06 08 2b 06 01 05-05 07 03 030...+....... sig_alg: algorithm: ML-DSA-65 (2.16.840.1.101.3.4.3.18) parameter: <ABSENT> signature:(0 unused bits) ... d.certificate: cert_info: version: 2 serialNumber: 29577999257397559174219641462943780786 signature: algorithm: ML-DSA-65 (2.16.840.1.101.3.4.3.18) parameter: <ABSENT> issuer: CN=CodeSigningRoot-MLDSA65 [...] d.certificate: cert_info: version: 2 serialNumber: 0xB9419A2C5D2422B3A58A5B449546D74B signature: algorithm: ML-DSA-65 (2.16.840.1.101.3.4.3.18) parameter: <ABSENT> issuer: CN=CodeSigningRoot-MLDSA65 [...] crls: <ABSENT> signerInfos: version: 1 d.issuerAndSerialNumber: issuer: CN=CodeSigningSubordinate-MLDSA65 serialNumber: 0xD0B2937F5BABC80AD55C0A90E1DE7057 digestAlgorithm: algorithm: shake256 (2.16.840.1.101.3.4.2.12) parameter: <ABSENT> signedAttrs: object: contentType (1.2.840.113549.1.9.3) set: OBJECT:pkcs7-data (1.2.840.113549.1.7.1) object: signingTime (1.2.840.113549.1.9.5) set: UTCTIME:Oct 28 16:05:27 2025 GMT object: id-aa-CMSAlgorithmProtection (1.2.840.113549.1.9.52) set: SEQUENCE: 0:d=0hl=2 l=26 cons: SEQUENCE 2:d=1hl=2 l=11 cons:SEQUENCE 4:d=2hl=2 l=9 prim:OBJECT:shake256 15:d=1hl=2 l=11 cons:cont [ 1 ] 17:d=2hl=2 l=9 prim:OBJECT:ML-DSA-65 object: messageDigest (1.2.840.113549.1.9.4) set: OCTET STRING: ... signatureAlgorithm: algorithm: ML-DSA-65 (2.16.840.1.101.3.4.3.18) parameter: <ABSENT> signature: [...] CMS 署名オブジェクトには、コード署名証明書と下位 CA 証明書の両方が直接格納されています。ルート証明書は、お客様が管理するトラストストアに配置される想定です。これらの証明書に加えて、CMS オブジェクトの ASN.1 構造では、 signerInfos 内の signedAttrs に入力データのダイジェストも含まれています。ダイジェストアルゴリズムは SHAKE256 で、OCTET STRING がバイナリダイジェストそのものを表します。CMS における ML-DSA の使用方法は RFC9882 で規定されています。 注意 : この例では 1 つの ML-DSA 署名のみを使用していますが、ユースケースによっては従来型と耐量子型の 2 つの署名を含む場合もあります。このようなデュアル署名のアーティファクトを使用すると、従来型の署名のみをサポートするレガシーな検証者との後方互換性を維持できます。アップグレードされた検証者は、両方の署名を検証できます。 署名済みコードの検証 署名済みコードのアーティファクトをロードする前に、署名を検証する必要があります。検証には、コードの署名の検証と、信頼されたルート CA までの証明書チェーンの検証が含まれます。 Runner.java ファイルの main メソッド内にある以下のコードスニペットで、証明書チェーンの検証とコードオブジェクト内の署名の検証を行います。 X509CertificateHolder rootCACertificate = CertificateUtils.fromPEM(rootCACertificatePEM); cmsCodeSigningObject.verifyDetachedSignature(<DATA_TO_SIGN>, rootCACertificate); このコードは、コード署名証明書から ML-DSA パブリックキーを取得します。署名の検証には AWS へのアクセスや認証情報は不要です。トラストストアにルート CA 証明書をロードしているエンティティであれば、 AWS KMS verify API にアクセスせずに署名を検証できます。 注意: Runner.java の実装では、ブラウザやデバイス・サーバーの OS 上のファイルシステムに組み込まれた証明書トラストストアは使用していません。本記事ではデモンストレーションの目的で、トラストストアを Java クラスオブジェクトのインスタンス内に配置しています。このコード署名の例を本番システムで使用する場合は、ホスト上のトラストストアを使用するよう実装を 変更する必要があります 。その際は、ルート CA 証明書を含む安全なトラストストアを構築して配布してください。 また、OpenSSL 3.5 以降を使用して、AWS Private CA から提供されるルート CA 証明書 root-ca-MLDSA65.pem をトラストアンカーとして、入力データファイルのデタッチド署名を検証することもできます。 openssl cms -verify -in signature-MLDSA65.p7s -content <input-data-file> \ -CAfile root-ca-MLDSA65.pem -inform DER -purpose any \ -binary -out /dev/null CMS Verification successful 注意: 本記事ではコード署名に焦点を当てていますが、AWS Private CA はその他のプライベート PKI ユースケースでもポスト量子 ML-DSA 認証を実現できます。例えば、AWS 外部のアプリケーションが AWS IAM Roles Anywhere を使用して、証明書ベースの認証で一時的な AWS 認証情報を取得し 、AWS リソースにアクセスできます。AWS IAM Roles Anywhere は現在、本記事で作成したような ML-DSA PKI をサポートしています。別のシナリオでは、mTLS クライアントや IKEv2/IPsec ピアが、AWS Private CA から発行された ML-DSA 証明書を使用して、ポスト量子 PKI ルート証明書を事前にプロビジョニングしたサーバーやピアに対して認証を行うことができます。 まとめ 今回の発表は、ポスト量子認証における重要なマイルストーンです。AWS Private CA に ML-DSA X.509 証明書が導入されたことで、プライベート PKI ユースケースに量子コンピュータへの耐性を取り入れることが可能になりました。対象となるユースケースには、mTLS や IKEv2/IPsec トンネルのクライアント認証、IAM Roles Anywhere、プライベート PKI 認証を使用するアプリケーションなどがあります。AWS Private CA の ML-DSA 証明書と AWS KMS による署名を組み合わせることで、ポスト量子コード署名や、CRQC が利用可能になった後も長期間にわたって動作するよう設計されたデバイスに向けた、ポスト量子の長期的な信頼の基点を確立できます。 ポスト量子暗号 全般と、 ポスト量子暗号への移行 に関する AWS の全体計画について、詳しくはそれぞれのページをご覧ください。 この記事に関するご質問がある場合は、 AWS Security, Identity, & Compliance re:Post で新しいスレッドを作成するか、 AWS サポート にお問い合わせください。AWS の PQC への取り組みの詳細については、 PQC ページ を参照してください。   Panos Kampanakis Panos は AWS の Principal Security Engineer です。サイバーセキュリティ、応用暗号、セキュリティ自動化、脆弱性管理の分野で豊富な経験を持っています。サイバーセキュリティに関する論文を共著し、セキュリティ情報共有、暗号、公開鍵基盤のための共通の相互運用可能なプロトコルと言語を提供するさまざまなセキュリティ標準化団体に参加してきました。現在は、暗号技術的に安全なツール、プロトコル、標準を提供するため、エンジニアや業界標準パートナーと連携しています。 Jake Massimo Jake は AWS Cryptography チームの Senior Applied Scientist です。国際会議、学術論文、標準化団体を通じて Amazon とグローバルな暗号コミュニティをつなぐ役割を担い、ポスト量子クラウドスケール暗号技術の導入に貢献しています。最近は、AWS とお客様が量子安全な暗号にシームレスに移行できるよう、コアライブラリやインフラストラクチャを含む AWS のポスト量子暗号機能のアーキテクチャ設計に注力しています。 Kyle Schultheiss Kyle は AWS Cryptography チームの Senior Software Engineer です。2018 年のサービス開始以来、AWS Private Certificate Authority サービスの開発に携わっています。以前は、Amazon Virtual Private Cloud、Amazon EC2、Amazon Route 53 などの AWS サービスの開発にも貢献しました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2025 年 6 月 13 日に公開された AWS Blog “ How to create post-quantum signatures using AWS KMS and ML-DSA ” を翻訳したものです。 量子コンピューティングの能力が進化し続ける中、AWS は、公開鍵暗号に対する新たな脅威にお客様が先手を打てるよう取り組んでいます。本日 (2025 年 6 月 13 日)、 FIPS 204: ML-DSA (Module-Lattice-Based Digital Signature Standard) の AWS Key Management Service (AWS KMS) でのサポート開始を発表します。デジタル署名に使用している既存の AWS KMS API ( CreateKey 、 Sign 、 Verify オペレーションなど) を通じて、ML-DSA キーの作成と使用が可能になりました。この新機能は一般提供されており、米国西部 (北カリフォルニア) および欧州 (ミラノ) の AWS リージョンで ML-DSA を使用できます。残りの商用リージョンも数日以内に対応予定です。今回のリリースは、先日の ブログ記事 で紹介した、AWS のより広範なポスト量子暗号移行計画の一環です。この記事では、AWS KMS を使用して ML-DSA キーを作成し、ポスト量子署名を生成する手順を説明します。 多くの組織が AWS KMS を使用して、ファームウェア、オペレーティングシステム、アプリケーション、その他のアーティファクトにデジタル署名を行っています。AWS KMS で ML-DSA をサポートしたことにより、FIPS 140-3 レベル 3 認定の HSM 内でポスト量子キーを生成し、署名・検証処理に使用できるようになりました。ML-DSA 署名を今から導入しておけば、暗号解読能力を持つ量子コンピュータ (CRQC) が利用可能になった場合でも、システムの運用期間全体を通じてセキュリティを維持できます。これは、長期間有効な信頼の基点を製造段階でデバイスに組み込むメーカーにとって特に重要です。ハードウェアに直接組み込む場合でも、長期間オフラインのままになる可能性のあるデバイスに組み込む場合でも同様です。いずれの場合も、出荷後にデジタル署名を簡単に更新することはできないため、システムの運用期間全体にわたるポスト量子対応が不可欠です。 新機能 AWS KMS では、3 つの新しい AWS KMS キースペック ( ML_DSA_44 、 ML_DSA_65 、 ML_DSA_87 ) が利用可能になりました。これらは新しいポスト量子 SigningAlgorithm である ML_DSA_SHAKE_256 と組み合わせて使用します。他の署名アルゴリズムと同様に、この名前には、署名スキーム内で署名または検証の前にメッセージをダイジェストするために使用されるハッシュ関数が含まれています。ここで使用されるハッシュ関数は、NIST が FIPS 202 で標準化した SHA-3 ファミリーに属する SHAKE256 です。 表 1 に、各キースペックの詳細 (NIST セキュリティカテゴリおよび対応するキーサイズ (バイト単位) など) を示します。各 ML-DSA キースペックは、セキュリティ強度とリソース要件のバランスが異なります。ML-DSA-44 は従来の 128 ビット暗号化に匹敵するセキュリティが必要なアプリケーションに適しています。一方、ML-DSA-65 と ML-DSA-87 はそれぞれ従来の 192 ビットおよび 256 ビット暗号化に相当する、より強力なセキュリティレベルを提供します。セキュリティレベルが上がるにつれてキーと署名のサイズも大きくなるため、セキュリティ要件とエンジニアリング上の制約に応じて最適なキースペックを選択できます。 Key spec NIST security Level Public key (B) Private key (B) Signature (B) ML_DSA_44 1 (128 ビットセキュリティ相当) 1,312 2,560 2,420 ML_DSA_65 3 (192 ビットセキュリティ相当) 1,952 4,032 3,309 ML_DSA_87 5 (256 ビットセキュリティ相当) 2,592 4,896 4,627 AWS KMS Sign API を RAW MessageType で使用する場合、署名対象のメッセージは 4,096 バイトに制限されます。4,096 バイトを超えるメッセージに署名するには、KMS Sign API への入力サイズを削減するために、AWS KMS の外部でメッセージを前処理して µ (mu) を作成する必要があります。この external mu プロセスでは、ML-DSA 署名キーペアの公開鍵を使用してメッセージをプリハッシュし、メッセージサイズを 64 バイトに縮小します。今回のリリースに合わせて、KMS Sign API に新しいメッセージタイプ EXTERNAL_MU を追加しました。これは ML-DSA の署名または検証の呼び出しで使用でき、AWS KMS に送信する前にメッセージが µ (mu) を使用して前処理済みであることを示します。 以降のセクションでは、external mu の作成方法を詳しく説明し、ML-DSA を使用した AWS KMS の基本的な操作を紹介します。キーの作成、署名の生成と検証について、 RAW と EXTERNAL_MU の両方の署名モードを取り上げます。なお、同じメッセージと署名キーを使用した場合、 RAW と EXTERNAL_MU のどちらで生成しても ML-DSA 署名は同一になります。 ML-DSA キーの作成 まず、 AWS コマンドラインインターフェイス (AWS CLI) を使用して、以下のコマンドで非対称 AWS KMS キーを作成します。 aws kms create-key --key-spec ML_DSA_65 --key-usage SIGN_VERIFY このコマンドは、以下のようなレスポンスを返します。 { "KeyMetadata": { "Origin": "AWS_KMS", "KeyId": " 1234abcd-12ab-34cd-56ef-1234567890ab ", "MultiRegion": false, "Description": "", "KeyManager": "CUSTOMER", "Enabled": true, "SigningAlgorithms": [ "ML_DSA_SHAKE_256" ], "CustomerMasterKeySpec": "ML_DSA_65", "KeyUsage": "SIGN_VERIFY", "KeySpec": "ML_DSA_65", "KeyState": "Enabled", "CreationDate": 1748371316.734, "Arn": " arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab ", "AWSAccountId": " 111122223333 " } } レスポンスに含まれる KeyId または Arn の値を控えておいてください。以降の署名操作でキーを参照する際に必要になります。このレスポンスから、 SIGN_VERIFY オペレーション用に ML_DSA_65 キーが作成され、署名オペレーションには ML_DSA_SHAKE_256 署名アルゴリズムが使用されることを確認できます。 署名 このセクションでは、Web における認可処理において当事者間のクレーム受け渡しに広く使われている JSON Web Token (JWT) を例に、ML-DSA による署名と検証の方法を紹介します。2021 年には、従来の非対称暗号アルゴリズムである楕円曲線デジタル署名アルゴリズム (ECDSA) を使用した JWT の署名と検証の方法を紹介しました (「 How to verify AWS KMS signatures in decoupled architectures at scale 」を参照)。以下の例では、AWS KMS で管理される ML-DSA プライベートキーで JWT に署名し、AWS KMS 内または OpenSSL を使用して外部で検証します。 署名対象の JWT コンテンツは、 RFC7519 のセクション 3.1 に基づいています。JWT ヘッダーは以下のとおりです。 {"typ":"JWT", "alg":"ML-DSA-65"} JWT クレームセットは以下のとおりです。 {"iss":"joe", "exp":1748952000, "http://example.com/is_root":true} ヘッダーとペイロードを Base64URL エンコードすることで、署名対象の JWT メッセージを生成できます。 echo -n -e '{"typ":"JWT",\015\012 "alg":"ML-DSA-65"}' | \ basenc --base64url -w 0 | \ sed 's/=//g' ; echo -n "." ; echo -n -e '{"iss":"joe",\015\012 "exp":1748952000,\015\012 "http://example.com/is_root":true}' | \ basenc --base64url -w 0 | sed 's/=//g' ; echo "" このコマンドは、ML-DSA で署名する対象となる以下の Base64 文字列を出力します。 eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJNTC1EU0EtNjUifQ.eyJpc3MiOiJqb2UiLA0KICJleHAiOjE3NDg5NTIwMDAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ 以下の例では、AWS KMS で管理される ML-DSA プライベートキーを使用してメッセージの ML-DSA 署名を生成し、バイナリ形式で出力します。JWT で使用するには Base64URL に変換する必要がありますが、この署名はさまざまなデータ暗号化および署名形式で利用できます。具体的には、Cryptographic Message Syntax (CMS)、CBOR Object Signing and Encryption (COSE)、UEFI や Open Titan のイメージ署名エンコーディングなどが挙げられます。バイナリからこれらの形式への変換は容易ですが、本記事の執筆時点では、一般的な暗号ライブラリの実装において新しいアルゴリズムのサポートがまだ利用できない場合があります。 RAW モードでの ML-DSA 署名 4,096 バイト未満のメッセージに AWS KMS で ML-DSA 署名を行うには、以下のように AWS CLI を使用します。 aws kms sign \ --key-id <1234abcd-12ab-34cd-56ef-1234567890ab> \ --message ' eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJNTC1EU0EtNjUifQ.eyJpc3MiOiJqb2UiLA0KICJleHAiOjE3NDg5NTIwMDAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ' \ --message-type RAW \ --signing-algorithm ML_DSA_SHAKE_256 \ --output text \ --query Signature | base64 --decode > ExampleSignature.bin target-key-id の値 <1234abcd-12ab-34cd-56ef-1234567890ab> を実際の KeyId に置き換えてください。このコマンドは署名を生成し、 ExampleSignature.bin としてディスクに書き込みます。 署名を生成したら、以下のコマンドでヘッダー、ペイロード、署名から構成される完全な JWT を作成できます。 echo -n "eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJNTC1EU0EtNjUifQ.eyJpc3MiOiJqb2UiLA0KICJleHAiOjE3NDg5NTIwMDAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ." ; \ basenc --base64url -w 0 ExampleSignature.bin | \ sed 's/=//g' ; echo "" このコマンドは、 RFC 7519 で要求される形式に準拠した、AWS KMS で署名済みの JWT を出力します。 eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJNTC1EU0EtNjUifQ.eyJpc3MiOiJqb2UiLA0KICJleHAiOjE3NDg5NTIwMDAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ. <base64url of the signature as per RFC7519> external mu モードでの ML-DSA 署名 AWS KMS では、Sign API 使用時のレスポンスレイテンシーを最小限に抑えるため、RAW メッセージのサイズを 4,096 バイトに制限しています。署名対象のメッセージが 4,096 バイトを超える場合や、external mu のプリハッシュによるパフォーマンス上のメリットを活用したい場合は、 RAW の代わりに EXTERNAL_MU メッセージタイプを使用する必要があります。 AWS KMS Sign API で EXTERNAL_MU メッセージタイプを使用するには、事前にローカルでメッセージのプリハッシュ計算を行う必要があります。まず、以下のコマンドで AWS KMS から公開鍵を取得し、DER 形式に変換します。下記の例のキー ID は、実際の AWS アカウントの有効なキー ID に置き換えてください。 aws kms get-public-key \ --key-id <1234abcd-12ab-34cd-56ef-1234567890ab> \ --output text \ --query PublicKey | base64 --decode > public_key.der external mu ダイジェストの作成手順は以下のとおりです。 メッセージプレフィックス (M`) を作成します M` = (domain separator || context length || context || Message) この例では、ドメインセパレータの値とコンテキスト長をゼロに設定します。これにより、署名で使用されるコンテキストが空文字列 (デフォルト) になります。 公開鍵をハッシュし、メッセージプレフィックスの先頭に付加します (SHAKE256(pk) || M') ハッシュして 64 バイトの mu を生成します Mu = SHAKE256(SHAKE256(pk) || M') OpenSSL 3.5 では、以下の単一コマンドでダイジェストを作成できます。 { openssl asn1parse -inform DER -in public_key.der -strparse 17 -noout -out - 2>/dev/null | openssl dgst -provider default -shake256 -xoflen 64 -binary; printf '\x00\x00'; echo -n "eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJNTC1EU0EtNjUifQ.eyJpc3MiOiJqb2UiLA0KICJleHAiOjE3NDg5NTIwMDAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ" } | openssl dgst -provider default -shake256 -xoflen 64 -binary > mu.bin これで、AWS KMS を呼び出して 64 バイトのダイジェストに署名し、ML-DSA 署名をファイル ExampleSignature.bin に出力できます。 MessageType は EXTERNAL_MU に設定してください。 aws kms sign \ --key-id 1234abcd-12ab-34cd-56ef-1234567890ab \ --message fileb://mu.bin \ --message-type EXTERNAL_MU \ --signing-algorithm ML_DSA_SHAKE_256 \ --output text \ --query Signature | base64 --decode > ExampleSignature.bin 最終的に署名された JWT トークンは、前述の RAW モードで生成されたものと同一です。 AWS KMS を使用した署名検証 このセクションでは、AWS KMS またはローカル環境で ML-DSA 署名を検証する方法を説明します。ここでは、AWS KMS 内のプライベートキーを使用して JWT コンテンツに対して生成された ML-DSA 署名が ExampleSignature.bin に格納されており、 KEY_ARN で識別されることを前提とします。 以下の例では、AWS KMS から直接取得した公開鍵を使用した署名検証を示していますが、これらの原則はプライベート PKI などの証明書ベースのシステムにも適用できます。プライベート PKI では、公開鍵は署名者のエンドエンティティ証明書に埋め込まれています。このようなシナリオでは、検証者はまず証明書チェーンが信頼されたルート証明書に結びついていることを検証して署名者の身元を確認し、次にエンドエンティティ証明書の公開鍵を使用してコンテンツの ML-DSA 署名を検証します。 IETF は、RFC ドラフト draft-ietf-lamps-dilithium-certificates を通じて、X.509 証明書での ML-DSA の使用を標準化しています。 RAW モードでの ML-DSA 検証 AWS KMS を使用して署名を検証するには、以下のコマンドを実行します。例の key-id は、署名時に使用したものと同じキー ID に置き換えてください。 aws kms verify \ --key-id <1234abcd-12ab-34cd-56ef-1234567890ab> \ --message "eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJNTC1EU0EtNjUifQ.eyJpc3MiOiJqb2UiLA0KICJleHAiOjE3NDg5NTIwMDAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ" \ --message-type RAW \ --signing-algorithm ML_DSA_SHAKE_256 \ --signature fileb://ExampleSignature.bin 以下のようなレスポンスが返されます。 { "KeyId": " arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab ", "SignatureValid": true, "SigningAlgorithm": "ML_DSA_SHAKE_256" } 検証結果は SignatureValid フィールドで確認できます。 external mu モードでの ML-DSA 検証 JWT コンテンツの external mu ダイジェストが mu.bin に格納されており、署名と対応するキーペアが AWS KMS にある場合、メッセージ全体にアクセスしたりダイジェストを再計算したりすることなく、このダイジェストを使用して検証できます。 aws kms verify \ --key-id <1234abcd-12ab-34cd-56ef-1234567890ab> \ --message fileb://mu.bin \ --message-type EXTERNAL_MU \ --signing-algorithm ML_DSA_SHAKE_256 \ --signature fileb://ExampleSignature.bin メッセージと公開鍵から external mu mu.bin を再生成する方法については、前述の 「external mu モードでの ML-DSA 署名」セクション を参照してください。 OpenSSL 3.5 を使用したローカル署名検証 ML-DSA 署名の生成には AWS KMS で生成・保管されたキーのセキュリティを維持しつつ、API の呼び出しコストを削減し、API クォータの使用をより細かく制御したい場合は、AWS KMS の外部でローカルに ML-DSA 署名を検証できます。 この例では、OpenSSL 3.5 を使用して ExampleSignature.bin の署名を検証します。まず、 「external mu モードでの ML-DSA 署名」 セクションで示したように、AWS KMS から DER エンコードされた公開鍵を取得し、ファイル public_key.der に保存する必要があります。OpenSSL 3.5 では、この公開鍵を使用してメッセージの署名を検証できます。 echo -n "eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJNTC1EU0EtNjUifQ.eyJpc3MiOiJqb2UiLA0KICJleHAiOjE3NDg5NTIwMDAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ" | \ openssl dgst -verify public_key.der -signature ExampleSignature.bin 検証が成功すると、 Verified OK と出力されます。 まとめ 本日 (2025 年 6 月 13 日) の AWS KMS における ML-DSA サポートの開始は、ポスト量子暗号に対する AWS の取り組みにおける重要なマイルストーンです。3 段階のセキュリティレベルと RAW・external mu の 2 つの署名モードにより、量子コンピューティング時代を見据えたセキュリティ要件に柔軟に対応できます。既存の AWS KMS API とシームレスに統合できるため、量子コンピュータに耐性のある署名を今すぐアプリケーションに組み込むことが可能です。この実装は、以下のようなユースケースで特に効果を発揮します。 ポスト量子暗号の使用時に FIPS 140-3 準拠要件を満たす必要がある場合 コード、アーティファクト、ドキュメントなどに対して、暗号解読能力を持つ量子コンピュータ (CRQC) が実現した後も長期間にわたって検証可能な署名を付与する必要がある場合 AWS KMS のような承認済みの暗号サービスを活用し、アプリケーション開発プロセスの一環としてポスト量子暗号のテストを開始する場合 ポスト量子暗号 全般、および AWS の ポスト量子暗号への移行計画 の詳細についてはリンク先をご覧ください。 Jake Massimo Jake は AWS Cryptography チームの Applied Scientist です。国際会議、学術研究、標準化団体への積極的な参加を通じて、Amazon とグローバルな暗号コミュニティの橋渡し役を担っています。クラウド規模でのポスト量子暗号技術の導入推進に取り組んでおり、現在は AWS 暗号ライブラリにおいて、最適化され形式的に検証されたポスト量子アルゴリズムの開発をリードしています。 Panos Kampanakis Panos はサイバーセキュリティ、応用暗号、セキュリティ自動化、脆弱性管理に関する豊富な経験を持っています。長年にわたり、技術イベントでさまざまなセキュリティトピックに関するトレーニングやプレゼンテーションを行ってきました。サイバーセキュリティに関する出版物を共同執筆し、セキュリティ情報共有、暗号、PKI のための共通の相互運用可能なプロトコルや言語を提供するさまざまなセキュリティ標準化団体に参加しています。 Mayank Ambaliya Mayank は AWS Key Management Service (AWS KMS) の Software Development Manager です。AWS KMS の暗号 API およびカスタムキーストアの開発をリードしています。AWS CloudHSM のお客様向け暗号 API および暗号 SDK の開発経験があり、最近では AWS KMS でのポスト量子アルゴリズムサポートや新しい暗号 API の追加に取り組んでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

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