3、信任根（RoT）介绍：硬件信任根 vs 软件信任根，TPM 与 HSM 的角色
聊远程证明，绕不开一个核心概念——信任根（Root of Trust, RoT）。
说白了，信任根就是整个安全体系的「第一块砖」。你想想看，如果连这块砖都是歪的，那上面盖的楼再高也没用。我在做固件安全评估时，经常遇到客户问：「我的系统已经用了签名校验，为什么还是被攻破了？」答案往往就出在信任根上——签名校验本身也需要一个可信的起点，这个起点就是 RoT。
3.1 什么是信任根？
信任根是一个必须被无条件信任的实体。它通常是硬件或软件中的一个最小单元，负责执行最关键的安全操作，比如度量、存储、报告。
它的核心特征有三个：
- 不可伪造性：攻击者无法冒充或篡改信任根的行为。
- 不可绕过性：所有安全决策都必须经过信任根，不能跳过。
- 最小化：信任根的代码和逻辑越少越好，减少攻击面。
核心原则：信任根是信任链的起点。从它开始，一级一级验证，最终建立起整个系统的可信状态。
3.2 硬件信任根 vs 软件信任根
这里有个经典的分歧：信任根到底该放在硬件里，还是软件里？
我个人习惯把这个问题拆成两个维度来看——安全性和灵活性。
3.2.1 硬件信任根
硬件信任根，就是把信任根实现在一个物理隔离的硬件模块里。比如 TPM 芯片、HSM、或者 SoC 内部的安全飞地（Secure Enclave）。
它的优势很明显：
- 抗物理攻击：硬件模块有防篡改设计，比如屏蔽层、电压检测、温度检测。
- 隔离性强：即使主 CPU 被攻破，硬件信任根依然安全。
- 性能稳定：专用硬件处理密码学操作，比软件快得多。
但缺点也摆在那：
- 成本高：增加硬件模块，BOM 成本上升。
- 灵活性差：硬件一旦固化，很难升级或修改。
- 供应链风险：硬件模块本身也可能被植入后门。
我的经验：在 IoT 设备中，很多厂商为了省成本，把信任根放在 SoC 内部的 OTP（一次性可编程存储器）里。这其实是个折中方案——安全性比纯软件高，但比独立 TPM 低。我曾经遇到一个项目，OTP 的熔丝被激光攻击直接读取了密钥……嗯，从那以后我再也不敢把关键密钥只放在 OTP 里了。
3.2.2 软件信任根
软件信任根，就是信任根实现在固件或操作系统层面。比如 Boot ROM 中的一段代码，或者 TEE（可信执行环境）中的安全监控器。
它的优势：
- 成本低：不需要额外硬件，纯软件实现。
- 灵活：可以通过固件更新修复漏洞或升级算法。
- 部署快：适合已有硬件不支持硬件信任根的旧设备。
但风险也很突出：
- 抗攻击能力弱：软件信任根运行在主 CPU 上，容易被侧信道攻击或内存破坏攻击。
- 依赖底层硬件：如果 CPU 本身有漏洞，软件信任根再强也没用。
- 度量起点问题：软件信任根的第一段代码（比如 Boot ROM）其实还是硬件固化的，严格来说不算纯软件。
注意：纯软件信任根在远程证明场景中几乎不可用。因为证明者需要向验证者证明自己的可信状态，如果信任根是软件，那验证者凭什么相信这个软件没有被篡改？这就陷入了「先有鸡还是先有蛋」的困境。
3.2.3 对比总结
| 维度 | 硬件信任根 | 软件信任根 |
|---|---|---|
| 安全性 | 高，抗物理攻击 | 低，依赖主 CPU 安全 |
| 成本 | 高，需要专用硬件 | 低，纯软件实现 |
| 灵活性 | 差，硬件固化 | 好，可升级 |
| 部署难度 | 需要硬件支持 | 容易，兼容旧设备 |
| 远程证明适用性 | 强，提供硬件背书 | 弱，信任链难以闭环 |
3.3 TPM 的角色
TPM（Trusted Platform Module）是目前最主流的硬件信任根实现。它是一颗独立的密码学协处理器，专门负责安全度量、密钥存储和远程证明。
TPM 的核心能力包括：
- 平台配置寄存器（PCR）：用于存储度量值的哈希。每次启动时，固件将各个组件的哈希值扩展到 PCR 中，形成一条不可逆的度量链。
- 背书密钥（EK）：TPM 出厂时内置的唯一密钥，用于证明 TPM 本身的身份。
- 身份证明密钥（AIK）：用于远程证明的签名密钥，由 EK 派生，保护隐私。
- 密封存储：将密钥或数据绑定到特定的 PCR 状态，只有系统处于可信状态时才能解封。
关键点：TPM 的 PCR 扩展操作是单向的——只能追加，不能回滚。这意味着攻击者无法伪造一个「干净」的度量值，除非他能控制整个启动链。
我在项目中遇到过一个问题：某厂商的 TPM 固件版本太老，不支持 SHA-256 扩展，只能用 SHA-1。结果被碰撞攻击绕过了 PCR 度量。嗯，这里要注意——TPM 本身也是固件，也需要更新。别以为买了 TPM 就万事大吉了。
3.4 HSM 的角色
HSM（Hardware Security Module）是 TPM 的「大哥」。它通常用于服务器端或云端，提供更高等级的安全保护。
HSM 和 TPM 的核心区别：
| 维度 | TPM | HSM |
|---|---|---|
| 部署位置 | 终端设备（PC、服务器、IoT） | 数据中心、云端 |
| 性能 | 低功耗，适合嵌入式 | 高性能，支持大量并发 |
| 密钥管理 | 有限，通常只存储平台密钥 | 丰富，支持密钥生命周期管理 |
| 认证标准 | TCG 标准 | FIPS 140-2/3 Level 3/4 |
| 典型用途 | 平台完整性度量、远程证明 | CA 密钥保护、交易签名、数据加密 |
在远程证明方案中，HSM 通常扮演验证者的角色。比如，云端验证服务使用 HSM 来存储验证密钥，并对证明请求进行签名。这样即使云服务器被攻破，攻击者也拿不到 HSM 内部的密钥。
我的建议：如果你的远程证明方案需要处理大量并发请求（比如百万级 IoT 设备），HSM 几乎是必须的。软件签名根本扛不住那个吞吐量。我曾经帮一个客户做过压测，软件签名每秒只能处理 200 个请求，换成 HSM 后直接飙到 5000+。
3.5 信任根在远程证明中的位置
为了让你更直观地理解，我画了一张图：
从图中你可以看到，信任根是整个远程证明方案的基石。无论是硬件信任根还是软件信任根，最终都要为远程证明服务提供可信的度量值和签名。
3.6 如何选择？
这个问题没有标准答案。我个人的经验是：
- 高安全场景（金融、政府、医疗）：必须用硬件信任根，推荐 TPM + HSM 组合。
- 成本敏感场景（消费级 IoT）：可以考虑软件信任根，但要做好风险评估。
- 混合场景：终端用 TPM，云端用 HSM，中间用远程证明协议打通。
避坑指南：我曾经见过一个项目，为了省成本，用 MCU 的 Flash 模拟 TPM 的 PCR。结果攻击者通过电压毛刺攻击让 Flash 写入失败，PCR 值永远停留在初始状态……嗯，从那以后我再也不建议用 Flash 模拟 PCR 了。硬件信任根就该用硬件实现，别想着偷工减料。