4. 硬件信任根：eFuse、OTP、TPM、HSM 在安全启动中的作用

聊安全启动，绕不开一个核心问题：信任从哪里开始？

你想想看，整个启动链从 ROM 代码开始，一路校验 Bootloader、校验 OS、校验应用。但 ROM 代码自己谁来校验？总得有个绝对可信的起点。这个起点，就是硬件信任根（Root of Trust，RoT）。

我个人习惯把信任根比作「安全世界的奇点」。它必须物理上不可篡改，逻辑上不可绕过。今天我们就来拆解四种最常见的硬件信任根实现：eFuse、OTP、TPM 和 HSM。

4.1 信任根的核心职责

不管用哪种硬件，信任根都要干三件事：

  • 存储根密钥——比如 OEM 公钥哈希、芯片唯一密钥。
  • 提供度量起点——ROM 代码测量自身完整性，然后把控制权交给下一级。
  • 执行不可变策略——比如「禁止从 JTAG 读取密钥」「版本号只增不减」。

这三条缺一条，信任链就断了。

核心原则：信任根必须是 物理不可克隆 且 逻辑不可绕过 的。软件层面的保护都是纸老虎，攻击者只要能用探针读到密钥，你的安全启动就形同虚设。

4.2 eFuse 与 OTP：芯片上的「一次写入」存储器

eFuse 和 OTP 经常被混为一谈，其实它们是一类东西——一次性可编程存储器。写进去就改不了，非常适合存根密钥和防回滚版本号。

4.2.1 eFuse 的工作原理

eFuse 本质上是一根微小的金属熔丝。编程时通过大电流把熔丝熔断，读出时检测电阻变化来判断是 0 还是 1。嗯，这玩意儿一旦熔断就不可逆，所以叫「一次写入」。

我在项目中遇到过一个问题：某款芯片的 eFuse 编程电压没做滤波，量产时偶尔出现熔断不完全，导致密钥位读出来是浮空值。后来我们加了编程时序的硬件重试机制才解决。所以量产前一定要做 eFuse 编程验证，读回来比对，别省这一步。

4.2.2 OTP 与 eFuse 的对比

特性 eFuse OTP（如反熔丝）
物理原理 熔断金属丝 击穿栅氧化层
编程可靠性 中等，受工艺影响 较高，一次击穿永久短路
面积开销 较大（每位需要独立熔丝） 较小（反熔丝结构更紧凑）
典型用途 密钥存储、芯片 ID、版本号 密钥存储、配置锁定
防物理攻击 较弱（可用 SEM 观察熔断状态） 较强（击穿点难以直接观测）

我的建议：如果芯片面积允许，优先用 OTP 存根密钥，用 eFuse 存防回滚版本号。因为版本号需要频繁更新（每次安全更新递增一次），eFuse 的熔断机制更适合少量多次写入；而根密钥一辈子只写一次，OTP 的物理隐蔽性更好。

4.2.3 防回滚中的 eFuse 应用

防回滚最直接的做法：把当前固件版本号写入 eFuse。每次启动时，Bootloader 读取 eFuse 中的版本号，只允许加载 >= 该版本的固件。

我曾经见过一个产品，工程师把版本号存在 Flash 里。结果攻击者把 Flash 吹下来，用编程器把版本号改回旧版，然后刷入有漏洞的旧固件——整个安全启动形同虚设。后来改成 eFuse 存储版本号，这个问题才根治。

// 伪代码：eFuse 版本号校验
uint32_t current_version = read_efuse(EFUSE_BOOT_VERSION);
uint32_t image_version = get_image_version_from_header();

if (image_version < current_version) {
    // 拒绝启动，进入恢复模式
    panic("Rollback detected! Image version too low.");
} else if (image_version > current_version) {
    // 新版本，先更新 eFuse 再启动
    burn_efuse(EFUSE_BOOT_VERSION, image_version);
    boot_image();
} else {
    // 版本匹配，正常启动
    boot_image();
}

注意：eFuse 编程有寿命限制。大多数 eFuse 支持约 10-100 次熔断（取决于工艺）。如果你的产品需要频繁 OTA 更新，要算好版本号递增次数，别把 eFuse 烧穿了。

4.3 TPM：独立的安全协处理器

TPM（Trusted Platform Module）是一个独立的安全芯片，有自己的 CPU、存储和密码引擎。它不依赖主 CPU 来保护密钥——密钥根本不出 TPM 芯片。

说白了，TPM 干的事就是：你给它数据，它给你签名或解密结果，但密钥你永远拿不到。

4.3.1 TPM 在安全启动中的角色

  • 平台配置寄存器（PCR）：存储启动组件的哈希值。ROM 测量 Bootloader，把哈希扩展到 PCR0；Bootloader 测量 OS，扩展到 PCR1……以此类推。任何组件的改动都会导致 PCR 值变化。
  • 密封（Sealing）：可以把解密密钥「绑定」到一组 PCR 值上。只有 PCR 值与密封时完全一致，TPM 才释放密钥。这就实现了「固件没被篡改，密钥才能用」的强绑定。
  • 远程证明：TPM 用 AIK（Attestation Identity Key）对 PCR 值签名，发给远程服务器。服务器验证签名后，就知道设备当前运行的是不是可信固件。

我记得有个客户做工业网关，要求设备启动时必须向云端报告自己的完整性状态。他们就是用 TPM 的远程证明功能：Bootloader 把度量结果扩展到 PCR，然后 TPM 对 PCR 签名，云端验签通过才下发业务配置。这套方案很成熟，但要注意 TPM 的 I²C/SPI 通信可能被中间人攻击——所以度量过程必须在 CPU 和 TPM 之间建立安全通道。

4.3.2 TPM 与 eFuse 的配合

TPM 自己也有 OTP 区域，用来存它的背书密钥（EK）和存储根密钥（SRK）。但 TPM 不直接参与防回滚版本号管理——版本号还是得靠 eFuse 或 OTP 来存。两者分工明确：eFuse 管版本号，TPM 管度量与证明。

4.4 HSM：硬件安全模块的降维打击

HSM（Hardware Security Module）是 TPM 的「大哥」版本。它通常是一个独立的硬件设备，拥有更强的计算能力、更丰富的密码算法支持和更高级的物理防护（比如主动屏蔽层、温度/电压攻击检测）。

在安全启动场景里，HSM 一般用在 服务器端或高端嵌入式设备 上。比如汽车域控制器、金融 POS 终端、军用通信设备。

4.4.1 HSM 的核心能力

  • 高速非对称运算：RSA-4096 签名验证能做到毫秒级，TPM 可能要几百毫秒。
  • 安全密钥生命周期管理：密钥生成、存储、使用、销毁全在 HSM 内部完成，外部无法干预。
  • 防物理攻击：HSM 外壳有防拆传感器，一旦检测到入侵，立即擦除所有密钥。
  • 多级权限控制：不同角色（管理员、审计员、操作员）只能执行授权操作。

我曾经参与过一个金融安全模块的项目，HSM 里存着根 CA 的私钥。每次固件签名时，HSM 会先验证签名请求的合法性（比如请求者身份、固件哈希是否在白名单里），然后才用私钥签名。整个过程私钥从未离开 HSM 芯片。嗯，这才是真正的「硬件信任根」——密钥物理上不可提取。

4.4.2 HSM vs TPM：怎么选？

维度 TPM HSM
成本 低（几美元） 高（几百到几千美元）
性能 中等 高
物理防护 基本（无主动屏蔽） 高级（防拆、防侧信道）
典型场景 PC、IoT 设备、消费电子 金融、汽车、军工、云服务
密钥存储量 有限（通常几十个密钥槽） 大（可存储数千密钥）

我的经验：如果你的产品是消费级 IoT，用 TPM 就够了；如果是车规级或金融级，别省 HSM 的钱。我曾经见过一个汽车 T-Box 项目，为了省成本用了 TPM，结果被侧信道攻击提取了签名密钥——后来全量召回换 HSM，成本翻了 10 倍。

4.5 四种信任根的协同架构

实际产品中，这四种硬件往往不是互斥的，而是协同工作。下面这张图展示了一个典型的高安全嵌入式系统的信任根架构：

硬件信任根协同架构图 硬件信任根协同架构 物理信任根层 eFuse / OTP：存储根密钥哈希、防回滚版本号、芯片唯一 ID 度量与执行层 ROM 代码：读取 eFuse 版本号，度量 Bootloader，扩展 PCR 安全协处理层 TPM / HSM：存储根密钥、执行签名/解密、提供远程证明 应用层：可信固件执行 防回滚版本号 存储在此层 度量链起点 不可绕过 密钥永不离开 硬件边界

从这张图可以看出：eFuse/OTP 是信任的物理根基，ROM 代码是信任的执行起点，TPM/HSM 是信任的密码引擎。 每一层都依赖下一层的不可篡改性，层层递进，最终构建出一条完整的信任链。

4.6 选型建议与避坑指南

最后，我根据实际项目经验，给几条选型建议：

  • 低功耗 IoT 设备：用 SoC 内置的 eFuse + 软件模拟 TPM（如 Intel SGX 的简化版）。成本敏感，但至少要有 eFuse 存版本号。
  • 工业/医疗设备：独立 TPM 芯片 + eFuse。TPM 负责度量与证明，eFuse 负责防回滚。
  • 汽车/金融设备：HSM + OTP。别省这个钱，一旦出事，召回成本远高于 HSM 的差价。
  • 云端/服务器：专用 HSM 集群。密钥管理必须符合 FIPS 140-2 Level 3 以上标准。

我曾经踩过的坑：有个项目选了某款 TPM 芯片，结果发现它的 PCR 扩展操作没有硬件锁定——攻击者可以在 Bootloader 加载前通过 SPI 注入伪造的度量值。后来我们加了一条规则：ROM 代码在度量 Bootloader 之前，先锁定 TPM 的 PCR 扩展接口，禁止外部写入。这个教训告诉我：信任根不仅要防软件攻击，还要防物理接口攻击。

好了，硬件信任根就聊到这里。记住一句话：没有硬件信任根的安全启动，就像建在沙滩上的城堡。 下一层的基础不牢，上面再多的软件保护都是白搭。

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