Android verified boot: Robust OS security

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.

What is a verified boot in Android?

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.

So how does it work?

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.

Why Android Verified Boot?

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:

Enhanced device security & integrity

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.

Protection against unauthorized modifications

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.

Device state communication

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.

How to implement verified boot in Android?

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. 

Check if Android Verified Boot (AVB) is active

To check if AVB is active:

1. Connect your Android device to a computer and open a command prompt/terminal
2. Open an ADB shell
   >> adb shell
3. The status remains in /proc/cmdline
>> cat /proc/cmdline
4. Look for variable ‘androidboot.verifiedbootstate’
   1. GREEN: AVB active, key set by vendor
   2. YELLOW: AVB active, but doesn’t fully comply with verified boot requirements
      (e.g. key set by user)
   3. ORANGE:
      1. AVB active, device unlocked or custom recovery mode
      2. AVB inactive or failed boot check

What are the prerequirements to activate/implement Android Verified Boot?

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.

How to enable Android Verified Boot? / What has to be changed in the build system?

If AVB is not enabled, activate it:

1. Connect your Android device to a computer and open a command prompt/terminal
2. Open an ADB shell
   >> adb shell
3. Navigate to the ‘BoardConfig.mk’ file
4. Set ‘BOARD_AVB_ENABLE’ = true
5. Generate and set AVB keys, for example through ‘openssl’
6. Sign the partitions using the generated keys
7. Build and flash the updated partitions to the device

How to disable verified boot Android?

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:

Userdebug

1. Connect your Android device to a computer and open a command prompt/terminal
2. Open an ADB shell
   >> adb shell
3. Restart the ADB daemon with root privileges
   >> adb root
4. Disable verified boot to stop the Android secure boot process
   >> adb disable-verity

Since 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

1. Boot the device into Fastboot Mode
   1. Turn off device
   2. Hold a device specific key combination (i.e. Volume down + Power)
2. Unlock the bootloader
   >> fastboot oem unlock
3. Follow the prompts to confirm the unlock
4. Reboot the device

What is the difference between verified boot and secure boot?

Two fundamental concepts become apparent when dealing with protecting the boot process: Secure Boot and Android Verified Boot. Although similar, both come with key differences.

Differences in scope

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.

Differences in chain of trust

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.

No rollback protection

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.

What is the downside of Secure Boot?

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!

Troubleshooting AVB: 3 examples that can save your day

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:

• A more severe issue might cause these error messages or states; hence, a thorough investigation is always advisable.
• Users might refer to AVB issues as Android Secure Boot errors.

1. Invalid signature or corrupted data detected

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.

2. Boot partition fails verification

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. 

3. Custom ROM installation fails

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.

Android verified boot: More than just a feature

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.

Enhance your device security with ease

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.