Java 27、TLS 1.3の鍵交換が既定で耐量子ハイブリッドに。コードを変えずに変わるハンドシェイク

既定で変わるのは、クライアントが提示する鍵交換方式の並び

ML-KEMは、原典がハイブリッド方式の耐量子側として組み合わせに挙げているアルゴリズムです。原典によれば、Javaプラットフォームにはすでに部品がそろっており、鍵カプセル化のAPIはJava 21のJEP 452で、ML-KEMそのものはJava 24のJEP 496で追加されています。TLSへのハイブリッド鍵交換の実装は、その次の一歩だと位置づけられています。

JEP 527は、ML-KEMと従来のEphemeral Elliptic-Curve Diffie-Hellman（ECDHE）を組み合わせた3つの方式をTLS 1.3に追加します。X25519MLKEM768はX25519とML-KEM-768、SecP256r1MLKEM768はsecp256r1曲線を使うECDHEとML-KEM-768、SecP384r1MLKEM1024はsecp384r1曲線とML-KEM-1024の組み合わせです。TLSの仕様ではこれらを「named groups」と呼び、名称はIANAが定めたものと同じだと原典は説明しています。

TLSクライアントは、対応する鍵交換方式を優先順に並べてハンドシェイクの最初のメッセージへ入れます。JDK 27では、この並びの先頭にX25519MLKEM768が置かれます。原典が示す既定の並びは、X25519MLKEM768、x25519、secp256r1、secp384r1、secp521r1、x448、ffdhe2048、ffdhe3072、ffdhe4096です。そしてこの順序に基づき、TLS 1.3クライアントはX25519MLKEM768とx25519のkey shareを提示する、と原典は述べています。

残る2方式、SecP256r1MLKEM768とSecP384r1MLKEM1024は既定では有効になりません。原典は、X25519MLKEM768が最も高速なハイブリッドグループであり、現在多くのTLSクライアントが既定で有効にしているものだと説明しています。

「コードを変えなくてよい」には条件がある

既存コードの変更が不要という説明には、原典自身が条件を付けています。恩恵を受けられるのは、そのコードが特定の鍵交換方式をすでに選択していない限り（as long as that code does not already select specific key exchange schemes）です。逆に言えば、過去に相互接続の都合でnamed groupsを明示的に絞り込んだアプリケーションは、指定した内容がそのまま使われます。移行前の棚卸しで最初に見るべきは、この明示指定の有無です。

適用範囲も限定されています。原典は非目標（Non-Goals）として、javax.net.ssl以外のAPIに対してハイブリッド鍵交換を実装することも、TLS 1.3以外のバージョンに実装することも目標ではないと明記しています。JDKのTLS実装を経由しない通信、たとえばネイティブライブラリやサイドカーのプロキシがTLSを終端している経路は、JDKを27に上げても変わりません。自社システムのどの通信がJSSEを通っているのかを先に把握しておかないと、「Java 27にしたので耐量子化は済んだ」という取り違えが起きます。

もう一点、ML-KEMを使う非ハイブリッドの鍵交換方式（non-hybrid key exchange schemes for TLS that use ML-KEM）も非目標として挙げられています。原典は、ハイブリッド方式のほうが現時点で需要が高く、量子・従来の双方の攻撃に対する最低限の保証を与えると述べ、純粋なML-KEM方式は将来の作業として実装しうるとしています。JDK 27で入ったのはハイブリッドであって、純粋なポスト量子暗号への移行ではありません。

制御と切り戻しは、システムプロパティとSSLParametersの2系統

既定の並びを変える手段として、原典はシステムプロパティ jdk.tls.namedGroups を挙げています。加えて、TLSソケット接続を構成する際に SSLParameters::setNamedGroups メソッドを呼んで方式を個別に選ぶこともできるとしています。

このうち原典が具体的な記法まで示しているのは、後者のSSLParameters側です。掲載されているコード例では、params.setNamedGroups に文字列の配列として "SecP256r1MLKEM768", "X25519MLKEM768", "secp256r1", "x25519" を並べ、ハイブリッド2方式と従来方式2つを使うよう設定しています。既定では無効なSecP256r1MLKEM768を有効にする例でもあるため、切り戻しだけでなく、特定の方式を優先させたい場合の書き方としても読めます。

一方、jdk.tls.namedGroups についてJEP 527の本文が述べているのはプロパティ名と用途までで、値の区切り方や記述例は示されていません。全社的な切り戻し手順として起動オプションを標準化する場合は、JDK 27の該当ドキュメントやリリースノートで記法を確認してから手順書に落としてください。本稿はJEP 527とJDK 27プロジェクトページに基づくため、ここでプロパティの値の書式を補って示すことはしません。

「壊れうる」論点は、原典が述べている範囲を確かめてから扱う

運用側で気になるのは、ハンドシェイクが通らなくなる経路があるかどうかです。ここは原典が述べている範囲を正確に押さえる必要があります。JEP 527が明示しているのは、既定の順序に基づいてクライアントがX25519MLKEM768とx25519のkey shareを提示すること、そしてテスト計画として、ハイブリッド方式に対応する他のTLS実装との試験で相互運用性を確認する（Testing against other TLS implementations that support hybrid schemes will confirm interoperability.）ことです。

つまり原典は、ハイブリッド方式に対応する相手との相互運用をテスト対象として挙げてはいますが、対応していないTLS終端装置、IDS、古いミドルウェアとの接続で何が起きるかは述べていません。最初のメッセージの大きさがどの程度増えるか、経路のMTUやフラグメンテーションにどう影響するかについても、JEP 527とJDK 27プロジェクトページには記載がありません。これらは一般に議論される論点ではありますが、原典の裏づけがない以上、本稿では「こうなります」とは書きません。

したがって検証は、推測を積み上げるのではなく、実際の経路で確かめる形になります。原典から確実に言えるのは、JDK 27のクライアントが提示するkey shareの内容が既定で変わること、そしてその挙動を jdk.tls.namedGroups と SSLParameters::setNamedGroups で制御できることの2点です。この2点があれば、変更前後を切り替えながら同じ経路で比較する検証は組めます。

移行前の確認リスト

金融や公共など、Javaが基幹に残り、TLS終端装置や監視装置が経路上に並ぶ環境では、JDKの更新と同時にハンドシェイクの内容が変わる点を、あらかじめ変更管理の対象として扱うのが安全です。原典から導ける確認項目は次のとおりです。

第一に、アプリケーションが setNamedGroups や jdk.tls.namedGroups で鍵交換方式を明示指定していないかを洗い出します。指定がある経路は既定の変更を受けません。第二に、JDK 27へ上げる対象のうち、どの通信がjavax.net.sslを経由しているかを区別します。非目標の記述どおり、それ以外の経路は変わりません。第三に、TLS 1.3で接続している経路と、TLS 1.2以下で接続している経路を分けます。JEP 527の対象はTLS 1.3だけです。

第四に、接続先ごとに、変更前と変更後のハンドシェイクが成立するかを実際の経路で確認します。原典が相互運用性をテスト項目に挙げているのは、JDK側の実装が他実装と噛み合うかという観点であり、個々の事業者の経路上にある装置の挙動を保証するものではありません。第五に、切り戻しの手順を、検証の前に用意して動作確認まで済ませます。設定で戻せる変更である以上、問題が起きてから記法を調べる状況は避けられます。

なお、JDK 27のプロジェクトページは、GA到達時点でGPLの下での製品版バイナリがOracleから入手でき、他ベンダーのバイナリは間もなく続くと記載しています（Last update: 2026/9/15 11:59 UTC）。利用しているディストリビューションの提供時期は、各ベンダーの案内で個別に確認してください。