「今盗んで、後で解く」に備える AWSのポスト量子暗号入門

Posted at 2026-09-24

はじめに

量子計算機に備えた暗号「ポスト量子暗号」が、AWSを含むクラウドや生成AIのサービスで、すでに使われ始めています。
ただ、名前は聞いても「何から何を守るのか」「自分のシステムは対応しているのか」は、わかりにくいですよね。
この記事では、ポスト量子暗号の仕組みを例え話で交えて説明し、AWS・他クラウド・生成AIベンダーの対応状況を、公式ドキュメントと手元での計測で確かめます。

先に、この記事で答える問いを2つ置いておきます。

問い1: 暗号化して送った通信が、10年後に読まれるかもしれないのはなぜでしょう?
問い2: AWSはポスト量子暗号に対応しているのに、CDKで作ったALBが守られていないことがあるのはなぜでしょう?

答えは、順番に説明したうえで回収します。

ポスト量子暗号とは

今の暗号は「行きは一瞬、帰りは数千年」

インターネットの通信を守っている暗号は、「答えを知っていれば一瞬で確認できるのに、知らないと見つけるのに途方もない時間がかかる問題」を土台にしています。

わかりやすい例は、素数の掛け算です。
61と53を掛けると3233になります。
これは電卓があれば一瞬です。
では逆に、「3233は、どの2つの素数を掛けたものか」と聞かれたらどうでしょう。
少し考えれば見つかりますが、掛け算よりずっと手間がかかります。

これを数百桁の数でやると、掛け算は一瞬のままなのに、元の2つを探す作業は今のコンピューターでは現実的な時間で終わらなくなります。
この「行きは一瞬、帰りは数千年」という差が、鍵の役目をしています。
RSA暗号や、TLSの鍵交換で使われる楕円曲線暗号(ECDH)は、どちらもこのタイプの問題に頼っています。

量子計算機は「帰り道」が得意

量子計算機は、今のコンピューターとは計算の仕方が違います。
そして、上の「帰り道」にあたる問題は、量子計算機が速く解ける種類に入ることがわかっています。

ショアのアルゴリズムという解き方がです

十分に大きな量子計算機ができたら、数千年かかるはずの計算が、短い時間で終わってしまいます。
今の鍵に、合鍵ができるようなものです。

ただし、今の時点で、実際の暗号を破れるほど大きな量子計算機はまだありません。
いつできるかも、はっきりとはわかっていません。

量子計算機でも近道が見つかっていない問題に取り替える

そこで、「量子計算機でも速く解く方法が見つかっていない問題」を土台にした暗号に取り替えよう、というのがポスト量子暗号です。

代表的なのは「格子」を使う方式です。
方眼紙の交点のように、点が規則正しく並んだ網目を思い浮かべてください。
網目の外にある点から、いちばん近い交点を探す問題は、2次元の方眼紙ならすぐに解けます。
ところが、この網目を数百次元に広げ、さらに少しだけノイズを混ぜると、今のコンピューターでも量子計算機でも、速く解く方法が見つかっていません。

アメリカの標準化機関であるNISTは、2024年8月に次の3つを標準として公開しました。

ML-KEM(FIPS 203): 鍵を安全に受け渡すための方式で、格子を使います
ML-DSA(FIPS 204): 電子署名の方式で、これも格子を使います
SLH-DSA(FIPS 205): ハッシュ関数を使う電子署名の方式です

注意したいのは、「絶対に破れない」と証明されたわけではない点です。
あくまで「今のところ、量子計算機でも速く解く方法が見つかっていない」という状態です。

古い錠前と新しい錠前を両方つける

新しい方式に、まだ誰も気づいていない弱点があるかもしれません。
そこで実際の通信では、従来の方式と新しい方式を同時に使う「ハイブリッド」が主流になっています。

玄関の扉に、使い慣れた古い錠前と、新しい錠前を両方つけるイメージです。
泥棒は、両方を開けないと中に入れません。
量子計算機で古い錠前が開けられても、新しい錠前が残ります。
逆に、新しい錠前に弱点が見つかっても、古い錠前が今までどおり守ります。

TLS 1.3では、X25519(従来の楕円曲線の鍵交換)とML-KEM-768を組み合わせた「X25519MLKEM768」という方式が、広く使われています。

今盗んで、後で解く

開けられない箱を集める人がいる

あなたが送ったデータは、相手に届くまでに、Wi-Fiのルーター、通信事業者の設備、海底ケーブルなど、たくさんの機器を通ります。
その途中の機器に手が届く立場なら、流れてくるデータのコピーを、そのまま保存しておけます。

もちろん、中身は暗号化されているので、今は読めません。
郵便に例えると、鍵のかかった箱を、配達の途中でこっそり写し取って倉庫にしまっておくようなものです。
箱は開けられなくても、しまっておけます。

では、開けられない箱を、なぜわざわざ集めるのでしょうか。

合鍵ができた日に、まとめて開ける

答えは、将来、合鍵(量子計算機)ができた日に、倉庫の箱をまとめて開けるためです。
この攻撃は「Harvest Now, Decrypt Later(今盗んで、後で解く)」と呼ばれています。

これが問い1の答えです。
今日送った暗号化通信でも、コピーが保存されていれば、10年後に読まれるかもしれません。

少しだけ仕組みを補足します。
TLSでは、最初に鍵交換(ECDHなど)で「共通の鍵」を作り、その鍵でAESなどの暗号を使って中身を暗号化します。
量子計算機で破られるのは、最初の鍵交換の部分です。
鍵交換の記録から共通の鍵が割り出されると、その鍵で暗号化された中身がまとめて読めてしまいます。

対策するとよいこと、しないと起きること

対策するとよいこと

今日から交換する鍵は、コピーを保存されても、将来解かれにくくなります
取り替えるのは鍵交換の部分だけで、AES-256のような暗号や、SHA-256などのハッシュ関数は、そのまま使えます
移行の期限にも備えられます(NISTのドラフト文書 NIST IR 8547 は、量子計算機に弱い公開鍵暗号を段階的に非推奨にし、2035年までに使用を認めない方向を示しています)

対策しないと起きること

量子計算機ができたとき、保存されていた過去の通信が読まれます。
どれくらい困るかは、そのデータを何年秘密にしておきたいかで決まります。

医療記録、製品の設計情報、長く保管する機密情報のように、10年以上秘密にしたいデータは影響が大きくなります
数分で失効するアクセストークンは、読まれた時点ですでに使えないので、影響はほとんどありません

「対策していないから、今すぐ破られる」わけではありません。
それでも今から動くのは、移行に何年もかかり、その間も通信は保存されうるからです。

なお、電子署名は事情が違います。
署名の偽造は、量子計算機ができた後にしか起きません。
過去にさかのぼって被害が出るわけではないので、鍵交換より後回しにできます。
ただし、ルート証明書やファームウェアの署名のように、何年も使い続けるものは早めの計画が必要です。

AWSの対応状況

対応済みのサービス

AWSの公式ドキュメントとブログで確認できた範囲では、次のサービスが対応しています。

AWS Key Management Service(AWS KMS)、AWS Certificate Manager(ACM)、AWS Secrets Manager: 2025年4月に、FIPS以外のAPIエンドポイントでハイブリッド鍵交換に対応しました(使うにはクライアント側のSDKも対応している必要があります)
Amazon CloudFront: 2025年9月に、クライアントとエッジの間の接続で対応し、既存のすべてのセキュリティポリシーで設定なしに有効になりました
Application Load Balancer(ALB)とNetwork Load Balancer(NLB): 2025年11月に、ハイブリッド鍵交換に対応したセキュリティポリシー(名前にPQが入るもの)が追加されました
ML-DSAによる電子署名: AWS KMSが2025年6月、AWS Private CAが2025年11月に対応しました

性能への影響について、AWSはAWS KMSで計測した結果を公開しています。
TLS接続を再利用するSDKの既定の設定では、1秒あたりの処理件数の低下は0.05%でした。
毎回新しくTLS接続を張る最悪のケースでも、低下は2.3%でした。

CDKで作ったALBの既定値

ここで問い2に戻ります。

ALBのHTTPSリスナーの既定のセキュリティポリシーは、作り方によって違います。

マネジメントコンソールで作った場合: ELBSecurityPolicy-TLS13-1-2-Res-PQ-2025-09(ポスト量子対応)
AWS CLI、AWS CloudFormation、AWS CDKで作った場合: ELBSecurityPolicy-2016-08(ポスト量子非対応)

これが問い2の答えです。
AWS側は対応していても、AWS CLI、CloudFormation、CDKでALBを作っていて、セキュリティポリシーを明示していなければ、古いポリシーのまま動いています。

CDKなら、リスナーの sslPolicy を指定します。
SslPolicy.TLS13_12_RES_PQ が ELBSecurityPolicy-TLS13-1-2-Res-PQ-2025-09 に対応します(aws-cdk-libのソースで確認しました)。

import * as elbv2 from 'aws-cdk-lib/aws-elasticloadbalancingv2';

alb.addListener('Https', {
  port: 443,
  certificates: [certificate],
  sslPolicy: elbv2.SslPolicy.TLS13_12_RES_PQ,
  defaultTargetGroups: [targetGroup],
});

実際にどの鍵交換が使われたかは、ALBのコネクションログで確認できます。
13番目のフィールドが鍵交換の方式です(公式ドキュメントの記載)。

入口は対応済み、出口は従来方式

もう1つ気をつけたいのが、通信の区間ごとの違いです。
公式ドキュメントの記載を区間ごとに整理すると、次のようになります。

区間	状況
クライアント → CloudFront	対応済み(TLS 1.3のみ)
CloudFront → オリジン	ドキュメントにML-KEMの記載がない
クライアント → ALB・NLB	PQポリシーを選べば対応
ALB → ターゲット	リスナーがPQポリシーならPQ対応のポリシーが使われる
クライアント → Amazon API Gateway	REST APIのみ、PQポリシーを選べば対応
API Gateway → バックエンド	下りはTLS 1.2のみで、PQ鍵交換は使えない

少し補足すると

CloudFrontのオリジン接続のドキュメントには、鍵交換の曲線として従来の3種類(prime256v1、secp384r1、X25519)だけが書かれています
ALBのバックエンド接続のポリシーは全リスナーの設定で決まり、ほかのリスナーがRFC 9151やFIPSのポリシーを使っていると、そちらが優先されます
ALBのバックエンド接続にPQ対応のポリシーが使われても、実際にPQで鍵交換するには、ターゲット側もML-KEMに対応している必要があります(ドキュメントからの推論です)
API GatewayのHTTP APIとWebSocket APIは、TLS_1_2ポリシーしか選べません
この表はドキュメントの記載に基づく整理で、実際の通信での検証はしていません

クライアントに面した入口は対応が進んでいますが、その先の出口は従来方式のままの区間が残っています。
CloudFrontからオリジンへの通信がインターネットを通る構成なら、そこがいちばん守りの弱い区間になりえます。

他のクラウドの対応状況

Google Cloud

Google Cloudの公式ドキュメントによると、次のとおりです。

外部・内部のアプリケーションロードバランサや、プロキシ型のネットワークロードバランサなど7種類が、X25519MLKEM768に対応しています
既定では現在は無効で、2026年10月から既定で有効、2027年10月からは常に有効になる予定です
対象はクライアントとロードバランサの間(フロントエンド)だけで、バックエンドへの接続は対象外です
Cloud KMSでは、ML-DSAとSLH-DSAによる署名が2026年7月に一般提供(GA)になりました
Cloud KMSのML-KEMは、執筆時点ではプレビューです

Azure

Microsoftの公式ブログによると、Windowsの暗号ライブラリ(SymCrypt)がML-KEMとML-DSAに対応し、Windows 11とWindows Server 2025では、更新プログラムを当てるとTLS(Schannel)でハイブリッド鍵交換が使えるようになっています。
Azureの各サービスについては、公式の一次情報を今回は確認できませんでした。

そこで、エンドポイントに直接つないで確かめました。
計測方法と結果は、次の節の生成AIベンダーとまとめて載せます。

生成AIベンダーの対応状況を計測してみた

各社のエンドポイントに、ハイブリッド方式と従来方式の両方を提示してTLS 1.3で接続し、サーバーがどちらを選ぶかを確かめました。
使ったのは、手元のMacのOpenSSL 3.6.4です。

openssl s_client -connect api.anthropic.com:443 -servername api.anthropic.com \
  -tls1_3 -groups X25519MLKEM768:X25519:P-256 -brief </dev/null 2>&1 \
  | grep -E "Protocol version|Negotiated TLS1.3 group"

ハイブリッドが選ばれた場合は、次のように表示されます。

Protocol version: TLSv1.3
Negotiated TLS1.3 group: X25519MLKEM768

従来方式が選ばれた場合は、2行目が表示されません。
結果は次のとおりです(2026年9月25日、筆者の環境で計測)。

エンドポイント	選ばれた鍵交換
api.anthropic.com	X25519MLKEM768
claude.ai	X25519MLKEM768
api.openai.com	X25519MLKEM768
generativelanguage.googleapis.com	X25519MLKEM768
aws.amazon.com	X25519MLKEM768
www.microsoft.com	X25519MLKEM768
azure.microsoft.com	X25519MLKEM768
management.azure.com	従来方式
login.microsoftonline.com	従来方式

Anthropic、OpenAI、Googleの生成AIのAPIは、すべてハイブリッド方式を受け入れました。
Microsoft側は、www.microsoft.com、azure.microsoft.comは対応していた一方で、Azureの管理API(management.azure.com)と、Microsoft Entra IDのサインイン(login.microsoftonline.com)は従来方式でした。
この2つは、ハイブリッド方式だけを提示すると接続できませんでした。

結果を読むときの注意点です。

これはサーバー側が受け入れるかどうかの計測で、SDKやCLIなどのクライアント側が実際にハイブリッド方式を提示しているかは、別に確認が必要です
ベンダーの公式発表ではなく1か所・1時点からの計測なので、経路や時期で変わる可能性があります

Jevの場合

TypeSafe AIのJevは、あらかじめ決めた選択肢に確率を返すAPIで、筆者は京都弁の本音を判定するアプリで使っています。

そのAPI(api.typesafe.ai)も、同じ方法で確かめました。

ハイブリッドと従来方式の両方を提示すると、従来方式が選ばれました
ハイブリッド方式だけを提示すると、handshake failure(アラート番号40)で接続できませんでした
TLS 1.3自体は使えています

今回の計測では、JevのAPIとの通信にポスト量子の鍵交換は使われていませんでした。
Jevに送るデータを長く秘密にしたい場合は、この点を頭に入れておく必要があります。

導入するとつながらなくなることがある

ハイブリッド方式には、通信の最初に送るデータ(ClientHello)が大きくなるという副作用があります。
ML-KEM-768の公開鍵だけで1,184バイトあり、ClientHelloが1つのパケットに収まらなくなることがあります。
AWSもKMSのブログで、通信経路によっては、パケットの中身を検査するファイアウォールやプロキシがハイブリッド方式の通信を止める場合があると書いています。

実際に、Claude CodeのGitHubリポジトリに、次の報告が上がっています(Issue #94225、執筆時点でオープン)。

約1.7KBのClientHelloが2つのTCPセグメントに分かれ、スペインの特定のISPの経路で接続がリセット(ECONNRESET)されました
従来方式の鍵交換だけにするか、VPNを経由すると、12回中12回つながりました

報告者は、Anthropic側の入口とこの経路の組み合わせを疑っていて、同じ経路からgithub.comやwww.google.comには12回中12回つながったという対照データも載せています。
原因は、Issue上ではまだ確定していません。
ハイブリッド方式を有効にしたら、実際の利用者の経路で接続を確かめる必要があります。

2つの問いへの答え

冒頭の問いに戻ります。

問い1の答え: 暗号化された通信のコピーを保存しておき、量子計算機ができた日にまとめて開ける「今盗んで、後で解く」攻撃があるからで、対策は鍵交換をハイブリッド方式に取り替えることです
問い2の答え: AWS CLI、CloudFormation、CDKで作ったALBの既定のセキュリティポリシーはELBSecurityPolicy-2016-08なので、PQ入りのポリシー名を明示する必要があります

AWSのポスト量子暗号の対応は、クライアントに面した入口から進んでいます。
まずは、自分のALBのセキュリティポリシーに PQ が入っているかを確かめるところから始めてみてください。

最後まで読んでいただきありがとうございました。

参考

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up