1. 课程导入
在嵌入式设备、车规控制器、工业网关、服务器固件以及移动终端中，设备从上电到进入操作系统之间，存在一段极其关键却常被忽视的“信任建立期”。如果这段过程被篡改、跳过或降级，攻击者就可能获得持久化控制权。多阶段安全启动（Multi-stage Secure Boot）正是为了解决这一问题而设计的系统性机制：它把启动过程拆分为多个可验证阶段，每一阶段在把控制权交给下一阶段之前，先验证下一阶段镜像的完整性与真实性，从而形成一条从不可变信任根到最终操作系统的信任链。
本课程的目标不是只讲“怎么开 Secure Boot 开关”，而是建立一套可落地、可排障、可恢复的工程能力。学完本课程后，你应当能够：
- 解释信任根、信任链、度量、验证、授权、回滚保护等核心概念，并区分它们与普通校验和的差异。
- 描述从 BootROM、一级引导、二级引导、固件到操作系统的多阶段启动路径，以及每阶段的验证对象和失败后果。
- 根据设备形态选择合适的安全启动方案，例如基于签名验证、基于哈希度量、基于硬件密钥槽或基于 TPM/安全芯片的方案。
- 设计故障恢复策略，包括 A/B 分区、回滚、恢复模式、看门狗复位和防变砖机制。
- 读懂启动日志、验证失败码和密钥状态，定位“签名失败、版本回滚、密钥吊销、镜像损坏”等典型问题。
核心判断：安全启动不是“加密启动”。加密解决的是机密性，安全启动解决的是完整性与真实性。设备可以明文启动，但依然要求每个阶段镜像必须通过签名验证。
核心概念：信任根、信任链与多阶段验证
多阶段安全启动的基石是“信任根”（Root of Trust, RoT）。信任根通常由芯片内部不可修改的 BootROM 代码、一次性可编程熔丝（OTP/eFuse）中保存的公钥哈希或根密钥、以及硬件密码加速器组成。信任根是启动过程中唯一被无条件信任的部分，因此它必须足够小、足够简单、不可被现场修改。
信任链（Chain of Trust）则是一个逐级传递的过程：BootROM 验证一级引导（如 SPL、BL1），一级引导验证二级引导（如 U-Boot、BL2），二级引导验证操作系统内核或安全监控程序。每一级只信任“上一级已验证过的下一级”，从而把信任根的范围逐步扩展到整个系统。若某一级验证失败，启动流程必须停止、进入恢复模式或触发告警，而不能继续执行未经验证的代码。
与信任链紧密相关的还有“度量”（Measurement）和“回滚保护”（Rollback Protection）。度量是把镜像哈希扩展到 TPM 或安全寄存器中，用于后续远程证明；回滚保护则通过单调计数器或版本号，防止攻击者把已修复的旧版本固件重新刷入设备。
方法流程：一次完整的安全启动如何发生
下面以典型的 ARM 嵌入式平台为例，给出多阶段安全启动的通用流程。不同芯片的命名可能不同，但逻辑基本一致。
- 上电复位：CPU 从 BootROM 固定地址取指，BootROM 读取 OTP 中的根公钥哈希，建立信任根。
- 验证 BL1：BootROM 从启动介质读取 BL1 镜像及其签名，用根公钥验证签名，并检查镜像版本是否满足最低安全版本号。
- 运行 BL1：BL1 初始化 DDR、时钟和安全引擎，然后验证 BL2。
- 验证 BL2：BL2 通常包含 U-Boot 或更完整的引导程序，它验证内核、设备树和根文件系统哈希。
- 选择启动槽：根据 A/B 分区状态和启动成功标记，选择可启动的槽位；若当前槽连续失败，则切换到备用槽。
- 移交控制权：验证全部通过后，跳转到操作系统；同时把度量值写入 TPM PCR 或安全寄存器。
- 失败处理：任一阶段失败，记录失败码，尝试恢复镜像或进入恢复模式，必要时触发看门狗复位。
在工程实现中，启动日志是排障的第一手材料。例如下面这段日志展示了 BL2 验证内核失败后切换到 B 分区的过程：
NOTICE: BL1: Booting BL2
NOTICE: BL2: Loading image id=3 (kernel) from slot A
ERROR: BL2: Image authentication failed: signature mismatch
WARN: BL2: Slot A boot failure count = 3, switching to slot B
NOTICE: BL2: Loading image id=3 (kernel) from slot B
NOTICE: BL2: Image authentication passed, hash=9f2c...a71d
NOTICE: BL2: Booting BL31
案例与场景：从消费设备到车规控制器
不同场景对安全启动的要求差异很大。消费类设备可能只要求防止固件被随意替换，而车规控制器和工业网关则要求可审计、可回滚、可远程证明。下表对比了几类典型场景的关注点。
| 场景 | 信任根形态 | 关键要求 | 恢复策略 |
|---|---|---|---|
| 消费级路由器 | BootROM + OTP 公钥哈希 | 防刷机、防降级 | 恢复模式 + TFTP 刷写 |
| 工业网关 | 安全芯片 + 单调计数器 | 远程证明、密钥轮换 | A/B 分区 + 看门狗 |
| 车规控制器 | HSM + 安全启动 ROM | 功能安全、版本可追溯 | 双备份 + 安全回滚 |
| 服务器 BMC | PFR CPLD + 根密钥 | 防固件植入、平台恢复 | PFR 金镜像恢复 |
常见误区与复盘要点
误区一：把安全启动当成“一次性配置”。密钥会过期、算法会被淘汰、漏洞需要修复，安全启动必须支持密钥轮换和版本升级，否则设备生命周期内无法维护。
误区二：只做验证，不做恢复。如果验证失败后设备直接变砖，现场维护成本极高。A/B 分区、恢复镜像和失败计数是量产设备的必备设计。
误区三：忽略启动性能。逐级签名验证会引入额外耗时，尤其是大镜像的 RSA 验证。需要在安全强度与启动时间之间做权衡，例如使用 ECDSA、并行哈希或硬件加速。
复盘清单：① 信任根是否真正不可修改？② 每一级是否验证了下一级的完整性和版本？③ 验证失败后是否有明确的恢复路径？④ 启动度量是否可被远程证明？⑤ 密钥吊销和轮换流程是否经过演练？
本课程后续将沿着“信任根建立 → 多阶段验证 → 密钥管理 → 故障恢复 → 量产与运维”的主线展开。你现在需要记住的是：安全启动的本质不是某一个开关，而是一条从不可变起点出发、逐级验证、失败可恢复、过程可审计的完整链条。只有把验证、恢复和可观测性放在一起设计，才能真正做到“启动可信、故障可控”。