在调用第三方推理 API 时，一个根本性的信任问题始终存在：供应商声称使用的模型版本和量化精度，是否真的与协议约定一致？传统模式下，用户只能被动接受服务端的输出，无法验证底层模型的实际状态。Tinfoil 提出了一套基于加密证明的完整解决方案，通过硬件可信执行环境（TEE）、软件度量签名与模型只读存储的三层验证，让推理供应商无法在模型量化状态上做任何隐瞒。
推理完整性的核心威胁模型
当企业将敏感数据发送到外部推理服务时，面临的核心风险并非仅仅数据泄露，而是模型身份的不可验证性。供应商可能出于成本或性能考虑，对外宣传使用某版本的未量化模型，实际上却部署了经过重度量化（int4 甚至更低）的版本，导致输出质量下降却无从举证。传统 API 调用的 TLS 加密只能保护传输层安全，却无法证明服务器端运行的代码和模型是否与声称的一致。
这种威胁的本质在于：用户是在 blind trust（盲目信任）的前提下使用推理服务。即便供应商提供了一份模型哈希值作为 “证据”，用户也无法在运行时验证这个哈希是否真正对应了正在处理请求的那段代码。攻击者只需在运行时动态加载不同的模型权重，即可绕过任何静态检查。Tinfoil 的设计目标正是要消除这种信息不对称，通过加密 attestation（证明）机制，让模型身份在每次推理请求前都可以被用户端验证。
三层验证架构的技术实现
Tinfoil 的验证体系将三个关键要素绑定在一起，形成一条不可伪造的信任链。第一个要素是硬件可信执行环境，支持 AMD SEV-SNP、AWS Nitro Enclave 以及 NVIDIA GPU TEE 等主流机密计算平台。这些硬件提供了远程证明能力，能够生成由硬件私钥签名的度量报告，证明特定代码确实运行在真实的物理芯片上而非模拟环境。
第二个要素是代码和运行时的度量签名。Tinfoil 使用 Sigstore 框架，在构建阶段对整个镜像进行哈希计算，生成包含提交信息和镜像哈希的签名 bundle。当用户进行验证时，只需信任 Sigstore 的根证书颁发机构，即可验证度量值是否来自可信的构建流程。这意味着任何对运行时代码的篡改 —— 无论是替换了推理框架版本还是植入了后门 —— 都会导致度量不匹配。
第三个要素是模型权重的只读保护。模型文件被封装进名为 modelpack 的只读磁盘镜像（.mpk），基于 EROFS 文件系统并启用 dm-verity 完整性校验。dm-verity 通过在文件系统层计算 Merkel 哈希树，使得任何对模型权重的微小修改都会导致根哈希变化，进而触发启动失败。这意味着一旦模型被封装进 modelpack 并记录了根哈希，供应商无法在运行时替换为其他量化版本的权重而不被发现。
客户端验证的完整流程
从用户端视角来看，一次完整的验证流程包含五个关键步骤。首先，客户端向推理服务的 attestation 端点发起请求，获取由硬件 TEE 签名的证明文档和 TLS 证书指纹。证明文档中包含了运行时代码的度量值（CRTM，即 Core Root of Trust for Measurement）以及服务器的公钥信息。
接下来，客户端使用硬件供应商提供的根证书（AMD 的 VCEK、AWS 的 Nitro 根证书等）验证证明文档的签名真实性。这一步确保了证明确实来自真实存在的硬件 TEE，而非攻击者伪造的返回值。如果硬件签名验证失败，说明当前连接的服务器并非运行在可信硬件环境中，客户端应当立即终止连接。
通过硬件验证后，客户端下载 Sigstore 签名 bundle，其中包含了构建时记录的预期度量值。客户端将这些预期值与证明文档中的运行时度量进行比对。任何差异都表明代码在构建后被人为修改过，可能是供应商试图隐瞒的量化操作或是其他篡改行为。
在度量验证通过后，客户端还需要确认 TLS 连接的终端点与证明文档中记录的公钥一致。这一步确保了 TLS 握手实际上是在经过验证的 TEE 内部完成的，而不是在不可信的代理层终止。如果服务器的 TLS 公钥与证明文档不匹配，说明存在中间人攻击或流量转发风险。
只有当上述所有验证步骤全部通过后，客户端才会向推理服务发送实际的提示词或输入数据。这种 “先验证后信任” 的模式从根本上改变了用户与推理供应商之间的权力关系 —— 不再是单向的 blind trust，而是基于加密证明的可验证信任。
CPU-GPU 联合证明与编排层
对于使用 GPU 进行推理的场景，Tinfoil 还引入了 CPU-GPU 联合证明机制。推理请求首先到达运行在 TEE 中的 confidential inference orchestrator（机密推理编排器），该编排器本身也经过完整的 attestation 验证。编排器负责将请求路由到具体的模型推理 enclave，而后者同时提供 CPU 和 GPU 两方面的 attestation 报告。
具体而言，NVIDIA GPU TEE 会生成关于 GPU 固件配置、CUDA 驱动版本以及模型权重加载状态的度量证明。CPU enclave 在转发推理任务前，会验证这些 GPU 度量是否符合预期。这样就形成了一条从客户端到 CPU 再到 GPU 的完整信任链，确保整个推理流水线都在可验证的可信环境中运行。
Tinfoil 将这一通用机制封装为 tfshim（Tinfoil shim）组件，部署在编排器和各个模型 enclave 中。tfshim 负责提供统一的 attestation 接口、 TLS 终止点以及安全策略执行点。通过标准化的 shim 层，基础设施团队可以在不修改上层推理代码的前提下，为任意模型部署可验证的机密计算环境。
工程落地的关键参数与监控要点
在生产环境中部署 Tinfoil 类型的推理完整性验证时，有几个关键的工程参数需要特别关注。硬件层面，需要确保 TEE 支持的版本与供应链安全策略一致，例如 AMD SEV-SNP 的 ABI 版本号应当纳入配置白名单。软件构建层面，Sigstore 签名的有效期、撤销列表的刷新频率以及根证书的轮换周期都应当纳入自动化运维流程。
监控层面，建议对以下指标进行持续采集：attestation 验证成功率的实时趋势、度量值不匹配事件的告警阈值、TEE 运行时状态（如内存加密引擎的健康度）以及 Sigstore bundle 的版本分布。当验证成功率出现下降趋势时，可能表明存在配置漂移或潜在的供应链攻击。
对于需要满足合规要求的行业（如金融、医疗），还可以将 attestation 报告作为审计日志的一部分长期保存，配合不可篡改的存储后端（如对象存储的 WORM 策略），为事后溯源提供密码学证据。
资料来源
- Tinfoil 官方文档：https://docs.tinfoil.sh/verification/attestation-architecture
- Tinfoil GitHub 验证器：https://github.com/tinfoilsh/verifier