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

Transcript

1. 「今盗んで、後で解く」に備える AWS のポスト量子暗号入門 JAWS-UG 東京 ランチタイム LT 会 #39 山下 祐樹
3. 今日の 2 つの問い 問い①：暗号化した通信が、 10 年後に読まれるかもしれません。 なぜでしょう ? 問い②： AWS はポスト量子暗号に対応しています。それでも、 あなたの ALB は守られていないかもしれません。 なぜでしょう ? 答えは、順番に説明していきます
4. まず、ポスト量子暗号ってなに ?
5. 今の暗号は「一方通行の計算」で守られています • 大きな素数を 2 つ掛けるのは、一瞬でできます • でも、掛けた結果だけを見て、元の 2 つを当てるのは、今のコ ンピューターでは事実上できません • この「行きは一瞬、帰りは数千年」の差が、鍵の役目をしてい ます 61と53を掛けると3233になる ↓ 3233は何と何をかけたらいいの？
6. 量子計算機は、その「帰り道」が得意です • 量子計算機は、普通のコンピューターと計算の仕方が違います • 十分に大きなものができたら、数千年かかる計算が、短時間で 終わります • 今の鍵に、合鍵ができるイメージです
7. そこで、鍵を作り直します • 量子計算機でも、速く解ける近道が見つかっていない問題を 使います • たとえば「格子」という網目の中から、ある 1 点を探す問題です • これが、ポスト量子暗号です
8. 新しい鍵と古い鍵を、両方かけます • 新しい方式に、まだ見つかっていない弱点があるかもしれませ ん • だから、従来の方式と新しい方式を、同時に使います （ハイブリッド） • 片方が破られても、もう片方が守ります
9. 誰かが、暗号文を保存しています • 今の暗号は、開けられません • それなのに、暗号化された通信のコピーを、保存して集めてい る人がいるとしたら • なぜ、開けられない箱を集めるのでしょうか ?
10. 今盗んで、後で解く • 合鍵（量子計算機）ができた日に、保存しておいた箱を、まと めて開けます • これが「Harvest Now, Decrypt Later」です • 問い①の答え：だから、 10 年後に読まれるかもしれません
11. 今から対策すると何がいいのでしょう • これから交換する鍵は、保存されても、将来解読されにくくなり ます • 替えるのは鍵交換だけ。 AES-256 などの暗号は、そのまま使 えます • 規制の期限にも間に合います （ NIST ドラフト IR 8547 ： RSA ・ ECC は 2030 年に非推奨、 2035 年に禁止の方向）
12. AWS はどこまで進んでいるでしょう • 入口（クライアントとの通信）は、対応済みです • Amazon CloudFront 、 Elastic Load Balancing （ALB ・ NLB）、 AWS KMS 、 AWS Certificate Manager 、 AWS Secrets Manager が、ハイブリッド鍵交 換に対応しています • 署名（ML-DSA）も、 AWS KMS と AWS Private CA が 対応済みです
13. では、問い②の答えです • コンソールで作った ALB の既定は、ポスト量子対応のポリシーです • でも、 CLI ・ CloudFormation ・ CDK で作った ALB の既定は、 古いポリシー（ ELBSecurityPolicy-2016-08 ）です • ssl̲policy を、 PQ 入りのポリシー名で明示する必要があります
14. 入口は対応済み、出口は従来方式です • Amazon CloudFront → オリジン：ドキュメントに ML-KEM の記載がありません。 • Amazon API Gateway → バックエンド： TLS 1.2 のみ。 TLS 1.2 は、 PQ 鍵交換に 対応しません • API Gateway の PQ 用ポリシーは、 REST API のみです
15. 他のクラウドも入口から進んでいます • Google Cloud ：ロードバランサで対応。既定で有効になる のは 2026 年 10 月から、 2027 年 10 月から常時有効です • Azure ： Windows は対応。計測では、 www.microsoft.com は対応、 management.azure.com と login.microsoftonline.com は従来方式でした （2026-09-20 筆者環境で計測）
16. 生成 AI の入口は対応していました • api.anthropic.com 、 claude.ai 、 api.openai.com 、 generativelanguage.googleapis.com が、ハイブリッド 鍵交換を受け入れました • サーバー側の受け入れを計測しただけで、公式発表ではありま せん （2026-09-20 筆者環境で計測）
17. Jev はどうでしょう • api.typesafe.ai に、ハイブリッドと従来方式を両方提示した ところ、従来方式が選ばれました。 • TLS 1.3 は使えていますが、ポスト量子の鍵交換は、今回の計 測では使われませんでした。 （2026-09-20 筆者環境で計測）
18. まとめ • 問い①：「今盗んで、後で解く」に備えて、鍵交換を今から替 える • 問い②：自分の ALB の ssl̲policy を、 PQ 入りに明示する • 導入したら、実環境で接続を確認します（報告事例： ClientHello が約 1.7KB に大きくなり、特定の ISP 経路で ECONNRESET 。 Claude Code Issue #94225 、原因は未 確定）。