要約

  • RFC 10042 は、ML-KEM と P-256、P-384、X25519 を組み合わせる三つの SSH 鍵交換方式を定めた IETF の Informational RFC であり、著者は Panos Kampanakis、Douglas Stebila、Torben Hansen である。
  • ハイブリッド応答には、サーバーの公開ホスト鍵と交換ハッシュへの署名が引き続き含まれる。さらに輸送鍵の確立後、別プロトコルが利用者を認証する。
  • AWS の SFTP デバッグ例では、ハイブリッド KEX、ホスト鍵アルゴリズムと指紋、利用者の公開鍵認証が別々に記録される。一つの「量子安全 SSH」表示より、こちらの方が監査に向く。

詳細ログを読むとき、同じ「key」という語に引きずられてはいけない。鍵交換の鍵、サーバーを識別するホスト鍵、利用者が保有する認証鍵は、所有者も有効期間も失敗時の対応も異なる。

RFC 10042 が共通化するのは鍵交換である。2026年8月に Informational 文書として公表され、mlkem768nistp256-sha256、mlkem1024nistp384-sha384、mlkem768x25519-sha256 の三方式を定義した。ML-KEM で得る秘密と従来の楕円曲線交換で得る秘密を結合し、SSH の輸送鍵を導出する。

狙いは、現在の暗号通信を保存し、将来の計算能力で解読する攻撃への備えだ。従来方式だけに依存しない共有秘密は、その脅威に対する実質的な前進である。ただし、その前進はサーバーが誰か、利用者に何を許したかという質問への回答ではない。

応答から消えなかったホスト鍵

仕様のメッセージ形式を見ると、境界は明白だ。クライアントは ML-KEM の公開鍵と従来方式の一時公開鍵を送る。サーバーは ML-KEM の暗号文と自分の一時公開鍵に加え、K_S、すなわち公開ホスト鍵と、交換ハッシュに対する署名を返す。

共有秘密 K は、後量子秘密と従来秘密を連結した値のハッシュである。交換ハッシュには、双方のソフトウェア識別子、SSH_MSG_KEXINIT、ホスト鍵、ハイブリッド交換値、K が入る。サーバーはホスト秘密鍵でこのハッシュに署名する。

一つの transcript に結ばれていても、役割は別だ。ハイブリッド KEX は通信を暗号化する新しい秘密を作る。ホスト署名は、あるサーバー鍵がその transcript を承認したことを示す。クライアントはさらに、その鍵が接続先に属するという根拠を確認しなければならない。

RFC 4253 は kex_algorithms と server_host_key_algorithms を別のリストとして交渉する。ホスト鍵の確認には known_hosts、別経路で確認した指紋、証明書などが使われる。未確認の鍵を受け入れれば能動攻撃に弱くなるという警告もある。ML-KEM の計算が正しくても、誤った相手を信頼した事実は消えない。

したがってホスト証跡には、署名方式、指紋または証明書、信頼元、検証結果、ローテーション履歴が必要だ。KEX 名だけを保存しても、サーバー識別の証明にはならない。

利用者認証は輸送層の後で始まる

輸送が確立すると、信頼の向きが逆になる。今度はサーバーが、指定された利用者をサービスに入れてよいか判断する。

RFC 4252 の利用者認証プロトコルは SSH 輸送層の上で動く。実装に必須なのは publickey で、パスワードと hostbased は任意、ほかの方式も追加できる。公開鍵認証では、利用者名、サービス名、方式、公開鍵、署名を確認し、その鍵が当該アカウントに許可されているか、追加認証が必要かを判断する。

ホスト署名と利用者署名は同じ公開鍵暗号を使い得るが、主体は逆だ。ホスト鍵はクライアントがサーバーを識別するためのもの。利用者鍵はサーバーが人や自動処理を識別するためのものだ。authorized_keys、MFA、無効化されたアカウント、強制コマンド、SFTP ディレクトリ制限は KEX 名の外側にある。

KEX、ホスト署名、利用者資格情報を段階的に移行すること自体は合理的である。問題は最初の段階が成功した時点で、残りの二段階まで完了したように報告することだ。

AWS のログが示す読み方

AWS Security Blog の SFTP 記事には、その違いを運用ログで確認できる例がある。2023年の例は標準化前の Kyber 名を使っていた。2025年9月5日の更新では、AWS Transfer Family の二つのポリシーが ML-KEM に移行し、後に RFC 10042 となる三方式をサポートすると説明している。

古いログを RFC 10042 の接続と呼ぶべきではない。しかしログの読み方は今も有効だ。まずハイブリッド KEX が表示され、別の行でホスト鍵方式 ssh-ed25519 と指紋が出る。さらに後で publickey による利用者認証が記録され、その後に SFTP セッションが開く。

ここから三つの確認票を作れる。

  1. 何を提示し、実際に何を選び、SSH_MSG_NEWKEYS まで完了したか。
  2. どのホスト鍵が署名し、クライアントはどの信頼規則で受け入れたか。
  3. どの利用者方式が成功し、どのアカウントと権限を得たか。

「connected」はチャネルが開いた証拠にはなる。しかしファイル権限、保存時暗号化、監査ログ、バックアップ、復旧まで保証する言葉ではない。

実験名から ML-KEM 名への移行は、ソフトウェア寿命の問題も示す。サーバー、デスクトップ、組み込みクライアント、自動化は同時には更新されない。バージョン、優先順位、フォールバックが接続ごとの結果を決める。IANA 登録の SHOULD は実装者が出会う場所を作るが、普及率を示さない。

狭い仕様だから実装で確かめられる

Amazon Science は Kampanakis を AWS の principal security engineer と紹介し、応用暗号、セキュリティ自動化、標準化を活動分野としている。2023年の AWS インタビューでは、非対称暗号の棚卸し、SSH など用途別の影響検証、アルゴリズムアジリティを挙げ、実験的プロトタイプと長期の大規模運用を区別した。

この経歴は RFC の問題意識を説明するが、単独の成果にはしない。Stebila と Hansen は共同著者であり、RFC は AWS、OpenSSH、PuTTY などの実装・レビュー貢献も記録する。ML-KEM は NIST の標準で、IETF と IANA が共通のプロトコル座標を維持する。

RFC 10042 は、メッセージ、秘密の結合、固定長符号化、入力検査、接続ごとの一時鍵、乱数再利用の禁止、失敗時の切断を定める。意図ではなく、相互試験できる最小契約になっている。

Heng Lu の「最小初期仕様」は、この範囲を弱さではなく設計上の強さとして読む。標準は最小の相互運用部分を固め、信頼ストア、アカウント、復旧の将来判断は実際の運用者に残す。「稼働コード優先」は、表示ではなく観測結果を保存するよう求める。

実用的な証跡には、ソフトウェアの版、提示・選択 KEX、ホスト鍵方式と指紋、信頼判断、暗号と MAC、NEWKEYS、利用者方式、認可結果、開いたチャネル、再鍵交換、フォールバック、失敗、観測できない範囲を含める。

RFC 10042 は一列目の証拠を強くした。残る二列を空欄のまま緑に塗らないことが、その成果を正確に評価する方法である。

情報源