Android 1. Android verify boot (AVB)

前言

众所周知,安全问题现在越来越被大家所重视,目前运行Android系统的设备市场占有率很大,我们在这里就简单地分析下Android如何保证自己的系统运行安全的。

熟悉Android 系统的朋友们都知道,Android整个系统的的image有好多个。有bootloader、包含kernel的boot.img,还有system.img和vendor.img。
在芯片刚启动的时候会利用芯片中的OTP fuse的值对bootloader 镜像文件进行校验。bootloader启动后会根据Android verify boot 的规则去验证 kernel 也就是boot.img。kernel启动后会利用DM-verity 去验证system 和vendor的image。如果验证通过就正常运行。否则就会报错,运行失败。说起来有些繁琐,看下图,简单地描述这个部分的验证关系。其中AVB和DM-verity 我们将在接下来的章节里面介绍。

在这里插入图片描述
在进行安全验证的过程中离不开一个很重要的结构vbmeta struct.下一节我们首先介绍一下这个结构体。

1.VBmeta struct

标题1.1vbmeta struct 结构

在这里插入图片描述
在这一节我们介绍一个很重要的结构体:vbmeta struct。这个结构体是Android能够实现AVB功能的关键所在。
根据前面的图我们可以看到,在vbmeta 中包含了 数个descriptor ,每个descriptor 描述关于镜像文件的信息。例如 boot 镜像的hash值,dtbo 镜像的hash值。system和vendor分区比较大,因此在这里存放了这两个分区的Hashtree的数据。
在vbmeta的镜像文件中除了存放vbmeta struct,还有AVB 私钥(key0)对vbmeta image的签名数据,以及AVB 公钥的数据。
其结构具体如下:
在这里插入图片描述

1.2 AVB key

AVB key 是一对非对称密钥。私钥用来签名,公钥用来验证。如关系如图所示:
在这里插入图片描述
其中key在源代码中存放的位置如下:
私钥

${MY_ANDROID}/device/fsl/common/security/xxxx_private.pem

公钥

${MY_ANDROID}/device/fsl/common/security/xxxx_public.bin.

为了更直观地了解vbmeta struct deneirong,我们可以根据Android 提供的工具,分析下vbmeta文件镜像的内容。命令下下:

Vbmeta image can be parsed using avbtool in Android.
$ cd ${MY_ANDROID}/out/target/product/xxxx
$ ../../../../external/avb/avbtool info_image --image vbmeta.img > vbmeta.img.info
$ cat vbmeta.img.info

在这里我们的结果信息如下:
在这里插入图片描述

2. DM-verity

DM-verity 是Android 系统安全的另一重要部分,它能保证Android 的 vendor 和 system 镜像文件中的内容是真实可靠的。
那这个是怎么实现的呢,之前在vbmeta的镜像文件中有一个kernel cmdline descriptor 描述如何实现和system 相关的dm-verity。同时在vbmeta 中还包含system和vendor 镜像文件的hashtree的相关信息。

那么对于DM-verity 我们要对什么进行签名呢。答案是和hashtree 相对应的dm-verity table.。构建 dm-verity table,表会标明内核的块设备(或目标)以及哈希树的位置(是同一个值)。该映射表还会标明块的大小和 hash_start,即哈希树的起始位置(具体来说,就是哈希树在映像开头处的块编号)。

如需关于 Verity 目标映射表字段的详细说明,请参阅Google官方文档。在参考文档里面会有相关的链接【1】。

DM-verity 的私钥在source code的地址:

${MY_ANDROID}/build/target/product/security/verity_private_dev_key.

公钥所在地址:

${MY_ANDROID}/build/target/product/security/verity_key.

对dm-verity table 签名之后,公钥放在boot镜像文件所在的分区中。

总结

综上所述,在Android系统中,安全启动主要包括以下几部分。

1.在刚启动的时候芯片rom对bootloader,或者如果使能了TEE OS,还包括对TEE 镜像的验证。
2.bootloader  对boot.img(kernel) 进行验证.
3.kernel启动完成后,/system /vendor分区进行验证

补充一点:
我们自己利用openssl产生公钥私钥的方法:

$ openssl genrsa -out verity_private_dev_key_tem 2048
$ openssl pkcs8 -topk8 -inform PEM -in verity_private_dev_key_tem -outverity_private_dev_key -outform     PEM –nocrypt
$ pem2mincrypt verity_private_dev_key_tem verity_key

参考文档

【1】https://source.android.google.cn/security/verifiedboot/dm-verity?hl=zh-cn#mapping-table

<think>好的,用户想了解AVB和DM-Verity的工作原理,并制作一份12页左右的PPT。首先需要明确这两个技术的关系和各自的作用。根据提供的引用内容,AVB和DM-Verity都用于防止未授权修改,但具体实现有所不同。我需要从用户提供的引用中提取关键点,并补充一些背景知识。 首先,用户提供的引用提到AVB负责启动验证,而DM-Verity用于文件系统完整性检查。引用[1]指出vbmeta的签名不影响dm-verity的验证,说明两者在流程上是分开的。引用[3]提到两者都使用哈希和签名来检测篡改,但AVB处理启动过程,DM-Verity处理运行时。需要将这些内容结构化,分章节呈现。 接下来,PPT的结构需要合理。通常包括简介、背景、工作原理、流程、关键组件、差异对比、应用场景、挑战等部分。用户希望12页左右,所以每个部分需要简洁,突出重点。可能需要每部分1-2页,加上封面和总结。 然后,考虑技术细节。比如AVB的分区哈希验证和启动链,DM-Verity的哈希树和块级验证。引用[2]提到了哈希表的处理,可能涉及AVBUtil中的代码,这部分可以作为技术实现的一个点。需要解释哈希树的结构,以及如何通过元数据验证块设备。 还需要对比两者的相同点和差异点,引用[3]已经给出了一些,可以进一步扩展。例如,AVB在启动阶段工作,而DM-Verity在运行时;两者都依赖密码学哈希,但签名的作用域不同。 用户可能需要实际案例或图表来辅助说明,比如启动流程图、哈希树示意图等。虽然用户没有要求图片,但PPT中可能需要用文字描述这些结构。例如,在DM-Verity部分解释哈希树的构建过程,如何逐层验证。 另外,注意用户提到的引用标记,在相关内容后添加[^1]、[^2]、[^3]。需要确保每个引用出现在正确的位置,比如讨论dm-verity原理时引用,哈希表处理时引用[^2],对比时引用。 最后,用户可能需要相关的问题,比如优化方法或应用场景,但根据指令,用户可能不需要这部分,但根据示例可能需要生成相关问题。不过用户的问题已经明确要求PPT结构,所以相关问题可能围绕更深入的细节或实际应用。 总结步骤:先梳理AVB和DM-Verity的各自原理,再分析它们的协作流程,对比异同,最后整理成PPT的大纲,确保每部分涵盖关键点,并正确引用提供的资料。同时注意技术术语的准确性和表达的清晰度,适合PPT的呈现方式。</think>### AVB与DM-Verity工作原理PPT结构(12页) **建议框架与核心内容整理** --- #### **封面(1页)** - 标题:Android Verified BootAVB)与DM-Verity原理分析 - 副标题:安全启动与运行时完整性验证 - 作者/日期 --- #### **目录(1页)** 1. 背景与需求 2. AVB的核心功能 3. DM-Verity的核心功能 4. AVB验证流程与启动链 5. DM-Verity哈希树结构与验证逻辑 6. 两者协作流程(AVB初始化→DM-Verity接管) 7. 相同点与差异对比 8. 密钥管理与签名机制 9. 安全防护场景分析 10. 典型攻击防御案例 11. 挑战与局限性 12. 总结 --- #### **1. 背景与需求(1页)** - **问题**:Android系统面临固件篡改、Rootkit注入等风险 - **目标**:确保启动链可信 + 运行时文件系统完整性 - **方案**: - AVB:验证启动分区(boot/recovery/system)[^1] - DM-Verity:实时验证块设备(如/system分区)[^3] --- #### **2. AVB核心功能(1页)** - **分层验证**: - Bootloader → vbmeta分区 → 其他分区(system/vendor) - 每个分区的哈希值或签名存储在vbmeta中 - **回滚保护**:版本号检查防止降级攻击 - **关键代码**:`libfs_avb`处理哈希树与元数据 --- #### **3. DM-Verity核心功能(1页)** - **哈希树结构**: - 数据块 → 哈希叶子节点 → 多层哈希父节点 → 根哈希 - **块级验证**:读取数据时实时验证对应哈希 - **只读模式**:检测到篡改则返回I/O错误 --- #### **4. AVB验证流程(1页)** 1. Bootloader加载vbmeta分区 2. 验证vbmeta签名(使用设备公钥) 3. 根据vbmeta中的描述符验证其他分区哈希 4. 启动系统后移交DM-Verity --- #### **5. DM-Verity验证逻辑(1页)** - **初始化阶段**: - 根据`system.img`生成哈希树并存储于`hashtree`分区 - 根哈希由AVB签名后写入vbmeta[^3] - **运行时**: - 内核`dm-verity`模块按需验证数据块 - 代码示例:`system/core/fs_mgr`中的哈希表处理 --- #### **6. 协作流程(1页)** ```plaintext AVB验证分区元数据 → 内核挂载system分区 → DM-Verity驱动加载哈希树 → 用户读取数据时触发验证 ``` - **依赖关系**:DM-Verity根哈希由AVB保护 --- #### **7. 相同点与差异对比(1页)** | **维度** | **AVB** | **DM-Verity** | |----------------|-----------------------|-----------------------| | **作用阶段** | 启动阶段 | 运行时 | | **保护对象** | 分区镜像 | 块设备数据 | | **技术基础** | 签名+哈希链 | Merkle哈希树 | | **防御目标** | 阻止启动非授权镜像 | 阻止运行时数据篡改 | --- #### **8. 密钥管理(1页)** - **AVB签名链**: - 厂商私钥签名vbmeta → 设备公钥预置在bootloader - **DM-Verity密钥**: - 根哈希由AVB签名,无需额外密钥 --- #### **9. 安全场景(1页)** - **AVB防御场景**:恶意boot/recovery刷写、分区替换 - **DM-Verity防御场景**:系统文件篡改、持久化后门 --- #### **10. 挑战与局限(1页)** - **性能损耗**:DM-Verity哈希计算增加I/O延迟 - **兼容性**:需内核支持dm-verity模块 - **密钥泄漏风险**:私钥泄露导致验证失效 --- #### **11. 总结(1页)** - **核心价值**:从启动到运行的端到端保护 - **设计启示**:分层验证、密码学绑定、硬件依赖 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值