信任链核心组件：Boot ROM、安全引导加载器、安全操作系统、安全应用

设备信任链，说白了就是一条「谁信谁」的链条。从硬件上电那一刻起，每一级软件都要验证下一级的身份和完整性。我做了这么多年安全固件，见过太多因为某一环没锁死，整条链就崩了的案例。

这一章我们拆开来看四个核心组件：Boot ROM、安全引导加载器、安全操作系统、安全应用。它们各自负责什么？怎么衔接？坑在哪？

2.1 Boot ROM：信任的根

Boot ROM 是芯片上电后执行的第一段代码。它固化在芯片内部，不可更改。这就是整个信任链的「根」——如果根烂了，上面长什么都白搭。

我个人习惯把 Boot ROM 比作「保险箱的锁芯」。它必须满足三个条件：

• 不可篡改：出厂后代码不能改，物理上只读。
• 最小化：功能越少，攻击面越小。只做一件事——验证下一级镜像。
• 硬件锚定：通常配合 OTP（一次性可编程存储器）或 eFuse 来存储根公钥哈希。

我在项目中遇到过一个问题：某款芯片的 Boot ROM 里留了个调试后门，可以通过特定 GPIO 电平跳过签名校验。嗯，这相当于保险箱的锁芯旁边留了个备用钥匙孔。后来我们不得不通过 eFuse 熔断来禁用这个后门。

2.2 安全引导加载器：承上启下

Boot ROM 验证通过后，控制权交给安全引导加载器（Secure Bootloader）。它通常分为两个阶段：

• SPL（Secondary Program Loader）：初始化 DDR、时钟等基础硬件。
• U-Boot 或类似组件：加载操作系统内核，并验证其签名。

你想想看，引导加载器是信任链里最脆弱的一环。为什么？因为它运行在内存里，内存天然容易被物理攻击。比如冷启动攻击、DMA 攻击，都能直接读取或篡改内存中的代码。

安全引导加载器还需要做一件事：度量启动。它把当前阶段的代码哈希值扩展到 TPM（可信平台模块）的 PCR 寄存器里。这样，后续阶段可以查询 PCR 值，确认整个启动过程没有被篡改。

2.3 安全操作系统：隔离与策略

操作系统是信任链的「执行者」。它负责把硬件提供的信任能力，转化为系统级的安全策略。

我个人比较推崇的方案是：分离内核。一个普通 Linux 内核跑用户应用，一个微型安全内核（如 OPTEE、Trusty）跑安全服务。两个内核通过硬件隔离（如 ARM TrustZone 或 RISC-V 物理内存保护）隔开。

特性	普通内核	安全内核
运行环境	非安全世界（Normal World）	安全世界（Secure World）
访问权限	受限，不能访问安全内存	可访问所有内存
典型功能	UI、网络、文件系统	密钥管理、指纹比对、支付
攻击面	大，暴露给用户	小，仅暴露安全服务接口

安全操作系统启动时，会验证自己的镜像签名。这个签名链一直追溯到 Boot ROM 里的根公钥。同时，它还会检查安全应用的签名——这就是下一级信任传递。

2.4 安全应用：最后一公里

安全应用（Trusted Application, TA）运行在安全操作系统之上。它处理真正的敏感操作：生成密钥、加解密数据、验证用户身份。

安全应用与普通应用通过 安全监控调用（SMC） 通信。普通应用发起请求，安全监控模式切换上下文，安全应用处理，再返回结果。整个过程，普通应用拿不到安全应用的代码和数据。

这里有个容易被忽略的点：安全应用的身份管理。每个 TA 必须有一个唯一的 UUID，并且它的镜像必须由设备厂商签名。安全内核在加载 TA 时，会校验这个签名。如果签名无效，直接拒绝加载。

我曾经见过一个支付应用，把私钥和加解密逻辑放在同一个 TA 里。结果攻击者通过侧信道攻击拿到了私钥。如果当时把私钥存储和加解密操作分开到两个 TA，攻击者即使拿到加解密接口，也拿不到私钥本身。

2.5 信任链全景图

下面这张图展示了四个组件的启动顺序和信任传递关系。你可以看到，每一级都验证下一级的签名，形成一条完整的信任链。

2.6 常见问题与避坑

最后，我总结几个实际项目中容易踩的坑：

• Boot ROM 回退漏洞：有些芯片允许回退到旧版本 Boot ROM。攻击者可以利用旧版本的已知漏洞。解决方案是 eFuse 熔断，禁止回退。
• 引导加载器未锁定调试接口：JTAG/SWD 接口如果在引导加载器阶段还开着，攻击者可以直接 halt CPU，读取内存。我建议在 Boot ROM 阶段就熔断调试接口。
• 安全操作系统未校验 TA 签名：有些实现为了性能，跳过了 TA 签名校验。这等于把安全世界的门敞开了。一定要校验，而且要用硬件加速的签名验证。
• 安全应用日志泄露：安全应用里的调试日志如果没关，可能会泄露密钥或敏感数据。生产版本必须关闭所有调试输出。