JEP 527:Post-Quantum Hybrid Key Exchange for TLS 1.3

Transcript

1. JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3 2026/09/30 JJUGナイトセミナー 「Java 27 リリース記念イベント」 @riko111
2. アジェンダ 01 JEP 527と耐量⼦暗号の背景 02 Javaにおける耐量⼦暗号ロードマップ 03 TLS 1.3ハイブリッド鍵交換の仕組み 04 JEP 527の実装内容と利⽤⽅法 05 実務への影響・注意点とまとめ 2
3. JEP 527とは TLS 1.3の鍵交換に 「従来の暗号」と「耐量⼦暗号」を組み合わせる仕組みを追加 💡 どちらか⼀⽅が破られても、 もう⼀⽅が安全なら鍵交換を守れる 3
4. なぜ今 耐量⼦暗号なのか 「Harvest Now, Decrypt Later」 暗号化通信を 傍受・保存 ⼤規模量⼦コンピュータが 実⽤化 保存しておいた データを復号 • IETFのTLSワーキンググループは、 TLS 1.3向けのハイブリッド鍵交換の仕様をRFC 10024として標準化 • JEP 527は、この仕様をJDKに実装しようという提案 4
5. Javaにおける耐量⼦暗号ロードマップ.1 API基礎基盤 • JEP 452（Java21） Key Encapsulation Mechanism API 公開鍵暗号を使⽤して安全に共有秘密を確⽴する • JEP 510（Java25） Key Derivation Function API 秘密鍵などから追加の暗号鍵を安全に導出する 5
6. Javaにおける耐量⼦暗号ロードマップ.2 PQCアルゴリズム • JEP 496（Java24） ML-KEM実装 モジュール格⼦ベースのKEM APIの実装 • JEP 497（Java24） ML-DSA実装 デジタル署名アルゴリズムの実装 6
7. Javaにおける耐量⼦暗号ロードマップ.3 TLS 1.3統合 • JEP 527（Java 27） ML-KEMを実際の通信プロトコルで使えるように 7
8. TLS 1.3のハンドシェイク クライアント ① Client Hello サーバ ② Server Hello ③ サーバの証明書 Finished ここから先の やりとりは 暗号化 ④ Finished 8
9. ハイブリッド鍵交換 ECDHE（従来⽅式） ⻑年の実績と分析がある ディフィー・ヘルマン鍵交換 量⼦コンピュータには弱い ML-KEM（新⽅式） ＋ NIST FIPS 203標準の 格⼦暗号ベース鍵カプセル化 量⼦攻撃に強いが実績が浅い どちらか⼀⽅が破られても安全 9
10. JEP 527の中⾝ IANAに登録された3つの新しいNamed Groupが Javaセキュリティ仕様に追加 X25519MLKEM768 デフォルトで優先される⽅式 ECDHE(X25519) + ML-KEM-768 SecP256r1MLKEM768 ECDHE(secp256r1) + ML-KEM-768 SecP384r1MLKEM1024 ECDHE(secp384r1) + ML-KEM-1024 NIST曲線ベースの組み合わせ より強い強度が必要な場合向け 10
11. デフォルトで有効、コード変更は不要 javax.net.sslを使う既存アプリはそのまま恩恵を受ける デフォルトの優先順位リスト X25519MLKEM768 x25519 secp256r1 / secp384r1 / secp521r1 x448 ffdhe2048 / ffdhe3072 / ffdhe4096 ⽅式を明⽰的に指定したい場合 SSLSocket tlsSock = (SSLSocket) SSLContext.getDefault() .getSocketFactory() .createSocket(); SSLParameters params = tlsSock.getSSLParameters(); params.setNamedGroups(new String[] { "SecP256r1MLKEM768", "X25519MLKEM768", "secp256r1", "x25519" }); tlsSock.setSSLParameters(params); 11
12. ハンドシェイクの中で何が起きるか クライアントは対応⽅式を優先順位付きで提⽰する クライアント ① Client Hello サーバ 候補リストを優先順位付きで送信 ② Server Hello ⾃分が対応している⽅式を上から選ぶ 結果： TLS 1.3の通常のハンドシェイクと同じ体験のまま 量⼦耐性を備えた鍵交換が使われる 12
13. 実務への影響と注意点 恩恵は⾃動、ただし前提を押さえておく 対象範囲 • javax.net.ssl 経由の TLS 1.3のみが対象 • TLS 1.3以外のバージョン は対象外 • ⾮ハイブリッドの純粋 ML-KEM⽅式は範囲外 確認しておきたいこと • 通信相⼿（ライブラリ/ プロキシ）が対応しているか • 鍵交換に伴うメッセージ サイズの増加 • 古いクライアントとの 後⽅互換性 ※IETFの仕様はRFC 10024として標準化 13
14. まとめ • JEP 527はTLS 1.3にML-KEM + ECDHEのハイブリッド鍵交換を 統合する • 「Harvest Now, Decrypt Later」という今そこにある脅威への備え • 既存コードは無変更で恩恵を受けられる設計（デフォルトで有効） • JDK 27に統合済み 14