Implementing Verified Boot (dm-verity) on Embedded Android IoT: A Step-by-Step Guide

Introduction to Verified Boot and dm-verity

In the rapidly expanding landscape of embedded Android IoT devices, ranging from smart home hubs to automotive infotainment systems, device integrity and security are paramount. Unsecured devices can be exploited, leading to data breaches, unauthorized access, or malicious system modifications. Android’s Verified Boot mechanism, with dm-verity at its core, provides a robust solution to these challenges, ensuring that the device boots with a trusted, untampered operating system.

Android Verified Boot (AVB) establishes a cryptographic chain of trust from the hardware root of trust all the way to the system partitions. dm-verity (device mapper verity) is a kernel feature that transparently verifies the integrity of block devices. It works by creating a hash tree for a given partition, where each block’s hash is stored in the tree, and the root hash of this tree is cryptographically signed and verified by the bootloader. If any block on the partition is modified, its hash will no longer match the pre-calculated hash in the tree, signaling a potential tampering attempt.

Why dm-verity is Indispensable for Embedded Android IoT

Protecting Against Runtime Tampering

Embedded IoT devices are often deployed in environments where physical access might be possible, or they might receive updates from potentially untrusted sources. Without mechanisms like dm-verity, an attacker could modify system binaries, libraries, or configuration files, potentially injecting malware or backdoors. dm-verity ensures that the system and other critical read-only partitions remain in their pristine, verified state during runtime. Any attempt to read a modified block will result in a verification error, which typically triggers a device reboot into recovery mode or prevents the partition from mounting.

Ensuring a Cryptographic Chain of Trust

The secure boot process begins with a hardware root of trust (e.g., fuses, ROM code) that verifies the initial bootloader. This bootloader, in turn, verifies the next stage, and so on, until the Android operating system itself is loaded. AVB, integrating dm-verity, extends this chain to the filesystem level. The bootloader verifies the vbmeta partition, which contains the root hashes and signatures for other critical partitions (like system, vendor, product). This ensures that every byte of the operating system is cryptographically validated before it’s used, preventing unauthorized firmware modifications even before the OS fully boots.

Prerequisites for dm-verity (via Android Verified Boot)

Kernel Configuration

To enable dm-verity, your Linux kernel must be configured with the necessary modules. This typically involves modifying your kernel’s defconfig file or using make menuconfig. The key configurations required are:

CONFIG_DM_VERITY=y: The core dm-verity device mapper target.
CONFIG_CRYPTO_SHA256=y: Required for the SHA256 hashing algorithm used by dm-verity.
CONFIG_DM_BUFIO=y: Device mapper buffer I/O support.
CONFIG_FS_VERITY=y: Filesystem verity support (though dm-verity operates at a lower block level, this is often a good practice).

You can verify these settings in your kernel’s .config file:

grep -E "CONFIG_DM_VERITY|CONFIG_CRYPTO_SHA256|CONFIG_DM_BUFIO|CONFIG_FS_VERITY" arch/arm64/configs/your_device_defconfig

Android Build System Setup (AOSP)

Implementing dm-verity with Android Verified Boot requires specific configurations within your device’s AOSP build environment, typically found in device/<vendor>/<device>/BoardConfig.mk or related `.mk` files. These flags instruct the build system to generate and sign the necessary verity metadata.

# Enable Android Verified Boot 2.0 (AVB)BOARD_AVB_ENABLE := true# Choose a strong signing algorithm. SHA256_RSA2048 is common, but SHA512_RSA8192 is more robust.BOARD_AVB_ALGORITHM := SHA256_RSA2048# Path to the signing key for system and other logical partitions. Use your own production keys.BOARD_AVB_SYSTEM_KEY_PATH := build/make/target/product/security/avb/testkey.pem# Rollback index. Increment this value for major security updates to prevent rolling back to older, vulnerable versions.BOARD_AVB_SYSTEM_ROLLBACK_INDEX := 0# Path to the signing key for the vbmeta image. Often the same as the system key.BOARD_AVB_VBMETA_KEY_PATH := build/make/target/product/security/avb/testkey.pem# Arguments for adding hashtree footer to vbmeta, typically setting verity mode to enforcing.BOARD_AVB_VBMETA_ADD_HASHTREE_FOOTER_ARGS :=     --hash_algorithm sha256     --additional_image_props "androidboot.veritymode=enforcing"# Add hashtree footers to critical read-only partitions. This enables dm-verity for them.BOARD_AVB_SYSTEM_ADD_HASHTREE_FOOTER_ARGS := --hash_algorithm sha256BOARD_AVB_VENDOR_ADD_HASHTREE_FOOTER_ARGS := --hash_algorithm sha256BOARD_AVB_PRODUCT_ADD_HASHTREE_FOOTER_ARGS := --hash_algorithm sha256# Include other custom read-only partitions if they require dm-verity protection.

Fstab Configuration

The device’s fstab file (e.g., device/<vendor>/<device>/fstab.<board>) needs to instruct init and fs_mgr to mount the specified partitions with `dm-verity` enabled. This is done by adding the `verify` flag to the mount options for critical partitions.

# fstab.your_device_board example/dev/block/by-name/system /system ext4 ro,barrier=1,wait,verify/dev/block/by-name/vendor /vendor ext4 ro,barrier=1,wait,verify/dev/block/by-name/product /product ext4 ro,barrier=1,wait,verify# Note: If you have /odm or /oem partitions that are read-only and static, add 'verify' for them too.

The `wait` option ensures that the block device is available before attempting to mount, while `verify` tells Android’s `fs_mgr` to set up the dm-verity device-mapper for that partition, using the metadata generated by AVB.

Building, Flashing, and Verifying Your dm-verity Protected Device

Building the AOSP Images

Once the `BoardConfig.mk` and `fstab` configurations are in place, the Android build system will automatically generate the dm-verity hash trees, embed them into the respective partition images, and sign the `vbmeta` image with the specified keys during the build process.

source build/envsetup.shlunch <device_target>make -j$(nproc)

After a successful build, you will find the generated images (e.g., `system.img`, `vendor.img`, `product.img`, `vbmeta.img`) in your `out/target/product/<device>/` directory.

Flashing to Your Embedded Device

Flashing these images onto your device is typically done via `fastboot`. Ensure your device’s bootloader is unlocked (if required) and in `fastboot` mode.

fastboot flash system system.imgfastboot flash vendor vendor.imgfastboot flash product product.imgfastboot flash vbmeta vbmeta.imgfastboot reboot

It is crucial to flash the `vbmeta.img` as it contains the root hashes and signatures that the bootloader uses to verify all other protected partitions. Without it, or if it’s outdated, the device may fail to boot or enter recovery.

Verifying dm-verity Protection

After flashing and booting the device, you can verify that dm-verity is active and enforcing. Connect via ADB and use the following commands:

adb shell getprop | grep verity# Expected output (may vary slightly by Android version/device):#[ro.boot.veritymode]: [enforcing]#[ro.vendor.verity.mode]: [enforcing]adb shell dmsetup info system_verity# Look for 'State: ACTIVE', 'Read-only: 1' to confirm dm-verity is active and protecting the system partition.

To truly test the integrity, you can attempt to tamper with a verified partition. This usually requires temporarily disabling AVB or having a test build. However, for a fully locked-down device, even attempting to remount `/system` as read-write will fail:

adb shell mount -o remount,rw /system# This command should fail with a
        
        
        
            
                
            
            
                Android Mobile Specs & Compare Directory
                Are you researching mobile hardware properties, processor SoCs, GPU chipsets, or RAM configurations? Access our complete specs catalog to compare up to 5 devices side-by-side!
                Compare Devices Specs →