ファームウェアはデバイスが何を信頼し、何を実行し、どのセキュリティ修正が実際に有効であるかを決定します。ベンダーがアップデートを出荷する際の明確な目標は、脆弱性を修正し、チェックを厳格化し、昨日まで機能していた手法を封じることです。不都合な真実は、昨日のファームウェアが必ずしも消えるわけではないということです。アップデート後でも、以前のファームウェアは公式ファクトリーイメージや完全なOTAパッケージとして利用可能な場合があります。
では、誰かが単純に古いビルドをインストールして、すでに修正された脆弱性を再び開くことを阻止するものは何でしょうか？この記事では、アンチロールバック保護（ARB）とそれが実際のデバイスで前進のみのセキュリティベースラインをどのように実施するかを詳しく説明します。
アンチロールバック保護（ARB）とは何ですか？
通常、ARBに気づくのは、合理的なことをしようとしてデバイスがそれを拒否した時です。アップデートがバグを引き起こし、最後の安定ビルドにロールバックしたい場合があるかもしれません。修理工場が端末を復旧するために古いイメージが必要な場合もあるでしょう。ARBはそれらの後戻りを完全に阻止します。
これは全く新しい発明ではありませんが、最近ははるかに積極的に展開されています。ダウングレード攻撃が実用的な手法となり、EU サイバーレジリエンス法から自動車業界のUNECE R155/R156、そして新しいIoTセキュリティベースラインまで、コンプライアンス圧力が高まっています。業界が突然ロールバック保護を発見したわけではありません。むしろ、ダウングレードの扉を開けたままにしておくことが無謀となるポイントに到達したのです。
用語の違い
アンチロールバック保護は異なる用語で説明されるため、根底にあるアイデアが一つなのに、いくつかの異なる「ロック」があると考えやすくなっています。
AndroidにおいてGoogleの正式な用語は、Verified Boot内のrollback protectionで、デバイスが起動時にチェックするロールバックインデックスを通じて実装されています。ユーザーや技術者の間では、同じ動作は一般的にARB（Anti-Rollbackの略）と呼ばれています。
ベンダーはその上に独自のラベルを追加します。最小受諾バージョンがチップ内のワンタイム プログラマブル ビットに保存されるため、FuseやeFuseという用語も使用されます。同じ理由でOTP（ワンタイム プログラマブル メモリ）という用語も使用されます。モバイル市場では、Samsungのロールバックレベルが「バイナリ」リビジョン、またはワークショップ用語では「BIT」と呼ばれることがよくあります。これは、同じ前進のみの境界がフラッシュや修理ワークフローで表示される方法によるものです。
用語に関わらず、結果は同じです。デバイスが最小受諾セキュリティバージョンを記録すると、そのベースラインより古いものの起動を拒否します。これを理解する最も簡単な方法は、ラチェットとして考えることです：アップデートは最小値を前進させることができますが、通常のソフトウェアはそれを後退させることはできません。
これはよくGoogleがAndroid 8（Oreo）で導入したものとして説明されます。この見解は近いですが、完全に正確ではありません。Android 8は、ロールバック保護が標準化され、Androidエコシステムがそれに合わせることを可能にする方法でシステム統合されたポイントです。
OnePlusに関する最近の報告がARBを再び注目させていますが、ハードウェアによって強制されるロールバック防止の根本的なアイデアははるかに古いものです。現在の議論は、完全に新しいセキュリティ概念の導入としてではなく、より新しいファームウェアビルドでの新たな強制の波として理解することが適切です。
ARBが対処するセキュリティ問題
ダウングレード攻撃中、攻撃者は署名を偽造したりカスタムファームウェアを発明したりする必要はありません。彼らは単純に、まだ署名されており、まだ公式に見え、すでにマッピングされた弱点をまだ含んでいる古いビルドにデバイスを押し戻すだけです。
これがARBが埋めるギャップです。セキュアブートはファームウェアが本物であることを教えてくれますが、それ自体では、ファームウェアが安全であるために十分に新しいことを保証しません。古い署名済みイメージが受け入れられ続ける場合、新しいリリースで出荷された修正は実際には任意のものになります。攻撃者は最も簡単なルートを選択し、後退することは前進の防御を破るよりも簡単な場合があります。
ARBはその動きをブロックします。デバイスが特定の閾値を越えると、時を遡るトリックはもはや機能しません。デバイスが意図的に古く、弱い状態に踏み込むことがないため、攻撃者は簡単な勝利のカテゴリ全体を失います。
ハードウェアによって強制されるバージョン境界
ストレージの再フラッシュ、イメージの再インストール、またはパーティションの交換は、デバイスがすでに受諾可能として記録したものを変更しません。より新しいベースラインが保存されると、古いバージョンは正しく署名され、パッケージ化されていても受け入れられないものとして扱われます。
これが、デバイスが前進した後、特に技術者が古いビルドを試して警告の代わりにハードな拒否に直面する実際のワークショップシナリオでは、「公式ファームウェア」が必ずしも「フラッシュ可能なファームウェア」を意味しない理由です。
なぜARBはソフトウェアポリシーではないのか
アンチロールバック保護はアップデーターでのベンダーの設定ではありません。保存された値は不可逆的に設計されているため、閾値を下げたり、リセットしたりすることはできません。
最小バージョンが編集可能であれば、攻撃者はまずそのメカニズムを標的にするでしょう。ARBは、デバイスの更新履歴をソフトウェアが書き換えることができないものにすることで、その罠を回避します。最小バージョンが前進すると、プラットフォームはその時点から強制されたベースラインとして扱います。
ARBが起動時にどのように機能するか
起動プロセスは制御された引き継ぎの一連の流れです。各段階には定義された仕事があり、各段階は制御が前進する前に次の段階をチェックします。ARBはその流れに簡単な質問を織り込みます：これから実行しようとしているものは、デバイスが要求するものと少なくとも同じくらい新しいですか？
ファームウェアバージョンインデックス
検証済み起動に参加するすべてのファームウェアイメージはバージョン情報を運びます。この値はセキュリティバージョンインデックスとして記述されます。高い数字は、より多くの問題が修正され、より多くの保護手段が導入されたベンダーの更新タイムラインの後の時点を表します。
ARBでは、デバイスはハードウェアに裏付けられたストレージに最小受諾バージョンを記録し、すべての候補イメージがその保存された参照と比較されます。デバイスは効果的にどれだけ前進したかを記憶し、将来の起動試行はその進行を尊重しなければなりません。
実際的な観点では、ARBは一部の後退ステップを永続的な非選択肢に変えます。以前起動していたビルドは、デバイスがより高い最小値を記録した後、永久に受け入れられなくなる可能性があります。
起動チェーン検証モデル
起動フロー自体はチェーンとして構造化されています。各段階は制御を引き渡す前に次の段階の整合性と起源を検証します。すべてのステップで署名がチェックされ、バージョンデータはそれらの署名と並行して評価されます。
すべてのコンポーネントがロックステップで前進する必要がないことも重要な点です。ベンダーはしばしばチェーンの部分を独立して更新します。各要素はコンテキストで検証され、保存された最小値との比較は重要な場所で行われます。
これが人々がARBの壁にぶつかったときに混乱する理由の一つです。彼らは単一の簡単なファームウェアバージョンを期待しますが、起動に重要なコンポーネントは異なる方法で重要な別々のバージョン境界を持つことができます。
BootROM
起動チェーンの始まりにはBootROMがあり、これは信頼の根として機能するチップに焼き込まれた不変のコードです。ベンダーは最初の段階を異なって表示する場合があります（例えば、QualcommはプライマリブートローダーまたはPBLと呼びます）が、役割は同じです。起動は固定された信頼できるベースから始まります。
その時点から、初期起動コードが保存された最小バージョンを読み取り、それを下回る段階をブロックし、攻撃者がルールをバイパスするために最初のレイヤーを書き換えることができないため、ロールバックチェックはすでに適用できます。
Samsungでは、これは通常、人々がアンチロールバックの実際的な意味を発見する瞬間で、ダウングレードを試みてSW REV / binaryの壁に真っ直ぐにぶつかることです。
なぜセキュアブートだけでは十分ではないのか
セキュアブートは現代のデバイス信頼の基盤として正しく記述されています。起動シーケンスの各段階が承認されたソースから生じ、変更されていないことを保証します。保証しないのは、承認されたコードが安全であるために十分新しいことです。セキュアブートはファームウェアが本物であるかどうかの回答に優れています。ファームウェアが古いかどうかには答えません。
セキュアブートが実際に検証するもの
セキュアブートは、デバイス起動中に使用されるソフトウェアがOEMによって信頼されることを保証します。ファームウェアイメージはデジタル署名されている必要があり、署名は実行しようとするコンテンツと一致している必要があります。これらの条件が満たされれば、イメージは認証性の観点から有効です。
ライフサイクルの観点では、それはストーリーの一部に過ぎません。古いバージョンは長期間にわたって有効に署名されたままである可能性があり、それがダウングレード攻撃の正確な開口部です。
署名されているが脆弱な問題
古いファームウェアバージョンはすべての認証性チェックを通過し、それでもすでに研究された攻撃パスを露出させる可能性があります。セキュリティアドバイザリは、しばしば以前のビルドに存在するが後で排除される問題を記述します。デバイスが以前のビルドを受け入れ続ける場合、後の修正は誰も巻き戻すことができない限りでのみ役立ちます。
最小バージョンを強制することで、ARBは既知の弱点がまだ存在する状態への復帰をブロックします。
ダウングレード攻撃が実際にどのように機能するか
ダウングレード攻撃は馴染みのあるパターンに従います。デバイスは古いビルドをインストールするよう強制または説得されます。攻撃者はその古いビルドでのみ機能するエクスプロイトを使用します。足場を得ると、持続性、データアクセス、またはより深い変更を試みることができます。
古いファームウェアがまだ適切に署名されている場合、セキュアブート自体はこれを阻止しません。ARBは最初のステップでダウングレードを拒否することで、最初からチェーンを断ち切ります。
ファームウェア新鮮度強制としてのARB
セキュアブートと組み合わせて、ARBは信頼に第二の次元を追加します。一緒になって、ダウングレード攻撃が依存するギャップを埋めます。バージョン制御なしの認証性は回帰の余地を残します。認証性なしのバージョン制御は信頼できないコードの実行を許可するでしょう。両方が存在する場合、プラットフォームは起源と最新性を強制します。
典型的な使用例と展開エリア
ファームウェアアップデートを通じて進化し、時間をかけてセキュリティ姿勢を保持しなければならないプラットフォームはすべて、ARBの恩恵を受けます。
Androidモバイルデバイス
多くの現代のAndroid携帯電話は、起動とアップデート設計の一部としてARBを実装しています。各セキュリティパッチレベルは、弱点を閉じることでプラットフォームを前進させます。以前のパッチレベルへの復帰を許可することは、すでに対処された問題を再導入することになります。
最小受諾バージョンを強制することで、ARBはデバイスを最新のセキュリティ状態に合わせ続けます。プラットフォームが前進すると、そのレベルが将来の起動とフラッシュのベースラインになります。
ゲームコンソール
ロールバック保護はゲームコンソールでもよく知られています。これらのシステムは、エクスプロイトパスを閉じ、セキュリティ制御を調整するファームウェアアップデートを受信します。古いファームウェアを自由に復元できる場合、既知の弱点は永続的なエントリーポイントのままになります。
したがって、コンソールプラットフォームは、特定のポイントを超えた回帰を防ぐ前進のみの閾値を使用します。システムが前進すると、以前の世代への復帰はブロックされ、後のセキュリティ改善が所定の場所に保たれます。
組み込みシステムと産業システム
長寿命の組み込みデバイスと産業機器は、しばしば物理的アクセスが現実的で、アップデートサイクルが遅い環境で動作します。時間の経過とともに、ファームウェアリビジョンは発見された弱点に対処します。古いビルドにロールバックすることで、すでに知られている脅威にシステムを露出させる可能性があります。
ARBはその後方へのドリフトを防ぐのに役立ちます。新しい最小バージョンが記録されると、以前の状態は受け入れられなくなります。これは、デバイスの運用寿命を通じて一貫したセキュリティベースラインをサポートします。
自動車ECU
自動車の電子制御ユニットは、安全性とシステム動作に影響を与える機能を管理します。ファームウェアアップデートは安全性の発見とサイバーセキュリティ評価に対応します。回帰を許可することはそれらの改善を損なうでしょう。
ARBスタイルの強制は、制御ユニットがより新しいファームウェアレベルに前進すると、より古く、より保護されていない状態に戻らないことを保証します。これは安全性への期待と現代のオーバー・ザ・エア アップデート戦略の整合性をサポートします。
デメリットは何ですか？
展開されたシステムでアンチロールバックを価値あるものにする同じ特性が、開発中に摩擦を生み出します。バージョン閾値が不可逆メカニズムに関連付けられると、柔軟性が低下し、間違いが永続的になる可能性があります。
不可逆Fuseおよび OTPリスク
最小許可ファームウェアバージョンは、改ざん耐性を意図したハードウェアに裏付けられた場所に保存されるため、間違った閾値が記録されると、開発またはテストデバイスがエンジニアがまだ必要とするビルドを拒否することになる可能性があります。
通常の設定ミスとは異なり、ロールバック保護は検証済み起動中に強制され、高いベースラインが記録されると古いバージョンの起動を特に拒否するよう設計されているため、ソフトウェアを再インストールすることで必ずしも修正できるとは限りません。
これが復旧が限定的である理由です。ロールバック境界を越えると、一般的な「古いビルドをフラッシュするだけ」のフォールバックがブロックされる可能性があり、一部のプラットフォームでは間違ったラインを越えたダウングレードは可逆的な間違いではなくブリックリスクとして広く報告されています。
デバッグの制限
トラブルシューティングはしばしば、リビジョン間での動作の比較を含みます。エンジニアは、問題を再現したり、問題が最初に現れた時期を確認するために、以前のビルドに戻る必要がある場合があります。ARBが実装されている場合、すでに閾値を越えて前進したデバイスでは、それらの後退ステップがもはや不可能になる場合があります。
これは調査の計画方法を変えます。チームは古いビルド用に別のハードウェアを保存し、シミュレーションにより依存し、またはより良いログ記録に投資します。ARBは前進のみのワークフローを奨励し、困難なバグハントの最中にいる場合、これはイライラさせる可能性があります。
パイプライン調整の課題
バージョン番号とリリースシーケンスは、開発、テスト、本番にわたって注意深く管理される必要があります。一つの段階が他の段階が準備できる前に最小バージョンを前進させると、チームは突然、共有デバイスで期待されるファームウェア組み合わせを実行できなくなる可能性があります。
したがって、ARBは調整を要求します。リリース計画、バージョン割り当て、更新シーケンスは整合させる必要があります。セキュリティ上の利益は明確ですが、運用規律がコストの一部になります。
まとめ
ARBは新しいアイデアではありませんが、ダウングレード攻撃が実際の脅威パターンとなり、コンプライアンス期待が高まり、fuse/eFuse/OTPベースのストレージが前進のみのベースラインを実用的で耐久性のあるものにしているため、現在広く展開されています。
Chimera Toolは、数千のモバイルモデルと複雑なサービス機能をサポートするオールインワンソフトウェアソリューションを提供します。モバイルセキュリティ研究の最前線にいることで、ARBおよびセキュアブートが厳格に強制されている環境でも、ユーザーがファームウェアを管理し、セキュリティバージョンを特定し、重要な修理を実行することを可能にします。
