Android verified boot 2.0 vbmeta 数据结构解析

验证启动(Verified Boot)是Android一个重要的安全功能,主要是为了访问启动镜像被篡改,提高系统的抗攻击能力,简单描述做法就是在启动过程中增加一条校验链,即 ROM code 校验 BootLoader,确保 BootLoader 的合法性和完整性,BootLoader 则需要校验 boot image,确保 Kernel 启动所需 image 的合法性和完整性,而 Kernel 则负责校验 System 分区和 vendor 分区。

由于 ROM code 和 BootLoader 通常都是由设备厂商 OEM 提供,而各家实际做法和研发能力不尽相同,为了让设备厂商更方便的引入 Verified boot 功能,Google 在 Android O上推出了一个统一的验证启动框架 Android verified boot 2.0,好处是既保证了基于该框架开发的verified boot 功能能够满足 CDD 要求,也保留了各家 OEM 定制启动校验流程的弹性。

由于 ROM code 校验 BootLoader 的功能通常与 IC的设计相关,所以 AVB 2.0 关注的重点在 BootLoader 之后的校验流程。BootLoader 之后系统启动所涉及的关键镜像通常包括 boot.img,system.img,Android O 的 treble Project 还引入了 dtbo 和 vendor.img。这些 image 挨个校验可以说费时费力,而 AVB 2.0 的做法事实上十分简单,引入一个新的分区:vbmeta.img(verified boot metadata),然后把所有需要校验的内容在编译时就计算好打包到这个分区,那么启动过程中 BootLoader 只需要校验 vbmeta.img,就能确认 vbmeta 内的数据是否可信。再用 vbmeta 中的数据去比对 bootimg,dtbo,system,img,vendor.img 即可。至于 OEM 是还需要放什么其他东西到 vbmeta 中,则可以由 OEM 自由定制,可以说保留了很好的客制化空间。

除了最基本的验证启动之外,AVB 2.0 还提供防止回滚的功能和对AB分区备份的支持,AVB 2.0 的详细文档可以参考:Android Verified Boot 2.0

无论是验证启动还是防止回滚,vbmeta 都是很重要的数据结构,下面对最简单的 vbmeta struct 做一个分析说明。
下面是 vbmeta struct 的结构图示:


vbmetaStruct.png

以上 vbmeta 所包含的数据可以分成两个大的Block:紫色色块部分为 Authentication data block 和 其他为 Auxiliary data block。当 BOARD_AVB_ALGORITHM 定义为 SHA256_RSA2048 时,默认编译出的 vbmeta.img 通常为 4KB。vbmeta.img 组成如下:

------------------------------------------------------------------------------
|   Header   |   Authentication Data   |    Auxiliary Data    |
------------------------------------------------------------------------------

其中 Header 的固定长度为 0x100 个字节,Authentication data 和 Auxiliary data 的长度存储在 Header 中。

下面分别对这三个部分进行分析、

Header 解析

Header 的数据结构为:typedef struct AvbVBMetaImageHeader
用 UE 打开 vbmeta.img,前 0x100 个字节信息如下:

vbmetaHeader.png

根据 struct AvbVBMetaImageHeader,上图中的 Header 信息解析如下:

字节 AvbVBMetaImageHeader 成员变量 说明
0x0 - 0x3 magic[AVB_MAGIC_LEN] magic字符串,固定为 AVB0
0x4 - 0x7 required_libavb_version_major libavb 大版本号 0x1
0x8 - 0xb required_libavb_version_minor libavb 小版本号 0x0
0xc - 0x13 authentication_data_block_size 如果选用 SHA256_RSA2048算法,则 authentication data size 固定为 0x140
0x14 - 0x1B auxiliary_data_block_size 根据 make_vbmeta_image 不同参数,长度不同,上图为 0x4C0
0x1C - 0x1F algorithm_type AvbAlgorithmType定义, 0x1 表示AVB_ALGORITHM_TYPE_SHA256_RSA2048
0x20 - 0x27 hash_offset hash data 在 authentication data 中的位置,通常为 0x0,hash data的具体说明会在 Authentication data 的解析中加以说明
0x28 - 0x2F hash_size hash data 的大小,使用SHA256算法时 Hash data 固定为 0x20 个字节,即 256 bits
0x30 - 0x37 signature_offset signature data 在 authentication data 中的位置,signature data紧跟在 Hash data 后面,所以 offset 在 hash 算法为 SHA256时,固定为 0x20
0x38 - 0x3F signature_size signature data 的大小,在签名算法使用 RSA2048 时,固定为 0x100个字节,即 2048 bits
0x40 - 0x47 public_key_offset 签名算法对应的公钥存储在 Auxiliary data block 中的位置,上图为 0x298
0x48 - 0x4F public_key_size 签名算法对应的公钥长度,使用RSA2048 作为签名算法时,该长度固定为 0x208, public key 部分会在 Auxiliary data block 的解析中加以说明
0x50 - 0x57 public_key_metadata_offset public key metadata 在 auxiliary data block 中的存储位置
0x58 - 0x5F public_key_metadata_size public key metadata 的大小,为 0x0 表示没有 public key metadata 数据
0x60 - 0x67 descriptors_offset descriptor 在 Auxiliary data block 中的位置,默认固定为 0x0,descriptor 的具体含义会在 Auxiliary data block 的解析中加以说明
0x68 - 0x6F descriptors_size descriptor 的长度,取决于 make_vbmeta_image 时的参数 ---include_descriptor_from_image
0x70 - 0x77 rollback_index 供rollback protection 功能使用,由 make_vbmeta_image 时的参数 ---rollback_index 指定,上图中为 0x0,即未对回滚保护做支持
0x78 - 0x7F reserved0[4] 16字节对齐使用,固定为四个 0x0
0x80 - 0xAF release_string[AVB_RELEASE_STRING_SIZE] avbtool 的 release 信息,48个字节,一般为 avbtool 1.0.0 xxxxx
0xB0 - 0xFF reserved[80] padding数据,保证 Header长度为 x100,内容必须全部填 0x0

  

Authentication data block 解析

Authentication data block 用于校验 vbmeta.img 的合法性和完整性,包含两部分内容:Hash data 和 signature data。
通过分析avbtool 的 Python 脚本,即可了解 hash data 和 signature data 的生成过程。

     Hash data 的生成
     hash data 是对 vbmeta 的 header 和 auxiliary data block 的 hash 计算,所以是先生成了 auxiliary data block,然后生成的 authentication data block,使用的算法由 header 中的 algorithm_type 指定,本文使用 SHA256,计算出的 hash data 长度为 0x20。截取 avbtool 的脚本代码如下:

 # Calculate the hash.
 ha = hashlib.new(alg.hash_name)
 ha.update(header_data_blob)
 ha.update(aux_data_blob)
 binary_hash.extend(ha.digest())

     signature data 的生成
     signature data 是对 上文计算出的 hash data 做 padding 之后的签名,使用的算法同样由 header 中的 algorithm_type 指定,本文使用 RSA2048,计算出的 signature data 长度为 0x100。截取 avbtool 的脚本代码如下:

 # Calculate the signature.
 padding_and_hash = str(bytearray(alg.padding)) + binary_hash
 binary_signature.extend(raw_sign(signing_helper,
                                  signing_helper_with_files,
                                  algorithm_name,
                                  alg.signature_num_bytes, key_path,
                                  padding_and_hash))

有一个需要注意的地方是,hash data 和 signature data 的总长加在一起为0x120,但header 中的 authentication data block size 却为 0x140,这是因为 image 对齐需要,0x120 不能被 64 整除,所以用 0x0 填充到长度为 0x140。

Auxiliary data block 解析

Auxiliary data block 的内容则十分丰富,总得来说分为两个大类:AvbDescriptor 和 RSA public key。

     AvbDescriptor 的生成
根据 avbtool make_vbmeta_image 命令支持的参数,OEM 可以自由的定制一些需要打包到 vbmeta.img 的数据,这样一段一段的二进制数据都按照AvbDescriptor 的数据结构打包进 auxiliary data block。AvbDescriptor 按照不同的 tag 分为以下几种:

typedef enum {
        AVB_DESCRIPTOR_TAG_PROPERTY,
        AVB_DESCRIPTOR_TAG_HASHTREE,
        AVB_DESCRIPTOR_TAG_HASH,
        AVB_DESCRIPTOR_TAG_KERNEL_CMDLINE,
        AVB_DESCRIPTOR_TAG_CHAIN_PARTITION,
} AvbDescriptorTag;

最常用的参数 ---include_descriptor_from_image 可以将 boot.img,dtbo,recovery.img,system.img,vendor.img 的 descriptor 打包到 Auxiliary data block 中。这些 descriptors 在 BootLoader 确认 vbmeta.img 的合法性和完整性后,可以直接被用来校验 boot.img,dtbo,recovery.img,system.img,vendor.img。

     RSA public key的生成
除了这些 descriptor 之外,auxiliary data block 中还有一个重要的信息,就是 RSA public key。这个 public key 将被用来校验 authentication data block 中的 signature data。
在 avbtool make_vbmeta_image 时,必须用--key参数来指定生成 signature data 的 RSA private key,AOSP external/avb/test/data 目录下有各种供测试使用 RSA private key,格式为 PEM。avbtool 会根据 RSA private key 提取 public key 并加上 RSA key 的 header 打包进 auxiliary data block。
可以通过avbtool extract_public_key --key [priv_key_path] --output [outpubk_path] 来查看生成的 public key 信息。
其中 RSA key header 格式如下:

typedef struct AvbRSAPublicKeyHeader {
         uint32_t key_num_bits;
         uint32_t n0inv;
} AVB_ATTR_PACKED AvbRSAPublicKeyHeader;

前文中所描述 header 中的 public key size 为 0x208,即 0x8 个字节的 AvbRSAPublicKeyHeader 长度,加上 0x200个字节即 2048位 的 public key 长度。

以上就是 vbmeta 除 padding 填充 0x0 之外,主要的数据信息。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,547评论 6 477
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,399评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,428评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,599评论 1 274
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,612评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,577评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,941评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,603评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,852评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,605评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,693评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,375评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,955评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,936评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,172评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 43,970评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,414评论 2 342

推荐阅读更多精彩内容