--- title: 如何解读远程证明报告 dek: 这份九步核查表帮你在任何数据离开自己的系统之前判断：某项服务的硬件签名证据，是否表明其软件和设置是你愿意信任的。 needs: 证明报告、厂商证书和公开的参考值 --- 证明报告是一份证据：在任何数据离开你的系统之前，你都必须对照自己的要求核查它。在远程证明中，一台机器就自身的软件和配置生成经硬件签名的证据，供远程的一方决定是否信任它。厂商工具可以确认报告是真实的、平台固件是最新的。但评判报告所记录的软件，仍是你自己的任务。例如，Intel 为 Trust Domain Extensions（TDX）提供的验证库，把一件事留给了验证方：比对 quote（Intel 对其签名报告的称呼）中的度量值与预期值。[^5]下面的九项检查以 Intel TDX 和 AMD Secure Encrypted Virtualization-Secure Nested Paging（SEV-SNP）的字段名为例。 ## 何时使用本指南 如果一项服务提供证明证据，而你要决定是否向它发送提示词、文档或模型权重，就可以使用本指南。这类服务运行在可信执行环境（TEE）中，按设计由硬件把工作负载与宿主机隔离。本指南中的工作负载是一整台虚拟机（VM）。例如，AMD SEV-SNP 会用每台虚拟机专属的密钥加密其内存。[^3]每当服务发布新软件，或厂商提高最低固件版本要求，都要重新做这些检查。 RFC 9334 是互联网工程任务组（IETF）制定的远程证明架构。按照它的术语，这项服务是证明方（attester）。验证方（verifier）对照参考值评估它的证据。你是依赖方（relying party），按自己的策略评判验证方给出的结果。[^1] ## 开始前需要准备什么 - **证据**：报告或 quote，以及随附的所有证书。 - **验证工具**：厂商提供的验证库或验证服务，以及最新的配套数据（collateral），例如证书吊销列表（CRL）。[^5] - **参考值**：服务商为每个版本公布的度量值，也称已知良好值（known-good values）。[^1] - **策略**：最低固件版本、可接受的度量值、你不接受的标志位，以及所有检查都通过后你会发送什么。 ## 第 1 步：确定 TEE 技术和每个证明方 先确定每个证明方及其采用的 TEE 技术，因为每种技术都有自己的证据格式和验证工具。[^2, 5] AI 服务还可能附上来自图形处理器（GPU）的证据。NVIDIA 的验证工具把 GPU 证据与签名清单中的参考度量值比对，另有一项在线证书状态协议（OCSP）服务检查证书是否已被吊销。[^6] - [ ] 写明每份报告背后的技术和处理器代际 - [ ] 从厂商或你审查过的其他来源获取每一种验证工具 ## 第 2 步：核验通往厂商根证书的签名链 检查报告的签名能否沿证书链追溯到厂商掌控的密钥。做不到这一点，报告就不能算作证据。SEV-SNP 报告的 SIGNING_KEY 字段标明签署该报告的密钥，例如芯片自身的版本化芯片背书密钥（Versioned Chip Endorsement Key，VCEK）。[^2] AMD 的密钥分发系统（KDS）提供 VCEK 证书以及签发这些证书的证书链：AMD 根密钥（ARK）签发 AMD SEV 密钥（ASK），ASK 再签发 VCEK 证书。[^3]对于 TDX，Intel 的验证库会检查预配认证密钥（Provisioning Certification Key，PCK）的证书链和 quote 的签名。[^5] - [ ] 证书链的终点是从厂商处获取的根证书 - [ ] 签名验证通过；SEV-SNP 报告的 SIGNATURE 字段如果全为零，说明报告未经签名[^2] - [ ] 报告中的 CHIP_ID 与获取 VCEK 时所用的标识符一致[^2, 4] ## 第 3 步：对照吊销数据检查固件版本 检查可信计算基（TCB）的版本。TCB 指保护机制所依赖的全部组件。AMD 把 TCB 版本定义为 SNP 固件、处理器微码等组件版本的组合。AMD 修复漏洞时，会提高最低补丁级别。每个 VCEK 都专属于某颗芯片，而且只对应它运行的某个特定 TCB 版本。[^3]报告的 REPORTED_TCB 字段标明派生签名密钥时所依据的版本。[^2] AMD 的指南会把这些值与 VCEK 证书中的值比对。[^4] Trail of Bits 发现，WhatsApp 的 Private Processing 系统起初信任固件自称的补丁级别。Meta 的修复改为从 VCEK 证书中读取补丁级别，并强制执行最低要求。[^7] 对于 TDX，Intel 的验证库会返回 OK、OUT_OF_DATE 或 REVOKED 等验证结果。Intel 还介绍了在宽限期内接受过时平台的策略。[^5] - [ ] 从厂商签名的数据中读取版本号，并与你设定的最低版本比较 - [ ] 检查厂商的 CRL（例如 AMD 的 KDS 为每款产品发布的 CRL[^3]），以及配套数据的时效 - [ ] 事先决定是否接受“过时”状态，以及最长接受多久 ## 第 4 步：将度量值与公布的参考值比对 把度量值与公布的参考值比对。度量值是代码或数据加载时记录下来的密码学哈希值。SEV-SNP 的 MEASUREMENT 是一个哈希值：虚拟机启动时，虚拟机监控器（管理虚拟机的软件）向虚拟机内存载入数据，固件在此过程中计算出这个值。[^2] TDX 把受保护的虚拟机称为信任域（trust domain）。MRTD 涵盖信任域的初始内容。按照惯例，RTMR0 至 RTMR3 这四个运行时度量寄存器，存放虚拟固件、操作系统和运行时随后记录的度量值。[^5] 参考值把每个哈希值对应到一个具体版本，你或他人可以检查这个版本。在 Apple 的 Private Cloud Compute 设计中，设备只为特定节点加密请求：这些节点经远程证明的度量值，必须与一份公开、只追加的透明日志中的某个版本相符。[^8] - [ ] 你的策略所依赖的每个度量字段都有预期值 - [ ] 每个预期值都能追溯到可审计的来源（例如可复现构建或只追加日志），并对应一个具名版本 ## 第 5 步：确认报告的新鲜性 发送一个随机数（nonce），即只使用一次、无法预测的值，并确认签名报告中包含它。上周生成的有效报告，说明不了这台机器今天的状态。按照 RFC 9334 中的随机数方法，负责评估的一方发出随机数，证明方把它写入签名证据。如果证据中的随机数与发出的一致，就说明这些声明是在随机数生成之后签署的。[^1] 两种技术都提供一个 64 字节的字段来存放这类数据。在 SEV-SNP 中，这个字段是 REPORT_DATA，固件不解析其内容。[^2]在 TDX 中则是 REPORTDATA，Intel 建议可以用它存放验证方的随机数。[^5] WhatsApp 的报告起初不含任何由客户端提供的值。因此，攻击者若攻破过某个 TEE 一次，本可以无限期地重放它的远程证明。[^7] - [ ] 每个会话都发送一个新的、不可预测的随机数 - [ ] 确认报告数据字段包含这个随机数，可以是直接写入，也可以是按服务商文档说明的方式取哈希后写入 - [ ] 拒绝缓存的报告，除非你的策略规定了可接受的最长时限 ## 第 6 步：确认报告与你的连接绑定 确认报告与你即将使用的连接绑定。新鲜性表明报告是最近生成的。绑定则表明，你的连接终止于经过远程证明的环境之内。Intel 指出，报告数据可以携带一把在信任域内部生成的公钥，用于建立安全会话。[^5] Meta 为 WhatsApp 做的修复，把传输层安全（TLS）握手中的 client_random 值写入每份报告，使每份报告都绑定到一个连接。[^7]还要问清楚 GPU 证据如何与你的会话绑定。没有这层绑定，GPU 证据可能来自另一台机器。 - [ ] 报告绑定了你这条连接所用的密钥或握手值，而且你的客户端会在发送数据之前核对这一点 - [ ] 出示的每份报告（包括 GPU 证据）都绑定到同一个会话 ## 第 7 步：检查调试标志和策略标志 即使报告真实、新鲜，也要检查调试标志和策略标志，因为它描述的仍可能是宿主机能够查看的环境。SEV-SNP 的 POLICY 字段包含一个 DEBUG 位。该字段还有一项设置，规定能否为这台虚拟机关联迁移代理（migration agent，即协助把虚拟机迁移到另一台机器上的软件）。[^2]在 TDX 中，设置 TDATTRIBUTES 里的 DEBUG 位后，宿主机就能访问信任域的处理器状态和私有内存。Intel 建议，不要把生产环境的机密交给设置了任何调试标志的信任域。[^5] - [ ] 调试功能已关闭：SEV-SNP 的 POLICY.DEBUG 和 TDX 的 TDATTRIBUTES 调试标志均为 0 - [ ] 其他策略位符合你的策略，例如迁移代理和同步多线程（SMT）的设置；保留字段均为零[^2] ## 第 8 步：列出度量值没有覆盖的内容 列出服务在启动后读取的输入。除非经过度量的代码记录了这些输入，或者把它们与预期值比对过，否则它们始终未经验证。Trail of Bits 在 WhatsApp 的系统中发现了两处这样的缺口。第一，环境变量来自度量完成后才读取的配置文件。内部人员本可借此加载恶意代码，而证明报告不会有任何变化。第二，高级配置与电源接口（ACPI）表负责向操作系统描述硬件，却没有纳入度量。恶意的虚拟机监控器本可借此声明能访问受保护内存的虚假设备。[^7]对于 AI 服务，要询问模型权重、适配器、系统提示词和服务配置。 - [ ] 列出启动后加载的输入，并为每一项注明度量或验证它的机制，例如内置于经过度量的镜像中的哈希值，或 RTMR3 中的一条记录 - [ ] 把其余输入标记为未验证，并判断这对你的数据而言是否可以接受 ## 第 9 步：记录决定 保留记录，让你自己或审计人员日后能够还原当时的决定。这是因为证明结果反映的是它生成时有效的策略、背书（通常由厂商就硬件签署的声明）和参考值。[^1] - [ ] 保存报告、证书、随机数和验证工具的输出 - [ ] 记录所用验证工具的版本，以及你采用的策略和参考值 - [ ] 记录决定、你接受的例外情况，以及哪些情况会触发重新检查，例如发布新版本 ## 示例 :::example 示例（假设情形）：合同摘要服务 一家律师事务所正在考虑是否把合同草稿发给一项虚构的摘要服务，该服务运行在 SEV-SNP 虚拟机中。服务商为每个版本在日志中登记参考度量值。它的文档说明，REPORT_DATA 存放的是用客户端随机数和服务器 TLS 公钥计算出的 SHA-512 哈希值。律所的软件收到了下面这份报告： ```text 简化的假设报告。字段名遵循 AMD SEV-SNP ABI 规范； 所有值均为虚构，大部分字段已省略。 POLICY DEBUG=0 MIGRATE_MA=0 SMT=1 MEASUREMENT 5e1c...9a0f REPORT_DATA 7d02...c4b1 REPORTED_TCB BOOT_LOADER=9 TEE=0 SNP=23 MICROCODE=72 CHIP_ID c81d...5577 SIGNING_KEY VCEK SIGNATURE 由芯片 VCEK 生成的 ECDSA 签名 ``` 律所的检查结果如下： 1. 签名和证书链验证通过，可一直追溯到律所从 AMD 下载的 ARK。 2. VCEK 证书中的 TCB 值与报告一致，并达到律所的最低要求。证书链中没有任何证书出现在 AMD 的 CRL 上。 3. MEASUREMENT 与服务商日志中的 2026.10.2 版本相符。 4. 用律所的随机数和本次握手的 TLS 密钥计算出的哈希值，与 REPORT_DATA 一致。 5. POLICY 禁止调试和迁移代理、允许 SMT，律所接受这一设置。 6. 服务商的文档显示，模型权重在启动后才下载，而且不会与固定的哈希值比对。 律所记录了检查结果。在服务商把权重的哈希值内置到经过度量的镜像之前，律所只发送非机密的测试文档。 ::: :::limits 通过检查的报告不能说明什么 - 一份通过检查的报告能够表明：真实的硬件启动了哪些软件、采用了哪些设置，以及你的连接终止于其中。它不能表明软件是正确的，也不能表明软件遵守了服务商在数据处理方面的承诺；要确认这些，需要审查度量值所对应的代码。 - 你仍然要信任硬件本身，以及硬件厂商的密钥、固件和验证服务。DDRop 研究人员描述的攻击者控制着宿主机的软件，并在一次短暂的现场接触中把一个小型装置安装到内存总线上。研究人员报告，这名攻击者能把一台恶意 Intel TDX 虚拟机的启动度量值改写成合法的度量值，使它通过远程证明。他们称，Intel 和 AMD 认为针对主内存的物理攻击不在其现有产品的防护范围之内。[^9] - 日志、存储以及经过远程证明的环境之外的其他系统，都不在报告的覆盖范围内。 :::