3. 信任根（RoT）设计：硬件信任根与软件信任根、ATF中的信任根选择
信任根，英文叫 Root of Trust，简称 RoT。说白了，它就是整个安全体系的「原点」。你想想看，如果这个原点都不安全，那后面所有基于它的校验、签名、认证，全都是空中楼阁。
我在做第一个安全启动项目时，对 RoT 的理解还很模糊。总觉得只要代码能跑起来就行。结果有一次，客户要求做 CC EAL5+ 认证，审查员直接问：「你的信任根在哪里？它是如何被保护的？」我当时就愣住了。嗯，从那以后，我花了很多精力去啃 RoT 的设计。
3.1 什么是信任根？
信任根，就是系统中「无条件信任」的实体。它不需要被验证，因为它是验证别人的起点。在嵌入式系统里，RoT 通常是一段固件、一个硬件模块，或者两者的组合。
它的核心职责就两个：
- 度量：测量下一级代码的完整性
- 验证：检查签名是否合法
如果 RoT 本身被篡改，那整个信任链就断了。所以，RoT 必须被物理保护，不能被软件修改。
3.2 硬件信任根 vs 软件信任根
这两者的区别，我习惯用一个比喻来解释：
- 硬件信任根：像一把焊死在主板上的锁。你砸不开，也换不掉。
- 软件信任根：像一把放在保险柜里的钥匙。保险柜本身是安全的，但钥匙可以被复制。
听起来硬件更安全对吧？但事情没那么简单。
3.2.1 硬件信任根（HW RoT）
硬件信任根，通常是一个独立的物理模块。比如：
- SoC 内部的 Boot ROM
- 独立的 TPM 芯片
- 专用的安全协处理器
它的最大优势是：不可篡改。Boot ROM 在芯片制造时就被固化，任何软件都无法修改它。我在项目中遇到过一种攻击手法，叫「电压毛刺攻击」。攻击者通过干扰电源，让 CPU 跳过 Boot ROM 的校验逻辑。但如果是硬件 RoT，这种攻击基本无效，因为校验逻辑是硬连线实现的。
硬件信任根的关键特性：
- 物理不可变性（OTP 或 Mask ROM）
- 抗侧信道攻击
- 独立于主 CPU 运行
3.2.2 软件信任根（SW RoT）
软件信任根，通常是一段存储在只读存储器中的代码。比如：
- Flash 中的 Bootloader
- eMMC 中的启动分区
它的优点是灵活。你可以通过 OTA 更新信任根的逻辑。但缺点也很明显：容易被物理攻击。我曾经调试过一个设备，攻击者直接拆开外壳，用编程器读取了 Flash 中的 Bootloader，然后修改了公钥。嗯，这就是典型的软件 RoT 被攻破的案例。
注意：软件信任根必须依赖硬件保护机制，比如写保护寄存器、OTP 熔丝。否则，它就是纸老虎。
3.3 ATF 中的信任根选择
ATF（ARM Trusted Firmware）对信任根的设计，其实给了你很大的自由度。它不强制你使用硬件 RoT 还是软件 RoT，而是提供了一套框架，让你根据硬件能力来选择。
我个人习惯把 ATF 的信任根分为三个层次：
| 层次 | 信任根载体 | 典型场景 |
|---|---|---|
| L0 | Boot ROM（硬件 RoT） | 手机、平板、高端 IoT |
| L1 | BL1（软件 RoT + 硬件保护） | 服务器、网络设备 |
| L2 | BL2（软件 RoT） | 低端 MCU、简单设备 |
你看，ATF 的 BL1 和 BL2 其实都可以作为信任根。但区别在于：
- BL1 作为 RoT：它运行在 SRAM 中，且 SRAM 在芯片复位时被硬件清零。这保证了 BL1 的「新鲜度」。
- BL2 作为 RoT：它通常存储在 Flash 中，需要依赖硬件写保护。
我在移植 ATF 到某款车规芯片时，就遇到了一个典型问题：芯片的 Boot ROM 太小，只有 8KB，放不下完整的 BL1。怎么办？
我的做法是：把 BL1 拆成两部分。第一部分（约 4KB）放在 Boot ROM 中，作为硬件 RoT。它只做一件事：加载并验证第二部分的 BL1。第二部分（约 20KB）放在 SRAM 中，完成剩余的初始化工作。这样既保证了安全性，又解决了空间问题。
3.4 信任根的选择策略
说了这么多，到底该怎么选？我总结了一个简单的决策树：
- 你的芯片有 Boot ROM 吗？
- 有 → 优先使用 Boot ROM 作为硬件 RoT
- 没有 → 考虑使用 BL1 或 BL2
- 你的芯片有 OTP 吗？
- 有 → 可以把公钥哈希烧录到 OTP 中，增强安全性
- 没有 → 只能把公钥放在 Flash 中，但需要额外的保护
- 你的产品需要防物理攻击吗？
- 需要 → 必须用硬件 RoT
- 不需要 → 软件 RoT 就够了
我的建议：如果条件允许，尽量使用硬件 RoT。虽然移植起来麻烦一点，但后续的认证和审计会轻松很多。我曾经帮客户做过一次渗透测试，软件 RoT 的设备平均 2 小时就被攻破了，而硬件 RoT 的设备撑了整整 3 天。
3.5 信任根的核心逻辑图
下面这张图，是我自己画的一个信任根设计框架。它展示了从硬件 RoT 到 BL33 的完整信任链：
这张图里，我特意把「硬件保护机制」单独列了出来。为什么？因为很多开发者只关注信任链的传递，却忽略了底层的保护。我曾经见过一个产品，BL1 的签名验证做得天衣无缝，但攻击者直接通过 JTAG 接口把 BL1 给替换了。嗯，这就是典型的「信任根没被物理保护」的教训。
3.6 避坑指南
最后，分享几个我踩过的坑：
- 不要假设 Boot ROM 是安全的：有些芯片的 Boot ROM 有漏洞，比如允许跳过签名验证。一定要查阅芯片的勘误表。
- OTP 熔丝要留够余量：我遇到过 OTP 烧录一次后，发现公钥哈希写错了，结果整批芯片报废。建议预留几个熔丝位用于测试。
- 注意信任根的更新机制：如果产品需要 OTA 更新信任根，一定要设计回滚保护。否则攻击者可以刷回旧版本的信任根。
信任根的设计，说白了就是「信任的起点」的选择。选对了，后面的工作就顺风顺水。选错了，整个安全体系都是空中楼阁。希望今天的分享，能帮你少走一些弯路。