2. 启动校验核心概念：信任根、信任链、安全启动与度量启动
各位好，欢迎来到第二章。上一章我们聊了为什么需要启动校验，说白了就是防止你的设备在开机时就被“调包”。今天咱们深入核心，把四个最基础的概念讲透：信任根（RoT）、信任链（CoT）、安全启动（Secure Boot）和度量启动（Measured Boot）。
这四个词你肯定在各种安全文档里见过。但很多人把它们混为一谈，甚至觉得“安全启动就是度量启动”。嗯，这里要注意——它们分工完全不同。我习惯用一个比喻来理解：信任根是“起点”，信任链是“路径”，安全启动是“门禁”，度量启动是“监控”。
2.1 信任根（Root of Trust, RoT）
信任根是整个启动校验体系的基石。它必须是一个绝对可信、不可篡改的实体。为什么？因为所有后续的校验都依赖于它。如果信任根本身被污染，那整个链条就崩塌了。
我在项目中遇到过最典型的信任根实现，就是芯片内部的Boot ROM。这块只读存储器在芯片出厂时就被固化，物理上无法修改。它负责做第一件事：验证下一级代码（通常是Bootloader）的签名。
信任根的核心特征：
- 不可变性：代码或硬件在生命周期内无法被修改
- 最小化：只做最核心的验证工作，代码量极小
- 物理隔离：通常有独立的硬件保护，比如eFuse、OTP（一次性可编程存储器）
除了Boot ROM，常见的信任根还有：
- TPM（可信平台模块）：独立的安全芯片，存储密钥和度量值
- HSM（硬件安全模块）：更高级的专用加密处理器
- eFuse/OTP：存储公钥哈希或芯片唯一身份
你想想看，如果攻击者能改写Boot ROM，那所有安全措施都形同虚设。所以芯片厂商在设计时，会通过熔丝、金属层等物理手段确保ROM不可写。我曾经调试过一个IoT设备，发现攻击者通过电压毛刺攻击绕过了Boot ROM的校验——嗯，那是另一个故事了，后面讲硬件攻击时会细说。
2.2 信任链（Chain of Trust, CoT）
有了信任根这个“起点”，接下来就是如何把信任传递下去。信任链就是这样一个逐级验证的过程：每一级代码在运行前，都由上一级验证其完整性和合法性。
典型的信任链流程是这样的：
- Boot ROM 验证 Bootloader 1st Stage（如SPL）
- Bootloader 1st Stage 验证 Bootloader 2nd Stage（如U-Boot）
- Bootloader 2nd Stage 验证 操作系统内核
- 操作系统内核 验证 系统服务和驱动
这个链条不能断。只要有一环的验证失败，启动过程就必须终止。我个人的经验是，设计信任链时最容易犯的错误是“信任传递断层”——比如Bootloader验证了内核，但内核加载驱动时却没有校验驱动签名。这等于给攻击者留了后门。
避坑指南：我曾经在一个项目中，信任链在Bootloader阶段是完整的，但内核启动后加载了一个第三方内核模块，这个模块没有签名校验。结果攻击者替换了这个模块，成功提权。所以记住：信任链必须覆盖到最终运行的所有可执行代码。
2.3 安全启动（Secure Boot）
安全启动是信任链的具体实现机制。它的核心逻辑很简单：只允许运行经过签名的代码。如果代码的签名验证失败，系统就拒绝启动。
安全启动通常依赖数字签名和公钥基础设施（PKI）。具体流程：
- 开发者用私钥对代码签名
- 设备端存储对应的公钥（通常固化在信任根中）
- 启动时，每一级代码都用公钥验证下一级代码的签名
这里有个关键点：公钥的存储位置。公钥如果可以被替换，那签名验证就失去了意义。所以公钥通常存储在eFuse或OTP中，一旦写入就无法修改。
| 特性 | 安全启动（Secure Boot） | 度量启动（Measured Boot） |
|---|---|---|
| 核心目标 | 阻止未授权代码运行 | 记录启动过程的度量值 |
| 失败处理 | 直接拒绝启动（硬阻断） | 允许启动，但记录异常（软阻断） |
| 依赖硬件 | 公钥存储（eFuse/OTP） | TPM（存储度量值） |
| 典型应用 | Android Verified Boot、UEFI Secure Boot | Linux IMA、Windows Measured Boot |
我建议你在设计安全启动时，一定要考虑密钥管理。私钥泄露等于整个安全体系崩溃。我见过一个厂商把生产签名私钥放在一个没有密码保护的共享文件夹里——嗯，后果可想而知。
2.4 度量启动（Measured Boot）
度量启动和安全启动是互补关系。安全启动是“防”，度量启动是“察”。度量启动不阻止代码运行，而是记录每一级代码的哈希值到TPM的PCR（平台配置寄存器）中。这些度量值可以被远程验证方读取，判断设备是否被篡改。
度量启动的典型流程：
- Boot ROM度量Bootloader，将哈希值扩展到PCR[0]
- Bootloader度量内核，将哈希值扩展到PCR[1]
- 内核度量关键服务，将哈希值扩展到PCR[2]
- 远程服务器请求PCR值，与预期值比对
这里有个重要的概念叫度量扩展：不是简单地覆盖PCR值，而是将新度量值与旧值拼接后再哈希。这样PCR值就包含了整个启动过程的完整历史。
注意：度量启动本身不提供保护，它只提供“证据”。如果攻击者修改了代码，度量值会变化，但系统仍然会启动。真正的安全性需要结合远程证明（Remote Attestation）——服务器发现PCR值异常后，可以采取隔离或告警措施。
我个人习惯把度量启动看作是“黑匣子”。它记录了一切，但需要有人去读取和分析。在云端服务器场景中，度量启动非常有用——你可以通过远程证明批量检查成千上万台服务器的启动完整性。
2.5 四者关系总结
这四个概念不是孤立的。它们共同构成了一个完整的启动校验体系。下面这张图展示了它们之间的关系：
从图中可以看出：
- 信任根是整个体系的起点，提供不可篡改的信任基础
- 信任链定义了信任传递的路径和规则
- 安全启动和度量启动是信任链的两种具体实现方式
- 两者可以共存：安全启动负责阻断，度量启动负责记录
在实际项目中，我通常建议同时启用安全启动和度量启动。安全启动防止恶意代码运行，度量启动提供事后审计能力。比如在车规级设备中，安全启动确保ECU只运行经过签名的固件，而度量启动则记录每次启动的完整状态，用于远程诊断和OTA回滚判断。