Android Verified Boot

Android started as a mobile phone operating system has widespread adoption and is running on more and more embedded devices of all kinds. This adoption has high demands placed on security at different levels starting from boot loader to system. Android verified boot addresses these exact security issues by establishing a chain of trust from the bootloader to the system image.

Secure booting

Android verified boot happens in two steps – Secure booting and system image verification. This section speaks about secure booting.

When you build the bits from Android AOSP source you will find the boot image with the file name boot.img. These boot images hold a signature block at the end of the image. When these images are flashed and run on a device, the bootloader verifies these signature using a key that is stored in a secure keystore on the device. OEM’s can ship their keys on the device by publishing them into the keystore with a signing mechanism.

An Android bootloader in run-time can have three states: Locked, Verified, Unlocked.

Closed devices are generally shipped with bootloader in locked state. In this state no images can be flashed or erased using Fastboot tool. Boot and recovery images are verified by the bootloader using the keystore while booting.

Verified bootloader state configurations are used when some partitions are required to be flashed or erased using Fastboot tool. Still the boot and recovery images are verified by the bootloader using an enrolled keystore.

If the bootloader is configured as unlocked a user can exercise all Fastboot commands.

The user experience on the device because of bootloader configured in a particular way and its check failures are shown below:

Boot Orange

Boot Yellow

Boot Red

Secure System Image

Android uses cryptographic hash trees involving leaf nodes, intermediary nodes and root hash. The root hash is signed with a certificate stored in the boot image ramdisk. dm-verity is a tool available in android that can be configured to verify images that get loaded into memory. Images like system, vendor can be provisioned to dm-verity while building Android for tamper checks during run time. dm-verity can be provisioned for user and user debug Android builds.

As dm-verity integrity checks are based on block level root hashes, OTA upgrades on such systems need to take place at block level than per file basis.

The build option for dm-verity is shown below for reference, the default option is enabled:


e-consystems an expert in embedded Android devices can support you with boot time optimization, customizing your Android device images and Android OTA.

Please visit our developer website to download detailed instructions to build, deploy and run Android on eSOMiMX6 devices.

Interested in off the shelve solution for Android OTA for your embedded device visit: we can customize it for you.

For further assistance and queries get in touch with