Amazon Web Services ブログ

AWS ポスト量子暗号への移行計画

Amazon Web Services (AWS) は、ポスト量子暗号 (PQC:Post-Quantum Cryptography) への移行を進めています。AWS の他のセキュリティおよびコンプライアンス機能と同様に、PQC は責任共有モデルの一部として提供されます。つまり、一部の PQC 機能はすべてのお客様に対して透過的に有効化されますが、他の機能はお客様が要件を満たすために選択して実装できるオプションになります。この移行は、インターネットなどの信頼されていないネットワークを介して通信するシステムから段階的に行われます。

暗号解読可能量子コンピュータ (CRQC: Cryptographically Relevant Quantum Computer) と呼ばれることもある大規模な量子コンピュータの脅威は、現在使用されている公開鍵暗号アルゴリズムを解読できる可能性があることです。これらのアルゴリズムは、ほとんどの通信プロトコルとデジタル署名スキームで使用されています。過去 8 年間、AWS は他の業界リーダー、政府機関、学術機関とともに、量子コンピューティングに対して耐性のある新しい公開鍵暗号アルゴリズムの提唱、研究、提案に取り組んできました。お客様は AWS が行う暗号化処理によってデータを保護しているため、私たちは早期から対策に着手し、将来的な PQC への移行における労力と影響を最小限に抑えました。AWS で使用されている公開鍵暗号を解読できるほど強力な量子コンピュータが現在存在する証拠はありませんが、私たちはそれを待っているつもりはありません。将来におけるお客様のデータのセキュリティを守るため、今のうちから対策を講じることを選びました。

この投稿では、AWS が PQC への移行の道のりがどこまで進んでいるかを簡潔にご紹介し、今後の方向性についてお伝えします。

過去 5 年間、私たちは米国国立標準技術研究所 (NIST) が評価中の PQC アルゴリズムの初期バージョンを、オープンソースライブラリと重要なセキュリティサービスの両方で展開し、お客様が PQC への移行によるパフォーマンスへの影響をテストできるようにしてきました。例えば、アルゴリズム実装のオープンソースライブラリ (AWS-LC)、TLS 実装 (s2n)、および AWS Key Management Service (AWS KMS)AWS Secrets ManagerAWS Certificate Manager (ACM) などのコアセキュリティサービスには、2019 年から NIST PQC 提案アルゴリズムの鍵カプセル化の実装が含まれています。

2024 年 8 月 13 日、NIST は 3 つの新しいポスト量子暗号 (PQC:Post-Quantum Cryptography)の暗号アルゴリズムを連邦情報処理標準 (FIPS) として発表しました。これは、2016 年に開始された NIST の量子コンピュータ PQC 標準化プロセスの結果です。AWS の従業員も、この 3 つの新 FIPS 標準を含む多くの暗号化スキームの提案に携わっています。

多くのお客様は、量子コンピュータ時代における安全な暗号化の標準化プロセスを注視してきました。これには、米国政府の Commercial National Security Algorithms (CNSA) Suite 2.0 の PQC 採用に関する要件や、欧州委員会の Recommendation on a Coordinated Implementation Roadmap for the transition to Post-Quantum Cryptography が含まれます。

第 1 ラウンドのPQCアルゴリズムが標準化されたことから、私たちは長期的なサポートのためにそれらを実装し始めることができます。暗号化操作を代行するサービスとオープンソースツールに依存しているお客様に、シームレスな移行を提供するために、PQC を実装するアプローチは次のとおりです。

AWS は今後数年にわたり、PQC への移行に多層的なアプローチを取ります。同時に進行するワークストリームは次のように定義しています。

  • ワークストリーム 1: 既存システムの棚卸し、新しい標準の特定と開発、テスト、移行計画を行います。最初の一連のアルゴリズム標準は公開されましたが、PQC を特定のアプリケーションやプロトコルに統合するための互換性確保のため、追加の標準が今後公開される予定です。
  • ワークストリーム 2: AWS に送信されるお客様データの長期的な機密性を確保するため、公開 AWS エンドポイントに PQC アルゴリズムを統合します。
  • ワークストリーム 3: ソフトウェア、ファームウェア、文書の署名などの機能に使用される、新たなポスト量子の長期的な Root of Trust (信頼の起点) をお客様がデプロイできるよう、AWS 暗号化サービスに PQC 署名アルゴリズムを統合します。
  • ワークストリーム 4: サーバーやクライアント証明書の検証など、セッションベースの認証に、ポスト量子署名を使用できるよう、AWS サービスに PQC 署名アルゴリズムを統合します。

ワークストリーム 1

この取り組みは、私達が現在進めている移行計画の外観であると捉えています。すでに私たちの全体的な戦略に反映されており、お客様のニーズに基づいて移行の優先順位付けを行っています。

お客様と同様に、私たちも暗号化を使用しているすべての場所を確認し、どの実装を移行する必要があり、優先順位をつける必要がありました。重要な決定の 1 つは、転送中 (in transit) の暗号化により重点を置き、保管中 (at rest) のデータの暗号化にはあまり重点を置かないことでした。公開鍵 (非対称) 暗号は、転送中の暗号化の基盤となるものです。なぜなら、信頼されていないネットワーク上で双方が共有秘密鍵のネゴシエーションを可能にするためです。しかし、現在広く使われている伝統的な公開鍵アルゴリズムが、暗号解読可能量子コンピュータ (CRQC) の実現により危険にさらされています。業界全体の現在の合意に基づけば、256 ビットの対称鍵暗号化に対する暗号解読可能量子コンピュータのリスクは、緩和する必要はありません。AWS の保管中のデータは 256 ビットの対称鍵暗号化で暗号化されているため、既存のお客様データを再暗号化したり、将来のデータを暗号化するために使用する対称アルゴリズムやキーを変更する必要はないと考えています。

対称暗号化キーやアルゴリズムの安全性は、暗号解読可能量子コンピュータによる暗号解読の脅威に晒されていませんが、公開鍵アルゴリズムを使用して共有対称鍵をネゴシエーションする場合があり、その際に対称鍵が危険にさらされる可能性があります。AWS で最初に PQC に移行する公開鍵暗号の用途は、まさにこの場合です。つまり、お客様と AWS サービスの公開エンドポイント間で共有対称鍵のネゴシエーションをする場合です。お客様が AWS サービスと通信するためのネットワークは、多くの場合 AWS やお客様のどちらの管理下になく、悪意のある第三者がデータを盗聴し、将来的に量子コンピュータを使って暗号を解読する可能性があります。ワークストリーム 2 では、この計画についてより詳しく説明しています。

次に AWS で PQC に移行するのは、長期的な Root of Trust (信頼の起点) として機能する公開鍵ペアを作成する機能です。これは通常、ソフトウェア、ファームウェア、ドキュメントにデジタル署名を適用するために使用されます。このような公開鍵ペアは、簡単に更新できないため、将来数年間にわたってデジタル署名の用途で有効である必要があります。人工衛星、ゲーム機、その他の IoT デバイスのファームウェアを考えてみてください。デバイスの寿命期間中に公開鍵ペアと署名アルゴリズムのコードを更新することが難しい場合があります。ワークストリーム 3 では、この計画をより詳しく説明しています。

AWS における公開鍵暗号の最後の領域は、一時的な Root of Trust (信頼の起点) として機能するキーペアを作成する機能を提供することです。これは通常、単一のトランザクション、Web セッション、または他の一時的なメッセージにデジタル署名を適用するために使用されます。この使用例の最も一般的な例は、デジタル証明書が TLS セッションでサーバーまたはクライアントを認証するために使用される方法です。ワークストリーム 2 と 3 が TLS セッションでのセッション鍵のネゴシエーションとデジタル署名のリスクを処理すると想定されるかもしれません。では、保護する残りの部分は何でしょうか? 実は、公開鍵暗号を利用してメッセージを交換する際には、広範囲のインターネットインフラストラクチャにおける標準と相互運用性に大きく依存します。業界がこれらの標準に合意し、相互運用性をテストするには時間がかかるため、このワークストリームが完了するまでに時間がかかります。ワークストリーム 4 では、この計画についてより詳しく説明しています。

AWS がどのように暗号化に関連するインベントリを作成し、PQC への移行計画を立てたかについて説明しました。暗号化の処理を AWS に全面的に任せていない場合、お客様は準備として何をすべきでしょうか? すべてのアプリケーションや業界に当てはまる単一のアプローチはありませんが、私たちが貢献したり、作業の一部として利用したりした推奨事項に関するより詳しい情報が記載されている関連するリソースをいくつかご紹介します。

組織全体の暗号技術/暗号システムの棚卸しを行って、PQC 移行の優先順位を付けることは、数年にわたる取り組みが必要かもしれません。しかし、短期的には次の 2 つの戦術的な対策を検討することをお勧めします。まず、ソフトウェアの更新バージョンを配布する機能を確保することです。これは、脆弱性管理やソフトウェアライフサイクル管理の観点から、組織にとって重要な機能です。この機能は、AWS コマンドラインインターフェース (AWS CLI)AWS SDK の新しい ポスト量子バージョンを公開した際に採用する必要があります。また、AWS サービスと通信するために TLS やその他の暗号化実装を使用するサードパーティ製品を更新する必要があるかもしれません。これにより、AWS が提供する PQC を活用できるようになります。

次に、組織全体で TLS 1.3 を採用する全社的な取り組みを開始することを強くお勧めします。TLS 1.3 および以降のバージョンは、従来からある公開鍵暗号を使ってセキュリティとパフォーマンスを改善しているだけでなく、PQC を使用できるようになることが義務づけられています。最近クライアントとサーバーで TLS 1.2 に更新した場合でも、システムを PQC の将来に備えるための作業が残っています。

ワークストリーム 2

お客様は、公開鍵暗号に基づくプロトコルを使用してクラウドサービスと通信します。これらのプロトコル (TLS など) は、お客様の通信の機密性が保たれ、転送中に改ざんされないことを保証するのに役立ちます。お客様の長期的な機密性の必要性を保護するために、私たちは量子コンピュータに対する長期的な対策として組み合わせた新しい鍵共有方式を先駆けて導入しました。この新しい方式は、楕円曲線ディフィー・ヘルマン (ECDH) という従来からある鍵交換アルゴリズムと、新しく標準化された ML-KEM アルゴリズムなどのポスト量子鍵カプセル化方式を組み合わせたものです。得られた 2 つの鍵を組み合わせることで、ネットワークトラフィックを暗号化するためのセッション通信鍵が確立されます。攻撃者がこの新しい鍵共有方式によって提供される機密性を破るには、これらの公開鍵プリミティブ (ECDH と ML-KEM) の両方を解読する必要があります。

AWS は、オープンソースの FIPS-140-3 検証済み暗号ライブラリ AWS-LC で ML-KEM を実装することで、ポスト量子暗号の展開の第一歩を踏み出しました。AWS-LC は AWS 全体で使用されている中核的な暗号ライブラリです。このワークストリームに関連して、HTTPS エンドポイントを持つ AWS サービス全体で使用されているオープンソース TLS 実装 s2n-tls でも使用されています。

Internet Engineering Task Force (IETF) は現在、ポスト量子暗号を組み込んだ TLS プロトコル標準の最終化を進めています。この標準が完成すれば、AWS は s2n-tls を新しい仕様に合わせて更新します。IETF 標準に基づく s2n のバージョンに AWS-LC からの ML-KEM 実装を統合できれば、この s2n バージョンを HTTPS ベースのインターフェースを提供するすべての AWS パブリックエンドポイントに展開を開始します。これは、AWS SDK や AWS CLI を通じてアクセスされる大半の AWS サービスを表します。SFTP、IPsec、SSH などの他のインターフェースを提供する AWS サービスについては、IETF などの標準化機関がそれらのプロトコルの実装ガイダンスを公開次第、ML-KEM サポートを追加します。

AWS マネージドサービスエンドポイントを PQC over TLS に移行する一環として、Elastic Load Balancing (ELB)Amazon API GatewayAmazon CloudFront など、ワークロードのサーバー側 TLS 終端を提供するサービスも有効化されます。これにより、これらのサービスで使用している同じデジタル証明書を使用でき、AWS がサーバー側で ML-KEM による TLS セッションのネゴシエーションを行います。これにより、既存の証明書を、未だ定義されていない PQC 標準のものに置き換えずとも、TLS セッションの長期的な機密性が提供されます。

ML-KEMへの移行をより円滑に進めるため、AWS は National Cybersecurity Center of Excellence (NCCoE) Migration to Post-Quantum CryptographyLinux Foundation’s Post Quantum Cryptography AllianceRust TLS Project など、主要な業界イニシアチブと協力しています。これらのパートナーシップは、テクノロジー分野全体で PQC ソリューションの異なる実装間のシームレスな相互運用性を確保するのに不可欠です。

ワークストリーム 3

多くのお客様は、ファームウェア、オペレーティングシステム、プリインストールされたサードパーティーのアプリケーションを含むシステムを製造しています。これらのコンポーネントは、公開鍵ベースのルート認証で暗号署名されており、エンドユーザーにサービスを提供する際のシステムのセキュリティと真正性を維持しています。セットトップボックスに接続しているスマート TVのように、インターネットに接続されずに 10 年以上稼働するシステムもあります。
さらに、一部のお客様は、製造時にハードウェアに直接ルート証明書を埋め込む必要があります。この処理は、元に戻したり更新したりすることはできません。10 年以上の稼働を想定したデバイスでは、量子コンピュータが暗号解読に使えるようになった場合でも、これらの初期のルート証明書のセキュリティを堅牢に保つ必要があります。

コードや文書に署名するために長期間有効な Root of Trust (信頼の起点) を提供する必要性に対処するため、AWS は ML-DSA という新しいデジタル署名アルゴリズムを採用します。ML-DSA は、量子コンピュータを持つ攻撃者に対しても安全であると考えられています。AWS は最初に AWS Key Management Service (AWS KMS) の機能として ML-DSA を提供し、お客様が AWS KMS で使用される FIPS-140-3 Level 3 検証済みのハードウェアセキュリティモジュール (HSM) 内で PQC 鍵を生成し、署名操作の Root of Trust (信頼の起点) として使用できるようにします。この統合は、PQC ロードマップにおける重要なマイルストンを示すものであり、お客様に長期的なセキュリティニーズに対する安全でポスト量子の Root of Trust (信頼の起点) と認証を確立する機能を提供します。

この長期的な視点は、PQC を早期に実装することの重要性を強調しています。これにより、長期間オフラインであっても、システムの全運用期間中にわたってセキュリティが確保されるようになります。Amazon は AWS KMS のこの機能を使って自社の Root of Trust (信頼の起点) を保護しますが、皆様にもこの機能を活用して同様の対策を検討していただくことをお勧めします。

ワークストリーム 4

ワークストリーム 2 では、通信チャネルを介してデータを共有する際のデータの機密性に対するリスクから保護するために PQC を展開する方法について議論しました。ストーリーを完結するには、ポスト量子の世界において、通信チャネル経由でサーバーとクライアントの身元の真正性を保護する方法が必要になります。

デジタル署名は、今日のTLS や SSH などのネットワークプロトコルにおいて、エンドポイントの認証に使われています。お客様は、信頼できる認証局 (CA) から発行された証明書を使用しています。この証明書は、デジタル署名を使って公開鍵をアイデンティティにバインドしており、サービスとクライアントのエンドポイントを認証するために使われます。現在利用可能な PQC 標準 (ML-DSA など) の一部は、証明書と組み合わせて実装することで、量子コンピュータ時代のリスクに対処できます。しかし、認証局とデジタル証明書を使用するシステムの間での相互運用性テストと、さらなる標準化が進まない限り、この作業を開始することはできません。この遅れの主な理由は、署名付きメッセージの受信者が、現在、広く信頼された証明書をどのように検証しているかにあります。たとえば TLS プロトコルでは、証明書チェーンを提示するサーバーに接続するクライアントは、サーバーが本物かどうかを判断するために、各証明書に埋め込まれた PQC 署名をすべて検証する必要があります。これらの署名の形式と、証明書の発行・管理プロセスは、Certificate Authority (CA) Browser Forum によって規定されています。CA Browser Forum のブラウザベンダー企業と証明書発行メンバーは、誰もが TLS セッションで広く信頼された証明書を安全に使えるようにするために、PQC が証明書の発行と検証にどのように機能するかを決定する必要があります。Amazon Trust Services は証明書発行者(訳者注 : 日本では一般に認証局/CAと呼称)であり、CA Browser Forum のメンバーです。私たちは、相互運用性テストを早めるためにこれらの標準の推進に関与しています。

広く信頼された証明書のための PQC の話がまとまりつつありますが、AWS Private CA サービスは、ML-DSA などの PQC アルゴリズムを使用して、プライベート用の証明書を発行できます。プライベート用の証明書は、CA ブラウザフォーラムが公開するルールに厳密に従う必要がないためです。プライベート証明書を使用するお客様は、クライアントとサーバーの両方のソフトウェアを制御できるため、PQC 認証スキームのクライアントとサーバーの両方を自由に実装できます。ワークストリーム 3 が完了し、AWS KMS で署名操作に ML-DSA が使用可能になると、AWS Private CA はプライベートネットワークで PQC を採用する準備のできたお客様向けに、証明書発行の一部として PQC を提供することを検討します。オープンソースの AWS-LC と s2n ソリューションは、必要に応じてお客様がクライアントとサーバーで PQC 証明書の検証機能を実装するために利用できます。

結論

この投稿では、責任共有モデルにおいて AWS が PQC に移行する方法について説明しました。また、PQC 移行戦略の作成方法と、AWS がその戦略のどの部分を提供するかについてのガイダンスを提供しました。業界が新しい暗号化アルゴリズムへの移行を行う中で、新しい課題と機会が生まれるでしょう。PQC 移行に関する追加情報、ブログ投稿、および定期的な更新については、AWS Post-Quantum Cryptography ページを引き続きご覧ください。
AWS のポスト量子暗号について詳しく知りたい場合は、post-quantum cryptography team にお問い合わせください。

この投稿に関する意見がある場合は、下のコメントセクションにコメントを投稿してください。この投稿に関する質問がある場合は、AWS Security, Identity, & Compliance re:Post で新しいスレッドを立てるか、AWS サポートに連絡してください。

Matthew Campagna
Matthew Campagna
Matthew は Amazon Web Services の暗号化の専門家であり、シニア・プリンシパル・エンジニアです。同社全体の暗号化ソリューションの設計とレビューを管理し、ポスト量子暗号への移行を指導しています。余暇には、通勤と睡眠を行っています。
Melanie Goldsborough
Melanie Goldsborough
Melanie は AWS のシニアセキュリティスペシャリストで、20 年以上にわたるインテリジェンスとテクノロジーの経験を持っています。彼女は公的機関を中心としたセキュリティサービスのグローバル販売戦略を立案しています。Melanie の専門分野は、コンテンツ開発、経営層とのエンゲージメント、そして顧客やパートナーの世界規模でのセキュリティ実践の向上に向けたプログラムの実行です。
Peter M. O’Donnell
Peter M. O’Donnell
Peter は AWS のプリンシパルソリューションアーキテクト(SA)で、セキュリティ、リスク、コンプライアンス分野の戦略アカウントチームの専門家です。9.5 年間にわたって AWS の SA を務め、データ保護、暗号化、ID 管理、脅威モデリング、コンプライアンス、セキュリティ文化、CISO とのエンゲージメントなどのセキュリティ関連トピックについて、同社の大規模かつ最も複雑な戦略的なお客様のサポートを行っています。

本ブログは Sr. Security Solutions Architect の勝原 達也が翻訳しました。原文はこちらを御覧ください。