要約

  • RFC 9708 は HSS/LMS の公開鍵と署名を X.509、PKIX、CMS で扱う方法を定める。LM-OTS の秘密鍵は一度だけ署名に使えるため、署名者は消費済みの葉を永続的かつ正確に管理しなければならない。
  • 一つの署名が検証できても、署名者の履歴が一つに保たれた証明にはならない。永続化の失敗、仮想マシンのスナップショット復元、複製によって、外部へ出た署名の葉が再び利用可能になる。
  • 安全性を決めるのは順序である。署名を外へ渡す前に次の状態を確定し、実効的な書き手を一つに限定し、全ての出力を二度と戻せない状態予約と照合する必要がある。

復旧担当者は「最後に正常だった」仮想マシンを起動する。サービスは応答し、生成された署名も検証に通る。それでも復旧は安全ではない。スナップショット以後に外部へ渡った署名を、復元された機械は覚えていないからだ。機械の時刻だけでなく、暗号鍵の使用履歴まで巻き戻っている。

RFC 9708 は、この運用上の境界を証明書と Cryptographic Message Syntax の中に位置づける。2025 年 1 月に Standards Track 文書として公開され、HSS と LMS の表現を更新し、RFC 8708 を置き換えた。証明書との整合、既知の正誤表への対応、新しいパラメータ集合は相互運用性を改善する。しかし HSS/LMS が状態を必要とする事実は変わらない。

基礎仕様の RFC 8554 では、秘密鍵状態に次のワンタイム署名インデックスが含まれる。署名処理の結果は署名だけではなく、後継の秘密鍵状態でもある。木が持つ葉を使い切れば次の状態はない。同じ秘密状態を二度利用した場合、暗号学的な安全保証はなくなり、偽造が現実的になり得る。

守るべきものは秘密の値だけではない。その値がこれまで何に使われたかという、正確な履歴が不可分に含まれる。

検証者が見るのは一件、状態管理者が守るのは全履歴

LM-OTS は一つの秘密鍵に一回の署名を割り当てる。LMS は多数のワンタイム鍵を Merkle 木の下にまとめ、HSS はその木を階層化できる。結果として実用的な署名回数を得るが、予算は有限である。検証者は署名が示す葉と認証経路をたどり、公開鍵との数学的な整合を確認できる。

しかし、その葉が別の複製でも使われたかどうかは、単独の署名からは分からない。検証は提示されたオブジェクトに対する局所的な観測であり、一意性は全ての複製、バックアップ、書き手、フェイルオーバー経路を含む大域的な主張である。

受領証 証明できる範囲
公開鍵を受理 ポリシーがその HSS/LMS 鍵を認めた
アルゴリズム識別子を解釈 符号化とパラメータ集合を理解できた
署名を検証 このオブジェクトが検証手順を満たした
葉インデックスを観測 特定の木位置が署名に現れた
状態を予約 一つの書き手がその位置を割り当てた
後継状態を永続化 不揮発性記憶がその位置を再提示しない
署名を出力 結果がセキュリティ境界を越えた
全履歴を照合 同じ位置の別出力が存在しない
業務結果を観測 下流が署名内容に基づいて動いた

上の行が下の行を自動的に証明することはない。RFC 9708 は使用済み葉の追跡を必須とし、その完全性を失えばワンタイム鍵を再利用し得ると警告する。具体例は、永続ストレージへの書き込み失敗、仮想マシンのスナップショット取得、そして複製である。高度な暗号攻撃ではなく、日常の運用手順が安全性を壊す。

外へ出す前に、未来を一つ消費する

署名を計算してクライアントへ返し、その後でインデックスを保存する実装を考える。応答後、保存前に電源が落ちれば、再起動したサービスは同じ葉を選べる。書き込み API が成功を返していても、データが揮発性キャッシュに留まっていれば結果は同じである。世界は署名を保持しているのに、署名者だけが忘れる。

NIST SP 800-208 は、状態管理を有状態ハッシュ署名の中心的な難点として扱う。その適合プロファイルでは、モジュールが葉識別子を増加させ、その増加を不揮発性記憶へ保存してから、署名を出力するか次の要求を受け入れなければならない。安全な流れは、位置の予約、再利用禁止の永続化、署名の完成、受領証付き出力、不確実な結果の照合という順になる。

永続化の後、出力の前に障害が起きれば、公開署名のない葉が一つ失われるかもしれない。これは容量の損失であって、一回性の破壊ではない。逆の順序は容量を節約する代わりに再利用を許す。不確実な葉は再び配らず、消費済みとして扱う方が安全である。

この設計は一般的なクラウド運用の直感と衝突する。同じ要求の再試行が同じ効果とは限らない。バックアップへの復元が安全な過去への復帰とは限らない。イメージの複製が単なる水平拡張とは限らない。署名状態だけは時間を逆向きに進められない。

可用性の複製は権限の複製になる

同じ秘密状態を持つ二つの稼働インスタンスは、それぞれ正しく検証できる署名を作りながら、同じ葉を割り当てられる。共有データベースがあっても、永続的な確定前にどちらかが署名を出力できるなら十分ではない。ハードウェアモジュールであっても、同じ状態を二台へ複製し、重ならない割り当て規則がなければ問題は残る。

一つの権威モジュールで直列化する、別々の署名者へ互いに交わらない部分木を割り当てる、単調なハードウェアカウンターで巻き戻しを阻止・検知する、旧書き手をフェンスしてから後継を有効にする、といった設計は可能だ。重要なのは「何が一つなのか」を証明することだ。「ハードウェア利用」は状態独占の証拠ではなく、「高可用性」は単一書き手の別名でもない。

NIST のプロファイルは一般的な IETF 表現より厳格で、承認パラメータを限定し、鍵生成と署名をハードウェア暗号モジュール内で行い、秘密鍵を出力しないことを求める。この要件は、そのプロファイルへの適合を主張する実装に適用される。RFC 9708 を実装する全製品が同じ条件を備えると推測してはならない。

証明書は公開鍵を運ぶが、過去のコピーを列挙しない

RFC 9708 はオブジェクト識別子を定め、AlgorithmIdentifier のパラメータを付けないこと、HSS/LMS 公開鍵に追加の ASN.1 包装を施さないことを規定する。X.509 の keyUsage は署名用途と整合し、暗号化や鍵共有を示してはならない。これは RFC 5280 の証明書基盤と RFC 5912 の ASN.1 モジュールに接続するための規律である。

RFC 5652 の CMS では、signed attributes の有無で署名入力が変わる。属性がなければ内容を直接署名し、ある場合は内容をハッシュし、content type と message digest を含む SignedAttributes の DER 符号化を署名する。RFC 4108 のファームウェア包装なども、既存コンテナの中で HSS/LMS を利用できる。

これらは表現と検証対象を明確にする。証明書は発行ポリシーの下で主体と公開鍵を結び付けるが、古いスナップショットに対応する秘密状態が残っていないとは証明しない。CMS は保護されたバイトを示すが、署名装置の内部で失われたディスク書き込みは示さない。利用者が増えるほど、外部フォーマットに現れない内部受領証の重要性が増す。

有限の署名予算は経営資源である

パラメータ集合と木構造によって署名可能回数が決まる。運用者は想定レート、寿命、予備容量、後継鍵の認証と配布に必要な期間を把握しなければならない。急な消費増加は攻撃、正当なリリース、計測不良のいずれでもあり得るが、残量への影響は同じである。インデックスを巻き戻しても予算は増えず、台帳が偽になるだけだ。

IANA の LMS 登録簿 は標準タイプコードを記録する。RFC Editor の情報ページ、テキスト版、XML 版、IETF の文書履歴、正誤表は、標準の状態と来歴を示す。特定の運用者の残り葉数や復旧の安全性までは示さない。

Heng Lu の動くコードという基準を適用すれば、問うべきものは実行時の状態遷移になる。署名が境界を越える前に、消費記録は確定したのか。最小初期仕様は相互運用の共通床を作るが、隔離や復旧のローカル設計を代行しない。現実の層を分ければ、標準が存在すること、一つの署名が通ること、安全な履歴が存在することを同じ表示へ潰さずに済む。

HSS/LMS は責任を消すのではなく移す。量子計算によって脅かされ得る数学的仮定への依存を一部減らす代わりに、記憶装置と運用者へ厳格な時間管理を求める。秘密鍵とは、秘密と、二度と忘れてはならない消費履歴の組である。

出典