Secure boot establishes a full chain of trust starting from a hardware-protected root of trust to the bootloader, the boot partition, and other verified partitions including system, vendor, and (optionally) oem partitions. During device boot, each stage verifies the integrity and authenticity of the next stage before handing over execution.
Secure boot requires the authenticity of all firmware code and data to be cryptographically verified before it is booted. This includes the kernel (loaded from the boot partition), the device tree (loaded from the dtbo partition), the system partition, the vendor partition, and so on.
Secure boot flow for a device is as follows:
1. Bootloader authentication
After power-on, the processor ROM loader validates U-Boot and Trusty OS with the AHAB and the value in the OTP SRK efuses (see Bootloader image authentication overview). The ROM loader only executes U-Boot and Trusty OS if they are validated successfully; otherwise, the boot is aborted.
The bootloader artifact includes U-Boot and Trusty OS. This image must be signed with a PKI (Public Key Infrastructure) tree after building. See 5. Sign the bootloader images.
The hash of the public key is programmed in the SRK OTP bits on the device (see 7. Secure the device). This allows the ROM loader to validate the public key included in the signed booloader image (see Bootloader image authentication overview).
2. Trusty initialization
After bootloader validation and execution, Trusty initializes the "secure world" and the trusted applications (avc, hwcrypto, trusty_gatekeeper). Trusty checks the access to the Replay Protected Memory Block (RPMB) secure storage to get required data to continue with the boot process.
Trusty TEE
A Trusted Execution Environment (TEE) is a system that applies levels of trust to code and data, guaranteeing their confidentiality and integrity. In general terms, the TEE offers an execution space that provides a higher level of security for trusted applications (TAs) running on the device.
Trusty is a secure Operating System (OS) that provides a TEE for Android. The Trusty OS runs on the same processor as the Android OS, but Trusty is isolated from the rest of the system by both hardware and software. Trusty and Android run parallel to each other. Trusty has access to the full power of a device’s main processor and memory but is completely isolated. Trusty’s isolation protects it from malicious apps installed by the user and potential vulnerabilities that may be discovered in Android.
On ARM processor, Trusty relies on ARM Trustzone™ to virtualize the main processor and create a secure Trusted Execution Environment.
| For more information, see Trusty TEE. |
Replay Protected Memory Block (RPMB) secure storage
RPMB is a separate physical partition in the eMMC device designed for secure data storage. Every access to RPMB is authenticated, which allows the system to store or retrieve data in an authenticated and replay-protected manner. Before accessing RPMB, you must program an RPMB authentication key. See 8. Initialialize the secure storage for Trusty OS.
3. VBMeta verification
VBMeta is signed by the host with the AVB (Android Verified Boot) private key during the build process.
The public part of the AVB key needs to be available to authenticate VBMeta image at runtime. The public key is stored in the RPMB secure storage.
Trusty accesses Replay Protected Memory Block (RPMB) secure storage to get the AVB (Android Verified Boot) public key and uses it to verify the VBMeta image.
|
For more information, see: |
4. Linux kernel validation
U-Boot validates the Linux kernel (in boot partition) and device tree (in dtbo partition) with the data inside VBMeta before jumping to the Linux kernel. They are verified by loading the entire contents into memory and then calculating its hash. This calculated hash value is compared to the expected hash value. If the value does not match, Android does not boot.
VBMeta image
The Android partition table has a vbmeta partition that contains a VBMeta image. This image contains verification data (e.g. cryptographic digests) for verifying required Android images to boot (boot, dtbo, and vendor_boot).
The central data structure used in AVB is the VBMeta struct. This data structure contains a number of descriptors and other metadata. Descriptors are used for image hashes, image hash tree metadata, and so-called chained partitions.
vbmeta partition holds:
-
The hash for the boot partition in a hash descriptor. Boot image is built as a chained partition, so it includes its VBMeta struct signed by the AVB boot key.
-
For the system and vendor partitions, vbmeta partition holds the root hash, salt, and offset of the hash tree in hash tree descriptors, while the hash tree follows the data of each partition.
| For more information about the VBMeta struct, see The VBMeta struct. |
After verifying VBMeta image, its content is used to verify the rest of the boot images. Because the VBMeta struct in the vbmeta partition is cryptographically signed, U-Boot can check the signature and verify it was made by the owner of AVB key (by embedding the public part of AVB key) and thereby trust the hashes used for boot, system, and vendor.
5. File system integrity check
dm-verity checks the integrity of the partitions at mount. Data access from Android file system will be verified by dm-verity to assure integrity.
Large partitions that do not fit into memory, such as, file systems, use a hash tree where verification is a continuous process happening as data is loaded into memory. In this case, the root hash of the hash tree is calculated during run time and is checked against the expected root hash value. If at some point the calculated root hash does not match the expected root hash value, the data is not used and Android enters an error state.
dm-verity
The Device Mapper verity (dm-verity) kernel feature supports transparent integrity checking of block devices. This allows the user to be sure that when booting a device, it is in the same state as when it was programmed. The vbmeta partition contains required metadata (hash tree descriptors: root hash, salt, and offset of the hast tree) for the dm-verity check for system, system_ext, vendor, and product partitions. When dm-verity is enabled, any operation that breaks the consistency of the images programmed in the partitions causes a dm-verity check failure, and thus a system boot failure.
| For more information, see Implementing dm-verity. |
