Android Pie で起動する携帯電話には Android Oreo のロールバック保護が必要です

Xda ニュース概要Nov 04, 2023

Android Pie (Android 9) で起動するすべてのデバイスは、ロールバック保護を可能にする検証ブート (Android 検証ブート 2.0) をサポートする必要があります。

Android Pie (Android 9) 今日ちょうどライブ行ってきました Google Pixel、Google Pixel 2、および さえ 必須の電話。 私たちはインタビューからリリースについてできる限り多くのことを学んでいます（Google Pixel 3） ジェスチャーナビゲーションのみになります!)、 AOSP コードのドロップ、最後に互換性定義文書 (CDD) です。 について掲載しました。 「重量級」アプリ向けの新機能 今日の初めに、Google が Android Oreo で導入された機能に関する表現を変更したことがわかりました。 ロールバック保護. この機能は次によって可能になります。 Android 検証済みブート 2.0 (単に検証ブートとも呼ばれます) ただし、OEM は Oreo リリースに AVB 2.0 を実装する必要はありませんでした。 現在、Google は、Android Pie で起動するすべてのデバイスが検証済みブート、ひいてはロールバック保護をサポートすることを義務付けています。

Android Oreo のロールバック保護

この機能の要点は、デバイスがダウングレードされたことが検出された場合に携帯電話が起動できなくなることです。 セキュリティ上の理由で安全ではないとみなされた、以前の未承認バージョンのソフトウェアへの移行 脆弱性。 もう少し技術的に説明すると、VBMeta データ構造はブート パーティションのハッシュを保持し、 システムおよびベンダー パーティションのハッシュツリー メタデータは、ロールバック インデックスを使用して古いロールバックを持つイメージを拒否します。 索引。

Android 検証済みブートでのロールバック保護。 ソース： グーグル.

この機能は、Google Pixel 2、Razer Phone、OnePlus 6 などのデバイスにはありますが、Samsung Galaxy S9 などの他の多くのデバイスにはありません (ただし、Samsung は独自の形式の Knox のロールバック保護.) 現在、Google は Android Pie で起動するすべてのデバイスにこの機能を必須にしています。

Android Pieでの検証済みブート

互換性定義ドキュメントの「デバイスの整合性」セクションの更新された文言によると、Android 9 で起動するデバイスはベリファイド ブートをサポートする必要があります。

9.10. デバイスの完全性

次の要件により、デバイスの完全性ステータスの透明性が保証されます。 デバイスの実装:

  • [C-0-1] ブートローダーの状態がシステム イメージのフラッシュを許可するかどうかを、システム API メソッド PersistentDataBlockManager.getFlashLockState() を通じて正しく報告しなければなりません。 FLASH_LOCK_UNKNOWN 状態は、この新しいシステム API メソッドが存在しなかった以前のバージョンの Android からアップグレードするデバイス実装用に予約されています。
  • [C-0-2] デバイスの整合性のために検証済みブートをサポートしなければなりません。

以前のバージョンの Android で検証ブートをサポートせずにデバイス実装がすでに起動されている場合 システム ソフトウェア アップデートでこの機能のサポートを追加することはできません。これらは、 要件。

...

  • [C-1-10] Android で使用されるパーティション (ブート、システム パーティションなど) にロールバック保護を実装しなければなりません 最小許容 OS を決定するために使用されるメタデータを保存するために改ざん防止ストレージを使用します。 バージョン。
  • 永続的なファームウェアを備えたコンポーネント (モデム、カメラなど) に対してロールバック保護を実装すべきです。 最小許容値を決定するために使用されるメタデータの保存には、改ざん防止ストレージを使用すべきです(SHOULD)。 バージョン。

最後の 2 つの箇条書きセットでわかるように、注意すべき点が 1 つあります。 ロールバック保護は、Android によって使用されるパーティション (ブート、システム、ベンダーなど) には必要ですが、永続的なファームウェアを含むパーティション (モデム、カメラなど) には必要ありません。 前者のパーティションのセットは、ほとんどのセキュリティ脆弱性が発見され、パッチが適用される場所であるため、これらのパーティションの保護が必須であることは喜ばしいことです。 ただし、永続的なファームウェアを備えたパーティションをターゲットとするエクスプロイトも存在するため、Google がパーティションに対するロールバック保護を義務付けていない理由は不明です。

XDA 上級会員 ンプジョンソンLineageOS チームのメンバーである は、永続的なファームウェアを使用したパーティションでロールバック保護を要求すると、 これらのパーティションはブートの早い段階でマウントされるため、セカンダリ ブートローダー (SBL) と eXtensible Bootloader (XBL) のタイインが必要です プロセス。 小規模な OEM が、カスタマイズされたモデムやその他の永続パーティションに合わせてカスタマイズされた XBL を実装するにはコストがかかります。 したがって、おそらく Google は、デバイス メーカーが CDD の最新の要件を満たしやすくするためにこれを要件にしているのではありません。

携帯電話が AVB 2.0 をサポートしているかどうかを確認する方法

電話機が AVB 2.0 をサポートしているかどうかを確認するために使用できる ADB シェル コマンドが 2 つあります。

adb shell
dumpsys package | grep "verified_boot"

または

adb shell
getprop | grep "avb"

最初のコマンドの出力が「android.software.verified_boot」の場合、AVB 2.0 がサポートされています。 2 番目のコマンドの出力に「[ro.boot.avb_version]」と「[ro.boot.vbmeta.avb_version]」が表示され、それぞれのバージョン番号がリストされている場合、それはサポートされています。

検証済みブートとカスタム開発

Android 検証済みブートは、ほとんどのカスタム ROM ユーザーには実際には影響しませんが、場合によっては回避策が必要なセキュリティ層が追加されます。 例えば、 汎用システムイメージのフラッシュ AVB を無効にする必要があります。 OnePlus 6 のベンダーなどの特定のパーティションを変更するには、AVB も無効にする必要があります。 最近知ったように. によると ンプジョンソン、AVB 2.0 を適切に実装すると、カスタム ブート イメージがロックされたブートローダーで動作できるようになります。 Android Pie を搭載したデバイスに AVB 2.0 が組み込まれることが環境にどのような影響を与えるかは今後わかりますが、それが次のような状況にならないことを願っています。 最近のレンガの恐怖 Xiaomi Redmi Note 5 Pro コミュニティ内。 必須の AVB 2.0 は、Google が Android プラットフォームのセキュリティを向上させるしかし、私たちの考える最大の変化は、 定期的なセキュリティパッチを義務付けるためのOEM契約の見直し.