# ロールバックとバージョン単調性 ## 定義 ロールバックとバージョン単調性は、ソフトウェア/ファームウェアの更新を巻き戻す機能が信頼性の回復に必要である一方、セキュリティ修正の巻き戻しは既知の脆弱性を再導入する経路になりうるという緊張関係を、コンポーネント外部で管理される単調増加の状態値によって調停する設計パターンである。「任意のロールバックを常に許可する」と「ロールバックを一切許可しない」という両極端はいずれも破綻する——前者は unzipping(段階的に古いバージョンまで遡って脆弱性に到達する攻撃)に弱く、後者はバグ入りの更新から戻る手段を失う。中心的な機構が Minimum Acceptable Security Version Number(MASVN)で、各リリースが持つ Security Version Number(SVN)に対して `Release[SVN] >= ComponentState[MASVN]` を更新許可の前提条件とし、`ComponentState[MASVN] = max(self[MASVN], ComponentState[MASVN])` という一方向にしか値が増えない更新式で単調性を機械的に強制する。deny list(既知の悪いバージョンの列挙)と署名鍵ローテーション(検証鍵の入れ替えで旧バージョンの署名を無効化)は、同じ目的のための代替・補完手法として位置づけられる。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 9 Design for Recovery]] §Rollbacks Represent a Tradeoff Between Security and Reliability, §Minimum Acceptable Security Version Numbers) ## 横断的知見 - **MASVN の「外部状態を単調に進める」設計は、バージョン履歴が原子性のために課す「唯一のコピーを決して書き換えるな」という黄金律と、同じ構造的発想を異なる目的に適用したものである**: [[@2009__MITOCW__Principles of Computer System Design - Chapter 9 Atomicity - All-or-Nothing and Before-or-After]] が扱うバージョン履歴(→ [[バージョン履歴]])は、named variable に対する上書きを禁じ、代わりに版を追記し続けることでトランザクションの原子性を機械的に保証する。MASVN もまた、`ComponentState[MASVN]` という値を減少させる操作を一切許さず、`max()` を取ることでしか更新できないようにする——対象は「トランザクションの直列化順序」ではなく「許容されるロールバックの下限」だが、いずれも「値を後退させない」という不変条件を、個々のコンポーネントのロジックではなく外部の共有状態の更新規則そのものに埋め込むことで安全性を担保する点で共通する。前者は並行性制御、後者はセキュリティという全く異なる問題領域から、独立に同じ「単調性を状態の更新規則で強制する」という解に到達している。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 9 Design for Recovery]] §Minimum Acceptable Security Version Numbers, [[@2009__MITOCW__Principles of Computer System Design - Chapter 9 Atomicity - All-or-Nothing and Before-or-After]] §9.2.3) - **ロールバックの「二つの極端」という問題設定の立て方自体が、同一書籍の別章が採る「二つの極端」の立て方と同型である**: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 8 Design for Resilience]] は、不確実な状況への応答をフェイルセーフ(可用性優先で開放する)かフェイルセキュア(完全性を検証できないので閉じる)かという二択で立て、ACL 読み込み失敗時の既定を「全許可」にするか「全拒否」にするかを典型例に挙げる。第9章のロールバック問題も「任意のロールバックを許可する」(可用性優先)か「一切許可しない」(セキュリティ優先)かという同じ形の二極対立として提示される。第8章はこの二択を「劣化を制御されたブレークポイントで段階的に許す」ことで、第9章は「単調増加する外部状態(MASVN)で許容範囲を動的に絞る」ことで解決しており、両章とも問題の立て方(二つの危険な極端)は共有しつつ、解決の軸(段階的劣化 対 単調な外部状態)は異なる独自の機構を用いている。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 9 Design for Recovery]] §Rollbacks Represent a Tradeoff Between Security and Reliability, [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 8 Design for Resilience]] §Failing Safe Versus Failing Secure) ## 未解決の問い - MASVN の「外部状態を単調に進める」パターンと、バージョン履歴の「唯一のコピーを書き換えない」パターンは、より一般的な「単調性による安全性の強制」という統一的なフォーマリズムで記述できるか。両者を同じ理論的枠組みで扱った文献は本 wiki にまだない。 - 攻撃者が一時的に MASVN を最大値まで押し上げてスキーム全体を機能不全にした場合の回復経路(鍵ローテーションで異常な `ComponentState[MASVN]` を検出しリセットする)は、その回復ロジック自体が新たな攻撃面になりうると本文でも指摘されるが、この回復経路をどう検証・監査すべきかの具体的な手法は示されていない。 - deny list・MASVN・署名鍵ローテーションを同時に組み合わせた運用は「大掛かりな取り組み」だと本文は明言するが、どの規模・成熟度の組織であればこの組み合わせが正当化されるかの基準は示されていない。段階的導入の順序(deny list → MASVN → 鍵ローテーション)以上の定量的な指針はあるか。 - OTP(one-time-programmable)ヒューズで MASVN を物理的に前方専用にするハードウェアの場合、単調性の強制がソフトウェア的な仕組み(`max()` 更新式)から物理的な仕組みへ移ると、両者の安全性保証の強度はどう比較できるか。 ## 関連 - ソース: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 9 Design for Recovery]] / [[@2009__MITOCW__Principles of Computer System Design - Chapter 9 Atomicity - All-or-Nothing and Before-or-After]] - 概念: [[バージョン履歴]](単調性を状態の更新規則に埋め込むという同型の構造) / [[復旧のための設計]](本 concept が具体化する上位の設計原則) / [[カナリアテスト]] / [[ソフトウェア変更管理]] - 関連 MOC: なし(新規 concept) ## 出典 - Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 9, §Rollbacks Represent a Tradeoff Between Security and Reliability, §Minimum Acceptable Security Version Numbers, §Rotating signing keys. - Jerome H. Saltzer and M. Frans Kaashoek, *Principles of Computer System Design: An Introduction*, Version 5.0, 2009, Chapter 9, §9.2.3. MIT OpenCourseWare, CC BY-NC-SA 3.0 US.