AWS KMS、ACM、Secrets Manager で ML-KEM ポスト量子 TLS をサポート開始

本ブログは 2025 年 4 月 7 日に公開された AWS Blog “ML-KEM post-quantum TLS now supported in AWS KMS, ACM, and Secrets Manager” を翻訳したものです。

Amazon Web Services (AWS) は、TLS 向けの最新のハイブリッドポスト量子鍵共有標準のサポートを 3 つの AWS サービスで開始したことを発表しました。本日 (2025 年 4 月 7 日) より、AWS Key Management Service (AWS KMS)、AWS Certificate Manager (ACM)、AWS Secrets Manager のエンドポイントは、中国・GovCloud を除く全商用リージョンの非 FIPS エンドポイントで、ハイブリッドポスト量子鍵共有のための ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) をサポートするようになりました。AWS SDK for Rust をベースに構築された Secrets Manager Agent も、ハイブリッドポスト量子鍵共有のオプトインサポートを提供するようになりました。これにより、エンドツーエンドでポスト量子対応の TLS を使用して、アプリケーションにシークレットを取り込むことができます。

AWS は、ポスト量子の機密性を最も緊急に必要とするセキュリティ上重要なサービスとして、これら 3 つを優先的にサポートしてきました。これらのサービスは、ML-KEM の前身である CRYSTALS-Kyber のサポートを以前から提供しています。CRYSTALS-Kyber のサポートは 2025 年まで継続されますが、2026 年にはすべての AWS サービスのエンドポイントで ML-KEM に置き換わります。

ポスト量子暗号への移行

AWS はポスト量子暗号移行計画に従うことをコミットしています。このコミットメントの一環として、ポスト量子暗号における AWS の責任共有モデルに従い、AWS は今後数年間で HTTPS エンドポイントを持つすべての AWS サービスに ML-KEM のサポートを拡大する予定です。AWS をご利用のお客様は、AWS サービスの HTTPS エンドポイントに接続する際に ML-KEM を提供できるよう、TLS クライアントと SDK を更新する必要があります。これにより、量子コンピューティングの進歩がもたらす将来の「harvest now, decrypt later (今収集して、後で復号) 」攻撃の脅威から保護されます。一方、AWS サービスの HTTPS エンドポイントは、クライアントから ML-KEM が提示された場合、それを選択する責任を負います。

ハイブリッドポスト量子鍵共有アルゴリズムをネゴシエートするという AWS のコミットメントは、AWS 全体で使用されているオープンソースの FIPS 140-3 認証暗号ライブラリである AWS Libcrypto (AWS-LC) と、AWS サービスの HTTPS エンドポイント全体で使用されているオープンソースの TLS 実装である s2n-tls によって実現されています。AWS-LC は NIST から複数の FIPS 認証 (#4631、#4759、#4816) を取得しており、FIPS 140-3 検証に ML-KEM を含めた最初のオープンソース暗号モジュールでした。

ハイブリッドポスト量子 ML-KEM が TLS パフォーマンスに与える影響

ECDH (楕円曲線ディフィー・ヘルマン) のみの鍵共有から ECDH+ML-KEM ハイブリッド鍵共有への移行では、TLS ハンドシェイクでより多くのデータを送信し、より多くの暗号処理を実行する必要があります。従来の鍵共有からハイブリッドポスト量子鍵共有に切り替えると、TLS ハンドシェイク中に約 1600 バイトの追加データが転送され、ML-KEM 暗号処理を実行するために約 80〜150 マイクロ秒の追加計算時間が必要になります。これは TLS 接続の開始時に 1 回だけ発生するコストであり、その接続中に送信される複数の HTTP リクエストに分散されます。

AWS は、TLS のハイブリッドポスト量子鍵共有へのスムーズな移行を実現するために取り組んでいます。この取り組みには、ML-KEM によるハイブリッドポスト量子鍵共有を有効にした場合の影響をお客様が理解できるよう、サンプルワークロードでのベンチマークの実施が含まれます。

AWS SDK for Java v2 を使用して、Amazon Elastic Compute Cloud (Amazon EC2) の C6in.metal インスタンス上のクライアントと、AWS KMS のパブリックエンドポイント間で、単一スレッドがシリアルに発行できる 1 秒あたりの AWS KMS GenerateDataKey リクエスト数を測定しました。クライアントとサーバーはいずれも us-west-2 リージョンを使用しました。AWS KMS への従来の TLS 接続は鍵共有に楕円曲線 P256 をネゴシエートし、ハイブリッドポスト量子 TLS 接続はハイブリッド鍵共有に楕円曲線 X25519 と ML-KEM-768 をネゴシエートしました。実際のパフォーマンス特性は環境によって異なり、インスタンスタイプ、ワークロードプロファイル、並列処理の量とスレッド数、ネットワークの場所と容量によって変わります。HTTP リクエストのトランザクションレートは、TLS 接続の再利用を有効にした場合と無効にした場合の両方で測定されました。

図 1 は、TLS 1.3 接続の再利用を無効にした場合の、さまざまなパーセンタイルで発行された 1 秒あたりのリクエスト数を示しています。最悪のシナリオ、つまり TLS ハンドシェイクのコストが分散されず、すべての HTTP リクエストで完全な TLS ハンドシェイクを実行する必要がある場合、ハイブリッドポスト量子 TLS を有効にすると、1 秒あたりのトランザクション数 (TPS) が平均で約 2.3% 減少し、108.7 TPS から 106.2 TPS になります。

図 1: TLS 接続の再利用なしの AWS KMS GenerateDataKey の 1 秒あたりのリクエスト数

図 2 は、TLS 接続の再利用を有効にした場合の、さまざまなパーセンタイルでの 1 秒あたりのリクエスト数を示しています。TLS 接続を再利用して TLS ハンドシェイクのコストを多くの HTTP リクエストに分散することは、AWS SDK for Java v2 のデフォルト設定です。デフォルトの SDK 設定でハイブリッドポスト量子 TLS を有効にした場合、TPS レートはほぼ変わらず、平均でわずか 0.05% の減少 (216.1 TPS から 216.0 TPS) にとどまることが確認できます。

図 2: TLS 接続の再利用ありの AWS KMS GenerateDataKey の 1 秒あたりのリクエスト数

この結果から、SDK の一般的な設定を使用した場合、ハイブリッドポスト量子 TLS を有効にしてもパフォーマンスへの影響はほとんどないことがわかります。測定結果によると、デフォルト設定のワークロード例でハイブリッドポスト量子 TLS を有効にしても、最大 TPS レートの低下はわずか 0.05% でした。また、SDK のデフォルト設定を上書きして、すべてのリクエストで新しい TLS ハンドシェイクを実行する最悪のシナリオを強制した場合でも、最大 TPS レートの低下は 2.3% にとどまりました。

以下の表は、測定したベンチマークデータです。各ベンチマークでは、TLS 鍵共有設定と TLS 接続再利用設定を変えながら、500 回の 1 秒間 TPS 測定を実施しました。測定には AWS SDK for Java v2 の v2.30.22 を使用しました。TLS 鍵共有は、postQuantumTlsEnabled() 設定を切り替えることで、従来方式とハイブリッドポスト量子方式を切り替えました。TLS 接続の再利用は、各 HTTP リクエストに Connection: close HTTP ヘッダーを挿入することで切り替えました。このヘッダーにより、各 HTTP リクエスト後に TLS 接続が強制的に切断され、HTTP リクエストごとに新しい TLS 接続を作成する必要があります。

ポスト量子暗号ドラフト仕様のサポート終了

ML-KEM の前身である CRYSTALS-Kyber をサポートする AWS サービスのエンドポイントは、2025 年まで CRYSTALS-Kyber のサポートを継続します。お客様が ML-KEM 標準に移行した後、標準化前の CRYSTALS-Kyber 実装のサポートを段階的に終了していきます。CRYSTALS-Kyber をサポートする以前のバージョンの AWS SDK for Java をご利用のお客様は、ML-KEM をサポートする最新の SDK バージョンにアップグレードしてください。AWS SDK for Java v2 の一般提供リリースをご利用のお客様は、CRYSTALS-Kyber から ML-KEM へのアップグレードにコード変更は必要ありません。

現在 CRYSTALS-Kyber をネゴシエートしているお客様が 2026 年までに AWS Java SDK v2 クライアントをアップグレードしない場合、AWS サービスの HTTPS エンドポイントから CRYSTALS-Kyber が削除されると、クライアントは従来の鍵共有に自動的にフォールバックします。

ハイブリッドポスト量子鍵共有の使用方法

AWS SDK for Rust をご利用の場合は、crate に rustls パッケージを追加し、prefer-post-quantum 機能フラグを有効にすることで、ハイブリッドポスト量子鍵共有を有効にできます。詳細については、rustls のドキュメントを参照してください。

AWS SDK for Java 2.x をご利用の場合は、AWS Common Runtime HTTP クライアントを構築する際に .postQuantumTlsEnabled(true) を呼び出すことで、ハイブリッドポスト量子鍵共有を有効にできます。

ステップ 1: AWS Common Runtime HTTP クライアントを Java の依存関係に追加する

AWS Common Runtime HTTP クライアントを Maven の依存関係に追加します。利用可能な最新バージョンの使用をお勧めします。ML-KEM を使用するには、バージョン 2.30.22 以降が必要です。

<dependency>
    <groupId>software.amazon.awssdk</groupId>
    <artifactId>aws-crt-client</artifactId>
    <version>2.30.22<version>
</dependency>

ステップ 2: Java SDK クライアント設定でポスト量子 TLS を有効にする

AWS サービスクライアントを設定する際に、ポスト量子 TLS を有効にした AwsCrtAsyncHttpClient を使用します。

// ポスト量子 TLS を有効にした AWS Common Runtime HTTP クライアントを設定
SdkAsyncHttpClient awsCrtHttpClient = AwsCrtAsyncHttpClient.builder()
          .postQuantumTlsEnabled(true)
          .build();

// AWS Common Runtime クライアントを使用する AWS サービスクライアントを作成
KmsAsyncClient kmsAsync = KmsAsyncClient.builder()
         .httpClient(awsCrtHttpClient)
         .build();

// ポスト量子鍵共有を使用する TLS 接続経由でリクエストを実行
ListKeysResponse keys = kmsAsync.listKeys().get();

ポスト量子 TLS セットアップのエンドツーエンドの例については、KMS PQ TLS サンプルアプリケーションを参照してください。

検証のポイント

ポスト量子対応クライアントを検証する際のポイントをご紹介します。

• 負荷テストとベンチマークの実行: AwsCrtAsyncHttpClient はパフォーマンスに最適化されており、Linux ベースの環境では AWS Libcrypto を使用します。まだ AwsCrtAsyncHttpClient を使用していない場合は、デフォルトの SDK HTTP クライアントと比較してパフォーマンスの向上を確認してみてください。AwsCrtAsyncHttpClient を使用した後、ポスト量子 TLS サポートを有効にしてください。ポスト量子 TLS を有効にした AwsCrtAsyncHttpClient が、ポスト量子 TLS なしのデフォルト SDK HTTP クライアントと比較して、全体的なパフォーマンス向上につながるかどうかを確認してみてください
• 異なるネットワークロケーションからの接続試行: リクエストが通過するネットワークパスによっては、中間ホスト、プロキシ、またはディープパケットインスペクション (DPI) を備えたファイアウォールがリクエストをブロックする場合があります。その場合は、セキュリティチームまたは IT 管理者と協力して、ネットワーク内のファイアウォールを更新し、これらの新しい TLS アルゴリズムのブロックを解除する必要があるかもしれません。この新しい TLS トラフィックとお客様のインフラストラクチャがどのように相互作用するかについて、ぜひお聞かせください

まとめ

ML-KEM ベースのハイブリッド鍵共有のサポートが、セキュリティ上重要な 3 つの AWS サービスのエンドポイントで開始されました。TLS 接続の再利用を有効にした場合、ハイブリッドポスト量子 TLS を有効にしてもパフォーマンスへの影響はほとんどありません。AWS の測定では、AWS KMS の GenerateDataKey を呼び出した際の最大 TPS の低下はわずか 0.05% でした。

バージョン 2.30.22 以降、AWS SDK for Java v2 は、AWS Common Runtime HTTP クライアントを使用する Linux ベースのプラットフォームで ML-KEM ベースのハイブリッド鍵共有をサポートしています。今すぐ Java SDK クライアント設定でポスト量子鍵共有を TLS で有効にすることをお試しください。

AWS は、ポスト量子暗号移行計画の一環として、今後数年間ですべての AWS サービスの HTTPS エンドポイントに ML-KEM ベースのハイブリッドポスト量子鍵共有のサポートを拡大する予定です。お客様は、AWS サービス HTTPS エンドポイントに接続する際に ML-KEM 鍵共有が提供されるよう、TLS クライアントと SDK を更新する責任を負います。これにより、量子コンピューティングの進歩がもたらす将来の harvest now, decrypt later 攻撃の脅威から保護されます。

ポスト量子暗号移行に関する追加情報、ブログ投稿、定期的な更新については、AWS ポスト量子暗号ページをご覧ください。AWS でのポスト量子暗号の詳細については、ポスト量子暗号チームにお問い合わせください。

この投稿に関するご質問がある場合は、AWS Security, Identity, & Compliance re:Post で新しいスレッドを開始するか、AWS サポートにお問い合わせください。

その他のリソース:

• AWS ポスト量子暗号
• AWS ポスト量子暗号移行計画
• ポスト量子暗号への移行におけるセキュアな TLS 接続の仕組みとクライアント設定ガイド
• AWS-LC FIPS 3.0: FIPS 140-3 検証に ML-KEM を含めた最初の暗号ライブラリ
• ポスト量子暗号のレイテンシー影響はデータ量の増加で軽減
• AWS ワークショップ: AWS でのポスト量子暗号の使用
• NIST FIPS 203、Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)