3. 可信链核心概念
在 Android 安全启动体系中，所有安全能力都建立在一个基本假设之上：系统启动的第一段代码必须是可信的。只要第一段代码可信，后续每一级代码在加载前都经过校验或度量，就能把这份信任逐级传递下去。围绕这一思想，衍生出信任根、信任链、度量启动、验证启动、安全启动等一组核心概念。理解它们之间的区别与联系，是掌握 Android 可信链集成的关键。
一、信任根：可信链的起点
信任根（Root of Trust, RoT）是整个可信链中“无需再被验证、天然被信任”的起点。它必须满足三个条件：不可被软件篡改、行为可预期、可被外部验证。在 Android 设备中，信任根通常由硬件提供，常见形态包括：
- Boot ROM：芯片出厂时固化的只读代码，是设备上电后执行的第一段程序，无法被刷写，天然作为信任根。
- 硬件密钥引擎：如 TEE、StrongBox、Titan M 等安全芯片，内部保存根密钥，私钥永不出芯片。
- eFuse / OTP：一次性可编程存储，用于固化公钥哈希、设备状态、防回滚版本号等。
信任根的核心价值在于：它把“信任”从软件层面下沉到硬件层面，使攻击者即使获得系统权限，也无法伪造信任起点。
二、信任链：信任的逐级传递
信任链（Chain of Trust, CoT）是把信任根的可信性，通过“上一级验证下一级”的方式，逐级传递到操作系统、应用层的机制。每一级代码在被执行前，都要由上一级使用密码学手段验证其完整性与合法性，验证通过才移交控制权。
Android 典型信任链的传递顺序如下：
Boot ROM（信任根）
│ 验证并加载
▼
Primary Bootloader（如 XBL / SPL）
│ 验证并加载
▼
Secondary Bootloader（如 ABL / LK）
│ 验证并加载
▼
boot.img（Kernel + ramdisk）
│ 验证并加载
▼
system / vendor 分区
│ 验证并加载
▼
Android Framework 与应用信任链的本质是“验证的传递”：只要每一环都严格验证下一环，且信任根不可篡改，那么整条链上的代码都可被认为是可信的。任何一环验证失败，启动流程就应中止或进入受限模式。
三、度量启动与验证启动：两种信任传递方式
信任链在实现上分为两种典型模式：度量启动和验证启动。它们的目标不同，常被混淆。
| 对比项 | 度量启动（Measured Boot） | 验证启动（Verified Boot） |
|---|---|---|
| 核心动作 | 对每级镜像计算哈希并记录到度量寄存器 | 对每级镜像做签名验证，决定是否放行 |
| 是否阻断启动 | 不阻断，只记录 | 验证失败则阻断或降级 |
| 信任依据 | TPM/TEE 中的度量值、远程证明 | 信任根中固化的公钥哈希 |
| 典型用途 | 远程证明、完整性审计、可信计算 | Android AVB、防篡改启动 |
| 回答的问题 | “系统启动时是什么状态？” | “系统是否被允许启动？” |
度量启动像“行车记录仪”，它不阻止车辆行驶，但完整记录每一段路程；验证启动像“门禁系统”，不符合条件的镜像根本进不来。二者可以并存：Android 的 AVB 属于验证启动，而配合 TEE 的度量与远程证明则提供度量启动能力。
四、安全启动与可信链的关系
安全启动（Secure Boot）是验证启动在平台层面的具体实现，它规定了“启动过程中每一级必须验证下一级签名”的强制策略。可信链则是安全启动所依赖的抽象模型。可以这样理解：
- 信任根是可信链的锚点；
- 可信链是信任传递的抽象结构；
- 验证启动是可信链在“放行判断”上的实现；
- 度量启动是可信链在“状态记录”上的实现；
- 安全启动是验证启动在设备上的强制策略与工程落地。
五、典型场景：Android AVB 中的可信链落地
以 Android Verified Boot 2.0（AVB）为例，其可信链落地过程如下：
- 芯片 Boot ROM 使用 eFuse 中固化的公钥哈希，验证 XBL/SPL 的签名。
- XBL 验证 ABL，ABL 验证 boot.img 的 vbmeta 签名。
- vbmeta 中包含 boot、system、vendor 等分区的哈希与签名，逐级校验。
- 若设备处于锁定状态且验证失败，启动中止；若为解锁状态，则给出警告并继续。
- 验证结果与设备状态写入 TEE，供后续远程证明或 Key Attestation 使用。
这一过程中，Boot ROM 是信任根，vbmeta 是信任链的“枢纽”，AVB 是验证启动的实现，而 TEE 中的度量值则支撑度量启动与远程证明。
六、常见误区与复盘
误区一：把“解锁 Bootloader”等同于“可信链失效”。解锁后验证启动可能被放宽，但信任根和度量能力仍在，远程证明仍可识别设备状态。
误区二：认为度量启动可以替代验证启动。度量只记录不阻断，无法阻止恶意镜像运行，二者职责不同。
误区三：忽略信任根的物理安全。若 eFuse 可被改写或 Boot ROM 存在漏洞，整条信任链都会崩塌。
误区四：只验证 boot 分区，忽略 vbmeta 与 dtbo。AVB 要求所有参与启动的分区都被纳入验证范围，遗漏即形成绕过路径。
复盘要点：可信链的强度取决于最弱一环。设计时应先明确信任根，再定义每一级的验证对象、验证算法、失败策略与状态记录方式，最后通过远程证明把启动状态暴露给云端，形成“启动—验证—证明”的闭环。