要約

  • RFC 10042 は SSH transport に三つの ML-KEM/ECDH 混合方式を定め、二つの一時共有秘密から K を導く。
  • その transcript に K_S と署名が入っていても、クライアントがどのホスト鍵を信頼するか、利用者に何を許可するかは別の判断である。

「混合鍵交換を使った」という記録は、何を示すのだろうか。RFC 10042 では、クライアントが SSH_MSG_KEX_HYBRID_INIT と C_INIT を送り、C_INIT は後量子側の公開鍵と古典側の公開鍵を連結する。サーバーは SSH_MSG_KEX_HYBRID_REPLY、ホスト公開鍵 K_S、ML-KEM 暗号文と古典側公開鍵を連結した S_REPLY、そして交換ハッシュへの署名を返す。ここから古典側の K_CL と後量子側の K_PQ が得られ、規定された固定長の表現をハッシュして SSH の共有秘密 K が作られる。

この設計は、秘密を「足す」だけではない。サーバーは encapsulation の前に C_INIT が選択された方式の期待長と一致するか確認しなければならない。クライアントも decapsulation の前に S_REPLY を確認する。失敗時は key-exchange-failed の理由で切断する。一接続ごとに ECDH と ML-KEM の一時鍵対を新しく生成し、ML-KEM ciphertext の乱数を再利用してはならない。固定長の符号化は、秘密の長さから側信道が生じる余地も抑える。

しかし、正しい形式のメッセージと K の導出は、接続先の社会的・運用的な同一性を選ばない。SSH の transport layer はサーバー認証を提供するが、RFC 4251 はホスト鍵を本当に対象ホストの鍵として扱うには、クライアントがあらかじめ公開鍵を知る必要があると説明する。名前と鍵を結ぶローカル・データベース、または受け入れた CA による証明という二つの信頼モデルがある。RFC 4253 も、クライアントが証明書かローカル・データベースで K_S を検証する手順を置き、未検証の受入れは能動攻撃に弱いと明記する。

RFC 10042 はこの検証を廃止も自動化もしていない。交換ハッシュには双方の識別文字列、二つの KEXINIT payload、K_S、C_INIT、S_REPLY、K が入る。したがって、鍵確立の特定の八つの入力を結び付けられる。そこにローカルの host-name-to-key 方針、利用者名、SSH_MSG_USERAUTH_REQUEST、許可されたサービス、channel request は入らない。SSH は利用者認証を transport の上に置き、サーバーのローカル方針に、どの認証方法とアクセスを受け入れるかを委ねる。

方式名も証拠の終点ではない。mlkem768nistp256-sha256、mlkem1024nistp384-sha384、mlkem768x25519-sha256 は IANA に登録された方法名である。構成にその文字列があることは対応準備を、KEXINIT にあることは提案を示せる。相手との共通選択、length check、decapsulation、派生、ホスト鍵受入れ、利用者認証、操作までを証明するわけではない。方式名を一つの compliance ラベルにすると、その間の責任ある判断が消える。