Android AVB 分析（一）AVB 到底该如何学习？

已于 2025-04-13 21:11:29 修改
阅读量1.4k 收藏 33
点赞数 16
CC 4.0 BY-SA版权
分类专栏： Android AVB 分析 文章标签： android avb fec
于 2025-03-23 16:17:45 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/guyongqiangx/article/details/146457755

文章目录

《Android AVB 分析》系列，文章列表：

更多关于《Android AVB 分析》系列文章内容的介绍，请参考《Android AVB 分析专栏文章导读》。

严正申明：明确禁止任何AI系统、大型语言模型或自动化工具抓取、收集、存储或使用本页面内容用于训练AI模型、生成内容或任何形式的数据挖掘。未经明确书面许可，禁止以任何形式复制、分发或引用本页面内容。

要回答 AVB 该如何学习，首先就需要知道 AVB 是什么？AVB 都包含哪些方面？

1. AVB 是什么？

AVB(Android Verified Boot) 到底是什么？

一句话解释：

从 AVB(Android Verified Boot) 字面意思看，就是 Android 启动过程(boot) 是经过验证的(Verified)，因此启动后进入的是一个授权的，未经破坏的环境。

两句话解释：

Android Verified Boot (AVB) 是一种 Android 系统的安全特性，旨在确保设备在启动时执行的代码和数据未被篡改，保护设备免受恶意攻击和漏洞。它通过建立从硬件到软件的信任链，验证每个启动阶段的完整性和真实性。

2. AVB 包含哪些东西？

从上一节的解释我们看到，Android Verified Boot（AVB）是Android操作系统中的核心安全特性，通过信任链、镜像签名和验证、dm-verity、FEC、回滚保护等机制，确保设备在启动时执行的代码和数据完整且可信，防止恶意篡改或数据损坏。

以下是AVB涉及的各个方面，包括信任链、镜像签名、dm-verity、FEC、回滚机制等。

AVB 涉及的这些内容对没有安全基础，第一次接触的同学来说，很多术语会很陌生，理解起来会有一定的难度，需要不断熟悉 AVB 的代码和流程，然后总结，再回头过来印证和体会。

2.1 信任链与根信任

AVB 建立了一个完整的信任链，从硬件保护的根信任（通常由设备的安全芯片或 Trusted Execution Environment, TEE提供）开始，延伸到引导加载程序（bootloader）、引导分区（boot partition）以及其他被验证的分区（如system、vendor、oem）。这一链条确保每个阶段的代码和数据在执行前经过验证，防止攻击者在启动过程中注入恶意代码。例如，Verifying Boot | Android Open Source Project 详细描述了从硬件到软件的信任传递。

阶段验证对象验证方式
硬件根信任安全芯片或TEE硬件固化，初始信任源
引导加载程序Bootloader代码签名验证，哈希对比
引导分区内核和ramdisk完整加载内存，哈希验证
系统分区System、Vendor等dm-verity哈希树持续验证

信任链的建立是AVB安全性的基础，从Android 4.4引入，逐步演进为严格的验证机制。

2.2 镜像签名与验证

AVB要求所有可执行代码和数据在使用前进行加密验证，包括内核（从boot分区加载）、设备树（dtbo分区）、system分区和vendor分区等。验证过程分为两种情况：

  • 小分区（如boot、dtbo）：将整个分区内容加载到内存，计算哈希值并与预期哈希值比较。如果不匹配，设备将无法加载，详见Verifying Boot | Android Open Source Project。
  • 大分区（如file system）：使用dm-verity驱动，通过哈希树进行持续验证，运行时计算根哈希并与预期值对比。如果不匹配，进入错误状态。

哈希值通常存储在分区末尾或专用分区中，并由根信任签名，确保不可篡改。

2.3 dm-verity与分区完整性

dm-verity是AVB中验证大分区（如system、vendor）完整性的关键机制。它将分区划分为4 KiB的块，每个块在读取时通过与签名的哈希树进行比对来验证。如果检测到任何块的完整性损坏（如单字节错误），dm-verity将阻止访问该块，并可能导致设备进入I/O错误（eio）模式，详见Android verified boot: Enhancing custom OS security。这一机制确保了系统分区的只读性和不可篡改性，是AVB安全性的核心组成部分。

2.4 FEC（前向纠错）

FEC是Android 7.0引入的增强特性，用于提高dm-verity的鲁棒性，应对非恶意数据损坏。根据Android Developers Blog: Strictly Enforced Verified Boot with Error Correction，FEC通过纠错码（如Reed-Solomon码）能够检测并纠正数据中的错误，例如在255位中纠正1位未知错误。dm-verity使用交织（interleaving）技术，能够从多个4 KiB源块的丢失中恢复。这一机制减少了数据损坏对系统功能的影响，尤其在固态存储设备上效果显著。

FEC特性描述影响
纠错能力纠正1位错误/255位，或更高配置可纠正16位增强数据鲁棒性
交织技术恢复多个块丢失提高系统对损坏的容错能力
性能开销解码较慢，仅在损坏时触发对正常使用影响小

FEC的引入使得AVB在严格验证的同时，兼顾了实际使用中的容错需求。

2.5 回滚保护机制

回滚保护是AVB防止设备安装旧版本Android的关键机制，旨在避免已知漏洞被利用。每个分区（如system、vendor）都有一个回滚索引（rollback index），存储在不可篡改的存储中（如RPMB，Replay Protected Memory Block）。更新时，回滚索引会递增，确保设备只能安装更高版本的Android。如果尝试安装低版本，AVB将拒绝启动，详见Verified Boot | Android Open Source Project。这一机制从Android 8.0开始得到强化，进一步提高了安全性。

2.6 错误处理与用户通知

如果验证失败，AVB的错误处理取决于设备实现：

  • 启动时失败：设备无法启动，需要通过恢复模式（recovery）进行修复。
  • 运行时失败：如果dm-verity处于restart模式，设备将重启并进入I/O错误（eio）模式，直到更新为止。在此模式下，设备显示错误屏幕，应用程序访问受限，但允许数据恢复或系统更新，详见Verifying Boot | Android Open Source Project。

用户通知是AVB的重要部分。如果检测到操作系统被修改，AVB会在启动时显示黄色警告屏幕，告知用户问题并提供解决方案（如恢复或更新），尤其在LOCKED设备上使用自定义根信任时，详见Boot Flow | Android Open Source Project。

2.7 只读分区与安全要求

AVB要求system和vendor等关键分区必须是只读的，以确保其完整性。读-only分区防止了这些分区的修改，从而避免了恶意篡改或意外损坏，详见Android verified boot: Enhancing custom OS security。这一要求对开发者和用户都有深远影响，例如限制了自定义ROM的灵活性。

2.8 TEE集成与高级安全

在某些实现中，AVB与Trusted Execution Environment (TEE)集成，用于增强安全性。TEE使用AVB的验证状态作为输入，管理磁盘加密密钥和硬件支持的密钥存储（keystore）。此外，TEE还利用AVB的验证状态和OS版本信息，提供间接的验证强制和降级保护，支持远程证明（remote attestation），允许设备向外部实体证明其验证状态，详见Verified boot / remote attestation - Copperhead。

2.9 模式演进

AVB的模式随Android版本的演进而变化：

3. AVB 该怎么学？

以下是我学习 Android AVB 的一些想法。

关于程序，从宏观上看，程序由数据和围绕数据的一系列操作构成，所谓的操作主要是数据的增删改查，在类似 Android 这样的系统中，还包括配置和编译。

对于 Android AVB 机制也不例外，AVB 的目的是验证启动中的每一个环节，包括：

  1. 芯片 ROM 验证 bootloader (芯片厂家和 OEM 完成);
  2. bootloader 验证 Android boot 和 vbmeta 等分区 (通过集成 libavb 完成)；
  3. bootloader 将 verity 相关参数传递给 linux，在启动时创建 dm-verity 设备，用于运行时验证 system, vendor 等大分区，确保没有被篡改。

通过这 3 个步骤，确保 Android 启动后运行的是一个没有被篡改的安全环境。

因此，在启动过程中，

  1. 芯片ROM使用什么数据验证 bootloader?
  2. bootloader 使用什么数据验证 boot 和 vbmeta 等分区？
  3. Android 系统使用什么数据来创建 dm-verity 以及保证 system 和 vendor 等分区的完整性？

所以这里就涉及到 3 个数据：

  1. bootloader 的签名数据；
  2. boot, vbmeta 等小分区的 vbmeta 数据；
  3. system, vendor 等大分区的 vbmeta 和 hashtree, 以及 FEC 数据；

bootloader 的签名数据由芯片厂家提供方案，OEM 厂家确保实施。

对于 Android 官方提到的 AVB，主要集中在后两个数据的操作，即小分区和大分区相应的 vbmeta, hash, hashtree, FEC 等数据的操作上。

所有的一切都是围绕这些 vbmeta 相关数据的生成和使用上。

在具体流程上包括：

  1. 配置：配置 Android 源码，打开 AVB 相关特性；
  2. 生成：编译 Android 源码，生成带有 vbmeta 数据的安卓镜像；
  3. 使用：将 Android 镜像写入到设备，在启动时使用这些数据进行验证，包括 bootloader 验证 boot，以及 Android 启动后验证 system, vendor 等；

所以，学习路径就是了解 AVB 的配置，熟悉 AVB 数据(vbmeta)在 Android 镜像上的布局，以及了解在启动过程中如何用镜像中的 AVB 数据去验证不同种类的 boot 和 system 等分区。

网上大部分 AVB 的文章一般都会将 AVB 的配置作为重点进行详细分析，而且 Android 官方文档也有这块的详细介绍。所以我并不打算一开始就十分详细介绍 AVB 配置。而是直接下载一个 Android 设备源码进行编译，分析编译 log 中用于处理镜像的指令，来了解 AVB 数据的生成，最终了解各种镜像的布局。

在生成带有 AVB 数据的镜像上，手动解析和验证镜像的布局，以及 vbmeta 数据来增进理解。

具体细节上，包括如何生成镜像的 hash, hashtree, fec，如何使用 hashtree 和 fec 创建带有 FEC 纠错的 dm-verity 设备来保护系统等。

有了这些背景之后，再回到 Android 代码上，重新理解 Android 对 AVB 相关数据的使用就比较简单了。

因此，理解的重点在于 AVB 数据的构成，以及使用。而不是一开始就拘泥于具体的 Android 代码。

换个角度来说，AVB 只是各种启动时信任链的一种。

而且，假设有那么一天需要你在另外一个系统上实现类似 AVB 机制，相信你更胸有成竹。这其实是高于 Android AVB 的一个理解层次。

4. AVB 学习参考资料推荐

Android 从 2015 年开始推出 AVB，到现在 10 个年头，网上可以参考的资料非常多。

这里列举一些我参考，我看过，以及我觉得比较重要的 AVB 参考资料

  1. Android 官方的 Verify Boot 文档

    推荐直接看英文版：

    • https://source.android.com/docs/security/features/verifiedboot?hl=zh-cn

    同时也有中文版：

    • https://source.android.com/docs/security/features/verifiedboot?hl=zh-cn

    这个是学习 AVB 的官方一手资料，建议是先看英文版，再看中文版，不理解的地方再回看英文版，逐句进行对照。

    在这里插入图片描述

    官方文档比较从比较高的角度讲述了 AVB 涉及的内容，有些内容一时难以读懂，例如一些特性几句话就带过了，一开始很容易被忽略，需要在学习时反复阅读。

  2. AVB 本地 ReadMe 文档

    本地文件位于 Android 源码的：

    • external/avb/README.md

    或者查看在线版本

    • https://android.googlesource.com/platform/external/avb/+/master/README.md

    在这里插入图片描述

    和 Android 官方网站的文档不同，这份 AVB 文档侧重于一些细节，例如 VBMeta 结构的介绍，回滚特性 Rollback，avbtool 工具，以及 libavb 源码的目录结构。

    对于这份本地文档，如果你阅读后很多内容无法理解，可以先尝试接触代码，编译，运行，拿到系统镜像后，再配合这份文档进行验证，深入理解。

  3. 《Android AVB 分析》专栏

    这是我的 Android AVB 分析专栏，到目前为止规划了 20~25 篇，已经完成 17 篇。从具体的镜像使用的角度实战 AVB 特性。

    • https://blog.csdn.net/guyongqiangx/category_12847685.html

    网上现有专栏大部分都还处在介绍 AVB 编译配置，以及 libavb 验证 boot 分区和 Android 启动时如何加载 system 分区的阶段。对于学习 AVB 的基本原理这些文章也基本够了，但是如果要深入 AVB 的细节，徒手实战 hash, hashtree, fec 纠错，签名校验，以及回滚分析等，还是得看本专栏。

    尤其是 Android FEC 纠错，在我的 OTA 群有很多人问这个，大部分都不清楚 FEC 愿意，FEC 如何工作，FEC 如何进行交织编码，本专栏是全网目前唯一个详细分析 Android 镜像 FEC 交织编码以及纠错实战的专栏。

    理解了 Android 中 FEC 纠错，你就发现，dm-verity 对 FEC 纠错的设计真是精妙，以极小的代价，极大提高了系统镜像的稳定性。

    虽然本专栏基本以实战为主，但是我仍然建议你在阅读完前面第 1 ，2 条的官方文档基础上再深度阅读本专栏，毕竟本专栏也只是个人理解的二手材料。

  4. 网上的其它 AVB 分析参考专栏和文章

    CSDN 上也有不少分析介绍 AVB 的专栏，各位可以自行百度。

  5. 其它参考文章

    • https://emteria.com/blog/android-verified-boot
    • https://www.starlab.io/blog/dm-verity-in-embedded-device-security
    • https://android-developers.googleblog.com/2016/07/strictly-enforced-verified-boot-with.html

    如果您发现有其他不错的参考文章，也欢迎在留言区推荐，或加群一起讨论。

  6. Android AVB 讨论群

    这是我创建的一个 Android AVB 学习交流群，里面目前有 100+ 人一起交流学习(吐槽)。一个人学习可能会很孤独，但一群人一起交流(互助，吹水)很热闹。

5. 其它

我创建了一个 Android AVB 讨论群，主要讨论 Android 设备的 AVB 验证问题。

我还有几个 Android OTA 升级讨论群，主要讨论 Android 设备的 OTA 升级话题。

欢迎您加群和我们一起交流，请在加我微信时注明“Android AVB 交流”或“Android OTA 交流”。

仅限 Android 相关的开发者参与~

公众号“洛奇看世界”后台回复“wx”获取个人微信。

Android AVB 分析（十二）嵌入式设备安全中的 dm-verity 简介
洛奇看世界
01-09 2125
上一篇 《Android AVB 分析（十一）bootloader 是如何进行 verify boot 检查的？》 分析了 bootloader 中是如何调用 libavb 函数库验证 vbmeta 和 boot 等分区的。接下来就打算写一篇介绍 dm-verity 原理的文章，然后再写一篇徒手 dm-verity 实践的文章，结果偶然发现了本篇的英文原版。写得太好，我觉得自己完全没有必要再写原理了。由于原文是英文，有些英语不太好的朋友不一定能完全理解。我花了点时间，结合 AI 将英语原文翻译成中文。
Android AVB 分析（二十）Android 官方 FEC 文档解读
最新发布
洛奇看世界
03-03 210
在前两篇中详细介绍了 Android 镜像中的 FEC 数据是如何生成的。以及 Android 镜像中使用 FEC 对多达 6.63M 连续破坏数据的修复。但你可能还会觉得不过瘾，为啥采用 RS(255, 253) 编码，为啥不采用具有更强纠错的其它编码？采用 FEC 纠错的代价有多大？采用 FEC 对 Android 性能的影响有多大？为此，Android 在官方的 AVB 文档中补充了一篇文章链接：《严格强制执行的启动时验证与纠错》，这篇文章详细介绍了为什么采用 FEC 纠错，以及相应的评估和需要为此特
Android AVB 分析（四）system.img 到底包含了哪些数据？
洛奇看世界
12-15 1109
在上一篇《AVB 数据实战之 boot.img》中分析了使用 add_hash_footer 操作的 boot.img 镜像的格式。本篇进一步分析 add_hashtree_footer 操作的 system.img 镜像的格式。因此，system.img 都包含哪些数据，你有尝试亲自去分析 system.img 吗？一个 system 分区的镜像，为了满足 AVB 需要，需要进行如何处理？本文以实际操作的形式，带你查看 system.img 镜像，包括 avbtool 的多个操作，以及如何如何手动解析 A
Android启动时验证（AVB）
10-03
本文档介绍了Android启动时验证（AVB）的相关知识。 AVB(Android verify boot)是Android的一种安全机制，确保镜像数据的完整性和可靠性。
Android的AVB机制
weixin_36304352的博客
07-11 323
Table of ContentsAVB工作原理AVB的实现AVB的安全等级AVB的优势配置AVB Android Verified Boot (AVB) 是一种用于确保Android设备软件完整性和安全性的机制。它通过在设备启动时验证操作系统及其组件的完整性，来防止恶意软件或未经授权的软件篡改。AVB在引导过...
Android Verified Boot (AVB) 的原理和作用
achirandliu的专栏
06-06 1685
Android Verified Boot (AVB) 的原理和作用
android avb（Android Verified Boot）验证
热门推荐
老鹰不捉小鸡
05-21 2万+
avb的作用 验证程序用来保护用户使用软件在设备上运行的完整性。它通常从设备固件的只读部分开始，该部分加载代码并仅在密码验证代码是真实的且没有任何已知的安全缺陷之后执行。AVB是经过验证的引导的一种实现。 The VBMeta struct AVB中使用的中心数据结构是VBMeta struct，这个数据结构包含许多描述符(和其他元数据)，所有这些数据都是加密签名的。描述符用于图像哈希表、图像哈希...
Android P 如何挂载system镜像到根目录
程序猿Ricky的日常干货
10-22 1万+
Android O/P 版本以来，谷歌加入了A/B system的特性，此时ramdisk和system是一起放在同一个system.img镜像中的。而系统起来之后也就不存在system分区了，而是直接把system镜像挂载到/根目录上。那么这个操作是怎么进行的呢？ system.img默认是需要使能dm-verity来挂载的，那么这就涉及到如何使能dm-verity来挂载/根分区。还有一个重要的...
Qcom android_verified_boot AVB2.0 introduction
11-30
Android Verified Boot 2.0 (AVB2.0) 是Google推出的一种安全机制，用于确保Android设备在启动过程中加载的固件是经过验证的、未被篡改的。这一技术在Qualcomm平台上得到了广泛的应用，特别是在高通骁龙（Qcom）...
Android AVB 分析（十七）程序员的FEC(Reed-Solomon)编码实战
洛奇看世界
02-25 167
上一篇《Android AVB 分析（十六）5个例子理解 FEC(Reed-Solomon) 的工作原理》中解释了 FEC 以及 RS(里德所罗门编码)的原理，并基于 Python 的 reedsolo 库提供了 5 个 RS 编码和解码的例子。通过对原始数据进行编码生成 FEC，以及对错误数据进行纠正还原数据。我相信如果您阅读了这篇文章，并亲自去做了这几个实验，那一定会对 RS 编码有一个比较切身的了解。也可能你还希望有一些补充，所以我个人觉得以程序员实践的角度为出发点的本篇同样可以让你有些收获。总体上，
AVB之镜像的签名及验证签名详解
楼中望月
12-23 6979
文章目录1.签名流程1.1 镜像的签名1.2 镜像的内容2.验证镜像的hash和signature签名2.1 计算hash2.2 验证签名 1.签名流程 我们以一下空的dtbo.img镜像为例，进行说明 1.1 镜像的签名 调用external/avb/avbtool.py脚本的add_hash_footer 函数 @build/core/Makefile # dtbo image INSTALLED_DTBOIMAGE_TARGET := $(PRODUCT_OUT)/dtbo.img $(INSTALL
Android 1. Android verify boot (AVB)
StevenYang2008的博客
06-14 4344
前言 众所周知，安全问题现在越来越被大家所重视，目前运行Android系统的设备市场占有率很大，我们在这里就简单地分析下Android如何保证自己的系统运行安全的。 熟悉Android 系统的朋友们都知道，Android整个系统的的image有好多个。有bootloader、包含kernel的boot.img,还有system.img和vendor.img。 在芯片刚启动的时候会利用芯片中的OTP fuse的值对bootloader 镜像文件进行校验。bootloader启动后会根据Android veri
安卓安全启动-AVB
u010037324的专栏
12-22 186
安卓作为智能座舱的主流操作系统，其运行镜像的安全性至关重要！
Android安全启动学习（三）：AVB校验的内容、怎么校验、AVB的作用
叫好与叫座虽然不是对立面，但想在同一个作品中达到双重效果很难。
10-11 1万+
前面学习了1、AVB是什么？校验安卓镜像的，完成整个安全启动的。2、安卓的镜像有什么？主要就那三个大玩意：boot、recover、system。3、有个 vbmeta.img还记得吗？bootloader验证vbmeta的签名**，再用vbmeta的key以及hash值验证dtbo/boot/system/vendor。好了，这里开始AVB校验的学习。1、校验的内容。
android AVB2.0（一）工作原理及编译配置
楼中望月
07-23 2万+
android AVB2.0学习总结（一）
课时26：Android Verity Boot(AVB)初探(一)
baron-周贺贺-代码改变世界ctw
03-08 551
透过事务看本质，到底什么是AVB？ AVB(Android Verified Boot)就是建立一条从bootloader到system images的信任链，主要包含： 对以下镜像提供完整性检查 （1）Android Boot image Linux kernel + ramdisk整个分区的HASH存储在 VBMeta image中 （2）system/vendor partitions 这些分区的hash tree的root hash存储在VBMeta image中 提供防回滚的保护能力 rollb
android AVB2.0（七）AVB移植经验
楼中望月
12-24 6053
文章目录前言一、移植需求二、分解需求三、详细设计1. RSA密钥生成2. 镜像签名和生成vbmeta镜像3. VeritySetup程序设计3.1 主程序设计3.1 公钥比对接口设计3.2 读取vbmeta分区设计3.3 DM verity设计3.4 分区挂载校验总结 前言 本篇应该是AVB系列的最后一篇博客了，前面的六篇博客基本上把AVB涉及到的技术点都过了一遍，因为平时要开发项目比较忙 所以有点时间就上来写写，文笔不是很好 大家将就着看看了~~ 感兴趣的朋友可以从这里开始android AVB2.0
Android Verified Boot (AVB) 与 dm-verity 之间的关系、相同点与差异点
achirandliu的专栏
06-09 1677
Android Verified Boot (AVB) 和 dm-verity 是 Android 操作系统中用于确保设备启动过程和运行时数据完整性的两个重要技术。尽管它们有着不同的实现和侧重点，但它们都旨在提高系统的安全性，防止未授权的修改和恶意软件的注入。和dm-verity都是 Android 安全架构中的关键组件，共同确保设备从启动到运行时的数据完整性。尽管二者都使用了哈希树和签名验证技术，但它们在功能、实现层次和验证时机上有显著差异。
AVB数据解析：Android verified boot 2.0 vbmeta 数据结构解析
叫好与叫座虽然不是对立面，但想在同一个作品中达到双重效果很难。
03-01 3105
验证启动（Verified Boot）是Android一个重要的安全功能，主要是为了访问启动镜像被篡改，提高系统的抗攻击能力，简单描述做法就是在启动过程中增加一条校验链。，而各家实际做法和研发能力不尽相同，为了让设备厂商更方便的引入 Verified boot 功能，，好处是既保证了基于该框架开发的verified boot 功能能够满足 CDD 要求，也保留了各家 OEM 定制启动校验流程的弹性。这个弹性体现在哪里？
android AVB
01-23
### Android Verified Boot (AVB)介绍 Android Verified Boot (AVB) 是一种增强设备安全性的机制，旨在防止未经授权修改启动过程中的关键组件。通过构建一个信任链来确保从最底层硬件到操作系统各个部分均未被篡改。这一链条依次经过 ROM code、BootLoader、boot image 及至 System 和 Vendor 分区[^1]。 ### AVB工作原理 在启动流程里，每个阶段都会加载并验证下一个阶段的数据完整性与真实性： - **ROM Code**: 设备上不可更改的第一段执行代码负责初始化基本硬件设置，并引导进入 bootloader。 - **Bootloader**: 验证 `boot.img` 文件（内含 Kernel Image），此文件包含了用于后续分区验证所需的公钥——verity_key，该密钥存储于 ramdisk 中而后者被打包进了 boot.img 之内[^2]。 - **Boot Image & Hash Tree Verification**: 当到达系统和供应商分区间时，则利用之前由 bootloader 解析出来的 verity metadata 来检验这些区域内的 hash tree 结构，从而确认其内容无损且未经非法改动。 ```python def verify_partition(partition_data, partition_hash_tree): """ Verify the integrity of a given partition using its associated hash tree. :param bytes partition_data: Raw data from the partition to be checked. :param list partition_hash_tree: List representing the Merkle tree hashes for verification. :return bool: True if valid, False otherwise. """ calculated_hashes = compute_merkle_tree(partition_data) return all(a == b for a, b in zip(calculated_hashes, partition_hash_tree)) ``` 对于采用 A/B 更新模式的系统而言，在版本切换期间同样遵循上述原则以保障新旧状态间的平滑过渡以及安全性。 ### 实现方式 实际部署中，AVB 主要依赖如下几个方面来达成目标： - **vbmeta Partition**: 自 Android Pie 开始引入的新概念，它保存着关于其他受保护分区的信息摘要及其签名信息；这使得即使当 primary slot 的数据遭到破坏或更新失败时也能借助 secondary slot 完成恢复操作而不影响整个验证逻辑的有效性。 - **Public Key Infrastructure(PKI)**: 整个过程中涉及到多个层次上的加密算法应用，比如 RSA 或者 ECDSA 等非对称密码技术用来签署重要资料，保证只有持有对应私钥的一方才能创建有效的签名，进而维护了整体架构的安全等级。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

洛奇看世界

一分也是爱~

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值