Android verified boot within the boot sequence

Question

I'm interested in understanding the verified boot process in Android, yet I was unable to find insights about some properties of the process.

From what I gathered so far I get that in Android devices the verified boot process is supported using dm-verity, which checks signed hashes of the memory blocks in which the OS to be loaded is located. Also, most (if not all) of current ARM processors based devices has the TrustZone feature which is used to create the so called "Secure World" and "Unsecure World".

What I'm trying to understand is how all this is wrapped up:

1. When in the Android boot process does dm-verity run?
2. Does the dm-verity run from within the "Secure World"? If so how the "Secure World" OS loading is verified?
3. When in the boot process is the first time that the TrustZone "worlds" feature is accessed/activated?

Answer 1

AVB is enforced by the bootloader and dm-verity is enforced by the kernel. Both run consecutively in android boot flow.

In factory:

1. OEM constructs hashtree of /system, /vendor, product and ODM partitions. Hashtree is not constructed for /boot and /vbmeta partitions.

2. In vbmeta partition, OEM writes hash descriptor of boot image which contains hash of boot image. OEM also writes hash descriptors of other partitions which contains root hash & salt of hashtree.

3. OEM signs vbmeta using OEM private key and appends its signature to vbmeta image itself. The OEM public key is hardcoded in android bootloader (ABL) at build time.

On boot:

1. ABL verifies signature on vbmeta using OEM public key.

2. ABL calculates hash of boot image as it loads and verifies it with the one stored in vbmeta.

3. After boot.img (contains kernel) is verified, the kernel is loaded and kernel starts dm-verity.

4. Kernel reconstructs hashtree of every partition except /boot and compares their root hash with the one stored in vbmeta.

5. If all hashes match, device boots to lock screen.

Chain partition is used for delegate authority like in case of enterprise devices and carrier devices. If an enterprise wants to include additional partitions, vbmeta for chain partition is stored in the footer or if there are multiple chain partitions, a separate vbmeta_enterprise that verifies all chain partitions can be created. It is signed by the private key (key1) of enterprise. The public key (key1_pub) is then stored in original vbmeta partition. This delegate authority can be easily revoked by simply updating original vbmeta image with new descriptors of the chain partitions and removing the public key key1_pub.

The chain of trust for AVB starts from ABL so it's possible to replace OEM public key with your own and re-sign vbmeta by following the same process as done by OEM. To protect ABL from tampering, production SoCs enforce secure-boot. To enable secure boot, production devices have their eFuse blown in the factory and it's irreversible. Fastboot unlock and unlock_critical commands do not turn off secure boot. Even a fastboot command can blow the eFuse of prototype devices which permanently enables secure boot of SoC.

fastboot oem SecureBoot EnableFuse

In Qualcomm Snapdragon SoCs, ABL is verified by Xtended Bootloader (XBL) and XBL is verified by Primary Bootloader (PBL). PBL is burned on CPU die and its public key is stored in eFUSE and thus making it tamper-resistant. Trusted Execution Environment (TEE) is not verified by AVB. It is verified by XBL_SEC (Xtended Bootloader Secondary) which is another bootloader verified by PBL. TEE image is double signed by the chipmaker and OEM. TEE is awaken by XBL_SEC at the same time when XBL loads ABL as shown in picture.

---

Android Verified Boot 2.0

Android verified boot 2.0 vbmeta data structure analysis

Analysis of Qualcomm Secure Boot Chains

Qualcomm’s Chain of Trust

Secure Boot and Image Authentication (pdf)

Answer 2

I know it is old question but anyways here some answers since the official documentation is lacking many important details:

Documentation to AVB can be found on the Google developers site and the official code repository.

When in the Android boot process does dm-verity run?

dm-verity is a kernel extension and runs when the partitions are mounted and during runtime. However, the Android Verified Boot process starts before the kernel is loaded. To be more precise, the ROM bootloader of your device verifies the integrity of the kernel (boot.img) before loading it and therefore prevents the kernel to be corrupted. As soon as the kernel is loaded dm-verity comes into action. You should know that the implementation of the Verified Boot is customised by every vendor. For example, Huawei and Samsung use their own implementations.

Does the dm-verity run from within the "Secure World"? If so how the "Secure World" OS loading is verified?

As mentioned dm-verity is a kernel extension and runs on kernel level and the Arm TrustZone is security extension of your CPU and runs before the kernel is loaded. The TrustZone operates on the hardware level and products like Samsung Knox use the Arm TrustZone to do real-time kernel verification. dm-verity itself does not need to run within TrustZone but it is possible that custom implementations of dm-verity use the TrustZone for cryptographic operations. For example, Samsungs uses the TrustZone for key attestation.

TrustZone is not directly part of the Android Verified Boot since it is a commercial product. It is used by companies like Samsung for additional verification of the kernel during boot phase as well as runtime. It is not necessary or mandatory for Android Verified Boot. The boot process in general with AVB can be summarised like this:

1. ROM bootloader verifies signature of flashable bootloader.
2. The flashable bootloader verifies signature of vbmeta.img, boot.img and other partitions and loads the kernel. Optional: Vendor specific checks are done before the kernel is loaded or the device specific TEE OS is initialised.
3. The kernel is loaded from boot.img and dm-verity checks the integrity of the partitions at mount and during the runtime of the kernel.

When in the boot process is the first time that the TrustZone "worlds" feature is accessed/activated?

As mentioned before, according to wikipedia TrustZone is closed source and we do not know when in the boot process it is available exactly. However, usually Trusted Execution Environments are loaded before the operating system. For example, Huawei loads it's TEE after the flashable bootloader was loaded. In such cases every component just validates the integrity of the next one and builds a key-chain.