第4章 证明协议：TPM2.0 Quote、Intel SGX/TDX Quote、AMD SEV-SNP 证明
远程证明的核心，说白了就是「拿证据说话」。你的可信环境到底安不安全？得拿出硬件签名的报告来。这一章我们聊聊三种主流的证明协议。我这些年跟它们打交道不少，踩过的坑也挺多。
这三种协议，本质上都是在做同一件事：收集证据 → 签名打包 → 交给验证方。但它们的实现思路、安全假设、适用场景，差别很大。
核心要点：TPM2.0 是平台级证明，SGX/TDX 是应用级证明，SEV-SNP 是虚拟机级证明。选哪个，取决于你的威胁模型。
4.1 TPM2.0 Quote：平台固件的「体检报告」
TPM2.0 的 Quote 机制，我最早接触是在做服务器启动完整性校验的时候。它解决的问题很简单：这台机器的固件和引导程序有没有被篡改？
流程大致是这样：
- 收集 PCR 值：TPM 内部有一组 Platform Configuration Registers（PCR），从加电开始，逐级度量 BIOS、Bootloader、OS Kernel。每个 PCR 存的是哈希值。
- 生成 Quote：挑战方发一个 nonce（随机数），TPM 把指定的 PCR 值、nonce 打包，用 TPM 内部的 Attestation Identity Key（AIK）签名。
- 验证：验证方拿到 Quote，用 AIK 的公钥验签，比对 PCR 值是否与预期一致。
这里有个关键点——AIK 的信任链。AIK 本身是由 Endorsement Key（EK）派生出来的。EK 是 TPM 出厂时烧录的，相当于硬件身份证。所以 Quote 的信任根，最终落在 TPM 芯片厂商手里。
我的经验：有一次客户反馈 Quote 验证总失败，查了半天发现是 PCR 的度量顺序变了。Linux 的 systemd-boot 和 GRUB 对 PCR 4 的写入方式不一样。嗯，这种「静默变更」最坑人。
4.2 Intel SGX/TDX Quote：飞地的「自证清白」
SGX 和 TDX 都是 Intel 的可信执行环境技术。SGX 针对应用级飞地（Enclave），TDX 针对虚拟机级信任域（Trust Domain）。它们的 Quote 机制，核心是 EPID（Enhanced Privacy ID）或 DCAP（Data Center Attestation Primitives）。
SGX Quote 的生成流程：
- 飞地初始化：Enclave 加载时，CPU 会度量其代码和数据，生成 MRENCLAVE 和 MRSIGNER。
- 请求 Quote：Enclave 向 Quoting Enclave（QE）发起请求，QE 是 Intel 提供的特权飞地。
- 签名：QE 用 EPID 密钥或 DCAP 证书对度量值签名，生成 Quote。
- 验证：验证方需要联网或本地缓存 Intel 的证书链，验签并比对度量值。
TDX 的流程类似，但度量的是整个 Trust Domain（包括内核、驱动、应用）。TDX Quote 里会包含 TD 的运行时度量，以及 MRTD（初始度量）和 RTMR（运行时度量）。
注意：SGX 的 EPID 模式需要联网验证，因为 Intel 的撤销列表是动态的。DCAP 模式可以离线，但需要自己维护 PCCS（Provisioning Certificate Caching Service）。我见过不少团队在离线环境里卡在这一步。
4.3 AMD SEV-SNP 证明：虚拟机的「硬件担保」
SEV-SNP 是 AMD 对 SEV 的增强，主要解决虚拟机被恶意 Hypervisor 篡改的问题。它的证明机制，我理解是三种里最复杂的。
SEV-SNP 的证明流程：
- 启动度量：AMD 的 PSP（Platform Security Processor）在 VM 启动时，度量整个镜像，生成 ID_BLOCK 和 AUTHOR_KEY。
- 生成 Attestation Report：VM 内的 Guest OS 通过
SNP_ATTEST指令，向 PSP 请求报告。报告包含 VM 的度量值、策略、芯片签名。 - 验证：验证方需要 AMD 的根证书链，验签报告，并检查策略是否允许当前配置。
SEV-SNP 的独特之处在于：报告里包含了 VMPL（VM Permission Level）信息。这意味着你可以证明某个代码运行在 VMPL0（最高权限）还是 VMPL3（最低权限）。这在多租户场景下很有用。
避坑指南：我曾经遇到一个案例，SEV-SNP 的 Attestation Report 验证总是失败。后来发现是 BIOS 里没有启用 SNP 的 SEV-SNP 选项，只开了 SEV-ES。硬件特性没开，报告自然签不出来。
4.4 三种协议的对比
我把它们的核心差异整理成了表格，方便你对照：
| 维度 | TPM2.0 Quote | Intel SGX/TDX Quote | AMD SEV-SNP 证明 |
|---|---|---|---|
| 信任根 | TPM 芯片 EK | Intel CPU + EPID/DCAP | AMD PSP + 芯片签名 |
| 度量范围 | 平台固件、引导链 | SGX：应用飞地；TDX：整个 TD | 虚拟机镜像、策略 |
| 离线验证 | 支持（需预置公钥） | DCAP 支持，EPID 需联网 | 支持（需预置证书链） |
| 防重放 | 依赖 nonce | 依赖 nonce + 时间戳 | 依赖 nonce + 策略版本 |
| 典型故障 | PCR 顺序不一致 | EPID 撤销、PCCS 不可达 | BIOS 未启用、策略不匹配 |
4.5 故障排查思路
不管用哪种协议，排查思路其实有共性。我总结了一个四步法：
- 检查硬件状态：TPM 是否启用？SGX/TDX 是否在 BIOS 里打开？SEV-SNP 的 BIOS 选项是否正确？
- 检查度量一致性：Quote 里的 PCR 值或 MRENCLAVE 是否和预期一致？有没有因为软件版本升级导致度量变化？
- 检查签名链：证书链是否完整？根证书是否过期？EPID 是否被撤销？
- 检查 nonce 和时效：nonce 是否匹配？时间戳是否在允许窗口内？
我的习惯：遇到 Quote 验证失败，我第一件事不是看代码，而是用厂商提供的工具直接 dump 原始 Quote 数据。TPM 用 tpm2_quote，SGX 用 sgx_quote，SEV 用 sev-tool。先确认硬件层能正常签名，再往上排查。
4.6 三种协议的适用场景
- TPM2.0：适合做平台启动完整性校验、磁盘加密密钥保护。我一般在服务器上用它做「可信启动」的根。
- SGX/TDX：适合保护敏感计算逻辑，比如密钥管理、隐私计算。TDX 更适合云原生场景，因为它不需要修改应用代码。
- SEV-SNP：适合虚拟机级别的隔离，尤其是多租户场景。如果你需要证明「我的 VM 没有被 Hypervisor 偷看」，SEV-SNP 是首选。
选哪个，没有标准答案。我建议你先画清楚威胁模型，再决定用哪种协议。毕竟，没有银弹。