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）去适配实现细节了。