Introduction

In the rapidly expanding landscape of embedded IoT, securing devices from tampering and unauthorized modification is paramount. Android Open Source Project (AOSP), while offering flexibility, requires careful hardening, especially at the boot level, to prevent malicious actors from gaining control. This expert-level tutorial delves into the intricate process of building a custom Verified Boot chain for AOSP on embedded IoT devices, guiding you from source compilation to a securely booted device. We will cover the foundational principles, the critical components like Android Verified Boot (AVB) 2.0 and dm-verity, and provide practical steps to implement a robust chain of trust.

Understanding Android Verified Boot (AVB)

Android Verified Boot is a security mechanism that ensures all executed code on a device comes from a trusted source, typically an OEM. It establishes a chain of trust starting from a hardware root of trust (RoT) and extends through the bootloader, boot partitions, and eventually the system partitions. If any stage of the boot process detects a modification, it can prevent the device from booting or flag it as compromised, protecting against various attack vectors including malware injection, rootkits, and unauthorized firmware updates.

The Chain of Trust

• Hardware Root of Trust (RoT): The immutable first stage, typically fused into the SoC, which verifies the initial bootloader.
• Bootloader: Verifies the integrity and authenticity of the boot image (kernel and ramdisk).
• Kernel: Once loaded, the kernel utilizes dm-verity to cryptographically verify the integrity of the system and vendor partitions as they are accessed.
• System Partitions: Verified on-the-fly by dm-verity, ensuring the core Android OS is untampered.

Prerequisites and Setup

Before embarking on building a custom verified boot chain, ensure you have the following:

• AOSP source code for your target embedded IoT device (e.g., a custom board, Raspberry Pi with AOSP port).
• A Linux-based build environment with sufficient resources.
• Familiarity with embedded systems, bootloaders (U-Boot, LK), and kernel configuration.
• Hardware access to your target device, including debugging interfaces (JTAG/SWD) for bootloader development.

Setting Up AOSP Build Environment

Follow the standard AOSP setup procedures:

sudo apt-get install git-core gnupg flex bison build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 libncurses5 lib32ncurses5-dev x11proto-core-dev libx11-dev libgl1-mesa-dev libxml2-utils xsltproc fontconfig imagemagickmkdir -p ~/aospcd ~/aosprepo init -u https://android.googlesource.com/platform/manifest -b android-12.0.0_r1repo sync -j8

Key Components of Verified Boot

Android Verified Boot 2.0 (AVB)

AVB 2.0 introduces a more flexible and robust signing scheme compared to its predecessor. It uses a vbmeta partition to store metadata about other partitions, including their hashes and signing public keys. This allows for rollback protection, preventing an attacker from flashing an older, vulnerable version of the OS.

Device Mapper Verity (dm-verity)

Dm-verity is a kernel feature that transparently verifies the integrity of block devices. It uses a cryptographic hash tree (Merkle tree) to ensure that every block read from a partition matches its expected hash. This protection extends to the file system, ensuring the system partition remains untampered throughout operation.

Implementing a Custom Verified Boot Chain

1. Configuring the Bootloader for Verified Boot

The bootloader is the first critical component in the chain of trust after the immutable RoT. You’ll need to modify your bootloader (e.g., U-Boot, Little Kernel) to incorporate AVB verification logic. This involves:

• Fusing the Root of Trust: This is hardware-specific. For most embedded SoCs, it involves “eFusing” the public key hash of your root signing key into the SoC’s immutable memory. This makes your device inherently trust your keys. Consult your SoC vendor’s documentation for exact procedures (e.g., NXP HAB, Qualcomm Secure Boot).
• Integrating AVB Libraries: Port AVB libraries into your bootloader. The AOSP source includes reference implementations. The bootloader will then read the vbmeta partition, verify its signature using the fused public key, and then use the verified vbmeta to check the integrity of the boot, system, and other critical partitions.

// Example U-Boot configuration snippet (simplified)#define CONFIG_AVB#ifdef CONFIG_AVB#define CONFIG_AVB_PUBLIC_KEY_PATH "/path/to/my_avb_pubkey.bin" // This should be fused#endif

2. Generating and Managing Signing Keys

AVB uses a set of cryptographic keys to sign images. You’ll typically have a root key, and potentially device-specific or partition-specific keys derived from it. Keep these keys secure!

# Generate a root key (e.g., 4096-bit RSA)openssl genrsa -out avb_root.pem 4096# Generate a partition key (e.g., for system image)openssl genrsa -out avb_system.pem 2048# Extract public keys for embedding (if needed)avbtool extract_public_key --key avb_root.pem --output avb_root_pubkey.bin

3. Configuring AOSP for AVB Signing

Modify your device’s BoardConfig.mk or device.mk files to enable AVB and specify your keys:

# Enable Android Verified Boot 2.0BOARD_AVB_ENABLE := true# Specify the algorithm (SHA256_RSA4096 is recommended for root)BOARD_AVB_ALGORITHM := SHA256_RSA4096# Path to your root signing keyBOARD_AVB_KEY_PATH := device/<vendor>/<device>/security/avb_root.pem# Public key for vbmeta verification in the bootloaderBOARD_AVB_VBMETA_PUBLIC_KEY_PATH := device/<vendor>/<device>/security/avb_root_pubkey.avbpubkey# Rollback index to protect against flashing older imagesBOARD_AVB_ROLLBACK_INDEX := 1# Arguments for generating the vbmeta imageBOARD_AVB_MAKE_VBMETA_IMAGE_ARGS :=     --set_hashtree_disabled_flag     --padding_size 4096     --hash_algorithm sha256     --algorithm $(BOARD_AVB_ALGORITHM)     --key $(BOARD_AVB_KEY_PATH)     --rollback_index $(BOARD_AVB_ROLLBACK_INDEX)# Define partitions to be signedBOARD_AVB_BOOT_ADD_HASHTREE_FOOTER_ARGS := --hash_algorithm sha256BOARD_AVB_SYSTEM_ADD_HASHTREE_FOOTER_ARGS := --hash_algorithm sha256BOARD_AVB_VENDOR_ADD_HASHTREE_FOOTER_ARGS := --hash_algorithm sha256# Add more partitions as needed

After configuring, build your AOSP images:

source build/envsetup.shlunch <your_device_target>-userdebugmake -j$(nproc)

This process will automatically sign your boot.img, system.img, vendor.img, and generate a vbmeta.img.

4. Integrating dm-verity into the Kernel

Ensure your kernel is compiled with dm-verity support. Check your kernel’s .config or configure it manually:

CONFIG_DM_VERITY=yCONFIG_DM_VERITY_FEC=y # Optional: For forward error correction

Your device’s fstab.qcom (or equivalent) in AOSP will typically include verify options for relevant partitions. For example:

/dev/block/platform/<soc>/by-name/system    /system    ext4    ro,barrier=1,verify    wait,avb=vbmeta/dev/block/platform/<soc>/by-name/vendor    /vendor    ext4    ro,barrier=1,verify    wait,avb=vbmeta

The avb=vbmeta option instructs the kernel to look for verity metadata within the vbmeta partition.

Testing and Validation

After flashing your custom images to the device:

1. Check AVB state:

   adb shell avbctl get_state

   This should report locked for production devices, indicating Verified Boot is active. During development, it might be unlocked or orange, which is fine for testing.

2. Tampering Test:

   Attempt to modify a system file directly on the device (e.g., via adb root, adb disable-verity if unlocked, then adb remount, and try changing a binary). Then reboot. The device should fail to boot or show a warning.

   # On a test device (with adb root and unlocked AVB for testing purposes)adb shellsu mount -o remount,rw /systemecho "MALICIOUS CODE" >> /system/bin/app_process64reboot

   Upon reboot, if Verified Boot is properly implemented and locked, the device should enter a recovery state or fail to boot the tampered system.

3. Rollback Protection Test:

   If you build an image with a lower BOARD_AVB_ROLLBACK_INDEX and attempt to flash it, the bootloader should prevent it if the device’s stored rollback index is higher.

Challenges and Considerations

• OTA Updates: A custom verified boot chain requires careful planning for Over-The-Air (OTA) updates. The update mechanism must also be aware of the signing keys and potentially update rollback indices.
• Key Management: Securing your signing keys is paramount. A compromise of these keys renders your verified boot chain useless. Implement robust key management practices (e.g., Hardware Security Modules – HSMs).
• Performance: dm-verity adds a slight overhead due to cryptographic operations. Ensure your hardware can handle this without significantly impacting user experience.
• Debugging: Debugging boot failures in a locked verified boot environment can be challenging. Plan for debug partitions or alternative boot modes.

Conclusion

Building a custom verified boot chain for AOSP on embedded IoT is a complex yet crucial step towards securing your devices in a hostile environment. By meticulously configuring the bootloader, properly managing cryptographic keys, enabling AVB 2.0 and dm-verity, and rigorously testing the implementation, you can create a robust chain of trust. This ensures the integrity and authenticity of your device’s software from the very first instruction executed, safeguarding against unauthorized modifications and providing a solid foundation for secure IoT deployments.