4. 可信根与信任链

固件安全的核心问题不是“如何加密”,而是“我从哪里开始相信”。如果系统启动的第一段代码本身不可信,那么后续所有签名校验、加密通信、访问控制都建立在流沙之上。可信根(Root of Trust, RoT)就是这块不可再分的信任基石,而信任链(Chain of Trust)则是从这块基石出发,逐级验证、逐级传递信任的过程。

一、可信根 RoT:信任的起点

RoT 是一组必须无条件可信的最小硬件/固件组合,它通常具备三个特征:不可修改(或修改可被检测)、可被独立验证、行为可预期。按功能可拆分为三类:

  • RTS(Root of Trust for Storage):保护密钥、计数器、度量日志等敏感状态,通常由 OTP、eFuse、TPM/TPM2.0、安全元件实现。
  • RTM(Root of Trust for Measurement):负责对启动链进行度量,是度量启动的起点,通常由 CPU 微码、Boot ROM 或固化在芯片中的一段不可改代码承担。
  • RTR(Root of Trust for Reporting):负责可信地报告度量结果,如 TPM 的 PCR 与 Quote 签名。

在典型 SoC 中,RoT 往往体现为一段固化在 Boot ROM 中的代码,它持有芯片厂商烧录的公钥哈希,用于验证第一级可写固件(如 BL1、FSBL)的签名。这段代码无法被软件覆盖,因此成为整条信任链的锚点。

二、CRTM:度量启动的第一块砖

CRTM(Core Root of Trust for Measurement)是 RTM 的具体实现,是度量启动中第一个被执行的度量组件。它必须在任何可被修改的固件之前运行,并对下一级固件进行哈希度量,将结果写入 PCR 或度量日志。CRTM 通常位于 Boot ROM 或 TPM 的固件中,其自身不被度量,而是作为度量的“零点”。

关键区别:安全启动依赖“签名验证”决定是否放行;度量启动依赖“哈希记录”决定是否可审计。两者可以独立使用,也可以组合使用——先度量、再验证、后记录,形成可证明的启动过程。

三、信任链传递:逐级验证的链条

信任链传递的本质是:每一级代码在被执行前,先由上一级可信代码验证其完整性和真实性,验证通过后才将控制权交出,同时把信任“传递”给下一级。典型链条如下:

  1. Boot ROM(RoT/CRTM)验证并加载 BL1;
  2. BL1 验证并加载 BL2 / U-Boot SPL;
  3. BL2 验证并加载 BL31、BL33(U-Boot proper);
  4. U-Boot 验证并加载 Linux Kernel 与 DTB;
  5. Kernel 通过 dm-verity / IMA 验证根文件系统与关键应用。

每一级验证通常包括:计算镜像哈希 → 用上一级公钥验证签名 → 检查版本/回滚计数器 → 通过后跳转执行。任何一级失败,启动即中止或进入恢复模式。

信任链传递与度量启动流程 Boot ROM RoT / CRTM BL1 可信固件第一阶段 BL2 / SPL 可信固件第二阶段 BL31 安全监控固件 BL33 / U-Boot 引导加载程序 Linux Kernel 内核 + DTB RootFS dm-verity / IMA 验证+度量 验证+度量 加载 验证 验证+加载 挂载验证 度量记录 PCR[0] = CRTM PCR[1] = BL1 PCR[2] = BL2 PCR[3] = BL31 PCR[4] = BL33 PCR[5] = Kernel TPM Quote 签名报告 RoT/CRTM 起点 安全固件 OS/应用层 度量记录

四、度量启动与安全启动:两种信任建立方式

度量启动(Measured Boot)与安全启动(Secure Boot)常被混淆,但目标不同:

维度 度量启动 安全启动
核心动作 对每级固件计算哈希并记录到 PCR/日志 用公钥验证每级固件签名,失败则拒绝执行
信任建立方式 事后可审计、可远程证明 事前强制拦截、保证只运行授权镜像
典型实现 TPM PCR、IMA、UEFI TCG2 UEFI Secure Boot、ARM Trusted Firmware、Verified Boot
失败后果 记录异常,可继续启动但可被检测 启动中止或进入恢复模式
适用场景 远程证明、合规审计、零信任接入 设备防篡改、固件防回滚、生产设备锁定

实际工程中,两者常组合使用:安全启动负责“不让坏固件跑起来”,度量启动负责“证明跑起来的固件是什么”。例如在 ARM 平台上,ATF 的 BL1/BL2 做签名验证,同时将每级镜像哈希扩展到 TPM PCR,最终由远程服务器通过 Quote 验证设备启动状态。

五、案例与常见误区

案例:某工业网关采用 U-Boot + FIT 镜像签名,Boot ROM 验证 SPL,SPL 验证 U-Boot,U-Boot 验证 Kernel。但运维人员为方便调试,在 U-Boot 环境变量中保留了 bootargs 可覆盖 root= 参数,导致攻击者可通过串口修改启动参数挂载恶意根文件系统。修复方式是锁定环境变量分区并启用 CONFIG_ENV_IS_NOWHERE 或签名保护。

常见误区:

  • 认为“有安全启动就不需要度量启动”——安全启动不提供远程可验证证据。
  • 把 RoT 等同于“一段加密代码”——RoT 的关键是“不可篡改”和“可验证”,而非保密。
  • 忽略回滚保护——攻击者可刷入旧版有漏洞但签名合法的固件,必须配合单调计数器。
  • 信任链断裂在“可写配置区”——环境变量、DTB、initramfs 若未纳入验证,就是后门。
# 查看 TPM PCR 度量值示例
$ tpm2_pcrread sha256:0,1,2,3,4,5
sha256:
  0 : 0x3D4A...  # CRTM
  1 : 0x8B2C...  # BL1
  2 : 0x1F7E...  # BL2
  3 : 0xA9D0...  # BL31
  4 : 0x5C63...  # BL33
  5 : 0xE812...  # Kernel

# 生成 Quote 远程证明
$ tpm2_quote -c 0x81010001 -l sha256:0,1,2,3,4,5 -q $nonce -m quote.msg -s quote.sig

理解 RoT、CRTM、信任链传递、度量启动与安全启动的关系,是设计可信固件体系的第一步。信任不会自动产生,它必须从一颗不可篡改的种子开始,经过每一级的验证与记录,最终形成可证明、可审计、可恢复的启动路径。