AVB2.0被用于启动引导，此用法添加一个“vbmeta.img”镜像。public key被编译到bootloader中用于校验vbmeta数据，vbmeta.img包含应由此public key验证的签名。
vbmeta.img包含用于验证的public key，但只有bootloader验证过vbmeta.img才会可信，就好比认证一样，包含可信public key和签名。
因此，我们在AVB中有两个重要key，一个验证vbmeta.img的OEM key，一个验证其他分区(boot/system/vendor)的verity key。当然可以使用OEM key作为verity key。
我们知道OEM key用于在bootloader阶段验证vbmeta.img。这还不够，我们必须验证其他分区，vbmeta.img包含的public key用于此目的。就像avb1.0中verity key一样，此public key用于验证system、vendor分区和boot分区。这里有些不同之处，avb1.0使用OEM key验证boot分区，使用verity key验证system/vendor分区，但avb2.0使用OEM key验证vbmeta.img，并使用其中包含的public key验证其他分区(system/vendor/boot等)。
Non-A/B system
AVB1.0
AVB2.0
正如我们上面所说，avb2.0使用OEM key来验证vbmeta.img，并使用其中所包含的public key验证其他分区。启动时bootloader将验证两个分区，一个是使用OEM key验证vbmeta.img，一个是使用vbmeta.img所包含的public key验证boot分区，而system/vendor分区由init/fs_mgr来验证(使用vbmeta.img所包含的public key)。
A/B system
AVB1.0
boot.img=kernel + ramdisk + signature，使用OEM key验证boot.img的signature合法性。
AVB2.0
VBMeta结构
AVB中使用的中心数据结构是VBMeta结构，此数据结构包含多个描述符(和其他元数据)，并且所有这些数据都被加密签名。描述符用于image哈希、image哈希表元数据和所谓的链式分区。
其中主vbmeta分区在哈希描述符中保存boot分区的哈希，对于system和vendor分区，哈希表在文件系统之后，主vbmeta分区在哈希表描述符中保存哈希表的root hash、salt和offset。因为vbmeta分区中的vbmeta结构是以密码方式签名的，所以bootloader可以检测签名，并验证它是有key0的所有者(例如，通过嵌入key0的公共部分)创建的，从而信任于boot、system和vendor。
链式分区描述符用于委托权限——它包含委托权限的分区名称以及该特定分区上的签名所信任的public key。
在这个设置中，xyz分区有一个完整性检查的哈希表，在哈希表后面是一个vbmeta结构，它包含带有哈希表元数据(root has、salt和offset等)，这个结构用key1签名的。最后，在此分区的末尾是一个页脚，它具有vbmeta结构的offset。
此设置允许bootloader使用链分区描述符来查找分区末尾的页脚(使用链分区描述符中的名称)，有助于帮助找到xyz分区的vbmeta结构并验证是否由key1签名的(保存在链式分区描述符中的key1 public key)。至关重要的是，因为有一个带offset的页脚，所以可以更新zyz分区，而不需要vbmeta分区进行任何更改。
参考：https://android.googlesource.com/platform/external/avb/+/master/README.md#The-VBMeta-struct