📚 课程目录第3章远程证明协议

3、远程证明协议：核心流程与数据模型

远程证明，说白了就是让一台设备向远程的验证方证明“我是我，我没被篡改”。这听起来简单，但实际落地时坑不少。我最早接触这个领域是在做IoT网关安全方案的时候，当时就被Challenge-Response协议折腾了好几个通宵。

3.1 远程证明的定义

远程证明（Remote Attestation）是一种安全机制。它允许一个可信的验证者（Verifier）远程确认一个被验证者（Attester）的当前状态是否可信。这个“状态”通常包括硬件配置、固件版本、运行中的软件栈等。

你想想看，设备在远端，你没法直接拆开看它有没有被植入后门。远程证明就是解决这个信任鸿沟的。

核心三要素：

Attester（被验证者）：需要证明自身状态的设备，比如你的智能摄像头、路由器。
Verifier（验证者）：远程的服务端，负责验证Attester发来的证据是否可信。
Relying Party（依赖方）：信任验证结果并据此做出决策的业务系统，比如云平台的控制面。

我在一个项目中见过有人把Verifier和Relying Party混为一谈，结果安全策略写得很混乱。记住，Verifier只负责出题和判卷，Relying Party才决定给不给权限。

3.2 挑战-响应协议流程

这是远程证明最经典的握手方式。为什么叫“挑战-响应”？因为Verifier先抛出一个随机数（挑战），Attester必须用自己内部的信任根对这个随机数签名（响应）。

流程大致分四步：

发起请求：Verifier向Attester发送一个证明请求，里面包含一个新鲜的随机数Nonce。
收集证据：Attester收到Nonce后，调用本地的可信组件（比如TPM、TEE）去测量当前系统状态，生成一份Evidence。
生成响应：Attester将Evidence和Nonce打包，用私钥签名，返回给Verifier。
验证断言：Verifier拿到响应后，验证签名、检查Nonce是否新鲜、比对Evidence是否匹配已知的参考值（Reference Values），最终生成一个Assertion。

我的经验：Nonce一定要用真随机数，别偷懒用时间戳或者递增ID。我曾经见过一个方案用设备启动时间做Nonce，结果攻击者重放旧响应就绕过了验证。

下面这张图把整个交互画清楚了：

3.3 证明数据（Evidence）

Evidence是Attester发给Verifier的原始数据。它包含什么？说白了就是设备当前状态的“快照”。

常见的Evidence内容：

度量日志（Measurement Log）：记录启动过程中每个组件的哈希值，比如BIOS、Bootloader、OS内核。
引用完整性度量（PCR值）：TPM内部寄存器存储的聚合哈希，用于快速比对。
设备身份信息：比如AK公钥（Attestation Key）的证书链。
Nonce：必须原样返回，否则Verifier会认为响应无效。

注意：Evidence本身是明文传输的，不要在里面塞敏感数据。它的安全性靠签名保证，不是靠加密。我在一个项目中看到有人把设备私钥也放进Evidence里，那简直是灾难。

举个例子，一个典型的TPM Quote数据格式：

TPMS_ATTEST {
  magic: 0xFF544347,        // TPM_GENERATED
  type: TPM_ST_ATTEST_QUOTE,
  qualifiedSigner: ...,
  extraData: { nonce },     // 挑战随机数
  clockInfo: { ... },
  firmwareVersion: 1.2.3,
  attested: {
    quote: {
      pcrSelect: { 0, 1, 2, 3, 4, 5, 6, 7 },
      pcrDigest: 0xA1B2C3...  // PCR值的摘要
    }
  }
}

3.4 断言（Assertion）

Verifier收到Evidence后，不会直接把它转发给Relying Party。它会先做验证，然后生成一个更高级的结论——Assertion。

Assertion是Verifier对Attester状态的判定结果。它包含：

字段	说明	示例值
attester_id	被验证设备的唯一标识	设备证书序列号
timestamp	断言生成时间	2025-03-15T10:30:00Z
verdict	验证结论	trusted / untrusted / unknown
reference_measurements	匹配到的参考基线版本	fw_v2.1.0_golden
verifier_signature	Verifier对断言的签名	Base64编码签名值

为什么要多此一举？因为Relying Party可能不懂TPM Quote的细节，它只想知道“这台设备能不能信任”。Assertion就是Verifier给出的最终判决。

我的建议：Assertion一定要有过期时间。我见过一个系统，Verifier生成的断言永久有效，结果设备被攻陷后，旧的断言还在被Relying Party接受。加个timestamp和TTL，成本很低，收益很大。

3.5 Evidence vs Assertion 对比

这两个概念容易混淆。我习惯这么区分：Evidence是“原始证据”，Assertion是“法官的判决书”。

维度	Evidence	Assertion
生成方	Attester	Verifier
内容	原始度量值、日志、Nonce	验证结论、时间戳、参考基线
签名方	Attester的AK私钥	Verifier的私钥
消费方	Verifier	Relying Party
可读性	机器可读，结构复杂	业务友好，结论明确

嗯，这里要注意：有些协议允许Verifier把原始Evidence和Assertion一起发给Relying Party，让依赖方自己做二次校验。这属于高级用法，但会增加Relying Party的复杂度。

3.6 避坑指南

最后分享几个我踩过的坑：

Nonce重用：同一个Nonce被多个设备使用，攻击者可以交叉重放。每个请求必须生成独立Nonce。
忽略PCR选择：有些实现只度量PCR 0-7，但攻击者可能篡改PCR 8以上的区域。记得根据威胁模型选择完整的PCR集合。
签名验证不严格：Verifier只验签名不验证书链，导致伪造AK也能通过。一定要做完整的证书路径验证。
断言缓存时间过长：设备状态可能随时变化，断言的有效期应该按秒计，而不是按天。

我曾经在一个项目中，因为忘记设置断言过期时间，导致一台已经被攻陷的设备在长达72小时内仍然被业务系统信任。那次事故之后，我把所有断言都加上了5分钟的TTL。

远程证明协议的核心就是Challenge-Response这个闭环。理解Evidence和Assertion的区别，你就掌握了远程证明的数据模型。剩下的就是根据具体硬件（TPM、TEE、SE）去适配实现细节了。