要約

  • RFC 9858 が追加した識別子は、検証者に HSS/LMS 署名の読み方を伝えるが、秘密鍵状態の保管履歴は伝えない。
  • 目の前の署名が有効でも、別プロセスや復元された装置が同じ葉番号から署名すれば、ワンタイム性は破られる。
  • 署名を外へ出す前の永続化、状態所有者の一意性、複製を生まない復旧、残量監視と後継鍵への移行が独立して必要になる。

VALID の一語が隠すもの

2025年10月に IRTF の Crypto Forum Research Group から公表された RFC 9858 は、SHA-256 の192ビット出力と、SHAKE256 の192ビットおよび256ビット出力を使う HSS/LMS パラメータ集合を追加した。対応する LM-OTS と LMS の型番号は IANA に登録され、実装はハッシュ関数、出力長、木の高さ、Winternitz 設定を取り違えずに処理できる。

これは相互運用の文法を確定する成果であって、鍵管理の履歴を認証する仕組みではない。

LMS では署名のたびにマークル木の葉を一つ消費し、その番号が q として署名に現れる。各葉の秘密はワンタイムであり、秘密鍵には静的な値だけでなく前進する有限状態がある。RFC 8554 は、秘密鍵状態の再利用が安全性を失わせ得ると明記している。

検証者が確認できるのは、メッセージ、署名、公開鍵、認証経路から根が再計算できるかどうかである。同じ q を別の装置が以前使ったか、トランザクションが署名放出後に失敗したか、来月の災害復旧で古いスナップショットが起動するかは見えない。一件の正しい署名から、世界に重複状態が存在しないと推論することはできない。

したがって証拠は二層になる。パラメータ層はハッシュ族、出力長、木の高さと計算方式を説明する。管理層は可変状態の所有者、予約、永続化、外部放出、複製と復旧を説明する。RFC 9858 は前者の選択肢を増やしたが、後者を代行しない。

192ビット集合は、256ビット出力の集合より鍵や署名を小さくできる一方、安全余裕も小さくなる。SHAKE256 は実装環境によって性能上の利点を持ち得る。しかし「RFC 9858 対応」という調達要件だけでは、どの集合を採用し、利用期間にどう適合し、停電時にカウンターをどう守るかが抜け落ちる。

NIST SP 800-208 は運用順序を具体化している。適合するハードウェアモジュールで鍵を生成する場合、秘密材料はエクスポート不可とする。そして署名を出力する前、または次の要求を受ける前に、葉インデックスを増加させて不揮発性記憶へ保存する。順序自体が安全条件だ。書き込みがキャッシュにしか届いていなければ、電源断で使用済み葉へ戻る可能性がある。

復旧も単なる巻き戻しではない。HSS の上位構造の下で独立した木を割り当てる、署名領域を重ならないよう分離する、別途生成した後継鍵へ移る、といった設計が必要だ。同じ可変秘密鍵を二拠点へコピーすれば、可用性対策がワンタイム秘密の競合源になる。

木の高さは総容量も決める。失敗や保守的な予約で葉を廃棄すれば、公開署名数より消費が進む。永続化済みの上限、予約済みの上限、実際に放出した上限、残容量を区別し、後継公開鍵を余裕を持って配布しなければならない。同じ葉から二つの署名が外へ出た後で、台帳を直しても事実は戻せない。

参照資料