1) Verified boot is the process of assuring users of the integrity of software running on a device by reducing risks from malware and preventing rollbacks to vulnerable past versions. It uses hashing, public key cryptography, and tamper-evident storage. 2) Android Verified Boot 2.0 (AVB) is Google's recommended method for verified boot integration. It uses a signed VBMeta structure containing hashes, hashtrees and rollback indexes to verify the integrity of partitions before booting. 3) AVB supports features like A/B partitions, locked/unlocked device states, and delegates verification authority through chained partitions. It interacts with bootloaders, uses avbtool to generate signatures,

1. 1
Confidential
U-boot and Android Verified Boot 2.0
Igor Opaniuk
Embedded Career Day 2.0, Feb 10

2. 2
Confidential
• Linux/Android Boot: generic approach
• Verified boot: what’s used for?
• AVB 2.0
- Generic overview
- AVB ops
- VBMeta structure/hashes and hashtrees
- Bootloader locked/unlocked states
- Rollback indexes
- Device boot states
- Role of the TEE and tamper-evident storage
• Links
Agenda

3. 3
Confidential
Linux/Android Boot: generic approach
● ROM bootloader: pre-relocation initialization; boot from NAND flash, SD, MMC
● SPL (in a sake of overcoming platform limitations: SRAM is limited; watchdog, CPU
clocks/timers; zeros BSS memory; DMA); U-boot “pre-loader”
● U-boot: more sophisticated tasks: network boot(TFP/NFS), different FS, command
line
Falcon mode ?

4. 4
Confidential
SPL: highlights
● arch_cpu_init()
○ initializes some registers, the watchdog, the DMA, etc;
● ccgr_init()
○ initializes CCGR registers in the CCM (Clock Controller Module);
● board_early_init_f()
○ initializes the M4 core and the pads of the UART1;
● timer_init()
○ initializes CPU timers and clock sources;
● preloader_console_init()
○ initializes serial port communications and prints the message "U-Boot SPL ...";
● spl_dram_init()
○ sets board-specific DRAM configuration (UDOO Neo Basic has 512MB of RAM
and different timings);
● memset() zeros BSS memory;
● board_init_r() continues the boot, loading the second stage of the boot-loader.

5. 5
Confidential
U-boot->Linux kernel

6. 6
Confidential
TI AM57xx boot

7. 7
Confidential
HiKey boot: a bit different approach (UEFI/EDK2)

8. 8
Confidential
Verified boot is the process of assuring the end user of the integrity of the software running on a
device.
Verified boot: generic info

9. 9
Confidential
Verified boot is the process of assuring the end user of the integrity of the
software running on a device.
● Reduces risk of malware
○ we tampered with, for example, by a rootkit
● Denies rollback to previous versions of firmware (with possible security
issues, could be vulnerable to an exploit)
● Safe software updates
P.S. In most cases it does not mean the user needs to be locked out (fyi:
bootloader lock/unlock)
Verified boot: what’s for?

10. 10
Confidential
Plays role in decisions related to enabling services as:
● DRM (Secure video playback etc.)
● Payments (Android Pay)
● Secure fingerprint/Secure input
● Secure storage
Verified boot: what’s for?

11. 11
Confidential
● Root of trust (static): verification chain from ROM
bootloader
○ Initial code assumed to be trusted, holds keys for
later stages
● Every byte loaded should be verified before usage
● Upgradable firmware
● Rollback protection
Verified boot: basic requirements

12. 12
Confidential
● TPM (Trusted Platform Module)/TrustZone
● Hashing
○ SHA256
● Public key crypto
Verified boot: technologies

13. 13
Confidential
• “Recommended”(c) by Google support to be added by device
manufactures
• Integration with bootloaders:
- libavb/libavb_ab
• Portable to any system with C99 compiler
• avb/avbab ops should be implemented
• C library/runtime primitives
- avbtool for generation VBMeta
- Support in fastboot (bootloader “lock/unlock”; )
- Embedding root public key (key0)
- Tamper-evident storage
Android Verified Boot 2.0

14. 14
Confidential
• .read_from_partition() - Reads N bytes from a partition identified by a string name
• .write_to_partition() - Writes N bytes to a partition identified by a string name
• .validate_vbmeta_public_key() - Checks if the given public key used to sign the ‘vbmeta’
partition is trusted
• .read_rollback_index() - Gets the rollback index for a given index location
• .write_rollback_index() - Sets the rollback index to a given location
• .read_is_device_unlocked() - Gets where the device is unlocked
• .get_unique_guid_for_partition() - Gets the GUID for a partition identified by a string name
Android Verified Boot 2.0: AVB ops

15. 15
Confidential
VBMeta 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.
Android Verified Boot 2.0: VBMeta structure
pic source: link (1)

16. 16
Confidential
Android Verified Boot 2.0: hashtree
pic source: link (3)

17. 17
Confidential
Android Verified Boot 2.0: chained partitions &
authority delegations
pic source: link (1)

18. 18
Confidential
Rollback protection is having the device reject an image unless rollback_index[n] >=
stored_rollback_index[n] for all n, and having the device increase stored_rollback_index[n] over
time
Android Verified Boot 2.0: Rollback indexes
pic source: link (1)

19. 19
Confidential
Android Verified Boot 2.0: A/B support
pic source: link (1)

20. 20
Confidential
Android Verified Boot 2.0: avbtool
pic source: link (1)

21. 21
Confidential
Unlocked state switch:
- Asserting physical presence of the user
- DRM/secure input are probably disabled
- Limited device guarantee
- Boot sequence changes
Locked/Unlocked states

22. 22
Confidential
Android Verified Boot 2.0: device boot states and flow
● green: If in LOCKED state and the key used for verification was not set
by the end user.
● yellow: If in LOCKED state and the key used for verification was set by
the end user.
● orange: If in the UNLOCKED state.

23. 23
Confidential
Android Verified Boot 2.0: device boot states
pic source: link (1)

24. 24
Confidential
1) Bootloaders triggers TEE for
HMAC generation
2) TA generates HMAC based on
counter and private key
3) HMAC is sent to eMMC controller
4) eMMC controller reads the pre-
loaded key and the counter value to
generate HMAC
5) Compares two HMACs. If they
are identical, RPMB access is
allowed
Android Verified Boot 2.0: tamper-evident storage

25. 25
Confidential
1. https://android.googlesource.com/platform/external/avb/+/master/README.md
2. https://www.denx.de/wiki/U-Boot
3. https://source.android.com/security/verifiedboot/dm-verity
4. http://github.com/OP-TEE
Links

26. 26
Confidential
Thank you