信任根与可信计算基：TPM 2.0 基础、TEE 简介与信任链建立
聊远程证明，绕不开一个核心问题：信任从哪来？
你想想看，如果连度量设备状态的工具本身都不可信，那证明结果还有什么意义？这就是我们今天要啃的硬骨头——信任根（Root of Trust）和可信计算基（TCB）。说白了，它们就是整个可信体系的“锚点”。
我个人习惯把信任根比作“上帝视角的起点”。它必须是一个物理上不可篡改、逻辑上绝对可靠的硬件元件。而 TCB 则是围绕这个起点，构建起来的最小可信软件集合。嗯，这里要注意，TCB 越小，攻击面就越窄，安全强度就越高。
TPM 2.0：硬件信任根的基石
TPM（Trusted Platform Module）是目前最主流的硬件信任根。我最早接触 TPM 1.2 时，觉得它就是个“黑盒子”，功能有限。到了 TPM 2.0，变化非常大。它不再是一个固定的功能集，而是一个灵活的规范族。
TPM 2.0 的核心能力，我归纳为三点：
- 安全存储：密钥、证书、哈希值等敏感数据，直接锁在 TPM 芯片内部。外部软件只能通过命令请求服务，拿不到原始数据。
- 平台配置寄存器（PCR）：这是信任链的核心。PCR 的值只能通过“扩展（Extend）”操作来更新，无法被直接写入或重置（除了重启）。
- 远程证明能力：TPM 可以用内部存储的私钥（EK 或 AK），对 PCR 的当前值进行签名。这个签名就是“设备状态可信”的铁证。
关键概念：PCR 扩展
PCR 的扩展操作不是简单的覆盖，而是：PCR_new = SHA256(PCR_old || new_data)。这意味着，任何微小的状态变化，都会导致最终哈希值完全不同。我在项目中遇到过有人想“回滚”PCR 值，这根本不可能——除非你物理重置 TPM。
TPM 2.0 的架构比 1.2 灵活得多。它支持不同的算法套件（比如 SM3/SM4 国密），也支持虚拟化场景。我个人建议，新项目直接上 TPM 2.0，别再用 1.2 了。
| 特性 | TPM 1.2 | TPM 2.0 |
|---|---|---|
| 算法灵活性 | 固定 SHA1/RSA | 支持多种算法（SHA256、ECC、SM3 等） |
| PCR 数量 | 固定 24 个 | 可配置，最多 32 个 |
| 授权机制 | 简单密码 | 支持密码、HMAC、策略会话 |
| 虚拟化支持 | 弱 | 原生支持 vTPM |
TEE：隔离执行的可信环境
TPM 是硬件信任根，但它不负责“运行代码”。TEE（Trusted Execution Environment）填补了这个空白。它提供了一个与普通操作系统隔离的安全区域，代码和数据在里面执行时，外部无法窥探或篡改。
目前主流的两大 TEE 技术：Intel SGX 和 ARM TrustZone。我两个都踩过坑，简单说说区别。
Intel SGX：应用级隔离
SGX 允许应用程序在内存中创建“飞地（Enclave）”。飞地内的代码和数据，连操作系统和 Hypervisor 都访问不到。我记得第一次调试 SGX 程序时，被它的内存加密机制搞得很头疼——飞地内的数据在写入内存时自动加密，读取时自动解密，对开发者透明，但性能开销不小。
- 优势：细粒度隔离，不需要信任整个 OS。
- 劣势：飞地内存有限（通常 128MB-256MB），且容易受到侧信道攻击。
- 避坑指南：我曾经在 SGX 飞地里处理大量数据，结果频繁触发页面交换，性能直接崩了。后来改用流式处理，才解决问题。
ARM TrustZone：系统级隔离
TrustZone 将整个 SoC 划分为两个世界：安全世界（Secure World）和普通世界（Normal World）。安全世界运行一个微型操作系统（如 OP-TEE），普通世界运行 Android 或 Linux。切换世界需要硬件指令支持。
- 优势：系统级隔离，性能开销小，适合移动设备。
- 劣势：安全世界的攻击面较大（整个安全 OS 都是 TCB 的一部分）。
- 个人经验：我在一个 IoT 项目里用过 TrustZone，发现安全世界的驱动一旦有漏洞，整个隔离就形同虚设。所以，TCB 越小越好，这个原则在 TrustZone 里同样适用。
选型建议：如果你的场景是“保护云端机密计算”，SGX 更合适；如果是“保护移动端或 IoT 设备的敏感操作”，TrustZone 更成熟。当然，现在还有 AMD SEV、RISC-V 的 TEE 方案，但 SGX 和 TrustZone 依然是主流。
信任链的建立：从硬件到应用
有了 TPM 和 TEE，我们怎么把它们串起来，形成一个完整的信任链？
信任链的建立，遵循一个基本原则：前一个组件度量并验证后一个组件的完整性，然后才将控制权移交。这个过程从系统上电开始，一直延伸到应用层。
典型的信任链流程如下：
- CRTM（Core Root of Trust for Measurement）：通常是 BIOS 或 UEFI 的第一段代码。它由硬件保证不可篡改，负责度量 BIOS 主代码。
- BIOS/UEFI：度量 Bootloader（如 GRUB）的代码和配置。
- Bootloader：度量操作系统内核和关键驱动。
- 操作系统内核：度量系统服务、安全模块和关键应用。
- 应用层：应用自身可以度量其依赖库和配置文件。
每一步的度量结果，都会通过“Extend”操作记录到 TPM 的 PCR 中。最终，PCR 的值就代表了整个系统的“可信状态”。
注意：信任链的强度取决于最薄弱的环节。如果 CRTM 被攻破，整个信任链就崩塌了。所以，CRTM 必须固化在 ROM 中，且不能通过软件更新。我曾经见过一个项目，为了“方便升级”，把 CRTM 放在了可写 Flash 里——这等于把信任根挖掉了。
为了让你更直观地理解，我画了一张信任链的流程图：
这张图展示了信任链的“链式”结构。每一步的度量结果，最终都会汇总到 TPM 的 PCR 中。当远程验证方请求证明时，设备会提供 PCR 的签名值，验证方通过比对预期值，就能判断设备是否处于可信状态。
实践建议：在实际部署中，不要只依赖单一的信任链。我建议结合 TPM 和 TEE 做双重验证：TPM 保证系统启动过程的完整性，TEE 保证运行时关键代码的隔离性。这样即使一方被攻破，另一方还能兜底。