3. Secure Boot硬件与固件基础
Secure Boot 不是一段“加解密代码”，而是一条从芯片上电第一刻就开始的信任链。要理解量产配置与调试，必须先看清 SoC 的启动硬件路径：谁最先运行、信任从哪里来、密钥放在哪里、失败时芯片会进入什么状态。本节围绕 BootROM、OTP/eFuse、密钥存储、安全启动模式与硬件信任根，建立后续配置工作的硬件与固件基础。
一、核心原理：硬件信任根与信任链
硬件信任根（Root of Trust, RoT）是整条安全启动链的起点，它必须满足三个条件：不可被软件修改、可被芯片唯一标识、其行为可被验证。典型实现由三部分组成：固化在硅片中的 BootROM 代码、一次性可编程的 OTP/eFuse 存储区、以及由 OTP 中哈希值锁定的公钥或密钥摘要。
上电后，CPU 从固定地址取指，执行 BootROM。BootROM 读取 OTP 中的安全配置位，判断当前处于哪种启动模式，然后用 OTP 中存储的公钥哈希去验证下一级引导程序（如 SPL、BL2、U-Boot）的签名。验证通过则跳转执行，并把信任延伸下去；验证失败则按策略停止启动、进入恢复模式或触发熔断。这条“BootROM → 一级引导 → 二级引导 → 操作系统”的逐级验证路径，就是信任链（Chain of Trust）。
二、SoC 启动流程与 BootROM 的角色
不同厂商的启动阶段命名略有差异，但结构高度相似。下面以典型 ARM 平台为例，展示从复位到系统接管的主要阶段：
BootROM 的代码量通常很小，只做最必要的事：初始化最小外设、读取启动介质、校验并加载下一级。它不解析文件系统，也不依赖外部配置，因此攻击面最小。量产调试时，BootROM 打印的启动日志（如 ROM code 版本、启动介质、校验结果）是判断问题发生在哪一级的第一手依据。
三、OTP/eFuse 与密钥存储
OTP（One-Time Programmable）或 eFuse 是芯片内的一次性可编程存储，烧写后不可逆。它承担三类关键信息：
- 安全配置位：是否启用安全启动、是否关闭 JTAG、是否允许降级、是否启用加密启动。
- 密钥材料：通常不直接存私钥，而是存公钥哈希或密钥摘要，BootROM 用其校验镜像签名。
- 版本与防回滚：安全版本号（Security Version Number），用于拒绝旧版本固件。
密钥存储的常见做法是：私钥保存在 HSM 或离线签名服务器中，公钥或其哈希烧入 OTP。设备端只做验签，不持有私钥。这样即使设备被物理拆解，也无法伪造合法镜像。下表对比几种典型存储位置：
| 存储位置 | 典型内容 | 可修改性 | 量产关注点 |
|---|---|---|---|
| BootROM | 启动代码、验签逻辑 | 不可修改 | 版本差异、已知漏洞 |
| OTP / eFuse | 安全位、公钥哈希、版本号 | 一次性，不可逆 | 烧写顺序、备份、误烧风险 |
| 外部 Flash | 引导程序、内核、根文件系统 | 可更新，需签名 | 镜像签名、防回滚、A/B 分区 |
| HSM / 签名服务器 | 私钥、签名证书 | 受控访问 | 权限分离、审计、密钥轮换 |
四、安全启动模式与调试场景
芯片通常支持多种启动模式，量产配置需要明确每种模式的行为：
- 非安全启动：不验签，便于研发调试，但量产必须关闭。
- 安全启动：逐级验签，失败即停止，是量产默认模式。
- 恢复模式：允许通过特定接口加载签名恢复镜像，用于救砖，但需严格限制。
- 调试模式：开放 JTAG 或串口，仅限产线或授权维修，量产设备应熔断关闭。
调试安全启动问题时，常见日志如下：
ROM: BootROM v2.3.1
ROM: Secure boot enabled, OTP secure bit = 1
ROM: Loading SPL from eMMC @ 0x400000
ROM: Verify SPL signature ... FAIL
ROM: Hash mismatch: expected 3f8a...c21d, got 9b04...7e55
ROM: Secure boot failure, halt.
这类日志直接指出失败发生在 BootROM 验证 SPL 阶段，且是哈希不匹配。排查方向包括：签名时使用的公钥与 OTP 中烧写的哈希是否一致、镜像是否被重新打包、烧写地址是否正确、是否误用了旧版本镜像。
五、常见误区与复盘
- 误区一：把安全启动当成“加密启动”。验签保证完整性，加密保证机密性，两者可独立启用，配置项不同。
- 误区二：OTP 烧写后再改配置。OTP 不可逆，量产前必须用样片验证完整流程。
- 误区三：忽略防回滚版本号。不递增版本号，攻击者可刷回含漏洞的旧固件。
- 误区四：调试口未关闭。JTAG 开放时，攻击者可直接读取内存或绕过验签。
理解本节内容后，后续的密钥生成、镜像签名、OTP 烧写与量产测试，才有明确的硬件落点。Secure Boot 的可靠性，最终取决于这些底层硬件配置是否被正确、可重复地执行。