4. 硬件信任根:eFuse、OTP、TPM、HSM 在启动校验中的角色

聊启动校验,绕不开一个核心问题:第一个信任从哪来?

你想想看,整个校验链条再长,总得有个起点。这个起点不能依赖任何软件,不能依赖外部输入,它必须是硬件层面固化的、不可篡改的。这就是我们常说的「硬件信任根」(Hardware Root of Trust)。

今天咱们就掰开揉碎,聊聊四个最常见的硬件信任根载体:eFuse、OTP、TPM 和 HSM。它们各自扮演什么角色?什么时候该用谁?我踩过哪些坑?

4.1 信任链的起点:为什么需要硬件根?

先讲个我自己的教训。早年做一款 IoT 网关,当时图省事,把公钥哈希直接写死在 Flash 里。结果呢?攻击者通过电压故障注入,把 Flash 里那段校验公钥给改了,然后用自己的固件签了个名……整批设备直接沦陷。

从那以后我明白一个道理:信任根必须物理不可变。你不能让攻击者通过任何软件手段改写它,甚至不能通过物理探针读取它。这就是硬件信任根存在的意义——它是一堵墙,把攻击者挡在信任链之外。

核心原则: 信任链的强度,取决于最弱的那一环。如果根是软的,整条链就是软的。

4.2 eFuse:一次性编程的「保险丝」

eFuse 这名字挺形象——电子保险丝。它本质上是一小段硅导线,出厂时是导通的。你通过施加超过额定值的电流把它熔断,就相当于写入了「1」。熔断后不可恢复,所以叫一次性编程(OTP)。

4.2.1 典型用途

  • 存储根密钥哈希: 把公钥的 SHA-256 哈希熔进 eFuse,BootROM 启动时直接读它来验签。
  • 芯片身份标识: 每颗芯片熔入唯一 ID,用于设备认证。
  • 安全配置位: 比如禁用调试接口、锁定 JTAG、强制安全启动模式。

4.2.2 避坑指南

我曾经在一个项目里吃过亏:量产时发现一批芯片的 eFuse 熔断失败,原因是编程电压时序没对准。eFuse 对电流脉冲宽度非常敏感,短了熔不断,长了可能伤及周边电路。所以我的建议是:量产前一定要做编程良率验证,至少 1000 颗样本。

注意: eFuse 的位密度很低,通常只有几百到几千比特。别指望用它存大密钥或固件。它只适合存「根」——比如一个哈希值或一个对称密钥。

4.3 OTP:更灵活的一次性存储

OTP(One-Time Programmable)和 eFuse 本质是一类东西,但实现方式更多样。除了熔断式,还有反熔丝(Antifuse)、电荷俘获(Charge Trap)等。OTP 的容量通常比 eFuse 大一些,可以达到几十 Kb。

4.3.1 OTP vs eFuse

特性 eFuse OTP
编程原理 电迁移熔断 反熔丝/电荷俘获
容量 小(通常 < 1Kb) 中等(可达 64Kb)
编程可靠性 对电流敏感 相对稳定
读取速度 快 快
典型场景 根密钥哈希、配置位 密钥存储、校准参数

我个人习惯:根哈希用 eFuse,密钥本体用 OTP。因为 OTP 容量大一点,可以存一个 AES-256 密钥或 ECC 私钥,而 eFuse 只存它的校验值。

4.4 TPM:专用的安全协处理器

TPM(Trusted Platform Module)是个独立的芯片,或者集成在 SoC 里的安全单元。它不只是存储,还能做密码运算、生成密钥、度量启动状态。

4.4.1 TPM 在启动校验中的角色

  • 平台配置寄存器(PCR): TPM 内部有一组 PCR,只能通过 Extend 操作写入。每次启动,BootROM 把固件哈希 Extend 进 PCR0,下一个阶段把下一级哈希 Extend 进 PCR1……最终 PCR 值反映了整个启动链的状态。
  • 密封(Seal): 可以把密钥「密封」到某个 PCR 值上。只有 PCR 值匹配时,TPM 才释放密钥。这意味着:如果固件被篡改,PCR 值不对,密钥就永远拿不出来。
  • 远程证明: TPM 可以用 Attestation Identity Key(AIK)对 PCR 值签名,发给远程服务器验证设备是否处于可信状态。
经验之谈: 我做过一个服务器可信启动项目,用 TPM 2.0 做度量启动。最头疼的是 PCR 的「顺序」——如果某个阶段的度量顺序错了,整个 PCR 值就不对。调试时建议先把 PCR 值打印出来,和预期值逐位比对。

4.5 HSM:企业级的硬件安全模块

HSM(Hardware Security Module)是 TPM 的「大哥」。它通常是个独立设备,插在服务器机箱里或做成 PCIe 卡。HSM 的运算能力更强,密钥管理更完善,而且有物理防篡改——拆开外壳会自动擦除密钥。

4.5.1 HSM 在启动校验中的角色

  • 代码签名: 在开发/生产环境中,HSM 持有根签名私钥,对固件进行签名。私钥永远不离开 HSM。
  • 密钥分发: HSM 生成设备密钥对,把公钥注入设备,私钥留在 HSM 中用于后续验证。
  • 批量验证: 在服务器端,HSM 可以高速验证大量设备的启动度量报告。

说白了,TPM 是「设备端」的信任根,HSM 是「后端」的信任根。两者配合使用,才能形成完整的信任闭环。

4.6 四种方案的选型对比

方案 成本 安全等级 适用场景
eFuse 极低(片上) 中(防软件篡改) MCU、低成本 IoT
OTP 低(片上) 中高(防物理读取) 嵌入式设备、消费电子
TPM 中(独立芯片) 高(防物理+密码加速) PC、服务器、网关
HSM 高(独立设备) 极高(防拆+合规认证) 云端签名、金融、政府

4.7 一张图看懂硬件信任根体系

下面这张图展示了四种硬件信任根在启动校验中的位置和关系:

硬件信任根体系结构图 硬件信任根体系结构 设备端 后端 eFuse 根哈希 / 配置位 OTP 密钥 / 校准参数 TPM PCR 度量 / 密封 / 远程证明 设备端信任根 HSM 代码签名 / 密钥分发 / 批量验证 后端信任根 远程证明 信任链传递 BootROM → eFuse/OTP 读取根哈希 → 验签下一级 → TPM 度量 → 远程 HSM 验证

4.8 我的选型建议

说了这么多,到底怎么选?我个人的经验是:

  • 如果你做的是低成本 MCU 产品(比如智能灯泡、传感器),eFuse 存个根哈希就够了。成本敏感,安全需求不高。
  • 如果是消费类嵌入式设备(比如路由器、摄像头),建议上 OTP 存密钥,配合安全启动。性价比最优。
  • 如果是 PC、服务器或工业网关,别省那几块钱,上 TPM。PCR 度量启动能让你在攻击发生后快速定位问题。
  • 如果是云端签名基础设施,HSM 是必须的。没有 HSM 的代码签名,等于把家门的钥匙挂在门外。
一个小技巧: 很多 SoC 现在把 eFuse 和 TPM 功能集成在一起了。比如某款主流车规芯片,内部有 eFuse 存根密钥,同时内置一个 TPM 2.0 引擎。选型时多看看芯片的安全特性,说不定能省一个独立 TPM 的成本。

嗯,硬件信任根这块就聊到这儿。记住一句话:信任是设计出来的,不是宣称出来的。选对硬件根,你的启动校验才算真正有了「根」。