要約

  • ステートフルHBS鍵は、比較的変化しない秘密材料と、使用済みOTSインデックスを示す可変状態から成る。バックアップが真正でも、その状態が最新かつ排他的とは限らない。
  • 完成した署名の引き渡しと状態の永続的な前進は、一つの不可分な処理でなければならない。セクター、予約区間、時間窓で容量を分けても、復旧後に割当てが重なれば安全性は失われる。
  • HSMの自己診断や有効なテスト署名は、装置が署名できることしか示さない。未使用状態を単独で保有している証拠にはならず、復旧には非重複境界を記した管理記録が要る。

復旧作業の画面には、安心できる表示が並ぶ。暗号化バックアップは開き、ハッシュは一致し、HSMはインポート後の自己診断に合格する。試験メッセージの署名も既知の公開鍵で検証できる。それでも、その署名が使ったインデックスを障害前に別のメッセージへ使っていなかったとは言えない。

RFC 10033は、IETFストリームのInformational文書として、この運用上の断層を扱う。XMSSやLMSは、多数のワンタイム署名（OTS）鍵を長期の公開鍵体系に組み込む。同じOTS秘密を異なるメッセージに再利用すると、偽造を計算上可能にする情報が露出し得る。したがって安全性は、秘密が盗まれないことだけでなく、各インデックスが一度しか使われないことにも依存する。

正しいが遅れているバックアップ

次の利用可能インデックスが8,000の時点でバックアップを作り、その後500件の署名を外部へ返したとする。稼働系の状態は8,500まで進んだが、事故で失われた。旧コピーを戻すと、秘密材料は正しく、生成される署名も検証に通る。しかし装置は8,000から8,499を再び未使用と判断する。外部世界には、すでにその範囲の署名が存在する。

壊れているのはファイルではなく、時間に関する主張である。チェックサムは改変の有無を示せても、後発の状態や生き残った複製の不存在は示せない。RFC 9802も、通常の秘密鍵バックアップをそのまま適用し、状態を正しく同期しなければOTS再利用が起きやすいと警告する。

NIST SP 800-208は、承認対象のステートフルHBSについて、鍵生成と署名をハードウェア暗号モジュール内で行い、秘密鍵材料を輸出しない構成を求める。RFC 10033は、そのNIST構成を超える環境の手法も論じる。RFCに輸出・取込みの方法があるからといって、NIST準拠モジュールの秘密鍵輸出が許されるわけではない。

秘密材料と可変状態

秘密材料は有効な署名を作る能力を与える。可変状態は、どの能力がまだ他者に見られていないかを示す。後者は小さなカウンターに見えても、実際には暗号境界の一部である。予約済み区間、署名装置の識別子、外向き応答ログ、キュー、VMスナップショット、移管元の停止証拠も同じ境界に入る。

そのため復旧は、完全性の確認から排他性の立証へ変わる。本物のコピーが二つ存在し、二つの装置が同じ範囲を自分のものだと思えば、どちらも正常に署名しながら安全条件を破る。プロセスのfork、未フラッシュのキャッシュ、VM複製、二拠点での同時災害対応が、この重なりを作り得る。

状態を進めてから署名を渡す

RFC 8391はXMSSの秘密状態を署名出力前に更新するよう求め、RFC 8554もLMSに同じ原則を置く。RFC 10033は、署名の解放と状態前進を、原子性・一貫性・分離性・永続性を備えた処理として設計する考え方を示す。

状態を先に永続化し、署名を返す前に停止した場合、インデックスは一つ無駄になる。逆に署名を先に返して状態書込みを失えば、外部で消費済みのインデックスが内部では空きに戻る。両者の損失は対称ではない。不確実な容量を捨てることは有限資源を減らすが、再利用は公開鍵全体への信頼を損ない得る。

セクター、区間、時間窓

RFC 10033は状態空間を分割する方法を整理している。セクター化は、共通公開鍵の下にある独立部分を別々の署名装置へ割り当てる。事前割当ては重ならないインデックス範囲を装置ごとに与える。区間予約では、プロセスが署名前にブロック全体を確保し、停止時には未使用の残りも廃棄する。時間窓を使う場合は論理時計を巻き戻さず、過去の窓の余りを再開しない。

分割は状態管理を不要にするのではなく、管理者を明確にする。セクター移管では元装置が利用をやめ、復旧先が稼働中・故障中・オフライン保管中のどのコピーとも重ならないことが必要だ。部分移管や再統合でも同じ台帳が要る。

NISTの非輸出構成外の方法として、RFCは下位木を事前生成する復旧方式も示す。未使用の上位OTS鍵で下位木のルートに署名し、シード、署名、インデックス、ハッシュを輸出して元コピーを不可逆に削除する。復旧側は最初の未使用シードを取り込み、木を再生成してハッシュを照合し、バックアップ媒体からシードを削除する。所有権移動を明示できる一方、障害や第三者保管後に「削除済み」を完全に証明する難しさは残る。

復旧管理票

RFC 10033が一般的な管理票を義務づけているわけではない。ここでは、緊急時の判断を後から検証可能にするため提案する。

記録すべきなのは、公開鍵、アルゴリズムとパラメーター、署名装置とHSMの識別子、バックアップ世代と作成時刻、復旧状態、外部で完全な署名が確認された最大インデックス、セクター・区間・時間窓、廃棄した予約容量、移管元の停止と削除の証拠、輸入パッケージのハッシュ、担当者と承認者、起動時刻と照合時刻である。

不確実性も残す。永続状態が40,000でも応答キューが40,063まで返した可能性があれば、その全範囲を避ける。故障元の停止を証明できなければ、そのセクターを隔離する。回収不能なオフラインコピーは、無害な保管物ではなく継続する重複リスクだ。

これは暗号学的証明ではない。復旧装置が未使用領域を排他的に持つと判断した根拠と、安全のため意図的に失った容量を明らかにする統治記録である。

情報源