机密推理：可信执行与私密服务

机密推理是一次服务会话的端到端属性。它要求声明的资产在请求处理期间始终留在声明的边界内。三种机制分别提供不同的保护：传输加密保护移动中的数据，隔离执行保护获准代码处理的明文，远程证明提供目标环境的证据。这些属性并不能证明获准应用本身安全，也不能保证模型不会泄露输入，更不能证明所有组件都已纳入边界。TEE 只是设计中的一个组件，不是整个设计。

这样区分以后，宽泛的隐私承诺就变成了具体的系统问题：保护哪些资产，防范哪些参与方，明文可以出现在哪里，证据覆盖什么，由谁评估证据，又由哪项决策发布密钥？答案必须描述一个具体部署，不能只抽象地谈可信执行。合同、访问控制、留存规则和审计可以补充这套设计，但它们支持的是不同主张。既不能说这些控制毫无用处，也不能把它们等同于由客户端强制执行的机密路径。

先明确资产与对手

受保护的资产通常属于不同主体。用户可能希望保护提示、检索上下文、输出和账户标识符，不让服务提供商的基础设施读取。模型所有者可能希望保护权重、适配器和系统指令，不让云运营者或由客户控制的宿主读取。执行期间，双方还可能关心激活值、KV 缓存（key-value cache）、分词器状态和密码密钥。这些目标可以共用部分机制，却并非天然对称，因为资产所有者、发布策略和获准接收方各不相同 (Anthropic and Pattern Labs 2025)。

有用的威胁模型应列出参与方及其能力，而不能只写“运营者”。名单可能包括网络观察者、控制宿主的云管理员、恶意虚拟机监控器或宿主操作系统、能够使用共享硬件的其他租户、服务应用运营者及其开发人员、其信任根和策略受到依赖的硬件厂商和验证方，以及创建并最终显示请求的客户端终端。工作负载内部的授权仍由 第 56 章 处理；模型行为或工具使用造成的披露仍属于 第 57 章 的范围。

受保护主张旁边还应列明明确排除项。常见排除项包括已经失陷的客户端终端、恶意但获准运行的应用代码、模型通过输出主动披露信息、厂商威胁模型之外的侧信道、拒绝服务等可用性故障，以及超出产品声明假设的物理访问。除非系统另有新鲜度或单调状态机制，否则密封状态回滚也属于排除项。排除一项风险不等于否认它，而是把边界交给另一项控制，或明确接受这项风险。

参与方或情形	需要建模的能力	机密路径可能保护什么	仍需其他控制处理什么
网络观察者	读取时序、长度、端点和加密数据包	传输中的请求与响应内容	填充、中继和元数据策略
云管理员、虚拟机监控器、宿主操作系统	调度、中断、提供 I/O、检查共享页面、拒绝服务	TEE 威胁模型范围内的 CPU 私有状态和内存	可用性、共享缓冲区验证和生命周期控制
共享硬件的其他租户	使用共享缓存、内存系统和加速器	架构上隔离的私有状态	产品特定的侧信道防御和部署隔离
服务应用运营者	选择被度量的镜像、模型、策略、日志和出口	仅限于获准且经过度量的设计明确排除运营者读取的内容	透明度、审查、授权和出口控制
硬件厂商和验证方	定义信任根、背书信息、参考值、撤销状态和评估规则	无法防范依赖方已经信任的根或策略	信任根多样性、本地验证和司法辖区清单
客户端终端	创建明文并消费明文	加密前和展示后的内容均不受保护	终端加固和面向用户的数据控制

追踪每一份明文副本

端到端审查必须从实际的 TLS 终止点开始，而不是从架构图中的第一个 TEE 开始。沿着请求路径检查负载均衡器或中继、分词器和其他预处理、调度器、CPU 缓冲区、加速器传输、设备内存、激活值、KV 缓存、GPU 之间的链路、后处理、安全过滤器和响应加密。随后继续追踪工具调用、遥测、日志、崩溃转储、缓存、存储和备份中产生的次级副本。如果某个阶段在声明边界之外看到明文，更强的机密性主张就止步于此。

这份清单经常会改变系统设计。TLS 也许必须在经过证明的工作负载内部终止；安全过滤器也许需要并入被度量的镜像，或者只能接收明确获准发布的投影；调度器可以使用长度和资源元数据，却不能读取词元；调试信息可以改成有界计数器，而不保存带有提示内容的追踪记录；工具调用可能需要独立的端到端加密与授权。因此，第 65 章 中的数据平面和 第 74 章 中的产物谱系，都是机密性论证的一部分，不是边界以下无关紧要的实现细节。

把用户的提示与输出，同服务提供商的权重、密钥、激活值和缓存分开。为每项资产指定所有者和发布策略。

覆盖入口、预处理、调度、CPU 与加速器内存、互连、后处理、工具、遥测、存储和故障产物。

列出证据必须包含或绑定的 CPU、GPU、交换机、固件、镜像、配置和运行时度量值。

检查背书信息、参考值、撤销状态、安全版本、度量值、调试状态、拓扑、新鲜度和经过证明的端点密钥。

只有通过与已接受证据绑定的通道，且租户和用途也符合预期时，才能发布提示、模型或数据密钥。

变更后重新证明，轮换密钥，清除设备，测试回滚和遥测，并保留足够证据解释每一项例外。

验证是一次发布决策

IETF 的远程证明过程架构（RATS）给出了精确的逻辑角色 (Birkholz et al. 2023)。证明方收集有关目标环境的声明，并生成证据。验证方使用厂商或供应链参与者提供的背书信息、获准的参考值和证据评估策略来评估证据，再返回证明结果。依赖方按照自己的策略使用该结果，例如准许节点加入，或要求密钥代理发布秘密。

这些角色必须分开。证明方不能自行决定自己的状态是否可接受；验证方不必持有秘密；依赖方也不必解析每一种厂商令牌。有些系统让一项服务同时承担多个角色，但逻辑责任与审计记录仍应彼此区分。

抽象地说，证据可以绑定一个新鲜随机数、一项度量值、一组安全声明和一把端点密钥：

$$E = \operatorname{Sign}_{sk_A} \left(n \parallel m \parallel c \parallel pk_E\right).$$

这里，$E$ 表示证据，$sk_A$ 是证明签名密钥或背书签名链中的一把密钥，$n$ 是新鲜随机数，$m$ 是启动时或运行时度量值，$c$ 是证据覆盖的安全声明集合，$pk_E$ 是该端点的临时公钥，$\parallel$ 表示无歧义连接。实际证据格式各不相同，AMD 报告、Intel quote、Arm 令牌和 NVIDIA 令牌不应被笼统地称为同一种东西。

度量值是对所覆盖字节、元数据或事件的摘要承诺。除非经过审查的“源代码到二进制”流程把源代码身份绑定到获准参考值，否则度量值不能证明源代码身份。它也不能证明语义行为、没有漏洞、推理正确或路径覆盖完整。即使虚拟机启动度量值已获接受，运行时加载的模型、驱动程序、配置或插件也不会自动受到覆盖。度量启动链或运行时事件链必须纳入这些内容，或者由策略通过其他受保护机制绑定它们的摘要。

验证方应检查证书链和签名、新鲜度、背书信息、参考值、TCB 状态和最低安全版本、撤销状态、调试与迁移属性、必要度量值与事件日志，以及部署策略。它还应确认 CPU、每个必要的加速器和每个受保护交换机属于同一会话和拓扑。只有全部通过后，依赖方才应通过与 $pk_E$ 绑定的通道通信，并发布会话密钥、权重密钥或数据密钥。

新鲜度与绑定防范的是不同攻击。新鲜随机数可以防止证明报文重放；绑定临时公钥可以防止会话密钥脱离证据，也有助于阻止混搭证据、布谷鸟攻击和中继攻击，也就是把一台机器的有效证据冒充成另一端点的证据。如果协议可能跨域复用证据，还应绑定租户、服务、协议转录和用途等上下文。

不同 CPU TEE 划出的边界并不相同

TEE 是一类技术，不代表统一保证。Intel SGX 隔离的是应用地址空间中的隔离区页面，其初始度量覆盖隔离区的构造过程，不覆盖任意宿主代码或 GPU。AMD SEV-SNP 按照 AMD 的威胁模型，保护机密虚拟机的私有页面和 CPU 状态，使其免受恶意宿主读取。Intel TDX 把来宾系统放入信任域，使用初始 MRTD 和运行时度量寄存器，并以事件日志解释各次扩展。Arm CCA 在可信监控固件之下创建 Realm，同时提供平台证据和 Realm 证据。整虚拟机方案通常减少应用移植工作，但来宾内核、驱动程序、共享内存 I/O 和远程证明集成仍需支持机密计算 (Costan and Devadas 2016; AMD 2020; Cheng et al. 2024; Li et al. 2022)。

技术系列与边界	防护对象	未覆盖范围	集成要求
SGX 隔离区页面和状态	SGX 模型范围内、隔离区以外的宿主软件	进程其余部分、操作系统服务、设备和应用正确性	划分应用，并尽量缩小隔离区接口
SEV-SNP 机密虚拟机的私有页面和状态	SNP 覆盖的虚拟机监控器读取，以及未经授权的重映射或修改	共享页面、恶意 I/O、可用性、应用漏洞和许多侧信道	启用机密来宾，并验证所有由宿主控制的输入
TDX 信任域的私有内存和状态	TDX 覆盖的宿主 VMM 访问	共享内存、设备、可用性和未经度量的运行时状态	评估 MRTD、RTMR、事件日志、属性和来宾策略
Arm Realm 的内存和状态	平台 CCA 实现范围内的普通世界宿主软件	外部设备、不可用资源和 Realm 边界以上的代码	同时评估平台证据与 Realm 证据

这些边界曾经失效，也一直在演进。Foreshadow 从当时的 SGX 实现中提取了秘密，并破坏了其远程证明假设 (Van Bulck et al. 2018)。持久的教训不是“硬件总会泄露”，而是每次接受决策都必须纳入产品威胁模型、固件状态、微码、安全公告、撤销状态和侧信道防护。

GPU 会形成复合边界

CPU 机密虚拟机不会自动覆盖加速器。机密 GPU 有自己的身份、固件、运行模式、声明和背书链。因此，CPU 与 GPU 报告是并行的证据根。复合证明是依赖方将这些证据根一起接受的策略，并不是一条由 CPU 度量所有 GPU 的线性链。

在 NVIDIA Hopper 系统中，证据可以覆盖 GPU 身份、机密模式配置、VBIOS 和固件度量值，以及驱动微码声明。应用、容器、服务引擎、模型和数据版本仍需由 CPU 度量启动、运行时度量或另外绑定的摘要覆盖。验证方还必须评估 IOMMU 策略和独占设备分配、GPU 固件与驱动兼容性、CPU 到 GPU 的链路、GPU 到 GPU 的链路、任何 NVSwitch，以及声明的拓扑 (Dhanuskodi et al. 2023; NVIDIA 2025)。

数据路径取决于具体产品和拓扑。在 Hopper 上，机密模式会加密并认证 CPU 到 GPU 的 PCIe 流量。中转缓冲区是宿主可见、不受保护的共享页面，只用于承载已保护的载荷，并不属于虚拟机私有内存。封装内的 HBM 中保存的是明文，没有整体加密。NVIDIA 为这部分内存声明的物理威胁假设，比防范复杂的封装级攻击更窄。Hopper 的 GPU 间 NVLink 保护取决于平台布局，多 GPU 设计也可能把 GPU 和交换机放在同一受信任物理边界内。Blackwell 在受支持配置中加入受保护的 NVLink，但这并不能证明每一种机架、交换机或拓扑都受到保护 (NVIDIA 2025)。

因此，检查清单必须具体：

• 验证 CPU 度量值、来宾属性、事件日志和端点密钥；
• 验证每个 GPU 的身份、运行模式、固件、驱动声明、TCB 状态和新鲜度；
• 验证每个必要交换机以及预期的 GPU 与交换机拓扑；
• 要求独占设备分配和预期的 IOMMU 配置；
• 记录该配置中的每条 CPU 到 GPU 的链路和 GPU 到 GPU 的链路是否提供机密性与完整性；
• 把分词器、调度器、模型、激活值、KV 缓存、后处理和加密端点放进声明边界，否则就缩小主张范围。

这些检查直接联系到 第 62 章 所述的内存与互连层级。拓扑变化是安全相关变更，不只是性能调整。

密钥发布闭合整条链路

远程证明只有在决策真正控制某项秘密或服务的访问权时，才具有运行效果。只有新鲜的复合证据满足策略后，密钥代理、KMS 或客户端才能发布权重密钥、数据密钥或会话密钥。一个实用的接受谓词是：

$$\begin{aligned} &\operatorname{Fresh}(E,n) \\ {}\land{} &\operatorname{Verify}(E) \\ {}\land{} &\operatorname{Bind}( \\ &\quad E_{\mathrm{CPU}}, E_{\mathrm{GPU}*}, \\ &\quad E_{\mathrm{switch}*}, pk_E) \\ {}\land{} &\operatorname{Policy}( \\ &\quad \operatorname{claims}(E)) \\ &= \mathrm{allow}. \end{aligned}$$

这里，$E$ 表示由 CPU、必要 GPU 和必要交换机组成的复合证据集，$n$ 是验证方提供的随机数，$pk_E$ 是绑定的端点密钥。规则还应绑定租户、用途、工作负载度量值、模型和数据版本、最低安全版本、到期时间及端点密钥。模型所有者密钥和用户会话密钥即使进入同一工作负载，也可以使用不同的发布策略。只要证据缺失、过期、处于调试模式、已撤销或彼此不一致，就应一律拒绝发布密钥。

生命周期变化必须触发新的决策。启动时，要配置并重置设备，建立 CPU 机密虚拟机，启动并清除 GPU，收集新鲜的 CPU、GPU 和交换机证据，并建立与远程证明绑定的通道。发生补丁、模型替换、扩缩容、迁移、拓扑变更或验证策略变更后，必须先重新证明，才能继续发布密钥。设备移除或发生故障时，应轮换或撤销密钥，随后重置并清除设备内存。回滚策略还要区分获准使用的旧镜像，与低于 TCB 或应用最低版本的降级。

已发布系统只是案例

Apple Private Cloud Compute、Meta 面向 WhatsApp 的 Private Processing，以及 Google Private AI Compute 都很有参考价值，因为它们公开了 TEE 之上的设计决策。不过，每一套都是厂商自行陈述的设计，不是独立认证。阅读资料时，应先弄清厂商主张什么，再寻找外部审查、可实际部署的验证工具，以及所述控制确实与生产环境一致的证据。

Apple 在 2024 年公布的设计提出五项目标：无状态处理、可强制执行的保证、无特权数据访问、不可定向和可验证透明度，最后一项通过公开软件度量值和客户端检查实现 (Apple Security Engineering and Architecture (SEAR), User Privacy, Core Operating Systems (Core OS), Services Engineering (ASE), and Machine Learning and AI (AIML) 2024)。中继有助于把用户身份与计算路由分开。Apple 在 2026 年介绍的扩展部署，把 Intel TDX、NVIDIA 机密计算和 Google 基础设施同原有验证设计组合起来，说明这些系统属性来自整体设计选择，而不是某一块芯片 (Apple Security Engineering and Architecture (SEAR), User Privacy, Core Operating Systems (Core OS), Services Engineering (ASE), and Machine Learning and AI (AIML) 2026)。

Meta 的 Private Processing 设计于 2026 年公布，声明采用 AMD SEV-SNP 与 NVIDIA H100 构成的边界，并加入 RA-TLS、匿名 HTTP 中继、透明度记录、产物到期和撤销，以及受约束的指标与日志 (Meta 2026)。这些控制各自承担不同职责：远程证明覆盖获准工作负载，中继降低定向攻击能力，遥测规则限制次级副本。

Google 的 Private AI Compute 简介描述了 SEV-SNP 前端、加固的 TPU 基础设施、内部双向远程证明、加密对等链路、IP 隐藏和公开二进制摘要 (Google Platforms and Devices et al. 2025)。该简介还区分了当前已有控制与未来对远程证明证据的外部检查，因此不能把它描述成与 Apple 相同的客户端验证路径。

AWS Nitro Enclaves 展示的是另一种边界。它把分配的内存和 vCPU 与父实例隔离，并提供根植于 Nitro 平台的证明。验证仍然信任 AWS 的证明 PKI，以及 Nitro 系统关于运营者访问能力的声明。评审时真正有用的问题不是该标签是否算作 TEE，而是平台边界、证据、密钥发布、构建可复现性和运营者威胁模型是否符合应用需求 (Amazon Web Services 2025; Trail of Bits 2024)。

衡量成本，不虚构通用数字

机密模式只给部分路径增加工作，而不是给所有计算统一加税。可以把延迟透明地拆成：

$$\begin{aligned} T_{\mathrm{base}} &= T_{\mathrm{compute}} + T_{\mathrm{io}}, \\ T_{\mathrm{CC}} &= T_{\mathrm{compute}} + T_{\mathrm{io}} \\ &\quad + \Delta_{\mathrm{crypto}} \\ &\quad + \Delta_{\mathrm{copy}} \\ &\quad + \Delta_{\mathrm{driver}}, \\ \mathrm{overhead} &= \frac{T_{\mathrm{CC}}-T_{\mathrm{base}}}{T_{\mathrm{base}}}. \end{aligned}$$

$T_{\mathrm{base}}$ 是基准请求时间，$T_{\mathrm{CC}}$ 是机密配置下的请求时间，$T_{\mathrm{compute}}$ 是加速器计算时间，$T_{\mathrm{io}}$ 是基准输入输出传输时间，三个增量分别表示新增的密码运算、数据复制，以及驱动或协议工作。计算量较大的请求可能摊薄固定传输成本，但公式并不承诺一定如此。

基准测试必须使用同一硬件、同一模型、精度、批次、上下文长度、输出长度、加速器拓扑、服务引擎、并发度、填充方式和预热状态。应报告吞吐量、首词元延迟、词元间延迟、p99、启动和证明时间、受保护内存容量，以及失败或重试行为，并把纯 CPU、单 GPU 和多 GPU 结果分开。

一项 H100 研究使用两套系统、三个模型系列和一个特定版本的 vLLM，结果显示，在大多数被测典型请求上开销低于 7%；部分较大模型的吞吐开销更低，但某些配置中的首词元延迟增幅较大 (Zhu et al. 2024)。这项结果是相关工作负载的有效证据，却不是适用于所有模型或部署的常数。引用时必须同时说明硬件、模型、软件、指标和工作负载。

替代方案改变信任与成本

TEE 把信任转移到硬件、固件、背书信息、参考值和验证策略。多方安全计算把信任分散给多个参与方；全同态加密允许服务器在不接收输入明文的情况下计算。它们的成本取决于模型与协议、安全参数、硬件、网络条件、近似方法和工作负载。不能把某一种 Transformer 和序列形状的结果写成通用开销倍数。

PUMA 展示了 LLaMA-7B 的三方安全推理，其论文标题和测量结果也清楚呈现了尚存的延迟 (Dong et al. 2025)。更新的工作仍在改变这条边界，其中包括支持 KV 缓存的 FHE 设计 (Yu et al. 2026)。即使这些系统无法满足某项交互延迟目标，也可能适合批处理、专用、混合或高保障工作流。

零知识证明系统可以证明推理正确性，也能对验证者隐藏见证，但仅有零知识并不能阻止执行普通推理的证明者读取提示明文。就这一威胁而言，零知识证明提供的是完整性，而不是提示机密性 (Chen et al. 2024)。差分隐私处理训练隐私和训练记录的影响，不回答谁可以读取实时提示，具体区分见 第 59 章。本地部署缩短了服务提供商路径，但仍需要本地明文边界、运营者策略、终端安全和供应链控制。

明确剩余风险

机密执行无法关闭所有披露路径：

• 流量分析。 加密数据流仍会暴露长度与时序。在一项研究的实验条件下，观察者可以精确重建 27% 的被测回复，并推断其中 53% 的主题 (Weiss et al. 2024)。填充、词元分组或整段回复批处理，可以用带宽或流式延迟换取更少的流量长度泄露。
• 侧信道和物理范围。 只有在所选产品和部署明确声明覆盖的范围内，缓存、资源争用、功耗、故障和封装攻击才受到防护。多租户和物理访问策略必须符合该范围。
• 恶意的获准代码。 有效证据也可能对应获准调试镜像、不安全的解析器、恶意模型或权限过大的服务。度量不等于代码审查。
• 输出外泄和工具外泄。 工作负载可能通过生成输出、工具调用或获准网络目的地泄露受保护上下文，因此授权和出口策略仍不可缺少。
• 回滚和密封状态。 如果系统没有在已回滚状态之外检查版本与新鲜度，有效的旧镜像或恢复状态仍可能违反当前策略。
• 供应链和验证。 固件签名者、构建系统、背书信任根、参考值发布者、验证方运营者和撤销渠道仍是受信任依赖。其所有权和司法辖区取决于具体部署。
• 终端失陷和可用性。 客户端以明文查看输入和输出，宿主仍可延迟、中断或拒绝服务。TEE 既不会加固客户端，也不保证服务可用。

保留运行记录

部署记录应当机器可读、带有版本，并与实际触发密钥发布的策略关联：

protected_assets_and_data_classes:
threat_model_and_explicit_exclusions:
plaintext_path_and_boundary_inventory:
workload_measurement_and_source_revision:
attestation_format_and_verifier_policy:
endorsements_reference_values_and_tcb_status:
freshness_and_session_key_binding:
cpu_gpu_switch_topology_and_link_protection:
image_model_data_and_key_revisions:
key_release_rotation_and_revocation:
ingress_egress_logging_and_storage_paths:
rollout_rollback_reset_and_scrub_policy:
side_channel_and_traffic_analysis_controls:
benchmark_workload_and_overhead_results:
verification_and_exception_owner:

除了成功发布，还要记录被拒绝的证据和策略例外。记录本身可能暴露软件版本、基础设施布局或数据类别，因此对它的访问也需要策略约束。

回归场景

测试应覆盖证据、拓扑、应用和运行流程中的失效：

• 证明报文重放、过期 TCB、已撤销固件、度量值不匹配和未绑定的会话密钥；
• 边界外终止 TLS、未经证明的 GPU、来自不同会话的 CPU 与 GPU 证据，以及明文 GPU 链路；
• 获准调试镜像、崩溃转储或日志副本、模型替换和定向中继；
• 流量长度泄露、密封状态回滚、工具外泄和验证方故障。

每个场景都要断言验证是否拒绝、密钥发布是否默认关闭、告警是否到达负责人，以及已经发布的密钥是否轮换或撤销。还要测试恢复过程：验证方故障不能悄悄变成“允许”，修补后的节点不能继承被替换节点的授权。

机密性属于完整路径，而不是某种产品

可靠的部署从资产和对手出发，盘点每一份明文副本，组合新鲜的 CPU 与加速器证据，绑定端点密钥，再由依赖方控制密钥发布。上线后仍需持续运行这套机制：版本下限会变化，固件会被撤销，拓扑会调整，模型会更新，调试也会产生新的副本。TEE 可以让高强度机密路径成为可能，但只有完整路径、验证策略、发布协议和运行纪律，才能决定系统实际保护什么。

延伸阅读