Introduction: The Imperative of Verified Boot in Android

In the ever-evolving landscape of mobile security, ensuring the integrity of a device’s software stack from the moment it powers on is paramount. Android Verified Boot (AVB), specifically its second iteration, AVB 2.0, stands as a cornerstone of Android’s security model. It’s a robust mechanism designed to detect and prevent malicious modifications to the operating system, ensuring that the device boots into a known, trusted state. For developers, custom ROM enthusiasts, and security researchers alike, understanding the intricate workings of AVB 2.0 is crucial, as it dictates how software can be modified, upgraded, or even rooted without compromising device integrity.

This article delves deep into the architecture of AVB 2.0, exploring its core components, the sophisticated verification process from the bootloader to the system partitions, and its profound impact on Android security and the custom ROM community.

The Evolution of Android Verified Boot: From AVB 1.0 to 2.0

Android’s journey towards comprehensive boot integrity began with AVB 1.0, which introduced basic cryptographic verification of the boot image and a read-only root filesystem enforced by `dm-verity`. While effective for its time, AVB 1.0 had limitations, particularly in its flexibility for A/B updates and its handling of multiple partitions without robust rollback protection.

AVB 2.0 emerged as a significant upgrade, addressing these shortcomings with a more modular and extensible design. Key improvements include:

• Chained Partitions: Allowing for granular verification of partitions (e.g., `system`, `vendor`) that can be signed independently yet cryptographically linked to the main `vbmeta` image.
• Rollback Protection: A robust mechanism that prevents an attacker from flashing an older, potentially vulnerable version of Android, typically enforced through hardware-backed anti-rollback counters.
• Per-partition Hash Descriptors: Enabling `dm-verity` trees to be generated and verified for individual partitions, offering greater flexibility and efficiency during updates.
• Flexible Public Keys: Support for embedding public keys directly in the bootloader or within a dedicated `vbmeta` partition, facilitating OEM customization.

Core Components and Mechanisms of AVB 2.0

The Bootloader: Root of Trust

At the heart of AVB 2.0 is the device’s bootloader, which serves as the immutable hardware Root of Trust. It contains OEM-embedded public keys (or their hashes) that are burned into a secure, unmodifiable area (e.g., eFuses). During boot, the bootloader is the first component to execute, and it is responsible for verifying the integrity of the next stage of the boot process.

VBMeta Partition: The Verification Metadata Hub

The `vbmeta` partition is a dedicated flash partition that stores critical AVB metadata. This includes:

• Cryptographic hash descriptors for other partitions (e.g., `boot`, `dtbo`).
• Public keys for verifying chained partitions (`vbmeta_system`, `vbmeta_vendor`).
• The anti-rollback index, used for rollback protection.
• Signature of the `vbmeta` itself, signed by the OEM’s private key.

The bootloader verifies the signature of the `vbmeta` image against its embedded public key. If the signature is invalid, the boot process is halted, or the user is prompted with a warning.

dm-verity: On-the-Fly Block Verification

`dm-verity` (device mapper verity) is a kernel module that ensures the integrity of block devices. It works by creating a hash tree (Merkle tree) over a partition’s data. The root hash of this tree is stored in the `vbmeta` or another verified partition. As the kernel reads blocks from the protected partition (e.g., `system`, `vendor`), `dm-verity` calculates their hashes and verifies them against the hash tree. Any discrepancy immediately indicates tampering, leading to a verification error and preventing further access to the corrupt data.

A simplified view of a `dm-verity` hash tree:

      Root Hash (in vbmeta)     /         Hash A  Hash B   /     /   Block 1 Block 2 Block 3 Block 4

Rollback Protection

AVB 2.0 incorporates robust rollback protection to prevent an attacker from downgrading a device to an older, potentially vulnerable software version. This is achieved by storing an anti-rollback index within the `vbmeta` image and securely in hardware (e.g., eFuses or Replay Protected Memory Blocks – RPMB). When a new software version is installed, the anti-rollback index is incremented. The bootloader compares the `vbmeta`’s index with the hardware-stored index; if the `vbmeta`’s index is lower, the boot is rejected.

The AVB 2.0 Boot Verification Flow

The AVB 2.0 verification process is a meticulous, multi-stage operation:

1. Bootloader Initialization: The bootloader starts, loads the `vbmeta` partition, and verifies its cryptographic signature using the OEM’s public key securely stored in hardware.
2. Initial Partition Verification: If `vbmeta` is valid, the bootloader uses its hash descriptors to verify critical partitions like `boot.img` and `dtbo.img` (Device Tree Blob Overlay).
3. Kernel and `initramfs` Load: The verified `boot.img` (containing the kernel and `initramfs`) is loaded.
4. `dm-verity` Setup: The kernel, via `init`, reads `dm-verity` metadata (root hashes, salt) for partitions like `system`, `vendor`, and `product` from their respective `vbmeta` images (e.g., `vbmeta_system`, `vbmeta_vendor`), which are chained and verified by the main `vbmeta`.
5. On-the-Fly Verification: As `system`, `vendor`, and other partitions are accessed, `dm-verity` continuously verifies their blocks. Any modification triggers an integrity error, preventing the compromised data from being used.

Impact on Custom ROMs and Development

AVB 2.0 significantly impacts custom ROM development and device modding. By default, flashing custom firmware without the OEM’s signature will trigger AVB, leading to boot failure or a warning screen, typically indicating a