android AVB2.0介绍，本篇主要介绍AVB2.0的概述和工作原理、配置和编译。
有关AVB2.0的其他子系统的介绍，请查看android AVB2.0学习总结
一、AVB2.0概述
什么是AVB？
先看一段google官方的定义：
“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 code and executes it only after cryptographically verifying that the code is authentic and doesn’t have any known security flaws. AVB is one implementation of verified boot.”
AVB是确保终端用户运行的设备安全的一整套流程。
通常从设备固件的只读部分启动，使用加密的方式验证代码是真实的，且没有任何已知的安全缺陷后才执行它。AVB是验证启动的一种实现。
AVB是android的一个非常重要的安全功能，主要是防止启动镜像被篡改，提高系统整体的抗攻击的能力，在启动的过程实现一整套的校验链，确保各个启动阶段是安全启动的。
我们先通过几个疑问，来了解一下AVB2.0
AVB在系统启动的哪些阶段工作？
AVB一般在bootloader阶段和INIT的第一阶段工作。
AVB在这两个阶段做了哪些事情？
AVB主要在Bootloader中校验vbmeta/vbmeta_system/boot/vendor_boot等分区，在init的第一阶段校验vbmeta/system/vendor等分区。
AVB工作原理大概是怎样的？
在bootloader或者UEFI中对vbmeta分区做校验，通过vbmeta中的descriptor描述符信息，去校验boot/vendor_boot等分区，同时获取系统中的device_status(locked or unlocked 即上锁或者未上锁)、boot_status(启动状态)、vbmeta中的加密的digest/加密算法/vbmeta大小等信息，append到kernel cmdline中；
然后启动kernel,kernel加载ramdisk运行init进程，进入init第一阶段，进行system/vendor分区的安全校验，会利用kernel cmdline中的值，跳过boot分区的校验；同时，因为system/vendor分区比较大，对大分区会执行hashtree的数据处理，将root digest等信息通过ioctl存到kernel中，后面访问数据时文件系统会执行dm-verity校验，执行运行时动态安全校验。
AVB对分区的处理是怎样的？
知道了其工作原理后，那google是如何设计框架的，对系统分区做了哪些设计呢？
首先，google想到了这样的设计：通过增加一个独立的分区，这个分区包括了其他分区的重要校验信息；只要保证这个vbmeta的足够安全，那么vbmeta中包含的其他分区的信息也就足够安全。
其次，这些安全的信息总不能用明文吧，所以得加密。用什么加密方式比较合适呢？google采用了RSA非对称加密，对镜像数据做RSA签名，将来在启动加载镜像分区时做公钥验证签名。一级级的保证各个分区的安全性。
好了，有了这些基本内容后，我们接下就介绍vbmeta的设计细节，以及它的设计用意。
一、vbmeta镜像内容说明：
在整个AVB验证的过程中，需要借助于vbmeta分区，需要增加vbmeta分区和vbmeta.img镜像。
vbmeta.img镜像，编译出来的大小为4KB
可使用avbtool提供的工具查看编译出来的vbmeta.img镜像内容：
命令：./android/external/avb/avbtool info_image --image android/out/target/product/xxx/vbmeta.img
The vbmeta image consists of three blocks:
| Header data - fixed size 256 bytes
rollback index | algorithm_type | signature offset | public_key offset| Authentication data - variable size
hash of vbmeta.img | signature of vbmeta.img| Auxiliary data - variable size
public key | public key metadata | descriptors of other include image
vbmeta分区描述内容及vbmeta_system.img内容 ：
Vbmeta的Descriptor的分类：
Chain Descriptor: 链式，vbmeta等分区数据少的分区。
Hash Descriptor:hash哈希，boot等小分区。
Hashtree Descriptor: dm-verity校验的大分区，像vendor
在A/B版本中的vbmeta分区描述：
vbmeta镜像的加解密过程简述
● 加密过程
根据摘要信息生成private key(私钥），利用私钥extra生成public key(公钥)，同时利用私钥对vbmeta镜像进行签名(signature)，并将公钥和计算的hash写到vbmeta镜像的header中。
● 解密过程
先验证公钥是否平台签发的（公钥比对，防止vbmeta镜像的公钥和签名都被篡改掉），然后利用公钥进行解密签名。
AVB中镜像的加密和解密过程，以boot.img镜像为例
编译制作boot.img时进行签名时，先通过SHA-256算法得到一个散列值digest（十六进制长度为64），然后用带RSA算法的私钥加密这个digest，并生成签名后和公钥一起加在镜像的footer尾部上，编译时也会将这个digest存一份到vbmeta.img镜像中。
在bootloader中加载boot镜像时，先从vbmeta.img镜像分区中读出boot
descriptor的digest，然后利用boot镜像中的公钥进行解密计算得到一个digest，和自己SHA-256计算得到的digest进行比较；
digest相等则说明boot.img是平台编译签名的，如果不相等，则boot.img可能是被篡改过的，boot启动失败。
最后再计算一次boot镜像内容的hash是否相等，hash不相等，启动也是失败。
私钥签名 公钥验签的python脚本举例说明，这个看起来就更明白些了吧？
私钥签名
def rsa_private_sign(data):
private_key = get_key('rsa_private_key.pem')
signer = PKCS1_signature.new(private_key)
digest = SHA.new()
digest.update(data.encode("utf8"))
sign = signer.sign(digest)
signature = base64.b64encode(sign)
signature = signature.decode('utf-8')
return signature
?
?公钥验证签名
def rsa_public_check_sign(text, sign):
publick_key = get_key('rsa_public_key.pem')
verifier = PKCS1_signature.new(publick_key)
digest = SHA.new()
digest.update(text.encode("utf8"))
return verifier.verify(digest, base64.b64decode(sign))
?
?调用
def test_sign():
msg = ‘test content'
sign = rsa_private_sign(msg)
print(rsa_public_check_sign(msg, sign)) # True
后面再抽时间来更新AVB相关的配置和镜像编译时如何处理镜像的，今天先马到这里，请大家多多关注和鼓励！！！
二、
AVB的配置开关
AVB key配置介绍
AVB编译镜像
三、AVB2.0的配置和编译