Android Verified Boot (AVB) is a feature that ensures the integrity and security of Android devices. In a previous post, we already talked about the various security features of this platform such as Android TEE. AVB safeguards the system boot process to protect the device against malicious attacks, modifications, and vulnerabilities. It is an integral part of secure embedded systems based on Android. Understanding this Android security feature and how it contributes to the overall security is essential for developers.
In this article, we’ll explain what Android Verified Boot is, how it works, and how it differs from Secure Boot. We’ll also outline why it is important to use AVB, and present common troubleshooting scenarios for Android secure boot processes developers encounter.
Source: Own illustration
A verified boot is an essential mechanism to protect Android devices. Android Verified Boot is maintained by the Android Open Source Project (AOSP) and was introduced in Android 4.4. The most recent version is AVB 2.0, which we’ll focus on.
In general, the Android secure boot process is based on cryptographically signed partitions. It is worth noting that—as with all cryptography—the solution is only as safe as the keys used. It is essential to use a suitable and sufficient key pair to sign components and store them safely. Otherwise, malicious actors can sign their components, undermining the entire process.
During the verified boot process, partition hashes must be signed. These signatures are also checked during boot to ensure each part is integer before loading.
Let’s take a look at the relevant steps in the boot process:
Bootloader
Every device—when powered on—starts with the bootloader. Acting as the initial element in the boot sequence, the bootloader starts up the hardware and loads the operating system.
Verifying boot partition
During this stage, the bootloader authenticates the signature of each component in the boot partition, which includes the kernel and ramdisk. This way a trusted chain of components is created. The complete boot partition undergoes hashing, and the resulting hash is authenticated. The bootloader then verifies this signature with the public key to guarantee the boot partition's integrity.
Verifying system partition
The system partition holds the Android Framework and system applications. A hash tree (Merkle tree) is utilized to manage this larger partition more effectively instead of hashing the entire partition, which would be too time-consuming. Verification of the hash tree's signature occurs instantly. Each data block from this partition is hashed and verified as the system accesses it. In case of incorrect hash values, the process immediately stops, preventing the execution of possibly compromised data.
Verifying other (vendor) partition
Most boot sequences also include vendor partitions. While these partitions are optional, they are also part of the verified boot process. In fact, at emteria we’ll add our own signed partitions to the verified boot process. By doing so, vendor partitions extend the general boot sequence in a safe and traceable manner. These optional partitions follow the same hashing method as the system partition to ensure fast verifications.
Booting OS
The operating system will boot once all verifications are completed. The device is now usable and is considered safe.
If these steps are followed, the boot process will ensure a safe and reliable start and protect the device from a range of potential threats.
Android Verified Boot offers several advantages over the regular boot process. AVB contributes to the overall integrity and reliability of devices. Here are some important reasons why developers should use AVB:
The bootloader ensures that trusted and verified code is executed during device startup. The kernel detects any unauthorized modification on the partitions by using the signatures and public keys. This verification leads to a comprehensive chain of trust during the boot sequence and thus prevents compromising activities. This reduces the attack surface on the OS level by preventing common vectors for malware and rootkits.
Besides the chain of trust, Android Verified Boot will prevent malicious actors from exploiting past vulnerabilities through rollback protection. This has been an issue but is resolved through the verification process and one-way upgrades introduced in Android 13.
With AVB enabled, users are getting an interpretable state of their device. The AOSP uses different state codes and additional information to communicate out-of-order boot processes.
The boot flow includes green, yellow and orange device states. Yellow and orange are warnings:
YELLOW: Warning for locked devices with customization
ORANGE: Warning for unlocked devices
Using this color scheme, the device transparently shows the device security status to the user.
To implement Android Verified Boot on devices, developers need access to the console and sufficient privileges to execute some commands. In this section, we’ll show how to check if AVB is enabled and give a walkthrough on how to enable it.
To check if AVB is active:
>> adb shell/proc/cmdline>> cat /proc/cmdline‘androidboot.verifiedbootstate’
To activate or implement Android Verified Boot the following prerequisites must be present:
1. Device settings
Ensure that USB Debugging is enabled on the device.
2. Verity support
Dm-verity is an essential feature used to verify the integrity of read-only partitions. It is based on a cryptographic hash tree and ensures the integrity of the system and vendor partitions. The AOSP provides a great overview of how this feature is implemented.
3. Read-only partitions
AVB requires the aforementioned partitions to be read-only. Partitions mounted as read-only prevent modifications to these system files and thus ensure their integrity. While the details and specifications of partitions are not the focus of this article, we want to refer to the relevant documentation at this point.
4. Bootloader support
The bootloader must be able to use ‘libavb’. A good example is U-Boot, which is commonly used on many embedded devices.
If AVB is not enabled, activate it:
>> adb shell‘BOARD_AVB_ENABLE’ = true‘openssl’Although AVB is an integral part of Android devices' security, disabling verified boot is possible. Doing so requires special privileges and should never be done on production devices. It is not recommended for any device, and you should avoid it if possible. However, when developing specific parts of the system software, developers might want to disable this feature to validate or test specific parts of the boot sequence without having to build & sign them first.
There are two options for this, either on userdebug or fastboot. Userdebug builds require the developer to compile their version from the android source code first.
Given that, the process to get Android secure boot disabled essentially comes down to one command:
>> adb shell>> adb root>> adb disable-veritySince this is not always the case, fastboot allows for a more accessible way to unlock the bootloader and get Android Verified Boot turned off.
>> fastboot oem unlockTwo fundamental concepts become apparent when dealing with protecting the boot process: Secure Boot and Android Verified Boot. Although similar, both come with key differences.
On the one hand, Android Verified Boot extends its chain of trust from the involved partitions during booting into the operating system. On the other hand, Secure Boot is a security standard initially designed for PC platforms and operates on the UEFI level, which is very uncommon in Android. As such, it primarily focuses on the initial boot stages, ensuring that only trusted software from the OEM is executed. Secure boot is more universal and widely adopted across platforms, while Android Verified Boot is—as the name implies—tied explicitly to Android.
Please be aware that the terms Secure Boot Android or Android Secure Boot are quite oft used interchangeably, with Android Verified Boot mixing the two concepts. Since for a secure boot Android Verified Boot is used the confusion makes sense.
As previously outlined, Android Veridied Boot establishes a full chain of trust and verifies each subsequent partition during runtime. In contrast, the chain of trust in Secure Boot is not a strictly defined concept and may vary depending on the implementation. Nevertheless, Secure Boot ensures the integrity of the firmware drivers and operating system during the boot process.
Rollback protection is an essential building block of AVB, preventing attackers from exploiting vulnerabilities present in outdated OS versions. Secure Boot does not natively have rollback protection, although it can be implemented if necessary.
Every security feature has its downsides. Secure Boot heavily relies on the secure storage of the keys for signing the system software. Malicious actors can exploit these keys by signing their software if compromised. Developing software directly interacting with the kernel can also be a security concern, since only trusted software can run.
While Secure Boot significantly enhances device integrity, vulnerabilities in the underlying hardware such as the kernel can lead to a high blast radius and undermine security entirely. In 2019, for example, researchers from Hong Kong University discovered a vulnerability in the GRUB2 bootloader (CVE-2019-14615) that enables attackers to run arbitrary code during boot sequences. Whether the device relies on a secure or verified boot, it is essential to keep it updated with Android security updates!
Boot processes can be complex. With Android Verified Boot enabled, even more points of failure can lead to a headache.
Next up, we’ll outline three example issues, possible explanations, and how users and developers might address these.
Keep these two points in mind:
This issue may indicate that the system's integrity is compromised. A compromised system state is most likely the result of a failed update, malware, or an underlying system error.
User
There is a good chance that reflashing the device solves the issue. This solution requires no additional tooling or knowledge of the Android secure boot process.
Developer
If the device does not boot at all, you need to ensure that the bootloader support for AVB is enabled. If the bootloader support is either not enabled or properly configured, chances are high that this causes the issue.
Verification failure might result from modifications to the boot partition without correct signatures, or indicate a corruption of boot files.
User
As a user, there is little to no solution to resolve this. Seek professional advice from the vendor or developer if your device states that the Android boot image verified as failed.
Developer
First, check if the boot partition hash matches the value in vbmeta. If this error message appears immediately after an update, verify that the partitions are signed with the correct key. Otherwise, the device might be compromised or altered. Hence, fastboot flashing to the previous image is advisable.
AVB blocks the installations or interrupts the boot process due to untrusted partitions.
User
Review the compatibility of the custom ROM and verify that it is properly signed. Another – although not advisable – solution might be to switch off AVB temporarily. This disables the Android secure boot process, leaving the device without a crucial security measure.
Developer
Similar to users, proper signage verification is essential. If the partitions are correctly signed, the installation procedure might be affected. Hence, verify and guide the user through installing a custom ROM or manage it yourself with AVB enabled.
This article has Android Verified Boot explained, detailing its critical role in enhancing device security. As an integral component of the Android OS, AVB establishes a secure chain of trust from the moment the device is powered on. It protects the boot partitions and allows for customized alterations to the boot sequence, enabling developers to adapt the OS to their specific requirements. Mandatory features like rollback protection further harden devices against common malicious attacks. While AVB is essential for device security, developers and users may trigger that protection involuntarily during development and updates, which is why we shared three common issues. In short, customization of the protected boot sequence has its specifics but outweighs the additional effort due to the significant security it offers.
At emteria, we take security seriously. Are you looking for automated and scalable solutions for all your Android customization needs? We offer various tools for fully automated and product-specific Android custom ROMs including OTA firmware updates.
To learn more about emteria’s Android solutions, contact us to book a live demo.