4、硬件信任根（RoT）：eFuse、OTP、TPM芯片在启动校验中的作用
聊到启动校验，有个绕不开的基石——信任根。
说白了，整个安全启动链条，总得有个「绝对可信」的起点。这个起点不能是软件，因为软件可以被篡改。它必须是硬件层面的、物理上不可篡改的东西。
这就是我们今天要聊的硬件信任根（Root of Trust, RoT）。我这些年做过的产品，但凡涉及安全启动，无一例外都要跟这三样东西打交道：eFuse、OTP、TPM芯片。
4.1 信任根到底解决什么问题？
先想一个问题：BootROM 里的代码，谁来验证它的完整性？
答案是：没人验证。BootROM 本身就是信任的起点。
但 BootROM 是掩膜在芯片内部的只读代码，出厂后无法修改。它只能做一件事——去验证下一级代码（比如 Bootloader）的签名。那验证签名需要的公钥哈希，存在哪里？
嗯，这就是硬件信任根要干的事：提供一个不可篡改的存储介质，存放公钥指纹、芯片身份、安全配置等关键信息。
核心观点：信任根不是「验证」出来的，而是「物理保证」出来的。只要根不被污染，整条链就安全。
4.2 eFuse：一次性可编程的「熔丝」
eFuse 是我用得最多的信任根载体。它本质上是一根硅熔丝，出厂时全部导通（逻辑 0）。通过施加超过额定值的电流，可以把熔丝熔断（逻辑 1）。
熔断后不可恢复。这就是「一次性可编程」的含义。
4.2.1 eFuse 存什么？
- 公钥哈希（Key Hash）：BootROM 用这个哈希去验证 Bootloader 签名的公钥是否可信。
- 安全启动使能位：熔断后强制开启安全启动，无法关闭。
- 芯片唯一 ID：用于设备身份认证。
- 调试接口锁定：熔断后 JTAG/SWD 接口永久关闭，防止调试器攻击。
我的经验：我在一个 IoT 项目里吃过亏——eFuse 的编程电压没控制好，导致熔断不完全，芯片启动时公钥哈希读出来是错的。后来我强制要求：eFuse 编程后必须回读校验三次，任何一次不一致就报废。
4.2.2 eFuse 的局限性
| 特性 | 说明 |
|---|---|
| 容量小 | 通常只有几百到几千比特，存不了大密钥 |
| 一次性 | 写错就废，无法擦除重写 |
| 物理可探测 | 高端攻击者可以用 SEM（扫描电子显微镜）读取熔丝状态 |
4.3 OTP：更灵活的「一次性可编程存储器」
OTP（One-Time Programmable）跟 eFuse 理念类似，但实现方式不同。OTP 通常使用反熔丝技术——编程时在栅氧化层上击穿一个导电通道。
我个人觉得，OTP 比 eFuse 更适合存「少量但关键」的数据。为什么？因为 OTP 的读取功耗更低，而且可以按位编程，不需要一次性写完。
4.3.1 OTP 的典型分区
OTP Memory Map (64-bit example):
+----------------------------+
| Bit 0-31: Key Hash[31:0] |
| Bit 32-47: Chip ID[15:0] |
| Bit 48-55: Security Flags |
| Bit 56-63: Reserved |
+----------------------------+
你想想看，这种结构在量产时非常方便。先写芯片 ID，再写安全标志，最后写密钥哈希——每一步都可以独立完成。
注意：OTP 的编程次数虽然叫「一次性」，但很多芯片支持按字（word）编程。比如 64 位的 OTP，可以分 4 次每次写 16 位。但一旦某一位被写为 1，就再也变不回 0 了。
4.4 TPM 芯片：独立的安全协处理器
eFuse 和 OTP 都是芯片内部的。那如果主芯片本身就不安全呢？
这时候就需要 TPM（Trusted Platform Module）了。TPM 是一颗独立的芯片，有自己的处理器、存储器和加密引擎。它跟主芯片通过 LPC 或 SPI 总线通信。
4.4.1 TPM 的核心能力
- 平台配置寄存器（PCR）：存储启动过程中各阶段的哈希值。每次扩展（Extend）操作都会更新 PCR，无法回滚。
- 背书密钥（EK）：出厂时写入的唯一身份密钥，用于证明芯片身份。
- 存储根密钥（SRK）：用于加密其他密钥，保证密钥不在总线上明文传输。
- 密封（Seal）功能：只有 PCR 值匹配时，才能解封数据。
实际场景：我在做一款金融 POS 机时，主芯片用的是普通 ARM Cortex-A 系列，没有硬件信任根。我们外挂了一颗 TPM 2.0 芯片。启动时，BootROM 先测量自身，把哈希扩展到 PCR[0]；然后测量 Bootloader，扩展到 PCR[1]；再测量内核，扩展到 PCR[2]。如果任何一个 PCR 值跟预期不符，TPM 拒绝释放磁盘加密密钥——机器直接变砖。
4.4.2 TPM vs eFuse/OTP：怎么选？
| 维度 | eFuse / OTP | TPM 芯片 |
|---|---|---|
| 成本 | 几乎零成本（集成在芯片内） | 额外 1-3 美元 |
| 容量 | 小（几百比特） | 大（几十 KB 非易失存储） |
| 灵活性 | 一次性写入，不可更改 | 可多次扩展 PCR，支持动态信任链 |
| 抗物理攻击 | 中等（可被 SEM 读取） | 高（有主动屏蔽层和传感器） |
| 适用场景 | 轻量级 IoT、MCU | PC、服务器、金融设备 |
4.5 硬件信任根在启动链中的位置
为了让你更直观地理解，我画了一张图。这张图展示了从芯片上电到操作系统加载的完整信任链，以及 eFuse/OTP 和 TPM 各自扮演的角色。
4.6 避坑指南：我踩过的三个坑
做硬件信任根设计，有些坑是教科书上不会写的。我分享三个真实经历：
- eFuse 编程顺序搞反了：有一次我先熔断了安全启动使能位，然后才去写公钥哈希。结果写到一半掉电了——哈希没写完，但安全启动已经强制开启。芯片直接变砖，整批 2000 片报废。后来我改了流程：先写所有数据，最后再熔断使能位。
- TPM PCR 扩展顺序没对齐：BootROM 和 Bootloader 对同一个组件的度量顺序不一致，导致 PCR 值对不上。排查了两天才发现是哈希扩展的输入顺序反了。我现在的习惯是：把 PCR 扩展策略写进设计文档，代码生成时自动检查一致性。
- OTP 读时序不满足：某款芯片的 OTP 读取需要等待 50ns 才能稳定，但 BootROM 代码在复位后立即读取，导致读到全 0。加了一个 NOP 延时就好了。嗯，这种问题仿真很难发现，必须实测。
重要提醒：硬件信任根一旦部署错误，几乎没有补救机会。eFuse 熔断了就是熔断了，OTP 写错了就是写错了。量产前务必做「破坏性测试」——故意写错数据，验证芯片是否能正确拒绝启动。
4.7 小结
硬件信任根是整个安全启动的基石。eFuse 和 OTP 适合做轻量级的静态信任根，成本低、集成度高；TPM 芯片适合做动态信任链，功能强、安全性高。
选哪种方案，取决于你的产品对成本、安全等级和灵活性的要求。我个人建议：能用 eFuse 解决的问题，不要上 TPM；但一旦涉及金融级安全，别省那颗 TPM 的钱。