本ブログは 2024 年 12 月 10 日に公開された AWS Blog “ AWS-LC FIPS 3.0: First cryptographic library to include ML-KEM in FIPS 140-3 validation ” を翻訳したものです。 AWS-LC FIPS 3.0 が National Institute of Standards and Technology (NIST) の Cryptographic Module Validation Program (CMVP) の 審査中モジュール リストに追加されたことを発表いたします。AWS-LC のこの最新の検証では、ML-KEM (Module Lattice-Based Key Encapsulation Mechanism) のサポートが導入されています。ML-KEM は、FIPS で新たに標準化されたポスト量子暗号アルゴリズムです。これは、米国連邦政府の通信を含む、最も機密性の高いワークフローの長期的な機密性を強化するための重要なステップです。 この検証により、 AWS LibCrypto (AWS-LC) は、FIPS モジュール内でポスト量子アルゴリズムのサポートを提供する初のオープンソース暗号モジュールとなります。 FedRAMP 、 FISMA 、 HIPAA などの連邦コンプライアンスフレームワークに基づいて運用されている組織など、FIPS 検証済み暗号モジュールを必要とする組織は、AWS-LC 内でこれらのアルゴリズムを使用できるようになります。 今回の発表は、新しい FIPS 140-3 認証を継続的に取得するという AWS-LC の長期的なコミットメントの一環です。AWS-LC は 2023 年 10 月に AWS-LC-FIPS 1.0 で 最初の認証を取得 しました。その後のバージョンである AWS-LC-FIPS 2.0 は、2024 年 10 月に 認証を取得 しました。この記事では、ポスト量子暗号アルゴリズム ML-KEM の FIPS 検証、AWS-LC FIPS 2.0 および 3.0 における既存アルゴリズムのパフォーマンス改善、バージョン 3.0 で追加された新しいアルゴリズムのサポートについて説明します。また、新しいアルゴリズムを使用してハイブリッドポスト量子暗号スイートを実装する方法と、将来の脅威から保護するために今すぐ設定できる構成オプションについても説明します。 FIPS ポスト量子暗号 大規模な量子コンピュータは、現在公開鍵暗号で保護しているデータの長期的な機密性に対する脅威となります。今記録して後で復号する攻撃 (record-now, decrypt-later 攻撃) として知られる手法では、攻撃者は今日のインターネットトラフィックを記録し、鍵交換と暗号化された通信をキャプチャします。そして、十分に強力な量子コンピュータが利用可能になったときに、暗号の安全性を支える計算上の困難性を突破することで、過去に記録した通信の共有シークレットと暗号鍵を解読できます。 ML-KEM は、量子コンピュータの脅威から公開鍵暗号を守るために NIST が標準化を進めている新しい鍵カプセル化メカニズムの 1 つです。 RSA 、Diffie-Hellman (DH)、または楕円曲線 Diffie-Hellman (ECDH) 鍵交換と同様に、2 者間で共有シークレットを確立することで機能します。ただし、RSA や DH とは異なり、ML-KEM は量子コンピュータでも突破が困難と考えられている数学的問題に基づいて鍵交換を行います。 現時点では、このような大規模な量子コンピュータを実現する技術はまだ確立されていません。そのようなコンピュータの実現には、さらなる科学技術のブレークスルーが必要です。しかし、将来実現する可能性に備えて、ML-KEM などのポスト量子アルゴリズムを今日の鍵交換プロトコルに導入することで、record-now, decrypt-later 攻撃のリスクを軽減できます。AWS は、ECDH などの従来の鍵交換方式と ML-KEM を組み合わせたハイブリッド鍵交換アプローチを採用し、現在および将来の攻撃者に対するリスクを軽減することを推奨しています。この記事の後半では、将来の脅威から保護するために今すぐハイブリッドポスト量子暗号スイートを実装する方法を紹介します。 AWS-LC FIPS 3.0 では、ML-KEM アルゴリズムの 3 つのパラメータセット (ML-KEM-512、ML-KEM-768、ML-KEM-1024) をすべてサポートしています。3 つのパラメータセットは、NIST が指定する異なるレベルのセキュリティ強度を提供します ( FIPS 203 [9, Sect. 5.6] または ポスト量子セキュリティ評価基準 を参照)。ML-KEM-768 は汎用的なユースケースに推奨されます。ML-KEM-1024 は、より高いセキュリティレベルを必要とするアプリケーションや、国家安全保障システムの所有者およびオペレーター向けの Commercial National Security Algorithm Suite (CNSA) 2.0 などの明示的な指令への準拠が必要なアプリケーション向けに設計されています。 アルゴリズム NIST セキュリティカテゴリ 公開鍵 (B) 秘密鍵 (B) 暗号文 (B) ML-KEM-512 1 800 1632 768 ML-KEM-768 3 1184 2400 1088 ML-KEM-1024 5 1568 3168 1568 表 1. ML-KEM の 3 つのパラメータセットにおけるセキュリティ強度カテゴリ、公開鍵、秘密鍵、暗号文のサイズ (バイト単位) s2n-tls との統合 ML-KEM は、TLS 1.3 のハイブリッド鍵交換 (draft-ietf-tls-hybrid-design) を通じて、AWS のオープンソース TLS 実装である s2n-tls で利用可能になりました。また、TLS 1.3 のハイブリッド ECDHE-ML-KEM 鍵合意 (draft-kwiatkowski-tls-ecdhe-mlkem) のサポートと、Curve x25519 および ML-KEM-768 の新しい鍵共有識別子も追加しました。 FIPS 140 準拠モードでのハイブリッド鍵確立では、コンポーネントアルゴリズムの 1 つが NIST 承認メカニズムである必要があります ( NIST ポスト量子 FAQ で詳細を確認できます )。ML-KEM が NIST 承認アルゴリズムのリストに追加されたことで、Curve x25519 のような FIPS 標準化されていないアルゴリズムもハイブリッド暗号スイートに含めることができるようになりました。TLS 暗号スイートを ML-KEM-768 と x25519 を使用するように設定することで (draft-kwiatkowski-tls-ecdhe-mlkem)、FIPS 検証済み暗号モジュール内で初めて x25519 を使用できます。これにより、AWS-LC が提供する高度に最適化され機能検証された Curve x25519 実装を通じて、より効率的な鍵交換が可能になります。 新しいアルゴリズムと新しい実装 AWS-LC FIPS の継続的な検証に対する AWS のコミットメントにおいて重要な 2 つの要素は、承認された暗号サービスとして新しいアルゴリズムを含めることと、既存アルゴリズムについてパフォーマンスを改善し形式検証で正しさを証明した新しい実装を追加することです。 新しいアルゴリズム AWS は、開発者が FIPS 検証済みの暗号を採用できるよう、認定された暗号アルゴリズムの最新リビジョンと新しいプリミティブを継続的に検証することにコミットしています。最新の標準化リビジョンでアルゴリズムを検証することで、グローバル標準に準拠した高品質な実装を提供しています。 AWS-LC FIPS 3.0 では、SHA（Secure Hash Algorithm）標準の最新規格である SHA-3 を追加しました。SHA-3 ファミリーは、さまざまなアルゴリズムをサポートするために使用される暗号プリミティブです。AWS-LC FIPS 3.0 では、ECDSA と RSA の署名生成および検証を SHA-3 と統合し、ポスト量子アルゴリズム ML-KEM 内でも統合しました。AWS-LC では、ML-KEM が FIPS 検証済みの SHA-3 関数を呼び出し、SHA-3 と SHAKE ハッシュ手順の最適化された実装を提供します。つまり、AWS-LC の SHA-3 実装を継続的に改良・最適化することで、ML-KEM など SHA-3 を使用するアルゴリズム全体のパフォーマンスも向上していきます。 EdDSA は、曲線 Ed25519 を使用した楕円曲線に基づくデジタル署名アルゴリズムです。NIST の更新された Digital Signature Standard (DSS) である FIPS 186-5 に追加されました。この署名アルゴリズムは、AWS-LC 3.0 FIPS モジュールの一部として提供されるようになりました。鍵合意については、共有シークレットから鍵を導出するために使用される Single-step Key Derivation Function (SSKDF) ( SP 800-56Cr2 ) が、ダイジェストベースと HMAC ベースの両方の仕様で利用可能です。SSKDF は、例えば KMS で ECDH を使用 した際に生成される共有シークレットから鍵を導出するために使用できます。さらに、Key-based Key Derivation Function (KBKDF) である SP 800-108r1 を使用して、元の鍵からさらに鍵を導出できます。これは HMAC に基づくカウンターモードを使用して利用可能です。 パフォーマンス改善 AWS は、TLS プロトコルなどのトランスポートプロトコルで広く使用されている公開鍵暗号アルゴリズムのパフォーマンス向上に注力しました。例えば、 Graviton2 での RSA 署名 は、ビット長 2048 で 81%、3072 で 33%、4096 で 94% 高速化され、主要な演算が正しく動作することの形式検証も追加されました。第 3 世代 Intel Xeon 以降で利用可能な Intel の AVX512 Integer Fused Multiply Add (IFMA) 命令を使用して、 Intel の開発者がこれらの命令と幅広い AVX512 レジスタを使用する RSA 実装を AWS-LC にコントリビュート しました。これは既存の実装の 2 倍の速度です。 EdDSA 署名のスループットは平均 108% 向上し、検証は 37% 向上しました。この平均は、Graviton2、Graviton3、Intel Ice Lake (Intel Xeon Platinum 8375C CPU) の 3 つの環境で測定されています。 このパフォーマンス向上は 、 s2n-bignum ライブラリから各ターゲット向けのコア演算のアセンブリ実装を統合することで達成されています。さらに、コア演算は定数時間で実装されており、各演算が正しく動作することが形式検証で証明されています。 以下の図 1 では、AWS-LC FIPS 1.0 と比較したバージョン 2.0 および 3.0 でのパフォーマンス改善の割合を示しています。2.0 で達成された改善は 3.0 でも維持されており、グラフでは繰り返し表示していません。グラフには対称鍵の改善も含まれています。セッション確立後の通信を暗号化するために TLS で広く使用されている AES-256-GCM では、Intel Ice Lake と Graviton4 全体で 16 KB メッセージを暗号化する際に平均 115% の向上があります。ディスクストレージで使用される AES-256-XTS では、256 B の入力の暗号化が Intel Ice Lake で 360%、Graviton4 で 90% 高速化されています。 図 1: AWS-LC FIPS バージョン 2.0 および 3.0 でのパフォーマンス改善のグラフ 今すぐ ML-KEM を使用する方法 s2n-tls と AWS-LC の両方の TLS ライブラリを設定して、鍵交換に X25519MLKEM768 と SecP256r1MLKEM768 を有効にすることで、今すぐ ML-KEM によるハイブリッドポスト量子セキュリティを有効にできます。AWS は、各ライブラリの既存の TLS 設定 API を使用して、AWS-LC libssl と s2n-tls の両方でこれらのハイブリッドアルゴリズムのサポートを統合しました。TLS 接続をネゴシエートするには、以下のコマンドのいずれかを使用してください。 # AWS-LC クライアント CLI の例 ./aws-lc/build/tool/bssl s_client -curves X25519MLKEM768:SecP256r1MLKEM768:X25519 -connect <hostname> : <port> # S2N-tls クライアント CLI の例 ./s2n/build/bin/s2nc -c default_pq -i <hostname> <port> まとめ この記事では、オープンソース暗号ライブラリ AWS-LC を通じて提供している暗号技術の継続的な開発、最適化、検証について説明しました。 また、FIPS 検証済みポスト量子アルゴリズムの追加と、将来の脅威に備えて今すぐこれらのアルゴリズムを使用するための設定方法を紹介しました。 AWS-LC-FIPS 3.0 は、AWS-LC の新しいバージョンを継続的に FIPS 認証を取得していくという AWS のコミットメントの一環です。新しいアルゴリズムが標準化されるたびに認証対象に追加し、既存アルゴリズムのパフォーマンスと形式検証の水準も引き上げています。このコミットメントを通じて、 AWS Libcrypto for Rust (aws-lc-rs) や ACCP 2.0 ライブラリ への統合により、Rust、Java、Python 開発者のより広いコミュニティを引き続きサポートしています。また、 CPython への統合を促進 し、AWS-LC に対してビルドして Python 標準ライブラリのすべての暗号処理に使用できるようにしています。さらに、 rustls が FIPS サポートを提供できるようにしました 。 この記事についてご質問がある場合は、 AWS サポート にお問い合わせください。 Jake Massimo Jake は AWS Cryptography チームの応用科学者です。国際会議、学術文献、標準化団体への参加を通じて Amazon とグローバルな暗号コミュニティをつなぎ、ポスト量子クラウドスケール暗号技術の採用を促進することを目標としています。最近は、ポスト量子移行をサポートするための AWS 暗号ライブラリの開発に注力しています。 Nevine Ebeid Nevine は AWS Cryptography のシニア応用科学者で、AWS の暗号ライブラリである AWS-LC のアルゴリズム開発、マシンレベルの最適化、FIPS 140-3 要件に注力しています。AWS 入社前は、自動車およびモバイルセキュリティアプリケーションにおけるさまざまな暗号ライブラリとプロトコルの研究開発に従事していました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 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 ハンドシェイクのレイテンシー比較 図 2 は、従来の ECDHE とハイブリッドポスト量子 (ECDHE + Kyber) 鍵確立の両方について、クライアント側で測定した 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 を設定するには 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> コードの初期化時に目的の暗号スイートを設定します。以下のコードサンプルは、最新のハイブリッドポスト量子暗号スイートを使用するように 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 ハンドシェイク数 最も大きなレイテンシー改善は、 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 は AWS Cryptography のシニアソフトウェアエンジニアです。ポスト量子暗号と暗号ハードウェアに関心を持っています。以前は AWS Security で、社内全体で使用される内部サービスの開発に携わっていました。Brian は Vanderbilt University で学士号を、George Mason University でコンピュータエンジニアリングの修士号を取得しています。「いつか」博士号を取得する予定です。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

はじめに 株式会社WinTicketでUnity&XRエンジニアをしています。加田です。私た ...