Introduction to Android Verified Boot (AVB)

Android Verified Boot (AVB) is a critical security feature designed to ensure the integrity of the operating system and protect users from malware and unauthorized modifications. At its core, AVB establishes a chain of trust from a hardware root of trust up through the bootloader, boot partition, and finally to the system and vendor partitions. This guide delves into the nuances of hardening AVB in custom AOSP implementations, offering expert insights and best practices for developers and system integrators.

Understanding and correctly implementing AVB is paramount for maintaining device security, especially in embedded systems, enterprise devices, or any scenario where system integrity is non-negotiable. We’ll explore how AVB works, how to properly sign custom AOSP builds, manage keys, and implement robust security policies to mitigate common attack vectors.

Understanding the Android Verified Boot Chain

The AVB mechanism operates on a cryptographic chain of trust. This chain begins with an immutable Root of Trust (RoT), typically residing in hardware (e.g., eFuses or a Hardware Security Module – HSM) within the System-on-Chip (SoC).

The Chain of Trust

1. Hardware Root of Trust: The very first code executed by the SoC (ROM Bootloader) verifies the authenticity and integrity of the next stage bootloader using public keys stored in the RoT.
2. Bootloader Verification: The verified bootloader then verifies the integrity of the boot.img partition, which includes the kernel and ramdisk. This is typically done using the vbmeta.img, which contains cryptographic metadata for other partitions.
3. Partition Verification (dm-verity): Once the kernel is loaded, dm-verity (device mapper verity) ensures the integrity of read-only partitions like system, vendor, and product in real-time. Any unauthorized modification to these partitions will trigger a verification failure, preventing the system from booting or operating correctly.

Key tools involved in AVB include avbtool for image signing and key management, and dm-verity for runtime integrity checking.

Custom AOSP Implementations: Signing and Configuration

Implementing AVB for a custom AOSP build involves careful configuration of the build system and proper key management. The goal is to sign all critical partitions with your own keys, ensuring that only your trusted builds can boot on the device.

1. Generating Custom AVB Keys

First, you need to generate a set of RSA key pairs that will be used to sign your images. It’s recommended to use a strong key size, such as 4096 bits.

avbtool generate_key --output_key avb_pkmd.pem --output_public_key_metadata avb_pkmd.bin --algorithm RSA4096 --salt 00000000000000000000000000000000

Store the avb_pkmd.pem private key securely. The avb_pkmd.bin public key metadata will be embedded into your bootloader or vbmeta for verification.

2. AOSP Build System Configuration

Modify your device’s BoardConfig.mk file to enable AVB and specify your custom keys:

# Enable AVB 2.0 (Required for Android 9 and above)DEVICE_GENERATE_AVB_KEYS := trueBOARD_AVB_ENABLE := true# Specify your custom signing keyBOARD_AVB_ALGORITHM := RSA4096BOARD_AVB_KEY_PATH := device/<vendor>/<device>/avb_pkmd.pemBOARD_AVB_ROLLBACK_INDEX := 1# Optional: Set rollback indices for specific partitions if neededBOARD_AVB_VBMETA_SYSTEM_VERSION := 1BOARD_AVB_VBMETA_VENDOR_VERSION := 1# Specify partitions to be signed and their hash algorithmBOARD_AVB_BOOT_ADD_HASHTREE_FOOTER_ARGS := 
--hash_algorithm sha256 
--rollback_index $(BOARD_AVB_ROLLBACK_INDEX)BOARD_AVB_SYSTEM_ADD_HASHTREE_FOOTER_ARGS := 
--hash_algorithm sha256 
--rollback_index $(BOARD_AVB_ROLLBACK_INDEX)BOARD_AVB_VENDOR_ADD_HASHTREE_FOOTER_ARGS := 
--hash_algorithm sha256 
--rollback_index $(BOARD_AVB_ROLLBACK_INDEX)# Add other critical partitions as needed, e.g., product, odm, etc.BOARD_AVB_CUSTOM_IMAGE_SIGNING_ARGS := boot system vendor

After configuring, rebuild your AOSP images (e.g., make -j$(nproc)). The build system will automatically use avbtool to sign the specified partitions and generate the necessary vbmeta.img.

3. Flashing and Bootloader Locking

Once your custom images are built and signed, flash them to your device:

fastboot flash boot boot.imgfastboot flash system system.imgfastboot flash vendor vendor.imgfastboot flash vbmeta vbmeta.img

Crucially, after flashing, **relock the bootloader** to enable full AVB protection. This is typically done via:

fastboot flashing lock

Note: The exact command might vary depending on your device’s bootloader. Relocking is essential; an unlocked bootloader disables AVB, allowing unsigned or tampered images to boot.

Best Practices for Hardening AVB

1. Secure Key Management

The private keys used for signing are the cornerstone of your AVB security. Any compromise of these keys allows an attacker to sign malicious images that your device will trust.

• Offline Storage: Store private keys on air-gapped systems or hardware security modules (HSMs).
• Access Control: Implement strict access controls for systems with access to signing keys.
• Key Rotation: Periodically rotate signing keys, especially if there’s any suspicion of compromise.

2. Enforce Strict Bootloader Lock Policy

Always relock the bootloader on production devices. An unlocked bootloader renders AVB ineffective. Ensure your device’s bootloader properly reflects its state (LOCKED/UNLOCKED) and reacts accordingly by enforcing AVB when locked.

3. Rollback Protection

AVB includes rollback protection to prevent an attacker from flashing an older, potentially vulnerable version of the OS. This is managed by rollback indices within the vbmeta and partition footers. Incrementing BOARD_AVB_ROLLBACK_INDEX (or specific partition versions) during updates ensures that older images with lower indices are rejected. Do not downgrade these indices.

4. Comprehensive Partition Coverage

Ensure that all critical read-only partitions are part of the AVB chain. Beyond boot, system, and vendor, consider product, odm, and any other partitions that contain system-critical binaries or libraries. Each unsigned partition represents a potential vulnerability.

5. Monitor and Alert for Verification Failures

Implement mechanisms to detect and report AVB verification failures. On a failed boot, the device typically enters a degraded state or displays an error message. For forensic analysis, monitor kernel logs (e.g., dmesg) for dm-verity errors. These failures can indicate tampering or corrupted storage.

6. Physical Device Security

While AVB protects against software-level tampering, physical access can still pose a threat. Complement AVB with robust physical security measures, especially for sensitive deployments. An attacker with physical access might bypass AVB if they can manipulate the hardware RoT or exploit vulnerabilities in the bootloader’s unlock mechanism.

7. Utilize Chained Partitions

For more complex configurations, AVB supports ‘chained partitions’, where one vbmeta image can point to another vbmeta image on a different partition. This is useful for modular builds (e.g., separate OEM and carrier customizations) where different entities might sign different parts of the OS.

# Example for a chained vbmeta partition (e.g., vbmeta_vendor)BOARD_AVB_VBMETA_VENDOR_ADD_HASHTREE_FOOTER_ARGS := 
--setup_as_root_of_trust 
--signing_key path/to/vendor_key.pem 
--signing_algorithm RSA4096

Conclusion

Hardening Android Verified Boot is an indispensable step in securing custom AOSP devices. By meticulously managing signing keys, enforcing bootloader lock policies, implementing rollback protection, and ensuring comprehensive partition coverage, developers can significantly enhance the integrity and trustworthiness of their Android systems. AVB provides a robust foundation for device security, but its effectiveness relies heavily on proper implementation and ongoing adherence to best practices. A proactive approach to AVB security will safeguard devices against a wide array of threats, from casual tinkering to sophisticated attacks.