4. 远程证明协议：RFC 9334（RATS）架构
聊远程证明，绕不开一个文档——RFC 9334。这个标准定义了远程证明（Remote Attestation）的通用架构，业内叫它 RATS（Remote Attestation Procedures）。说白了，它就是给设备证明这件事画了一张蓝图，告诉大家谁该干什么、消息怎么传。
我最早接触这个标准是在一个 IoT 平台项目里。当时各家芯片厂商的证明方案五花八门，有的用 DICE，有的用 TPM，还有的自研协议。后来发现 RATS 架构能把它们统一到一个框架里聊，嗯，这确实省了不少事。
4.1 三个核心角色
RATS 定义了三个角色：Attester、Verifier、Relying Party。我习惯把它们类比成「被检查者」「检查官」「决策者」。
| 角色 | 英文 | 职责 | 类比 |
|---|---|---|---|
| 证明者 | Attester | 收集自身状态，生成证据 | 被检查者 |
| 验证者 | Verifier | 验证证据，生成断言 | 检查官 |
| 依赖方 | Relying Party | 根据断言做决策 | 决策者 |
4.1.1 Attester（证明者）
Attester 就是被证明的设备。它需要收集自身的可信状态，比如固件哈希、启动度量值、硬件标识符。这些原始数据在 RATS 里叫 Evidence（证据）。
我在一个工业网关项目里遇到过一个问题：设备上报的度量值格式不统一，有的用 TPM 2.0 引用的 PCR 值，有的用 DICE 的 TCB 信息。后来我们统一用 RATS 的 Evidence 格式封装，才解决了兼容性问题。
4.1.2 Verifier（验证者）
Verifier 是架构里的核心。它接收 Attester 发来的 Evidence，然后做两件事：
- 验证证据的真实性——检查签名、证书链、度量值是否匹配预期
- 生成断言——把验证结果转成 Relying Party 能理解的格式
你想想看，Verifier 其实是个翻译官。它把设备底层的硬件度量值，翻译成「这个设备是可信的」「固件版本是 2.1.0」这样的高层断言。
4.1.3 Relying Party（依赖方）
Relying Party 是最终做业务决策的角色。它不关心 PCR 值是多少，也不关心签名算法是 ECDSA 还是 RSA。它只关心一件事：这个设备能不能接入我的网络？
举个例子：一个云平台收到 Verifier 的断言后，决定是否给设备下发访问令牌。这就是 Relying Party 的典型场景。
4.2 证据与断言
这两个概念容易混淆。我刚开始学 RATS 时也搞混过，后来用一句话记住了：证据是原始数据，断言是结论。
4.2.1 Evidence（证据）
Evidence 是 Attester 生成的、关于自身状态的原始信息。它通常包含：
- 启动度量值（Boot Measurements）
- 固件哈希
- 硬件标识符（如 TPM 的 EK 公钥）
- 运行时状态（如安全策略配置）
- 时间戳或 Nonce
Evidence 的特点是：机器可读、平台相关。不同芯片厂商的 Evidence 格式可能完全不同。
关键点：Evidence 必须包含「新鲜度」信息。没有 Nonce 或时间戳的 Evidence，在安全审计里直接判不合格。
4.2.2 Assertion（断言）
Assertion 是 Verifier 对 Evidence 验证后输出的结论。它通常是：
- 「设备 A 的固件版本为 2.1.0，可信」
- 「设备 B 的 TCB 状态为可信」
- 「设备 C 的度量值与预期不符，不可信」
Assertion 的特点是：人类可读、平台无关。Relying Party 直接拿它做决策，不需要理解底层硬件细节。
| 维度 | Evidence | Assertion |
|---|---|---|
| 生成方 | Attester | Verifier |
| 内容 | 原始度量值、签名 | 验证结论、属性声明 |
| 可读性 | 机器可读 | 人类可读 |
| 平台相关性 | 强相关 | 无关 |
| 典型格式 | TPM Quote、DICE 证书 | JWT、EAT |
4.3 RATS 架构图
下面这张图展示了 RATS 的核心流程。我习惯把它画成三层的：Attester 在最底层，Verifier 在中间做转换，Relying Party 在最上层做决策。
4.4 实际部署中的角色合并
理论上三个角色是独立的，但实际部署时经常合并。我见过几种常见模式：
- Verifier + Relying Party 合并：云平台自己验证证据，自己决策。适合封闭生态。
- Attester + Verifier 合并：设备自己验证自己，然后对外输出断言。适合高性能设备。
- 完全分离：三个角色独立部署。适合跨厂商、跨平台的开放生态。
4.5 消息流与信任传递
RATS 的信任传递是链式的。我习惯用一句话概括：信任从硬件根开始，逐级向上传递。
- 硬件信任根（如 TPM、DICE）生成初始度量值
- Attester 收集这些度量值，打包成 Evidence
- Verifier 验证 Evidence，输出 Assertion
- Relying Party 信任 Assertion，做出业务决策
这个链条里，每一级都依赖上一级的可信性。如果硬件信任根被攻破，整个链条就断了。所以选硬件时，我建议优先选有独立安全芯片的方案。
4.6 常见问题与避坑
最后分享几个我在项目中踩过的坑：
- 证据格式不统一：不同芯片厂商的 Evidence 格式差异很大。建议在 Verifier 端做格式适配层。
- 断言过期：Assertion 要有有效期。我见过一个系统因为断言缓存时间过长，导致已篡改的设备还能正常访问。
- 角色职责混淆：有些团队让 Relying Party 直接验证 Evidence，绕过了 Verifier。这会导致业务逻辑和安全逻辑耦合，后期维护成本极高。