Android Verified Boot 2.0

本文由英文所写，英文水平有限，如有错误请联系本作者，谢谢！

Brief

AVB2.0 is used in bootloader, it add an image “vbmeta.img” for this usage. A public Key will be compiled into Bootloader for verify vbmeta data and vbmeta.img include a signature that should be verified by this public key.

The vbmeta.img also include the public key for later verify using, but this key would only be trusted when vbmeta.img is verified by bootloader. This is just like a certification, include trusted public key and a signature.

So, we have two important key in AVB, one is the OEM key for vbmeta.img verify and another verity_key for other partition(boot/system/vendor) verify.And of course you can just use your oem key as your verity_key as well.

Bootloader OEM Key (Qcom platform)

• public key:

1) UserKey - Saved in DevInfo.

bootable/bootloader/edk2/QcomModulePkg/Include/Library/DeviceInfo.h

typedef struct device_info

{

<snip>

UINT32 user_public_key_length;

CHAR8 user_public_key[MAX_USER_KEY_SIZE];

<snip>

}DeviceInfo;

2) OEMKey - Saved in “OEMPublicKey.h” of ABL

bootable\bootloader\edk2\QcomModulePkg\Library\avb\OEMPublicKey.h

/**

* Internal builds use TestKeyRSA4096Public

* OEM should replace this Array with public key used to sign boot.img

* avbtool extract_public_key --key KEY --output OUTPUT

*/

static const char OEMPublicKey[] = {

“avbtool” can extract public key through extract_public_key option, but the private key file is needed to set as an argument:

avbtool extract_public_key --key KEY --output OUTPUT

--key KEY        Path to RSA private key file

--output OUTPUT  Output file name to write public key

 - If the public key in vbmeta partition was matched with UserKey, the BootState would be GREEN.

 - If it was unmatched with UserKey, but matched with OEMKey, the BootState would be YELLOW.

 - If it was unmatched with either of them, the BootState would be RED.

• private key:

1) Default private key

external/avb/test/data/testkey_rsa4096.pem

2) Customized private key

use “BOARD_AVB_KEY_PATH :=” to define a customized key path.

Other partition Verity Key (Qcom platform)

We have known that the OEM key is used to verify vbmeta.img in bootloader. This is not enough, we must verify other partitions too.The public key that included by vbmeta.img is used for this purpose. Just like the verity_key in avb 1.0, this public key is used to verify system partition, vendor partition and boot partition as well. There are some differences here. “avb 1.0” uses the oem key to verify boot partition, and “/verity_key” to verity system/vendor partition, but “avb 2.0” uses the ome key to verify vbmeta.img, and the public key in it to verify other partition include boot partition.

On Qcom platform the public key in vbmeta.img is the same key as OEM public key, this public key is for later usage, such as boot/system/vendor verify.The bootloader just verify vbmeta.img and boot.img then boot to kernel, other image is verify by init/fs_mgr. We only need to maintain one pair of keys in this solution, I guess this is the reason why qcom do it this way.

Non-A/B system

AVB 1.0:

AVB 2.0:

As we have said above, avb 2.0 uses OEM boot key to verify vbmeta.img, and this public key to verify other partition.
Bootloader will verify two partition, one is vbmeta.img, the other is boot.img for booting, system/vendor is verified by init/fs_mgr.

A/B system

AVB 1.0:

AVB 2.0: