3、硬件信任根（RoT）：eFuse、OTP、TPM、HSM 的概念与作用
聊可信启动，绕不开一个核心问题：信任从哪里开始？
你想想看，整个启动链——从 BootROM 到 Bootloader，再到内核、文件系统——每一级都要验证下一级的签名。但第一级代码谁来验证？它自己就是起点。这个起点，就是硬件信任根（Root of Trust，RoT）。
说白了，RoT 是一个不可篡改的硬件锚点。它保证设备一上电，执行的第一条指令就是可信的。我这些年做嵌入式安全，见过太多因为 RoT 没做好，整个安全体系崩塌的案例。嗯，今天我们就把它彻底讲透。
3.1 为什么需要硬件信任根？
纯软件方案不行吗？
理论上可以。比如把公钥硬编码在 BootROM 里。但问题是，BootROM 虽然只读，攻击者却能通过电压毛刺、激光注入等方式，让它跳过验证逻辑。一旦跳过，后面加载的镜像就全是恶意的了。
硬件信任根的核心价值在于：它把信任锚点从易受攻击的代码，转移到了物理不可克隆的硬件特性上。攻击者要改 RoT，就得改芯片本身——这成本高到几乎不可能。
核心原则：信任链的长度取决于 RoT 的强度。RoT 一旦被攻破，整个安全体系归零。
3.2 四种主流硬件信任根
实际项目中，我接触最多的就是这四种：eFuse、OTP、TPM、HSM。它们各有各的脾气，选型时得看场景。
| 类型 | 存储介质 | 可编程性 | 典型容量 | 主要用途 |
|---|---|---|---|---|
| eFuse | 硅熔丝 | 一次性写入（OTP） | 几百 bit ~ 几 Kbit | 芯片 ID、密钥存储、安全配置 |
| OTP | 反熔丝 / 电荷陷阱 | 一次性写入（可分区锁定） | 几 Kbit ~ 几十 Kbit | 公钥哈希、设备密钥、启动配置 |
| TPM | 独立安全芯片 | 可多次写入（受策略控制） | 几 MB（含 NVRAM） | 平台完整性度量、密钥管理、远程证明 |
| HSM | 独立硬件安全模块 | 可多次写入（高安全策略） | 几 MB ~ 几十 MB | 密钥全生命周期管理、签名/验签、加密运算 |
3.3 eFuse：芯片出厂后的第一道锁
eFuse 本质上是一根根硅熔丝。出厂时所有熔丝都是导通的（逻辑 0）。写入时，通过大电流把熔丝烧断（逻辑 1）。烧断后不可恢复，所以叫一次性可编程（OTP）。
我个人习惯把 eFuse 比作芯片的「出厂烙印」。它通常用来存：
- 芯片唯一 ID：每颗芯片一个，用于身份识别。
- 根密钥的哈希值：BootROM 用这个哈希验证公钥的完整性。
- 安全配置位：比如禁用 JTAG、锁定调试接口。
避坑指南：我曾经在一个项目中，工程师把 eFuse 的写入电压算错了，结果整批芯片的熔丝烧断不完全，导致密钥位读取不稳定。嗯，从那以后我要求每次 eFuse 写入前，必须做电压校准和校验回读。
3.4 OTP：更灵活的「一次性」存储
OTP 和 eFuse 很像，但技术实现不同。OTP 用的是反熔丝或电荷陷阱结构。写入后，存储单元的状态永久改变。
OTP 比 eFuse 的优势在于：可以分区锁定。比如，前 1Kbit 存公钥哈希，锁定为只读；后 2Kbit 存设备密钥，可以在产线写入后再锁定。这种灵活性在量产中非常实用。
我建议在 OTP 里至少存以下内容：
- 根公钥的 SHA-256 哈希（32 字节）
- 设备唯一密钥（16~32 字节）
- 安全启动配置（如允许降级的版本号下限）
- 生命周期状态（开发→试产→量产→报废）
注意：OTP 空间非常宝贵。我见过有人把整个公钥（256 字节）塞进 OTP，结果空间不够，不得不砍掉其他安全功能。正确的做法是只存哈希，公钥放在 Flash 里，启动时用哈希校验公钥。
3.5 TPM：平台信任的「公证人」
TPM（Trusted Platform Module）是一个独立的安全芯片。它不像 eFuse/OTP 那样只是存储，它有自己的处理器、真随机数发生器、非对称加密引擎。
TPM 的核心能力是平台配置寄存器（PCR）。PCR 的值只能通过扩展操作（PCR_Extend）来更新：
// PCR 扩展操作示意
new_pcr_value = SHA256(old_pcr_value || measurement_data)启动过程中，每个阶段的代码度量值依次扩展到 PCR 里。最终 PCR 的值就代表了整个启动链的完整性状态。攻击者哪怕改了镜像，PCR 的值也会对不上。
我记得有一次做服务器可信启动，客户要求用 TPM 做远程证明。TPM 用 PCR 值签名后发给验证服务器，服务器比对预期值。整个过程不需要暴露任何密钥——TPM 自己管理私钥，外部根本拿不到。
3.6 HSM：企业级密钥的「保险柜」
HSM（Hardware Security Module）是这四种里最「重」的。它通常是一个独立的硬件设备，有防篡改外壳、温度/电压传感器、自毁机制。
HSM 的主要场景是：
- 密钥生成：在 HSM 内部生成密钥，私钥永远不离开硬件。
- 签名/验签：镜像签名操作在 HSM 内部完成。
- 密钥备份：用 HSM 的密钥封装功能，安全导出加密后的密钥副本。
在产线中，HSM 通常作为根签名机。所有固件镜像的签名，都在 HSM 内部完成。私钥一旦被提取，整个产品线的信任就崩塌了。
我的建议：如果产品对安全等级要求极高（比如金融支付、车规级），直接用 HSM 做根签名。虽然贵，但出事后赔偿的金额够买几百个 HSM 了。
3.7 四种 RoT 的选型对比
实际项目中怎么选？我整理了一个决策矩阵：
| 需求场景 | 推荐方案 | 理由 |
|---|---|---|
| 低成本 IoT 设备 | eFuse + OTP | 集成在 SoC 内，几乎零额外成本 |
| 通用计算平台（PC/服务器） | TPM | 标准化接口，支持远程证明 |
| 高安全嵌入式（汽车/工控） | eFuse + 独立 TPM/HSM | 芯片内 RoT 做第一级，独立芯片做密钥管理 |
| 金融/政务/云基础设施 | HSM | 合规要求，防物理攻击 |
3.8 硬件信任根在可信启动中的位置
下面这张图展示了 RoT 在启动链中的核心位置。你可以看到，所有信任都从芯片内部的 RoT 开始，逐级传递到外部镜像。
3.9 实际项目中的避坑经验
做了这么多年安全，踩过的坑不少。分享几个印象深刻的：
- eFuse 写入不可逆，测试阶段别乱烧：我曾经有同事在开发板上烧了 eFuse 的 JTAG 禁用位，结果芯片再也无法调试，只能换板子。建议开发阶段用软件模拟 RoT，量产前再烧写。
- OTP 空间规划要留余量：产品迭代过程中，可能需要增加新的安全配置位。如果 OTP 空间用满，就只能换芯片型号。我一般预留 20%~30% 的空间给未来扩展。
- TPM 的 PCR 值不是越多越好：有些工程师喜欢把所有度量都塞进 PCR，结果 PCR 数量不够用。建议只度量关键组件（BootROM、Bootloader、内核、关键配置），其他组件用内核的 IMA 机制度量。
- HSM 的密钥备份要谨慎：HSM 的私钥一旦丢失，所有已签名的镜像都无法再更新。我建议用 HSM 的密钥封装功能，生成两份加密备份，分别存放在不同地理位置的保险柜里。
个人习惯：每次设计 RoT 方案时，我都会先画一张「信任链传递图」，明确每一级信任谁、用什么密钥、验证什么内容。这张图画清楚了，代码实现基本不会跑偏。
3.10 小结
硬件信任根是整个可信启动的基石。eFuse 和 OTP 适合做芯片内的轻量级锚点，TPM 适合做平台级的完整性度量，HSM 适合做企业级的密钥管理。选型时，根据产品的安全等级、成本预算、量产规模来权衡。
记住一句话：信任不能凭空产生，必须有一个不可篡改的硬件起点。这个起点，就是 RoT。