Introduction to Android Verified Boot 2.0 (AVB2)

Android’s robust security architecture is a cornerstone of its widespread adoption, and at its heart lies Android Verified Boot 2.0 (AVB2). This critical security feature ensures the integrity of the entire boot chain, from the immutable hardware root of trust right up to the loaded Android operating system. AVB2 is designed to detect and prevent malicious or corrupted modifications to the system software, safeguarding users from potential threats like rootkits and persistent malware. Unlike its predecessor, AVB2 introduces significant enhancements, particularly with the VBMeta header and a more flexible, extensible design, allowing for better OEM customization and stronger protection.

The Immutable Root of Trust and the Boot Chain

The foundation of AVB2’s security model is the Root of Trust (RoT). This is typically a hardware component, often a cryptographic public key or hash permanently fused into the device’s System-on-Chip (SoC) at the factory. This RoT is immutable and serves as the ultimate anchor for verifying all subsequent software components. The boot process begins by verifying the initial bootloader (ABL, Android Bootloader) against this RoT. If successful, the ABL then takes over, verifying the next stage in the boot chain, and so on, creating a cryptographic chain of trust.

Understanding VBMeta: The Central Pillar of AVB2

A crucial innovation in AVB2 is the VBMeta partition (or header). VBMeta acts as a central repository for metadata crucial to verification. It contains:

1. Hashes and Signatures: Cryptographic digests and signatures for various partitions (e.g., boot.img, system.img, vendor.img, dtbo.img).
2. Public Keys: Keys used to verify other signed images, allowing for key rotation and multiple signing authorities.
3. Rollback Protection Version: Anti-rollback counters to prevent flashing older, potentially vulnerable software versions.
4. Device State: Information about the device’s locked/unlocked state.

The VBMeta image (vbmeta.img) itself is signed by the OEM’s private key. The public key corresponding to this OEM key is often embedded in the bootloader. Therefore, the bootloader’s first step after its own verification is to verify the vbmeta.img. If the vbmeta.img signature is valid, the bootloader can then trust the hashes and descriptors within it to verify other partitions.

Hash Trees and dm-verity: Ensuring Data Integrity

While VBMeta verifies the integrity of entire images, dm-verity (device mapper verity) ensures the ongoing integrity of partitions while they are in use, particularly for large, read-only partitions like system.img and vendor.img. dm-verity employs a Merkle tree (hash tree) structure. Here’s how it works:

• The partition’s data is broken into fixed-size blocks (e.g., 4KB).
• Each block’s hash is calculated.
• These hashes are then hashed in pairs, forming the next level of the tree, until a single root hash is generated.
• This root hash is stored in the VBMeta image.

During runtime, when the Android kernel attempts to read a data block from a dm-verity protected partition, it re-calculates the hash of that block and verifies it against the corresponding hash in the hash tree, eventually tracing back to the root hash stored in VBMeta. If any block’s content has been tampered with, the hash verification will fail, preventing the system from using the corrupted data and potentially halting the boot process or indicating a compromised state.

The AVB2 Boot Flow in Detail

Let’s trace the typical AVB2 boot sequence:

1. Boot ROM: Executes immutable code, verifies the initial bootloader (ABL) using the hardware Root of Trust.
2. Android Bootloader (ABL):
• Verifies the signature of the vbmeta.img using an embedded OEM public key.
• If vbmeta.img is valid, it reads the verification data (hashes, public keys, anti-rollback counters) for critical partitions like boot.img, dtbo.img, etc.
• Verifies boot.img and dtbo.img against their respective hashes/signatures in VBMeta.
• If all critical partitions are valid, it proceeds to load the kernel.
3. Android Kernel:
• Upon starting, the kernel receives parameters from the bootloader, including the dm-verity root hashes for partitions like system.img and vendor.img.
• It configures the device-mapper to activate dm-verity for these partitions.
• During operation, any read from these partitions is transparently verified using their respective hash trees against the root hash provided by VBMeta.

If any verification step fails, AVB2 takes action. Depending on the failure and the device state (locked/unlocked), it might display a warning, prevent booting, or enter a recovery mode.

Customization and Development with AVB2

For developers and OEMs, interacting with AVB2 is critical. When a device is OEM Unlocked (e.g., via fastboot flashing unlock), AVB’s strict verification often shifts to a