Amazon Web Services ブログ

ラウンド 2 の ポスト量子暗号 TLS が KMS でサポートされました

AWS Key Management Service (AWS KMS) が AWS KMS API エンドポイントに接続する際に使われる Transport Layer Security (TLS) 1.2 暗号化プロトコルにおいて新しいハイブリッド型のポスト量子暗号（耐量子暗号）鍵交換アルゴリズムをサポートするようになりました。これらの新しいハイブリッドポスト量子アルゴリズムは、古典的な鍵交換による実証済みのセキュリティと、標準化作業で評価中の新しいポスト量子鍵交換の潜在的な耐量子安全特性を組み合わせたものです。これらのアルゴリズムの中で最も高速なものは、古典的な TLS ハンドシェイクと比較して約 0.3 ミリ秒のオーバーヘッドがあります。追加された新しいポスト量子暗号鍵交換アルゴリズムは、Kyber のラウンド 2 バージョン、Bit Flipping Key Encapsulation（BIKE）、および Supersingular Isogeny Key Encapsulation（SIKE）です。標準化に参加している各組織は、米国国立標準技術研究所（NIST） のポスト量子暗号の標準化プロセスの一環として、アルゴリズムを NIST に提出しています。このプロセスは、複数年にわたる数ラウンドの評価にまたがり、2021 年以降も続く可能性があります。

以前のハイブリッド量子暗号 TLS に関するブログ投稿で、AWS KMS がラウンド 1 バージョンの BIKE と SIKE を備えたハイブリッドポスト量子暗号 TLS 1.2 をリリースしたことを発表しました。ラウンド 1 のポスト量子暗号 アルゴリズムは引き続き AWS KMS でサポートされていますが、ラウンド 2 のアルゴリズムよりも優先順位が低くなっています。クライアントをアップグレードして、ラウンド 2 アルゴリズムのネゴシエーションを有効にすることを選択できます。

なぜポスト量子暗号 TLS（耐量子暗号 TLS）が重要なのか？

大規模な量子コンピューターは、古典的な TLS 接続の暗号鍵交換に使用されている公開鍵暗号を破ることが出来る可能性があります。現在、そのような大規模な量子コンピューターは利用可能ではありませんが、長期的なセキュリティの要件について考えておき、計画することは重要だと言えます。古典的なアルゴリズムを使用している記録された TLS トラフィックは将来、大規模な量子コンピュータによって復号される可能性があります。TLS 接続の上でデータを送受信し、長期的に機密性を担保したいアプリケーションを開発している場合には、大規模な量子コンピューターを使って、許可していないユーザーによる影響を受ける前にポスト量子暗号へ移行することを検討したほうが良いでしょう。例えば、大規模な量子コンピューターが 25 年先に登場すると想定し、データをこれから 20 年先まで保護する必要があると考えている場合、今後 5 年以内にポスト量子暗号の仕組みに移行する必要があることを意味します。 AWSはこの未来に備えるために取り組んでおり、皆さんにも準備していただきたいと考えています。

アプリケーションへの潜在的なインパクトを測定していただけるように、標準化作業が完了するのを待たずに、ポスト量子暗号 TLS の機能を今提供しています。また、この機能により提案中のポスト量子暗号スキームによって提供される保護も行われます。この機能を利用することで AWS KMS エンドポイントに接続する際のセキュリティのバーをより高いレベルにしてくるはずですが、同時にこの機能は通信バンド幅とレイテンシーにインパクトを与えます。また、この新しいアルゴリズムは、TLS コネクションをプロキシーして中継するシステム上で接続エラーを引き起こす可能性があります。そのため、実装の有効性や見つかった問題についてフィードバックをお寄せいただき、改善に役立てたいと考えています。

ハイブリッド型ポスト量子暗号 TLS 1.2

ハイブリッド型 ポスト量子暗号 TLS は、単一の TLS ハンドシェイクで古典的な鍵交換アルゴリズムとポスト量子暗号鍵交換アルゴリズムの両方のセキュリティ保護を提供する機能です。図1は、古典的な TLS 1.2とハイブリッドのポスト量子暗号 TLS 1.2 の接続シークレット派生プロセスの違いを示しています。ハイブリッドポスト量子暗号 TLS 1.2 には、古典的な TLS 1.2 と 3 つの大きな違いがあります。

図1 : TLS 1.2 における古典的なハイブリッドポスト量子暗号の接続シークレットの生成の違い

図1 : TLS 1.2 における古典的なハイブリッドポスト量子暗号の接続シークレットの生成の違い

  • ネゴシエートされたポスト量子暗号キーは、ハッシュベースのメッセージ認証コード（HMAC）キーとして使用される前に、ECDHE キーに追加されます。
  • ASCII フォーマットのテキストハイブリッドが、HMAC メッセージの先頭に付加されます。
  • TLS ハンドシェイクの結果作られるクライアント鍵交換メッセージ全体が HMAC メッセージの最後に追加されます。

ポスト量子暗号 TLS に関する技術的な背景

現在、AWS KMS へのすべてのリクエストは Perfect Forward Security を提供する鍵交換アルゴリズムを備えた TLS を使用し、次の古典的なスキームのどちらかを使用しています。

既存の FFDHE および ECDHE スキームは、サーバー側の長期秘密鍵の侵害から保護するために Perfect Forward Security を使用しますが、これらのスキームは大規模な量子コンピューターからの攻撃を保護出来ません。将来的には、十分な能力を備えた大規模な量子コンピューターが Shor のアルゴリズムを実行して、記録されたセッションの古典的な TLS セッション鍵を復元し、暗号化されたデータにアクセスできるようになる可能性があります。 TLS ハンドシェイク中にポスト量子暗号鍵交換アルゴリズムを使用すると、大規模な量子コンピューターの攻撃から保護されます。

大規模な量子コンピューティングの可能性は、新しい量子耐性のある暗号化アルゴリズムの開発に拍車をかけています。 NIST は、ポスト量子暗号キーカプセル化メカニズム（KEM）の標準化を開始しました。 KEM は、共有対称鍵を生成するために使用される鍵交換の一種です。 AWS は、ポスト量子暗号の取り組みで採用する3つの NIST KEM の提案を選択しました。

ハイブリッドモードは、ネゴシエートされたキーが最も弱いキー合意スキームと同じくらい強力であることを保証します。スキームの1つが壊れた場合、通信は機密のままです。トランスポート層セキュリティ1.2ドラフトのインターネット技術特別調査委員会（IETF）ハイブリッドポスト量子暗号キーカプセル化方法では、ポスト量子暗号 KEM を ECDHEと組み合わせて、TLS1.2 用の新しい暗号スイートを作成する方法について説明しています。

これらの暗号スイートは、TLS ハンドシェイク中に 2つの独立した鍵交換を実行するハイブリッド鍵交換を使用します。次に、鍵交換は、それぞれの鍵を暗号化して 1 つの TLS セッション鍵に結合します。この戦略は、古典的な鍵交換の実証済みのセキュリティと、NIST によって分析されている新しいポスト量子暗号鍵交換の潜在的な量子安全特性を組み合わせたものです。

ハイブリッド型ポスト量子暗号 TLS のパフォーマンス面の効果

ポスト量子暗号暗号スイートは、古典的な暗号スイートとは異なるパフォーマンスプロファイルと帯域幅使用の特徴を持っています。 AWS は、Amazon Elastic Compute Cloud（Amazon EC2）C5n.4xlarge 上のクライアントとパブリック AWS KMS エンドポイント間の 2,000 回の TLS ハンドシェイク全体の帯域幅とレイテンシーを測定しました。これらは両方とも us-west-2 リージョンで行われました。独自のパフォーマンス特性は異なる場合があり、以下にあげる環境要因で変わる可能性があります。

  • CPUの速度とコア数
  • 既存のワークロード、AWS KMS を呼び出す頻度と、アプリケーションが実行する他の作業
  • ネットワークのロケーションとキャパシティ

以下のグラフと表は、現在ほとんどのお客様が使用している古典的な ECDHE 鍵交換アルゴリズムに加えて、新しくサポートされたすべてのラウンド 2ポスト量子アルゴリズムに対して AWS が実行したレイテンシー測定値を示しています。

図2は、古典的な ECDHE のみ使ったものと比較した、すべてのハイブリッド型ポスト量子アルゴリズムの遅延の違いを示しています。ECDHE のみの場合と比較すると、SIKE は約 101ミリ秒のオーバーヘッドを追加し、BIKE は約 9.5ミリ秒のオーバーヘッドを追加し、Kyber は約 0.3ミリ秒のオーバーヘッドを追加しています。

図2 : 4 つの鍵交換アルゴリズムの TLS ハンドシェイクのレイテンシーをパーセンタイルで可視化したもの

図2 : 4 つの鍵交換アルゴリズムの TLS ハンドシェイクのレイテンシーをパーセンタイルで可視化したもの

図3は、Kyber を使用した ECDHE と ECDHE のみの遅延の違いを示しています。 Kyber を追加すると、約 0.3 ミリ秒のオーバーヘッドが追加されます。

図3: トップ 2 の鍵交換アルゴリズムによる TLS ハンドシェイクのレイテンシーをパーセンタイルで可視化したもの

図3: トップ 2 の鍵交換アルゴリズムによる TLS ハンドシェイクのレイテンシーをパーセンタイルで可視化したもの

次の表は、各暗号スイートの TLS ハンドシェイクを完了するために必要なデータの合計量（バイト単位）、平均遅延、およびさまざまなパーセンタイルでの遅延を示しています。すべての測定値は、2,000 回の TLS ハンドシェイクから収集されました。ハンドシェイクの開始からハンドシェイクが完了するまでの時間はクライアントで測定され、すべてのネットワーク転送時間が含まれます。すべての接続は 2048 ビットのキーを使用した RSA 認証を使用し、ECDHE は secp256r1 曲線を使用しました。すべてのハイブリッドポストクォンタムテストでは、NIST Round 2 バージョンを使用しました。 Kyber テストは Kyber-512 パラメーターを使用し、BIKE テストは BIKE-1レベル1 パラメーターを使用し、SIKE テストは SIKEp434 パラメーターを使用しました。

暗号化方式 バンド幅
(バイト)		 ハンドシェイクの合計
 平均時間
(ミリ秒） 		p0
（ミリ秒） 		p50
（ミリ秒） 		p90
（ミリ秒） 		p99
（ミリ秒）
ECDHE (古典的)
3,574 2,000 3.08 2.07 3.02 3.95 4.71
ECDHE + Kyber R2
5,898 2,000 3.36 2.38 3.17 4.28 5.35
ECDHE + BIKE R2
12,456 2,000 14.91 11.59 14.16 18.27 23.58
ECDHE + SIKE R2
4,628 2,000 112.40 103.22 108.87 126.80 146.56

デフォルトでは、AWS SDK クライアントは TLS ハンドシェイクを1回実行して、新しい TLS 接続をセットアップしてから、その TLS 接続を複数のリクエストに再利用します。これは、ハイブリッドポスト量子暗号 TLS ハンドシェイクのコストの増加が、TLS 接続を介して送信された複数のリクエストに対して償却されることを意味します。ポスト量子暗号アルゴリズムを使用する全体的な追加コストを評価するときは、この償却を考慮に入れる必要があります。そうしないと、パフォーマンスデータを正しく理解できない可能性があります。

AWS KMS は、Kyber ラウンド2 を KMS の最も優先度の高いポスト量子暗号アルゴリズムとして選択しました。ポスト量子暗号アルゴリズムにおける次に優先となるのは BIKE ラウンド2、SIKE ラウンド2 です。これは、Kyber のパフォーマンスが、ほとんどの AWS KMS のお客様が現在使用していて、慣れている古典的な ECDHE のパフォーマンスに最も近いためです。

ハイブリッド型ポスト量子暗号の暗号スイートの使い方

AWS KMS でポスト量子暗号スイートを使用するには、AWS SDK for Java2.x 用のAWS Common Runtime（CRT）HTTP クライアントのプレビューリリース版が必要です。また、s2n ポスト量子暗号ハイブリッド暗号スイートを使用するように AWS CRT HTTP クライアントを設定する必要があります。 AWS KMS のポスト量子暗号 TLS は、AWS GovCloud（US-East）、AWS GovCloud（US-West）、Beijing Sinnet Technology Co. Ltd（”Sinnet”）が運営する AWS China（北京）リージョン、および Ningxia Western Cloud Data Technology Co. Ltd（”NWCD”）が運営する AWS China（寧夏）リージョンを除くすべての AWS リージョンで利用できます。 NIST はまだポスト量子暗号の標準化していないため、Federal Information Processing Standard（FIPS）に準拠する必要がある接続では、ハイブリッド鍵交換を使用できません。たとえば、kms.<region> .amazonaws.com はポスト量子暗号スイートの使用をサポートしていますが、kms-fips.<region> .amazonaws.com はサポートしていません。

  1. AWS SDK for Java 2.xを使用している場合は、AWS CommonRuntimeクライアントのプレビューリリースをMavenの依存関係に追加する必要があります。 
    <dependency>
    <groupId>software.amazon.awssdk</groupId>
    <artifactId>aws-crt-client</artifactId>
    <version>2.14.13-PREVIEW</version>
</dependency>
  2. 次に、アプリケーションの既存の初期化コードで新しいSDKと暗号スイートを構成する必要があります。 
    if(!TLS_CIPHER_PREF_KMS_PQ_TLSv1_0_2020_07.isSupported()){
    throw new RuntimeException("Post Quantum Ciphers not supported on this Platform");
}

SdkAsyncHttpClient awsCrtHttpClient = AwsCrtAsyncHttpClient.builder()
          .tlsCipherPreference(TLS_CIPHER_PREF_KMS_PQ_TLSv1_0_2020_07)
          .build();
          
KmsAsyncClient kms = KmsAsyncClient.builder()
         .httpClient(awsCrtHttpClient)
         .build();
         
ListKeysResponse response = kms.listKeys().get();

これで、サポートされているリージョンでAWS KMS に対して行われるすべての接続で、新しいハイブリッドポスト量子暗号暗号スイートが使用されます。セットアップされたすべての完全な例を確認するには、こちらのサンプルアプリケーションを確認してください。

やってみて頂きたいこと

ポスト量子暗号対応のクライアントの利用方法についていくつかご紹介します。

  • 負荷テストとベンチマークを実行します。これらの新しい暗号スイートは、古典的な鍵交換アルゴリズムとは異なる動作をします。ハンドシェイク時間を長くできるように接続タイムアウトを調整する必要がある場合があります。または、AWS Lambda 関数内で実行している場合は、実行タイムアウト設定を延長する必要があります。
  • 別のロケーションから接続してみてください。リクエストがたどるネットワークパスによっては、ディープパケットインスペクション（DPI）を備えた中間ホスト、プロキシ、またはファイアウォールがリクエストをブロックしていることに気付く場合があります。これは、ClientHello の新しい暗号スイートまたはより大きな鍵交換メッセージが原因である可能性があります。この場合、セキュリティチームまたは IT 管理者と協力して、関連する構成を更新し、新しいTLS 暗号スイートのブロックを解除する必要がある場合があります。インフラストラクチャがこの新しいバリアントの TLS トラフィックとどのように相互作用するかという点についてフィードバックを頂きたいと考えています。質問やフィードバックがある場合は、AWS KMS ディスカッションフォーラムで新しいスレッドを開始してください。

まとめ

このブログ投稿では、AWS KMS でのラウンド2 ハイブリッドポスト量子暗号アルゴリズムのサポートを発表し、AWS KMS エ ンドポイントに接続するときに TLS のハイブリッドポスト量子暗号鍵交換アルゴリズムの実験を開始する方法を示しました。

追加情報

ポスト量子暗号についてさらに知りたい方は以下の情報源を参照してください。

このブログポストの原文はこちらにあります。このブログポストは AWS ソリューション アーキテクトの高橋 悟史が翻訳しました。