Amazon Web Services ブログ

ポスト量子暗号 TLS が AWS KMS でサポートされました

AWS Key Management Service (AWS KMS) が KMS API エンドポイントに接続する際に使われる Transport Layer Security (TLS) ネットワーク暗号化プロトコルにおけるポスト量子暗号ハイブリッド鍵交換をサポートしました。この投稿では、ポスト量子暗号 TLS とは何か、 ハイブリッド鍵交換とは何か、 なぜこれらの技術が重要か 、この機能でどのようなメリットを得られるのか、そしてフィードバックの方法について説明します。

ポスト量子暗号 TLS とは?

ポスト量子暗号 TLS は、ポスト量子暗号の暗号プロトコルを追加する機能です。 AWS はオープンソースの TLS 実装である s2n を使用しています。2019年6月に AWS はポスト量子暗号 s2n をリリースしました。これは、IETF ドラフトで定義されている2種類のポスト量子暗号ハイブリッド暗号スイートを実装しています。暗号スイートは、従来型とポスト量子暗号の両方のセキュリティ保護を行う暗号鍵交換方式を指定するものです。

ポスト量子暗号 TLS の重要性

大規模な量子コンピュータは、TLS 接続の暗号鍵交換で使用されている既存の公開鍵暗号を破る可能性があります。大規模な量子コンピューターは現時点で利用可能ではありませんが、長期的なセキュリティ保護のニーズについて考え、準備しておくことが重要です。記録された TLS トラフィックは将来的に大規模な量子コンピュータで復号出来る可能性があります。TLS 接続の上で送信されているデータの長期間の機密性維持が必要なアプリケーションを開発している場合、大規模な量子コンピュータが実用化され、悪意を持った人に利用可能になる前にポスト量子暗号に移行することを検討するべきでしょう。AWS はこの機能の提供について取り組んでおり、お客様にも準備して頂きたいと考えています。

AWS は大規模な量子コンピュータの実現を待つのではなく、今この機能を提供します。 お客様は、アプリケーションに対する潜在的なパフォーマンス影響を計測することが可能です。また、お客様は、ポスト量子暗号スキームによってもたらされる追加の利点を得ることが可能です。AWS はこの機能が既に存在する KMS エンドポイントへの接続に関するセキュリティーのバーを向上させると考えていると共に、新しい暗号スイート帯域利用率やレイテンシに影響を与えると考えています。また、TLS 接続を中継する中間システムにも影響を与える可能性があります。将来に渡るサービスの改善のために AWS はこれらのお客様環境における影響についてフィードバックして頂きたいと考えています。

ポスト量子暗号 TLS 登場の背景

現在、AWS KMS への全てのリクエストは 下記の暗号鍵交換スキームのどちらかを利用した TLS を利用します :

FFDHE と ECDHE は安全な暗号鍵交換の業界標準です。 KMS は TLS キーネゴシエーションで揮発性の鍵のみを使います。これにより全ての接続において固有の鍵を使っていることが保証され、ある接続で発生したセキュリティ侵害が他の接続に影響を与えることがなくなります。 これらの方式は、既存のコンピュータを使った暗号解読に対しては安全ですが、大規模な量子コンピュータを使った既知の攻撃手法に対しては安全ではありません。 近い将来、大規模な量子コンピュータは Shor のアルゴリズムを用いて、記録されたセッションから TLS のセッションキーを復号し、データにアクセス出来るようになる可能性があります。大規模な量子コンピュータから保護するためには、ポスト量子暗号鍵交換アルゴリズムが TLS ハンドシェイクで必要になります。

大規模な量子コンピューティングの可能性は、ポスト量子暗号の開発に拍車をかけました。NIST(National Institute of Standards and Technology)ポスト量子暗号アルゴリズムの標準化作業を開始しています。 AWS は2つのNIST 標準案に貢献しています :

Bit Flipping Key Encapsulation (BIKE)
Supersingular Isogeny Key Encapsulation (SIKE)
BIKE と SIKE は鍵カプセル化メカニズム(KEMs)です。 KEM は 共有される対称鍵を決定するための暗号鍵交換の方法です。ポスト量子暗号の s2n は揮発性の BIKE もしくは SIKE の鍵のみを使用します。

NIST の標準化プロセスは2024年までかかる予定です。 それまでの間に、BIKE や SIKE のような提案されているアルゴリズムのみを使うことは、未知のセキュリティ脆弱性により TLS 接続のデータ漏洩に結びつく可能性があります。 このリスクを低減し、新しいポスト量子暗号のスキームを使うために、従来型のアルゴリズムと NIST に提案している新しいポスト量子暗号アルゴリズムを組み合わせる必要があります。TLS 1.2のためのハイブリッドポスト量子暗号カプセル化手法 、このIETFドラフトは BIKE と SIKE を EDCHEと組み合わせて TLS の新しい暗号スイートを作る方法を示しています。

この2つの暗号スイートは、TLS ハンドシェイク中に行われる2つの独立した暗号鍵交換を使用します。また、暗号論に従って複数のキーを単一の TLS セッションキーに結合します。アプローチは提案中のポスト量子暗号鍵交換と既存の暗号鍵交換手法の高い保証レベルを両立させます。

ハイブリッドポスト量子暗号 TLS のパフォーマンスへの影響

ポスト量子暗号スイートは、既存の暗号スイートと比較すると異なるパフォーマンス特性と帯域要件を持っています。AWS では、Amazon EC2 C5 2x.large インスタンス で単一のハンドシェイクで必要なレイテンシと帯域幅を測定しました。この測定結果は、 SDK を使って KMS に接続するときの予測のベースラインとなります。お客様環境での実際の結果はハードウェア( CPU の速度と、コア数)、既存のワークロード( KMS に対するコール数と他のアプリケーションの実行状況)、ネットワーク(ロケーションとキャパシティ)に依存することが予想されます。

BIKE と SIKE は異なるトレードオフを持っています。 BIKE はより高速な計算速度と長い鍵長を持つ鍵を特徴としています。 SIKE は遅い計算速度と、短い鍵長が特徴です。 下記の表は、AWS による計測結果です。 EDCHEを使った従来型の暗号キーエクスチェンジアルゴリズムも比較に含まれています。

表1
TLSメッセージ ECDHE(単位 バイト) ECDHE with BIKE(単位 バイト) ECDHE with SIKE(単位 バイト)
ClientHello 139 147 147
ServerKeyExchange 329 2,875 711
ClientKeyExchange 66 2,610 470

表 1 はそれぞれのTLSメッセージで送信されたデータ量(単位はバイト)を示しています。 ClientHello メッセージは、新しいClientHello エクステンションを含むためポスト量子暗号スイートでは大きくなっています。 キーエクスチェンジメッセージのサイズは BIKE もしくは SIKE メッセージを含むためサイズが大きくなっています。

表2
テスト項目 ECDHE (単位 ミリ秒) ECDHE with BIKE(単位 ミリ秒) ECDHE with SIKE(単位 ミリ秒)
サーバー処理時間 0.11 20.26 95.53
クライアント処理時間 0.10 0.39 57.05
合計ハンドシェイク時間 1.19 25.58 155.08

表2は同じリージョンにあるクライアントとサーバーがハンドシェイクに使った時間(単位はミリ秒)を示しています。サーバー処理時間は、鍵生成、サーバー鍵交換メッセージへの署名、クライアント鍵交換メッセージの処理の時間を含んでいます。 合計時間は、クライアント側でハンドシェイクが開始してから終了する時間をネットワーク転送時間も含めて計測しています。 全ての接続は RSA 2048 ビット鍵による認証と secp256r1 楕円暗号を使用した ECDHE を使用しています。BIKE のテストは BIKE-1 レベル1パラメータを使用しており、SIKE のテストは SIKEp503 パラメータを使用しています。

TLSハンドシェイクは新しいコネクションを確立する際に1度だけ実行しています。SDK は可能な時は複数の KMS へのリクエストで接続を再利用します。したがって、お客様にとっては、既に既存の TLSセッションがあるという前提だと、後続の往復の通信にかかった時間を計算に含めたくないはずです。そうしないとご自身で測定されるパフォーマンスデータと比較する際の誤差が大きくなります。

ハイブリッドポスト量子暗号スイートの利用方法

注意 : AWS CRT HTTP クライアントはベータリリースであり、aws-sdk-java-v2 リポジトリの中の aws-crt-dev-preview ブランチの中にあります。ベータリリースとお客様のベータリリースの利用については、AWS Service Terms のセクション1.10(ベータサービスへの参加)に従ってください。

AWS KMS でポスト量子暗号スイートを利用するには、 お客様は Java SDK 2.0 の開発者プレビューと AWS Common Runtimeが必要です。s2n のハイブリッドポスト量子暗号スイートを利用するには、AWS Common Runtime HTTP クライアントの構成が必要です。 このクライアントで KMSエ ンドポイントへの接続が可能ですが、TLS終端にFIPS 140-2 認定済暗号を使っていないエンドポイントのみに接続が可能です。例えば、kms.<リージョン名>.amazonaws.com はポスト量子暗号スイートをサポートしますが、kms-fips.<リージョン名>.amazonaws.comはサポートしません。

完全なセットアップの例をご覧になりたいかたは、こちらをご覧ください。

GitHubとパッケージレイアウト

図1 は GitHubとパッケージのレイアウトを示しています。下記のステップは構築と SDK の構成手順を示しています。

  1. Java SDK v2 Common Runtime Developer プレビューをダウンロードします
    $ git clone git@github.com:aws/aws-sdk-java-v2.git --branch aws-crt-dev-preview
    $ cd aws-sdk-java-v2
  2. aws-crt-client JAR ファイルをビルドします
    $ mvn install -Pquick
  3. プロジェクトの中で、 AWS Common Runtime クライアントを Maven 依存関係に設定します
    <dependency>
        <groupId>software.amazon.awssdk</groupId>
        <artifactId>aws-crt-client</artifactId>
        <version>2.10.7-SNAPSHOT</version>
    </dependency>
  4. 既存のアプリケーション上の初期化コードの中で新しい SDK と暗号スイートを構成します
    if(!TLS_CIPHER_KMS_PQ_TLSv1_0_2019_06.isSupported()){
        throw new RuntimeException("Post Quantum Ciphers not supported on this Platform");
    }
    SdkAsyncHttpClient awsCrtHttpClient = AwsCrtAsyncHttpClient.builder()
              .tlsCipherPreference(TLS_CIPHER_KMS_PQ_TLSv1_0_2019_06)
              .build();
    KmsAsyncClient kms = KmsAsyncClient.builder()
             .httpClient(awsCrtHttpClient)
             .build();
    ListKeysResponse response = kms.listKeys().get();
    

これで、サポートされているリージョン内の AWS KMS への全ての接続が、新しいハイブリッドポスト量子暗号スイートを使うようになります。

試して頂きたいこと

ポスト量子暗号クライアントを使ういくつかのアイデアをご紹介します

  • 負荷テストとベンチマークの実行。新しい暗号スイートは既存の暗号鍵交換アルゴリズムとは異なる動作をします。 より長いハンドシェイクを許容出来るように、接続タイムアウトを調整する必要があるかもしれませんし、AWS Lambda 関数内で実行している場合には、Lambda 自体の実行タイムアウトを長くする必要があるかもしれません。
  • 異なるネットワークの場所からの接続を試す。KMS へのリクエストが通るネットワークパスに依存して、 中間ホストやプロキシー、ファイアーウォールなどのディープパケットインスペクション(DPI)によってリクエストをブロックするものがある可能性があります。この事象は ClientHello メッセージの中の新しい暗号スイートや、長くなった暗号鍵交換メッセージに起因する可能性があります。もしその場合には、新しい TLS  暗号スイートのブロックを解除するために、セキュリティーチームや IT 管理者の方と協力して設定を変更する必要があるかもしれません。 私達は、お客様のインフラストラクチャが新しい種類の TLS 通信にどのように対処したかをフィードバック頂きたいと考えています。

追加情報

ポスト量子暗号にご興味があり、追加の情報が必要な場合にご覧ください。

NIST Post-Quantum Cryptography
European Telecommunications Standards Institute (ETSI) Quantum-Safe Cryptography

まとめ

この投稿では、ポスト量子暗号セキュリティのトピックについて紹介すると共に、AWS と NIST が課題に対して取り組んでいることをカバーしました。また、KMS エンドポイントに接続する際の TLS ハイブリッド ポスト量子暗号鍵交換アルゴリズムを試してみる方法を紹介しました。

この投稿についてフィードバックがある場合には、コメントを入力してください。KMS のエンドポイントに接続する HTTP クライアントについて質問がある場合には、AWS KMS ディスカッションフォーラムで新しいスレッドを作ってください。

原文 : Post-quantum TLS now supported in AWS KMS

この投稿の翻訳はSA 高橋が担当しました。