Amazon Web Services ブログ

Kyber を使用したハイブリッドポスト量子 TLS のチューニング方法

本ブログは 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 ハンドシェイクのレイテンシー比較

図 1: 従来の TLS ハンドシェイクとハイブリッドポスト量子 TLS ハンドシェイクのレイテンシー比較

図 2 は、従来の ECDHE とハイブリッドポスト量子 (ECDHE + Kyber) 鍵確立の両方について、クライアント側で測定した TLS ハンドシェイク中の送受信バイト数を示しています。

図 2: 従来の TLS ハンドシェイクとハイブリッドポスト量子 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 を設定するには

  1. AWS SDK for Java 2.x 用 AWS Common Runtime HTTP クライアントのプレビューリリースを取得します。Maven の依存関係設定では、以下のコードサンプルに示すようにバージョン 2.17.69-PREVIEW 以降を指定する必要があります。 
    <dependency>
    <groupId>software.amazon.awssdk</groupId>
    aws-crt-client
    <version>[2.17.69-PREVIEW,]</version>
</dependency>
  2. コードの初期化時に目的の暗号スイートを設定します。以下のコードサンプルは、最新のハイブリッドポスト量子暗号スイートを使用するように 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 ハンドシェイク数

図 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 Jarvis

Brian は AWS Cryptography のシニアソフトウェアエンジニアです。ポスト量子暗号と暗号ハードウェアに関心を持っています。以前は AWS Security で、社内全体で使用される内部サービスの開発に携わっていました。Brian は Vanderbilt University で学士号を、George Mason University でコンピュータエンジニアリングの修士号を取得しています。「いつか」博士号を取得する予定です。

本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。