硬件信任根（RoT）：TPM、HSM、eFuse——信任的起点

各位同学，我们开始第二讲。

上一章我们聊了信任传递链的整体轮廓。说白了，整个链条的起点就是——硬件信任根。没有它，后面所有的签名校验、安全启动都是空中楼阁。

我经常跟团队说一句话：“信任不能凭空产生，必须有一个物理锚点。” 这个锚点，就是今天我们要讲的三个硬件模块：TPM、HSM、eFuse。

2.1 信任根到底解决什么问题？

先想一个问题：CPU 上电后执行的第一条指令，怎么知道它是安全的？

你可能会说：“代码是写在 ROM 里的，改不了啊。” 没错，但 ROM 里的代码怎么验证下一级固件？它需要一把公钥。这把公钥存在哪？如果存在 Flash 里，攻击者可以替换。存在寄存器里？掉电就没了。

所以，我们需要一个不可篡改、不可伪造、物理隔离的存储和计算环境。这就是硬件信任根。

核心定义：硬件信任根（Root of Trust, RoT）是一个在物理上受保护的模块，它提供可信的度量、存储和报告能力。它是整个安全体系的“原点”。

2.2 三大硬件信任根详解

我按自己的理解，把它们分成三类。你想想看，它们各自解决不同层面的问题。

2.2.1 eFuse——一次性可编程的“物理熔丝”

eFuse 是最底层的信任根。它本质上是一根根硅上的熔丝，通过大电流烧断来存储信息。烧断后不可恢复。

它存什么？

  • 芯片唯一 ID
  • 根密钥的哈希值
  • 安全启动的配置位（比如：是否强制校验签名）
  • 调试接口的锁定状态

我在项目中遇到过一件事：某款芯片的 eFuse 空间只有 128 位，但我们需要存储 256 位的根密钥哈希。怎么办？最后方案是把密钥哈希截断到 128 位，配合芯片唯一 ID 做派生。嗯，这是妥协，但硬件限制摆在那。

注意：eFuse 烧录是一次性的。一旦烧错，芯片就废了。我见过有人把调试锁定位烧反了，整批 5000 片芯片无法调试，只能报废。所以量产烧录前，务必做三次模拟验证。

2.2.2 TPM——专用安全芯片

TPM（Trusted Platform Module）是一个独立的安全协处理器。它有自己的 CPU、ROM、SRAM、非易失性存储，甚至还有真随机数发生器。

TPM 的核心能力：

  • 平台配置寄存器（PCR）： 存储度量值的哈希链，用于记录系统状态
  • 背书密钥（EK）： 芯片出厂时注入的唯一身份凭证
  • 存储根密钥（SRK）： 保护用户数据的加密密钥
  • 远程证明： 向远程服务器证明“我是一台干净的机器”

我个人习惯把 TPM 看作“系统的黑匣子”。它不参与主 CPU 的计算，只负责记录和报告。攻击者即使控制了操作系统，也无法篡改 PCR 里的值——因为 PCR 只能扩展（extend），不能重置（除非物理复位）。

特性 TPM 2.0 eFuse HSM
可编程性 可多次写入（PCR扩展） 一次性烧录 可编程，但受策略控制
密钥存储量 有限（通常 24 个 PCR + 少量 NV 索引） 极少（几十到几百位） 大（可存储数千个密钥）
计算能力 有（支持 RSA/ECC/SHA） 无 强（支持硬件加速加密）
典型应用 PC、服务器、IoT 网关 SoC 内部、嵌入式设备 金融、CA、云端密钥管理
成本 中等（$1-$5） 极低（芯片内集成） 高（$100-$10000+）

2.2.3 HSM——企业级“保险柜”

HSM（Hardware Security Module）是 TPM 的“大哥”。它通常是一个独立的硬件设备，有防篡改外壳、温度/电压传感器，甚至有的型号内部灌了环氧树脂——想拆开？芯片会自毁。

HSM 主要用于：

  • CA 根证书的签名
  • 支付系统的密钥管理
  • 云端 KMS（密钥管理服务）的硬件后端

我曾经帮一家银行部署 HSM，他们的要求是：密钥一旦写入 HSM，任何人（包括管理员）都无法导出明文。所有签名操作必须在 HSM 内部完成。这就是所谓的“密钥不出硬件”。

一个小技巧：如果你在做产品选型，记住这个原则——eFuse 管“根”，TPM 管“链”，HSM 管“服务”。eFuse 保护最底层的根密钥，TPM 负责启动过程中的度量链，HSM 负责运行时的密钥服务。三者可以协同工作。

2.3 信任链的起点：从 eFuse 到 TPM

现在我们把三个模块串起来，看看实际启动流程中它们如何配合。

// 伪代码：信任链初始化流程
void boot_chain_init() {
    // 1. CPU 从 ROM 启动，读取 eFuse
    hash_t root_hash = efuse_read(EFUSE_ROOT_KEY_HASH);
    
    // 2. 验证 BootROM 自身的完整性（自检）
    if (!sha256_verify(rom_code, rom_signature, root_hash)) {
        panic("BootROM integrity check failed!");
    }
    
    // 3. 度量下一级（SPL/BL1），将度量值扩展到 TPM PCR
    tpm_pcr_extend(0, sha256(bl1_code));
    
    // 4. 用 eFuse 中的密钥验证 BL1 签名
    if (!rsa_verify(bl1_code, bl1_signature, root_hash)) {
        panic("BL1 signature verification failed!");
    }
    
    // 5. 跳转到 BL1，继续传递信任
    jump_to(bl1_entry);
}

你看，eFuse 提供了最原始的“根密钥哈希”，BootROM 用它验证自己，然后度量下一级。每一级都把自己的哈希扩展到 TPM 的 PCR 里。这样，系统启动后的任何时刻，你都可以通过读取 PCR 值来知道“系统是从哪个状态启动的”。

2.4 一张图看懂信任根体系

下面这张图展示了 eFuse、TPM、HSM 在信任链中的位置和关系。

硬件信任根体系结构图 硬件信任根体系结构 eFuse 一次性可编程熔丝 存储：根密钥哈希、芯片ID TPM 专用安全协处理器 功能：度量、存储、报告 HSM 硬件安全模块 功能：密钥管理、签名服务 提供根密钥 扩展信任 信任传递关系 eFuse 提供不可篡改的根 → TPM 度量并记录启动链 → HSM 为上层服务提供密钥保护 三者共同构成“硬件信任根”的完整拼图 SoC 内部 安全启动、调试锁定 PC/服务器 BitLocker、远程证明 金融/云 CA签名、KMS后端

2.5 避坑指南：我踩过的三个坑

做信任根设计，有些坑是共通的。我分享三个亲身经历。

  1. eFuse 空间不够用——某次设计只给了 64 位 eFuse，但我们需要存 256 位哈希。最后方案是存哈希的前 64 位，配合芯片唯一 ID 做密钥派生。但这样安全性降到了 64 位。所以，选型时 eFuse 空间宁大勿小。
  2. TPM PCR 使用顺序搞反——PCR 的扩展顺序决定了度量链。我曾经把 BL1 和 BL2 的度量顺序写反了，导致远程证明时 PCR 值对不上。排查了两天才发现。后来我养成了习惯：先画 PCR 分配表，再写代码。
  3. HSM 的密钥备份策略——有一次 HSM 硬件故障，里面的根密钥差点取不出来。幸好我们做了密钥分片备份（Shamir 秘密共享），用 5 个管理员各自保管一个分片，任意 3 个就能恢复。嗯，HSM 不是万能的，备份策略必须提前设计。

2.6 小结

硬件信任根是整个安全体系的基石。eFuse 提供不可篡改的根存储，TPM 负责度量和报告，HSM 提供企业级的密钥服务。三者各司其职，共同构建了从芯片上电到系统启动的信任起点。

记住一句话：没有硬件信任根，软件安全就是空中楼阁。

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