4、硬件信任根：eFuse与OTP、TPM安全芯片、硬件安全模块(HSM)

安全启动的链条，总得有个起点。这个起点不能是软件，因为软件可以被篡改。它必须是物理世界里的一个锚点——硬件信任根。

说白了，信任根就是「不可更改的初始秘密」。它决定了你的设备到底信谁。我见过不少团队，软件签名做得花里胡哨，结果信任根没锁死，攻击者直接改个公钥就绕过去了。嗯，那真是白忙一场。

这一章，我们聊聊三种主流的硬件信任根方案：eFuse/OTP、TPM 安全芯片，以及硬件安全模块（HSM）。

核心观点： 信任根必须满足三个条件——不可篡改、不可读取、不可绕过。缺一个，整个安全体系就是纸糊的。
硬件信任根三种方案对比 eFuse / OTP 一次性可编程存储器 • 熔丝/反熔丝物理结构 • 写入后不可擦除 • 存储公钥哈希/芯片ID • 成本低，集成在SoC内 • 容量小（KB级别） 典型用途：存储根公钥 TPM 安全芯片 独立安全协处理器 • 独立芯片/固件TPM • 密钥生成在芯片内部 • 私钥永不出芯片 • 支持PCR度量扩展 • 支持远程证明 典型用途：平台身份认证 HSM 硬件安全模块 • 专用物理隔离设备 • 防篡改封装 • 高速密码运算 • 密钥生命周期管理 • 多租户/审计日志 典型用途：根密钥签名 选择哪种方案，取决于你的安全等级需求、成本预算和产品形态

4.1 eFuse 与 OTP：芯片自带的「熔断开关」

eFuse 和 OTP（One-Time Programmable）是芯片内部的一次性可编程存储单元。你可以把它想象成芯片自带的「熔断开关」——烧断之后，就再也接不回来了。

我个人习惯把 eFuse 叫做「芯片的出厂烙印」。它最常见的用途，就是存储根公钥的哈希值。BootROM 在启动时，会读取这个哈希，然后校验下一级镜像的签名公钥是否匹配。

避坑指南： 我曾经在一个项目里看到，工程师把整个公钥（2048位）直接写进 eFuse。结果容量不够，只能重新流片。正确的做法是只存公钥的哈希（256位），用哈希来校验公钥的完整性。

eFuse 的写入过程是不可逆的。一旦烧写错误，这颗芯片就废了。所以量产时，一定要有严格的校验流程。

特性 eFuse OTP（反熔丝）
物理原理 熔断金属连线 击穿栅氧化层
默认状态 逻辑 0（未熔断） 逻辑 1（未击穿）
写入可靠性 中等（可能熔断不彻底） 高（击穿后稳定）
面积开销 较大 较小
常见工艺 28nm 以下 成熟工艺（180nm+）

你想想看，如果攻击者能物理读取 eFuse 的内容，那存储的密钥就全暴露了。所以，现代 SoC 都会在 eFuse 控制器里加一道「读保护锁」。一旦熔断某个特定的安全位，eFuse 的内容就只能被硬件密码模块使用，软件无法直接读取。

4.2 TPM 安全芯片：独立的「保险柜」

TPM（Trusted Platform Module）是一个独立的密码协处理器。它有自己的 CPU、存储器和密码加速器。私钥在芯片内部生成，也永远留在芯片内部。

我记得第一次接触 TPM 时，最让我惊讶的是它的「密钥永不离开芯片」的设计。就算攻击者物理拆开芯片，也只能看到加密后的密文，真正的私钥在制造时就已经被物理保护起来了。

TPM 在安全启动中的角色，主要是提供平台身份认证和度量启动（Measured Boot）。它会记录每个启动组件的哈希值到 PCR（平台配置寄存器）中。这些 PCR 值只能通过扩展（Extend）操作来更新，无法直接写入。

关键机制： PCR 扩展操作：PCR_new = SHA256(PCR_old || new_measurement)。这意味着启动顺序一旦改变，最终的 PCR 值就会完全不同。远程验证方可以通过比对 PCR 值，判断设备是否被篡改过。

TPM 2.0 规范相比 1.2 版本，增加了更多算法支持和更灵活的授权机制。我个人建议新项目直接上 TPM 2.0，别再用 1.2 了。

  • TPM 1.2： 仅支持 SHA-1、RSA-2048。哈希碰撞风险已存在。
  • TPM 2.0： 支持 SHA-256、ECC、SM2/SM3（国密）。算法可扩展。
  • 固件 TPM（fTPM）： 集成在 CPU 的固件中，成本低，但安全性弱于独立芯片。
注意： fTPM 虽然方便，但它依赖 CPU 固件。如果 CPU 的信任根被攻破，fTPM 的安全性也就无从谈起。对于高安全等级的场景，还是用独立 TPM 芯片更稳妥。

4.3 HSM：工业级的「密钥保险库」

HSM（Hardware Security Module）是硬件信任根里的「重器」。它通常是一个独立的物理设备，有防篡改外壳、主动入侵检测、以及物理销毁机制。

我在做车规级安全启动方案时，接触过不少 HSM。说实话，第一次看到它的价格时，我吓了一跳——一台入门级的 HSM 就要几万块。但当你了解到它保护的密钥价值时，就会觉得这钱花得值。

HSM 的核心能力包括：

  1. 安全密钥生成： 使用硬件真随机数发生器（TRNG），确保密钥不可预测。
  2. 密钥生命周期管理： 从生成、存储、使用到销毁，全程受控。
  3. 高速密码运算： 专用硬件加速，签名速度可达每秒数千次。
  4. 多租户隔离： 不同业务域的密钥互相隔离，互不干扰。
  5. 审计日志： 所有密钥操作都有记录，可追溯。

在安全启动体系中，HSM 通常用于「根签名」环节。产品量产时，用 HSM 对固件进行签名，然后把签名后的固件和公钥一起烧录到设备中。设备端的信任根（eFuse 或 TPM）再校验这个签名。

我的经验： 量产签名环境一定要用 HSM，不要用软件私钥。我曾经见过一个团队，为了省成本，把根私钥放在一个加密 U 盘里。结果 U 盘丢了，整个产品线的信任体系都得重建。HSM 虽然贵，但它是「买保险」，不是「消费」。

4.4 三种方案的选型建议

没有最好的方案，只有最合适的方案。我根据项目经验，整理了一个选型参考：

场景 推荐方案 理由
低成本 IoT 设备 eFuse/OTP 集成在 SoC 内，零额外成本。存储根公钥哈希即可。
PC/服务器 独立 TPM 2.0 标准化接口，支持远程证明，生态成熟。
汽车/工业控制 HSM 或 安全MCU 需要防物理攻击，满足功能安全等级（ASIL-D）。
高安全等级（金融/政务） HSM + TPM 组合 HSM 做根签名，TPM 做平台身份，双重保险。

嗯，这里要注意一点：不管选哪种方案，信任根的「不可绕过性」才是关键。如果攻击者能通过 JTAG 或其它调试接口跳过信任根校验，那再强的硬件也没用。所以，量产时一定要把调试接口锁死。

硬件信任根是安全启动的基石。它不一定要多复杂，但一定要「硬」——物理上不可篡改，逻辑上不可绕过。下一层，我们就要在这个基石上，搭建完整的签名校验链条了。

← 上一章 📖 返回目录 下一章 →