机密 AI 推理远程证明：让模型密钥只释放给合格执行环境

把推理部署到“机密 VM”并不能直接证明当前节点启用了正确 TEE、GPU 处于要求的模式、启动镜像未变，或证明结果不是昨天截获的。真正的控制点是：只有符合发布策略的新鲜证明才能取得模型 DEK、租户输入 DEK 或短期数据访问令牌。密钥管理 负责保管密钥，本篇定义密钥释放前必须核验的执行环境事实。

按 RATS 角色拆开信任

RFC 9334 把远程证明分成 Attester、Verifier 和 Relying Party。推理实例作为 Attester 产生 Evidence；独立 Verifier 根据参考值与 endorsements 生成 Attestation Result；密钥释放服务作为 Relying Party 只消费经过认证的结果。不要让实例自己提交 trusted=true，也不要让 KMS 直接解析各厂商原始二进制报告，否则每次硬件升级都会把供应商细节扩散到密钥策略。

冻结 ai.attestation.policy.v1，至少绑定环境、工作负载镜像 digest、启动参数摘要、允许的 CPU TCB、GPU 证明状态、调试关闭标志、验证器版本和最晚更新时间。EAT（RFC 9711）可作为标准声明容器，但 claim 名存在不等于可信；Verifier 必须说明哪些 claim 来自硬件、哪些来自编排层，缺失的强制测量一律拒绝。

{
  "policy": "ai.attestation.policy.v1",
  "nonce": "base64url(random-256-bit)",
  "ephemeralPublicKeyHash": "sha256:...",
  "releaseId": "release_42",
  "tenant": "t_42",
  "workloadDigest": "sha256:...",
  "cpuTcb": "accepted-set-2026-07",
  "gpu": {"required": true, "debug": false},
  "purpose": "tenant-input-dek",
  "expiresInSeconds": 300
}

新鲜度与复合证明必须同时成立

实例在被证明的执行环境内生成不可导出的临时私钥，只把公钥交给证明路径。硬件绑定的 Evidence 必须覆盖 nonce + ephemeralPublicKeyHash + releaseId + tenant + purpose；仅把这些字段放在普通请求旁边，无法阻止攻击者把合格 Evidence 转给自己的公钥形成 cuckoo relay。具体 TEE 用其受保护的 report/user data 承载这组 canonical binding，缺少硬件绑定能力就不能释放密钥。

密钥服务保存单次 challenge。Verifier 验证证书链与 Evidence 后，Relying Party 仍要核对 Attestation Result 的 audience 是当前 key broker、未过期，TCB 当前未撤销，policy/reference digest 与申请 release 一致，并复算上述 binding。RP 先把 DEK 封装给被证明公钥，再在 release store 用 CAS 将 nonce 从 PENDING 原子改为 CONSUMED，同一事务保存 binding 与 wrapped result；只有赢家能返回，响应丢失只能读取同一结果，不同 binding 重试直接拒绝。

GPU 推理往往同时依赖 CPU TEE、设备固件、驱动和工作负载。只验 VM 报告会漏掉被替换的 GPU 路径，只验 GPU 又无法证明是谁请求了设备。平台要组合各层 Evidence，验证证书链、TCB 状态、设备绑定与镜像测量，再由一份策略给出整体结果。Confidential Containers 的 Attestation Agent、Key Broker Service 分层可用于理解该边界，但生产仍需冻结自己接受的 claim 和版本。

远程证明也不证明模型没有后门或回答正确。推理跨硬件可复现性 仍需验证输出等价，AI 供应链安全 仍需治理制品来源；证明只回答“当前执行环境是否属于允许集合”。

把故障注入放进发布门禁

预发布演练至少包括：重放旧 Evidence、并发消费 nonce、替换临时公钥、release/tenant/purpose 不匹配、把 A 的 Evidence 中继给 B、错误 result audience、过期结果、未批准镜像、debug、旧 TCB、缺少 GPU 证明和 Verifier 超时。期望是密钥不释放或旧 data lease 失效，不允许为了可用性改成“验证失败也放行”。

验收记录包含 Evidence 与 binding 摘要、nonce、result audience、参考值/策略 digest、TCB 状态、证书链、临时公钥指纹、key version、data lease 和到期时间；原始数据与密钥不得进入普通日志。观测可结合 AI Agent 可观测性，但证明日志进入独立安全域。

硬指标是：不合格矩阵取得密钥为零；每次解密关联未过期证明和 data lease；参考值更新覆盖全部 Verifier；KMS 或 Verifier 不可用时明文新任务为零。只有已登记且 lease 未过期的 enclave 可在策略允许的短窗口完成在途请求，不能领取新租户密钥。

更新参考值时保留可逆性

升级先把新镜像与 TCB 加入候选策略，在无明文的 shadow Verifier 上重放 Evidence；一致后向少量实例开放，再扩大。回滚先停止候选 generation 的新密钥释放与任务准入，终止候选实例，撤销其 data lease、broker token 和临时证书，并从实例清单、活跃 lease 与解密审计三处验证归零，再把流量切回上一个仍安全的 digest。

吊销临时证书只阻止未来认证，不能收回已释放的 DEK。若实例可能导出明文、私钥保护失效或无法证明内存随终止清除，应把相关 DEK/KEK 视为泄露，轮换并重新包装；只有证明密钥从未离开不可导出边界且实例已销毁，才可免于轮换。旧策略在观察期内只服务旧 release，不能无限接受所有版本。

若厂商标记旧 TCB 已撤销，回滚不得重新接受它；安全降级是排队、转到另一个已证明的区域或拒绝敏感任务。云灾难恢复 需要预先证明备用区也拥有独立 Verifier、参考值与 KMS 授权，而不是事故时复制一条宽松策略。

机密计算只有与新鲜 Evidence、明确参考值和用途受限的密钥释放组成闭环，才能从硬件卖点变成可验收的生产安全控制。

延伸阅读

• 密钥管理
• 推理跨硬件可复现性
• AI 供应链安全
• 云灾难恢复