摘要

  • RFC 9684 定义了请求 TPM 1.2/2.0 Quote 与 BIOS、IMA、网络设备启动日志的 YANG RPC，并要求客户端提供新鲜 nonce。
  • Quote 的签名和 PCR/日志一致性只能覆盖被选中的 TPM、PCR 与测量政策；它们不会证明设备所有相关组件都进入了范围。
  • 还必须分别验证 AIK/AK 绑定、日志覆盖、Reference Values、Verifier 评估、Attestation Result、Relying Party 授权、执行动作和网络结果。

机框管理板返回了签名正确的 TPM 2.0 Quote。Nonce 是刚生成的，PCR 也能用日志重放出来。控制台于是给整台设备打上绿色标记。几分钟后，审核人员发现两块线卡各有自己的 TPM，而请求只点名了管理板证书。

绿色没有撒谎，却说得太大。它证明的是某颗 TPM 对某组 PCR 的一次新鲜回答，不是整个复合设备已经接受了一张统一判决。

RFC 9684 的价值就在于把前一件事标准化。ietf-tpm-remote-attestation 允许 YANG 客户端发送 challenge、选择 PCR、接收 Quote，并提取 BIOS、IMA 或网络设备启动日志。它建立互操作的证据入口；它没有替组织决定证据的范围和权力。

Nonce 约束重放，不补全测量面

客户端必须提供具有适当熵的新鲜 nonce。Attester 把它纳入响应，验证方因此可以拒绝把旧 Quote 当成新请求的答案。这张收据回答“该 Evidence 是否针对本次 challenge”。

它不回答设备在 Quote 之后是否改变，也不让未选中的 PCR 自动出现，更不会替 IMA 测量一个政策没有列入的文件。对于复合设备，RFC 9684 明确把“每颗 TPM 与具体被测组件之间的关系如何传达”留在范围之外。

当设备支持 mtpm 时，没有指定 certificate-name 可能让所有兼容 TPM 响应；指定一个证书则缩小对象。两种行为都要求外部资产图说明证书、TPM、控制板、线卡和实际功能之间的对应关系。否则，“选择更精确”也可能只是精确地问错对象。

可复核的 challenge 记录应保存设备身份、RPC、nonce、TPM 版本、证书名、hash bank、PCR 索引、日志类型与选择配置版本。只保留最终 pass，会在换卡、轮换证书或升级镜像后失去解释能力。

验签者还要验证签名者的资格

TPM 2.0 响应可以包含 TPMS_QUOTE_INFO、Quote signature、证书名、uptime 与辅助分析用的未签名 PCR 值。这些字段服务于不同问题：签名保护被证明结构，PCR 值帮助重建，证书把密钥指向预期的证明角色。

RFC 9684 要求接收方确认 TPM 1.2 证书对应有效 AIK，或 TPM 2.0 证书对应有效 AK，并确认私钥控制属于有资格代表目标 TPM 进行证明的实体。来自另一把真实密钥的正确签名，仍然可能没有权力代表这块组件。

模型中的支撑结构还可能被配置错误。证书未必对应预期 AK；密钥类型可能被写错；算法列表可能宣称物理 TPM 不支持的能力；系统软件从未 extend 的 PCR 也可能被选为输出对象。这些错误不一定破坏 RPC 或安全传输。

NETCONF 与 RESTCONF 保护管理交换，回答消息是否通过预期通道到达。它们不会决定密钥是否属于目标 TPM、TPM 是否覆盖目标组件，也不会决定结果是否满足业务政策。安全通道和正确判决是相邻事实，不是同一事实。

PCR 匹配只说明被测序列自洽

PCR 以滚动 hash 累积测量扩展。测量日志保存可供重放的事件序列。Verifier 可以按顺序计算预期 PCR，与签名 Evidence 比较，再把每项测量与 Reference Values 对照，定位分歧条目。

这套方法能证明“日志所描述的序列与 PCR 一致”，却不能证明“所有该测的东西都在日志里”。RFC 9684 的 IMA 附录指出，template 决定记录哪些字段，IMA policy 决定测量哪些文件；如果没有政策，就不会产生测量，IMA 实际上处于关闭状态。

因此，一份短日志可以完美重放，仅仅因为测量面很窄。BIOS/UEFI、IMA 与网络设备 boot log 也覆盖不同阶段。复合设备可能并行执行多个组件，事件顺序未必符合简单的线性预期。

补丁和升级会合法地改变 hash，Reference Integrity Manifest 必须同步更新。某项测量与 Reference Value 不同，可能是篡改，也可能是已批准镜像先上线、参考值后到，或者审核取错了设备型号。差异是证据，原因是进一步调查的结论。

报告至少应分开保留：测量政策版本、声明覆盖面、原始日志、重放结果、Reference Values 的来源与有效期、允许差异、评估政策和最终理由。把这些字段压成“可信度 92”会让组织无法在基线出错时重新判定。

Evidence 到行动之间还有两种权力

RFC 9334 把角色分得很清楚：Attester 产生 Evidence；Verifier 依据 Endorsements、Reference Values 与政策进行 appraisal，生成 Attestation Result；Relying Party 再把结果用于某个具体事务。RFC 9683 则提供网络设备远程完整性验证的运行背景。

RFC 9684 主要改善 Evidence 的取回方式。它没有让设备厂商、Verifier 或管理平台获得跨场景的最终授权。一份结果足以做资产盘点，不一定足以允许路由会话；同一份负面结果可以触发维护、限制某项功能或要求人工复核，不必自动关闭整台设备。

即使 Relying Party 做出 deny，执行点还要给出自己的收据：端口是否隔离、会话是否撤销、流量是否迁移、冗余是否维持服务。TPM Quote 不观察这些动作。把它当成结果证明，就是让传感器替执行系统签字。

读取证明数据本身是一项高权限操作

日志中的 hash 和配置细节可能暴露软件版本，为攻击者寻找已知漏洞提供线索。大体量日志请求还会消耗设备资源，形成拒绝服务压力。因此 RFC 9684 要求用 NACM 保护相关 RPC，并建议默认拒绝，只允许授权 Verifier 提取证明数据。

成熟政策不会无限制地“把所有日志都拉回来”。它需要规定谁能问、能问哪些组件、频率和容量上限、Evidence 保存地点与访问记录。测得过少会造成虚假确定性；取走过多则扩大敏感面并消耗生产设备。

最小初始规范 在这里意味着只标准化共同需要的证据交换，把未来的本地政策留在明面。现实层级 要求把“已证明”标签拆回 nonce、签名、测量、基线与授权。运行代码优先 则要求继续追到执行点和真实网络状态。

CHARRA 让 TPM 回答可以跨管理系统被读取和核验。正确的结论应保留完整主语：这颗 TPM 在这次 challenge 中保护了这组测量；这个 Verifier 用这套参考值和政策作出结果；这个 Relying Party 随后采取了这项动作。

来源