1. 信任根与信任链
聊远程证明，第一个绕不开的概念就是「信任根」。说白了，信任根就是一个系统里绝对可信的起点。它不需要被外部验证，因为它本身就是验证别人的基准。我刚开始接触这个领域时，总觉得这像是个哲学问题——「先有鸡还是先有蛋」？但在工程上，我们得有个确定的锚点。
1.1 信任根的定义
信任根（Root of Trust, RoT）是一组必须被无条件信任的硬件、固件或算法。它通常具备三个核心属性：
- 不可伪造性：攻击者无法模拟或篡改信任根的行为。
- 不可绕过性：所有安全决策都必须经过信任根。
- 持久性：信任根的状态在设备生命周期内保持稳定。
核心观点：信任根不参与「证明自己可信」的过程，它只负责证明别人。就像法庭上的首席法官——没人质疑法官的身份，他只负责裁定证人的证词是否有效。
你想想看，如果信任根本身都需要被验证，那验证它的东西又由谁来验证？这就陷入了无限递归。所以，信任根必须是物理上或逻辑上不可篡改的。
1.2 硬件信任根：TPM 与 TEE
在实际工程中，最常见的硬件信任根有两种：TPM 和 TEE。我当年在做一个 IoT 网关项目时，就踩过这两种方案的坑，今天一并分享给你。
1.2.1 TPM（可信平台模块）
TPM 是一个独立的安全芯片，专门用来存储密钥、执行加密运算和提供平台度量。它的核心能力包括：
- 平台配置寄存器（PCR）：存储系统启动过程中的度量值，比如 BIOS、引导加载程序、操作系统内核的哈希值。
- 背书密钥（EK）：芯片出厂时烧录的唯一身份标识，相当于 TPM 的「身份证」。
- 身份证明密钥（AIK）：用于远程证明时签名度量报告的密钥，由 EK 派生。
| 特性 | TPM 2.0 | TPM 1.2 |
|---|---|---|
| 算法支持 | SHA-256、ECC、RSA | SHA-1、RSA |
| PCR 数量 | ≥24 个 | ≥16 个 |
| 授权机制 | 密码、策略、HMAC | 仅密码 |
| 远程证明 | 原生支持匿名证明 | 需额外扩展 |
个人经验：我在一个金融支付终端项目里用过 TPM 2.0。当时最头疼的是 PCR 的扩展操作——每次度量都要做一次 SHA-256 哈希拼接，顺序错了整个信任链就断了。调试时我打印了每一步的 PCR 值，才发现是 BIOS 阶段少度量了一个 Option ROM。嗯，从那以后我养成了「度量前先列清单」的习惯。
1.2.2 TEE（可信执行环境）
TEE 和 TPM 不同，它不是一个独立芯片，而是 CPU 内部的一个安全隔离区域。ARM 的 TrustZone 和 Intel 的 SGX 都是典型的 TEE 实现。
TEE 的优势在于：
- 性能高：直接在 CPU 主核上运行，不需要额外的通信总线。
- 内存隔离：安全世界和普通世界共享物理内存，但通过硬件总线过滤实现隔离。
- 灵活性强：可以在 TEE 内运行自定义的安全应用（Trusted Application）。
避坑指南：我曾经在一个项目中用 TEE 做密钥管理，结果发现 TEE 的「安全存储」其实依赖于外部 Flash。如果攻击者能物理篡改 Flash 内容，TEE 启动时的镜像验证就可能被绕过。所以，TEE 的安全边界一定要延伸到非易失性存储的完整性保护上。
1.3 信任链的建立与传递
有了信任根，接下来就是怎么把这份信任「传递」给系统的其他组件。这个过程叫做信任链（Chain of Trust）。
信任链的建立遵循一个基本原则：每一级组件在启动或加载之前，必须先度量下一级组件的完整性，只有度量通过后才将控制权移交。
典型的信任链流程如下：
- Root of Trust for Measurement (RTM)：通常是 CPU 微码或 Boot ROM，它度量 BIOS/UEFI 的代码和配置。
- BIOS/UEFI：度量 Option ROM、引导加载程序（如 GRUB）和操作系统内核。
- 操作系统内核：度量内核模块、设备驱动和关键系统服务。
- 应用层：度量用户态的可执行文件和动态库。
每一级的度量结果都会被记录到 TPM 的 PCR 中。PCR 的值只能通过 TPM2_PCR_Extend 操作更新，无法直接写入或重置（除了系统重启）。
// PCR 扩展操作示例（伪代码）
// 假设当前 PCR[0] = H(BIOS)
// 现在要度量引导加载程序 bootloader.bin
hash = SHA256(bootloader.bin)
new_pcr_value = SHA256(pcr[0] || hash)
TPM2_PCR_Extend(0, new_pcr_value)为什么会这样设计？因为 PCR 的「只扩展不覆盖」特性，保证了攻击者无法回滚到旧的、可能已被篡改的度量状态。你想想看，如果 PCR 可以被直接覆盖，那攻击者完全可以在篡改 bootloader 后，把 PCR 改回篡改前的值——那信任链就形同虚设了。
1.4 信任链的图形化表示
下面这张图展示了从硬件信任根到应用层的完整信任链传递过程。我习惯把它叫做「信任的接力赛」——每一棒都必须确认下一棒的身份，才能把接力棒交出去。
1.5 信任链的传递机制
信任链的传递不仅仅是「度量-移交」这么简单。在实际实现中，有几个关键机制必须理解：
- 度量启动（Measured Boot）：每一级都记录度量值，但不中断启动流程。即使某个组件被篡改，系统仍然可以启动，但 PCR 值会反映出异常。远程证明服务可以通过比对 PCR 值来判断设备是否被篡改。
- 安全启动（Secure Boot）：每一级在移交控制权之前，必须验证下一级的数字签名。验证失败则立即停止启动。安全启动是「强制执行」的信任链，而度量启动是「记录并报告」的信任链。
- 远程证明（Remote Attestation）：设备将 PCR 值和度量日志（Event Log）发送给远程验证方。验证方通过比对 PCR 值和预期值，判断设备是否处于可信状态。
实践建议：我个人习惯在项目中同时启用安全启动和度量启动。安全启动负责「防篡改」，度量启动负责「可审计」。两者配合使用，才能构建一个完整的信任链体系。我曾经见过一个项目只开了安全启动，结果攻击者通过修改度量日志的方式绕过了远程证明——嗯，这就是典型的「只锁门不装摄像头」。
1.6 信任链的挑战与局限
信任链不是万能的。在实际部署中，我遇到过几个典型问题：
| 挑战 | 描述 | 缓解措施 |
|---|---|---|
| 物理攻击 | 攻击者通过探针、激光等手段直接读取 TPM 内部密钥 | 使用防篡改封装、主动屏蔽层 |
| 侧信道攻击 | 通过功耗、电磁辐射等信息泄露推断密钥 | 采用恒定时间算法、随机化操作 |
| 固件漏洞 | Boot ROM 或 BIOS 本身存在安全漏洞 | 及时更新固件、使用硬件熔丝锁定 |
| 供应链攻击 | 在设备出厂前植入恶意固件 | 建立可信供应链、出厂前进行完整性校验 |
避坑指南：我曾经在一个项目中过度依赖 TPM 的 PCR 值，认为只要 PCR 值匹配就万事大吉。结果发现攻击者通过修改度量日志（Event Log）的方式，让 PCR 值看起来正常，但实际上系统已经被篡改。记住：PCR 值只告诉你「度量了什么」，不告诉你「度量得对不对」。一定要结合度量日志的完整性校验，才能确保信任链的可靠性。
信任根和信任链是远程证明的基石。没有它们，后续的证明协议、密钥协商、会话建立都无从谈起。理解了这个基础，你就能明白为什么远程证明的核心问题最终都归结为「如何让验证方相信，设备上的信任根没有被篡改」。