In April of 2015, Andrew Boie, a member of Intel’s boot security team gave a presentation about Android Verified Boot (AVB) feature based on Android version 5 aka. Lollipop at the Android Builders Summit. Although this feature had originally appeared in the Android 4.4 or “KitKat” release. It is where it all started. Let us dig it further.
What is verified boot?
Verified boot is the process of assuring the end user of the integrity of the software running on a device. It typically starts with a read-only portion of the device firmware which loads executable code and executes it only after cryptographically verifying that the code is authentic and doesn’t have any known security flaws. This includes the kernel (loaded from the boot partition), the device tree (loaded from the dtbo partition), system partition, vendor partition, and so on.
Android verified boot (AVB) is one implementation of verified boot. It also ensures that all its executed code comes from a trusted source OEMs (Original Equipment Manufacturers), rather than from an attacker or corruption. In addition to verifying the OS, Verified Boot also allows Android devices to communicate their state of integrity to the user.
Why is Verified Boot required?
The idea behind Verified Boot is to establish a chain of trust from the bootloader up to the Android system image. The Bootloader is a piece of software that runs every time your phone starts up. It tells the phone what programs to load in order to make your phone run. Prior to this feature, malware could tamper with the system or boot image on an Android device, which was difficult to defend against. Under Verified Boot, the boot and recovery images are protected with a signature that covers all of the elements in those images, kernel, ramdisk, and an optional second-stage loader.
The central data structure used in AVB is the VBMeta struct. This data structure contains a number of descriptors (and other metadata) and all of this data is cryptographically signed. Descriptors are used for image hashes, image hashtree metadata, and so-called chained partitions. The VBMeta image is cryptographically signed and contains verification data for verifying boot. Image, system.
Verified Boot, introduced in Android 4.4 (Kit Kat), provides a hardware-based root of trust, and confirms the state of each stage of the boot process. During boot, Android warns the user if the operating system has been modified from the factory version, provides information about what the warning means, and offers solutions to correct it.
In Android 4.4 it added support for Verified Boot and the dm-verity kernel feature. This combination of verifying features served as Verified Boot 1.0.
The dm- verity is a kernel feature, in order for the integrity protection it provides to be effective, the kernel which the device boots needs to be trusted. On Android, this means verifying the boot partition, which also includes the root file system RAM disk and the verity public key. In Android 6 (Marshmallow) there was an introduction to the warning mode. The device implemented with Advanced Encryption Standard (AES) crypto performance above 50MiB/sec support Verified Boot for device integrity.
Where previous versions of Android warned users about device corruption, but still allowed them to boot their devices, Android 7.0(Nougat) started strictly enforcing Verified Boot to prevent compromised devices from booting. It also added support for forward error correction to improve reliability against non-malicious data corruption. Phone wont boot if verified boot fails. Unless Bootloader unlocked. No direct APIs to check bootloader status. Android 8.0(Oreo) and higher includes Android Verified Boot (AVB), a reference implementation of Verified Boot that works with Project Treble. Android 8.1 Oreo, which implements Android Verified Boot (AVB 2.0). This prevents the device from being rooted with any type of one-click root strategy. Even if root was successful, verified boot would detect the changes made to the system partition and the device would fail to boot into the Android OS. In addition to working with Treble, AVB standardized partition footer format and added Rollback protection features.
AVB includes Rollback Protection which is used to protect against known security flaws. Rollback protection is typically implemented by using tamper-evident storage to record the most recent version of the Android and refusing to boot Android if it’s lower than the recorded version. Versions are typically tracked on a per-partition basis.
Many MediaTek based smartphones have been fully rooted with locked bootloaders. This is accomplished by pushing a custom recovery to the /recovery partition using the SP Flash Tool. Once custom recovery is installed, flash the latest version of Magisk to patch the stock boot image and gain system less root of the stock OS. This method works on Android 8.1 and all other versions of Android that are compatible with Magisk Manager (Android 4.4 KitKat and newer). On Qualcomm devices, rooting Android 8.1 is nearly impossible without an unlocked bootloader.
To conclude, with the growth of the number of connected devices security risks are increasing day by day. Verified Boot ensures all its executable code comes from a trusted source (OEMs), rather than from an attacker or corruption. It establishes a full chain of trust, starting from a hardware-protected root of trust to the bootloader. Secure boot is a security standard developed by members of the PC industry to help make sure that a device boots using only software that is trusted by the Original Equipment Manufacturer (OEM). When the PC starts, the firmware checks the signature of each piece of boot software, including UEFI firmware drivers, EFI applications, and the OS.
Practically speaking, secure boot is only a fraction of what is needed for full verified boot. Secure boot stops after the EFI or BIOS verifies the signature of the boot payload, usually the bootloader. Whatever the bootloader decides to do after is beyond the scope of what secure boot can provide.
As far as I understand, it seems that only Google Pixel models make secure boot possible for custom ROMs at the moment, and possibly a few other devices with some tricks. It’s a complex case for open source, and it generally secret keys in the Android ROM and information from hardware manufacturers. As misunderstood by many, it is not at all an anti-jailbreak mechanism, as users can enroll their own keys to build images using those keys to get a verified boot of their code. Verified boot is significant for ultra-secure Android devices where true professional grade security hardening is a must.
