3. 安全启动与验证启动
在Android系统的启动安全体系中，Secure Boot与Verified Boot是两个经常被混用的概念。它们都涉及“启动时验证”，但目标、验证对象、失败后果和信任模型并不相同。理解二者的区别，是掌握Android Verified Boot系统工程的第一道门槛。
一、核心原理：两种“启动验证”的不同使命
Secure Boot（安全启动）的核心目标是只允许运行被授权的软件。它通常由SoC厂商或平台固件实现，验证对象是引导加载程序（Bootloader）、TEE、系统固件等。如果验证失败，设备会拒绝继续启动，甚至直接变砖。Secure Boot强调的是“准入控制”：不信任的代码，根本不允许执行。
Verified Boot（验证启动）的核心目标是保证系统分区的完整性和真实性，并允许设备在可恢复的前提下启动。它验证的是boot、system、vendor、vbmeta等Android分区。验证失败时，设备可能进入恢复模式、显示警告，或根据dm-verity策略降级运行。Verified Boot强调的是“可检测、可恢复、可审计”：即使系统被篡改，也要让用户和上层知道。
一句话区分：Secure Boot决定“能不能启动”，Verified Boot决定“启动的东西是不是原厂的、有没有被改过”。
二、信任根与信任链：从不可变硬件到可变系统
无论是Secure Boot还是Verified Boot，都依赖信任根（Root of Trust, RoT）。信任根是系统中第一个被无条件信任的组件，通常由硬件实现，例如SoC内部的BootROM、eFuse中烧录的公钥哈希、或TEE中的安全存储。
信任链（Chain of Trust）则是从信任根出发，逐级验证下一级组件的过程：
- BootROM：芯片上电后执行的第一段代码，不可修改，是信任根。
- Primary Bootloader：由BootROM验证其签名，验证通过后执行。
- Secondary Bootloader / ABL：由Primary Bootloader验证。
- vbmeta：包含各分区哈希和签名，由ABL验证。
- boot / system / vendor：由vbmeta中的哈希和签名间接验证。
这条链上任何一环验证失败，信任链即断裂。Secure Boot通常要求链上每一环都必须通过，否则停止启动；Verified Boot则允许在特定条件下继续启动，但会记录状态并提示用户。
三、完整性验证与真实性验证：两个不能混淆的目标
完整性验证（Integrity Verification）回答的是：“数据有没有被改动？”它通过哈希算法（如SHA-256）计算分区内容的摘要，并与预期值比对。如果哈希不匹配，说明数据被篡改或损坏。
真实性验证（Authenticity Verification）回答的是：“数据是不是由可信来源签发的？”它通过数字签名实现：厂商用私钥对哈希签名，设备用预置公钥验签。只有签名有效，才能证明数据来自持有私钥的授权方。
| 对比维度 | 完整性验证 | 真实性验证 |
|---|---|---|
| 核心问题 | 数据是否被改动 | 数据是否来自可信来源 |
| 典型算法 | SHA-256、dm-verity哈希树 | RSA、ECDSA、AVB签名 |
| 依赖密钥 | 不需要密钥，只需预期哈希 | 需要公钥/私钥对 |
| 能否防伪造 | 不能，攻击者可同时改哈希 | 能，无私钥无法伪造签名 |
| Android对应 | dm-verity、vbmeta哈希 | AVB签名、Bootloader验签 |
关键理解：完整性验证是“防意外损坏”，真实性验证是“防恶意伪造”。Verified Boot同时使用两者：先用签名验证vbmeta的真实性，再用哈希验证各分区的完整性。
四、方法流程：一次典型Android启动的验证路径
以支持AVB 2.0的设备为例，启动验证流程如下：
1. BootROM 加载并验证 Primary Bootloader 签名
2. Primary Bootloader 验证 ABL 签名
3. ABL 读取 vbmeta 分区，验证其签名（真实性）
4. ABL 解析 vbmeta 中的哈希描述符，计算 boot/system/vendor 哈希（完整性）
5. 若验证通过，设置 verified boot state = green
6. 若验证失败，根据设备状态设置 yellow/orange/red，并决定是否继续启动
7. 内核启动后，dm-verity 对 system/vendor 进行块级完整性校验
8. 运行时通过 AVB 状态接口向上层报告启动可信状态其中，vbmeta是Verified Boot的“信任枢纽”：它本身由ABL验证签名，同时携带其他分区的哈希和签名信息。这种“签名清单”结构，使得一次验签即可覆盖多个分区，避免逐个分区重复验证。
五、案例与场景：验证失败时会发生什么
假设一台设备被解锁了Bootloader，用户刷入了修改过的boot镜像：
- Secure Boot层面：如果Bootloader仍处于锁定状态，修改后的boot镜像签名不匹配，ABL会拒绝启动，设备可能进入fastboot或恢复模式。
- Verified Boot层面：如果Bootloader已解锁，设备会显示“设备已解锁”警告，启动状态变为orange，系统仍可启动，但dm-verity可能被禁用或降级。
- 完整性验证：如果system分区被篡改但未重新签名，dm-verity会在读取到损坏块时返回I/O错误，导致应用崩溃或系统异常。
常见误区：很多人认为“解锁Bootloader就等于关闭了Verified Boot”。实际上，解锁只是改变了验证失败后的处理策略，验证逻辑本身仍然存在。解锁设备通常会进入orange状态，系统会明确告知用户“当前启动未通过官方验证”。
六、复盘：Secure Boot与Verified Boot的协作关系
Secure Boot和Verified Boot不是替代关系，而是分层协作关系：
- Secure Boot负责从信任根到Bootloader的“硬信任链”，确保最底层固件不被替换。
- Verified Boot负责从vbmeta到Android分区的“软信任链”，确保系统镜像的完整性和真实性。
- 信任根是两者的共同起点，通常由硬件不可变存储保护。
- 信任链是两者的共同机制，逐级签名验证，任何一环断裂都会影响整体可信度。
在Android Verified Boot系统工程中，理解“完整性验证防损坏、真实性验证防伪造、信任根不可变、信任链逐级传递”这四个核心思想，才能正确设计、调试和评估启动安全策略。Secure Boot管“门禁”，Verified Boot管“体检”，二者结合，才构成Android设备从芯片到系统的完整启动安全防线。