Introduction: The Imperative of Verified Boot

In the rapidly evolving landscape of Android IoT, Automotive, and Smart TV devices, security is not merely a feature; it’s a foundational requirement. As these devices become integral to our daily lives, controlling critical infrastructure and handling sensitive data, ensuring their integrity from the moment they power on is paramount. This is where Android’s Verified Boot and Device Mapper Verity (DM-Verity) come into play. For new System-on-Chips (SoCs) and custom hardware platforms, integrating these security mechanisms correctly, particularly through the Android Device Tree, is a complex yet crucial endeavor.

Verified Boot establishes a chain of trust from the hardware root of trust up to the system partition, ensuring that every stage of the boot process is verified before execution. DM-Verity, a core component of Verified Boot, specifically focuses on preventing persistent rootkits and malware by cryptographically verifying the integrity of block devices (like system, vendor, or product partitions) at runtime. This guide provides an expert-level, step-by-step approach to implementing Verified Boot and DM-Verity for new SoCs by leveraging Android Device Tree configurations.

Understanding Android Device Tree (DT) and its Role

The Android Device Tree (DT) is a data structure that describes the hardware components of a system, enabling the kernel to configure itself without hardcoding device-specific information. For new SoCs, developing a custom DT is often one of the first and most critical steps in porting Android. It allows for flexible hardware definition, from CPU cores and memory maps to peripheral devices like I2C, SPI, and GPIOs. In the context of Verified Boot and DM-Verity, the DT can specify properties and configurations that inform the bootloader and kernel about the integrity verification process, including where to find verification keys or specific hardware-backed security features.

DM-Verity: Ensuring Data Integrity

DM-Verity operates by creating a hash tree for each protected partition. The root hash of this tree is signed with an OEM-specific key. During boot, the bootloader verifies the root hash. Once the system is running, the kernel’s DM-Verity module verifies data blocks on demand. If any block has been tampered with, its hash will not match the expected value in the hash tree, leading to an error. This prevents attackers from modifying system binaries, libraries, or configurations after the bootloader has completed its initial checks, providing robust protection against offline and online attacks targeting the filesystem integrity.

Implementing Verified Boot & DM-Verity in Your Device Tree

Integrating Verified Boot and DM-Verity for a new SoC requires careful coordination between kernel configuration, device tree definitions, and the Android build system. Here’s a detailed walkthrough:

Step 1: Prerequisites and Development Environment Setup

Before diving into the configurations, ensure you have a properly set up Android Open Source Project (AOSP) build environment, including your custom kernel source, the appropriate toolchains, and a working device tree source (DTS) for your new SoC. Familiarity with device tree syntax and the Android build system (`BoardConfig.mk`, `Android.mk`) is essential.

Step 2: Kernel Configuration for DM-Verity

The Linux kernel must be compiled with the necessary DM-Verity support. Navigate to your kernel source directory and configure it (e.g., using `make menuconfig` or by directly editing `.config`). Ensure the following options are enabled:

CONFIG_DM_VERITY=y
CONFIG_DM_VERITY_FEC=y # Optional: Forward Error Correction for DM-Verity
CONFIG_FS_VERITY=y # For file-based verity (Android 10+)
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_CTS=y
CONFIG_CRYPTO_ECB=y
CONFIG_CRYPTO_AES=y
CONFIG_BLK_DEV_DM=y

Step 3: Device Tree Source (DTS) Modifications

While the Android build system typically handles the generation of verity metadata and signing, certain aspects, especially for newer hardware or specific bootloader interactions, might benefit from Device Tree properties. For instance, you might define unique identifiers or hardware-backed key paths. A crucial component for Verified Boot is often the `android,verified-boot` property within your `chosen` node, or specific properties passed to the bootloader via FDT (Flattened Device Tree). For direct DM-Verity configuration through the device tree, while less common for the main `system` partition (which is handled by `fs_mgr`), you might specify partitions or hardware-specific details if your bootloader requires them or if you have custom trusted partitions.

For example, if your bootloader requires specific flags or a path to a hardware-backed key for initial root hash verification, you might add something like this (highly dependent on SoC and bootloader implementation):

/ {
    chosen {
        bootargs = "console=ttyS0,115200 androidboot.verifiedbootstate=orange"; // Example bootargs
        android,verified-boot = ;
    };

    verified_boot_config: verity-config {
        compatible = "android,verified-boot-v1";
        avb-pubkey-path = "/firmware/avb_pkmd.bin"; // Path to AVB public key metadata
        avb-rollback-index = <0>;
        // Other OEM/SoC specific verity configuration
    };
};

However, the primary integration of DM-Verity and AVB (Android Verified Boot) is usually managed via the Android build system for partitions like `system`, `vendor`, `product`, and `boot` image integrity.

Step 4: Integrating Verity Keys into the Build System

The Android build system (`BoardConfig.mk`) is where you enable and configure AVB. You’ll need to define your signing keys and specify how partitions should be verified.

First, generate your AVB keys. You can use the `avbtool` from AOSP:

$ avbtool generate_key --output avb_pkmd.bin --key pkmd.pem --algorithm SHA256_RSA4096

Then, add the following to your device’s `BoardConfig.mk`:

# Enable Android Verified Boot 2.0
BOARD_AVB_ENABLE := true
BOARD_AVB_ALGORITHM := SHA256_RSA4096
BOARD_AVB_KEY_PATH := device/<vendor>/<device>/avb_pkmd.pem
BOARD_AVB_ROLLBACK_INDEX := 0 # Increment for OTA updates to prevent downgrade attacks
BOARD_AVB_RECOVERY_KEY_PATH := $(BOARD_AVB_KEY_PATH)

# Define partitions to be verified by AVB
BOARD_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)
BOARD_AVB_PRODUCT_ADD_HASHTREE_FOOTER_ARGS := 
    --hash_algorithm sha256 --rollback_index $(BOARD_AVB_ROLLBACK_INDEX)

# Optional: Specify different algorithm/key for different partitions
# BOARD_AVB_SYSTEM_ALGORITHM := SHA512_RSA8192
# BOARD_AVB_SYSTEM_KEY_PATH := device/<vendor>/<device>/system_avb.pem

Place your generated `avb_pkmd.pem` key at the specified `BOARD_AVB_KEY_PATH` in your device tree configuration directory.

Step 5: Partition Layout and Signing

The `system`, `vendor`, `product`, `boot`, and `dtbo` (Device Tree Blob Overlay) partitions are typically signed. The Android build system, upon enabling AVB, automatically integrates the necessary verity metadata (hash trees and signatures) into the images during compilation. For example, `system.img` will have an appended verity footer. The bootloader is then responsible for reading this footer, verifying its signature against the OEM’s public key (often fused into hardware or securely stored), and then using the verified root hash to initialize DM-Verity for the respective partition.

Ensure your `fstab` entries for the root filesystem (e.g., `system`, `vendor`) include the `verify` flag or `avb` flag:

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

Step 6: Bootloader Integration

The bootloader plays the critical role in establishing the initial chain of trust. It must be capable of:

• Loading the AVB public key(s).
• Verifying the `boot.img` signature (and its embedded `dtb` if applicable).
• Passing the verified boot state (green, yellow, orange, red) to the kernel via `androidboot.verifiedbootstate` in the kernel command line.
• Loading the `dtbo.img` (if used) and passing the combined DT to the kernel.
• Informing the kernel about the verified root hash for partitions like `system` and `vendor`.

The specifics of bootloader integration are SoC-dependent and outside the scope of direct Android Device Tree modification for the kernel itself, but it’s crucial to ensure your custom bootloader is properly configured to use the AVB public key and enforce the verification chain.

Verifying Your Implementation

After building and flashing your custom Android image, you can verify the status of Verified Boot and DM-Verity on the device using `adb`:

$ adb shell getprop ro.boot.verifiedbootstate
# Expected output: green (if fully verified), yellow (if unlocked), orange (if custom OS), red (if tampered/failed verification)

$ adb shell dmctl verity get-root-hash
# Expected output: A SHA256 hash value for verified partitions

$ adb shell su -c 'mount | grep verity'
# Expected output showing mounts with 'dm-verity' or 'fs-verity' options

$ adb shell su -c 'cat /proc/cmdline | grep androidboot.verifiedbootstate'
# Expected to show the boot state passed from the bootloader

You can also try intentionally tampering with the `system.img` (e.g., modifying a binary) before flashing to observe the boot failure or