OpenJDK、JDK 27でTLS 1.3に耐量子ハイブリッド鍵交換を導入　既定の優先方式も変更

既定の鍵交換でハイブリッドを優先

JDK 27のTLS 1.3実装では、ハイブリッド方式のX25519MLKEM768が既定の最優先候補になりました。TLSクライアントは、対応する鍵交換方式を優先順に並べて接続開始時のメッセージに含めます。

TLSの仕様では、こうした鍵交換方式をnamed groupsと呼びます。JEP 527が定める既定の一覧では、先頭のハイブリッド方式に続いて、x25519やsecp256r1などの従来方式も並びます。

既定の順序に従うTLS 1.3クライアントは、一覧の方式のうちX25519MLKEM768とx25519について、鍵交換に使う値（key share）を提示します。一覧には従来方式も含めて複数の方式が並びますが、key shareを提示するのはこの2方式です。

追加されたハイブリッド方式のうち、SecP256r1MLKEM768とSecP384r1MLKEM1024は既定では無効です。JEPは、X25519MLKEM768を最も高速なハイブリッド方式と説明しています。

従来方式と耐量子方式を組み合わせる

今回のハイブリッド鍵交換は、量子計算機による攻撃に耐えることを目指すML-KEMと、従来の楕円曲線を用いる鍵交換方式ECDHEを組み合わせます。追加された各方式では、使う曲線やML-KEMの種類が異なります。

X25519MLKEM768の構成は、X25519を用いるECDHEとML-KEM-768です。SecP256r1MLKEM768では、secp256r1曲線のECDHEとML-KEM-768を組み合わせます。

SecP384r1MLKEM1024は、secp384r1曲線のECDHEとML-KEM-1024を使います。JEPによると、ハイブリッド方式は組み合わせたアルゴリズムのどちらか一方が破られていない限り、安全性を保つ設計です。

JEPが背景に挙げるのは、攻撃者が暗号化データを今から蓄積し、将来の量子計算機で復号する脅威です。従来方式を破れる大規模な量子計算機がまだ存在しない段階でも、対策が急務だと説明しています。

一方、JEPは耐量子アルゴリズムの検証の蓄積が、従来方式の長年の試験や分析には及んでいないことにも触れています。ハイブリッド方式は、この違いを踏まえて両者を組み合わせるものと位置づけています。

コード変更が不要なのは未指定の場合

JEPは、特定の鍵交換方式を選択していないコードなら、耐量子TLSが利用可能な場合にコードの変更なしで恩恵を受けられるとしています。

JEP 527がハイブリッド鍵交換を実装する対象は、javax.net.sslのAPIとTLS 1.3に限られます。ML-KEMだけを使う非ハイブリッド方式も、今回の対象から外れています。JEPは、この方式を将来実装する可能性に触れています。

開発者が方式を指定する手段も用意されています。システムプロパティのjdk.tls.namedGroupsで、既定の方式一覧を変更できます。

TLSソケット接続ごとの設定には、SSLParameters::setNamedGroupsメソッドを使えます。JEPのコード例は、ハイブリッド方式を二つと従来方式を二つ選ぶ構成です。

JEPの試験計画には他のTLS実装との相互運用試験も含まれる

JEPは、新しいハイブリッド方式の試験計画も示しています。クライアントとサーバー間で新方式が正しく動作するかを、単体試験で確認するとしています。

方式を明示した場合も単体試験の対象です。システムプロパティのjdk.tls.namedGroupsによる指定と、SSLParameters::setNamedGroupsによる指定の両方が確認対象です。

ほかのTLS実装との相互運用試験も計画に含まれます。対象は、ハイブリッド方式に対応する実装です。