EnclaveX：基于CPU/GPU TEE的端到端机密AI系统

大家读完觉得有帮助记得关注和点赞！！！

摘要

大型语言模型（LLM）迅速普及，推动了AI应用的广泛采用。大多数部署依赖于集中式基础设施，如Microsoft Azure、Google Cloud或AWS，要求用户共享敏感数据以及训练或微调代码。这种依赖性带来了重大的安全和隐私问题，因为必须信任云提供商以确保机密性和完整性。

可信执行环境（TEE）如Intel SGX/TDX、AMD SEV‑SNP和ARM CCA已被引入以缓解这些风险。最近，NVIDIA开发了GPU TEE（如H100/H200），但对集成CPU和GPU TEE的端到端工作流程的全面评估仍然有限。关键方面，包括性能开销、远程证明以及AI/LLM应用的安全保证，尚未得到充分研究。

本文通过提出一种结合CPU和GPU TEE的端到端工作流程来弥补这一空白。我们提出了在VM级别（通过Intel TDX和AMD SEV‑SNP）和应用级别确保机密性和完整性的机制，突出了诸如Kubernetes管理员能够访问机密VM内容等漏洞。最后，我们使用行业基准评估了我们系统的性能开销，重点关注集成Intel TDX与NVIDIA H200 GPU的配置。

1. 引言

云计算彻底改变了数据处理（sgx_pyspark），包括AI/ML工作负载的训练/微调和推理（securetf），但它引入了深刻的安全和合规风险，特别是对于处理敏感信息的行业，如电子健康和金融。传统云设置将数据暴露于来自特权内部人员、恶意管理员或供应链漏洞的威胁，甚至在计算期间——“使用中的数据”仍然是保护静态数据和传输中数据的加密范式中的一个明显盲点。

在电子健康领域，患者记录和基因组数据必须符合HIPAA等法规，泄露可能侵蚀信任并招致巨额罚款。金融机构面临PCI-DSS和类似标准，在AI驱动的欺诈检测或算法交易期间面临模型投毒或数据外泄的风险。多租户云加剧了这些问题，因为共享基础设施扩大了攻击面，而生成式AI的兴起加剧了对知识产权泄露和欧盟AI法案等框架下监管审查的担忧。

为此，可信执行环境（TEE）如Intel SGX/TDX（isgx; IntelTDXWhitepaper2022）、AMD SEV-SNP（amd_sev_snp）或NVIDIA Hopper GPU（nvidia_tee）旨在通过将应用执行与云服务提供商（CSP）管理软件和基础设施隔离来减少此攻击面。具体而言，TEE很好地集成到CSP编排和部署软件Kubernetes（K8s）（kubernetes）中，允许用户透明地将工作负载部署在机密虚拟机（CVM）TEE内，例如使用机密容器（confidential_containers）。CVM封闭的应用可以进一步通过CVM包含的GPU驱动程序安全地使用NVIDIA Hopper机密GPU（cGPU），保护CVM-cGPU IO和计算免受CSP侵害。

然而，这种最先进的方法仍然未能将整个CSP管理栈从应用的可信计算基（TCB）中移除，特别是K8s管理员。在实践中，K8s管理员保留完整的API权限，例如，可以运行kubectl exec进入机密VM并访问敏感数据，实际上作为安全飞地内的root用户运行。为防止这种情况，必须在应用层保护秘密。密钥只应在成功证明后释放给应用，类似于Intel SGX模型。通过这种设计，即使管理员设法exec进入机密VM，他们仍然无法访问应用的加密密钥。我们还在Guest内核中禁用内存转储功能，以防止K8s管理员转储CVM内应用的内存。

在本文中，我们介绍EnclaveX，一个全面的端到端云机密计算平台，重新构想安全的AI/ML部署。EnclaveX集成了CPU TEE（如Intel TDX用于加密内存隔离）、机密GPU（如NVIDIA H200（nvidia2024h200）用于受保护的AI/ML加速）以及用于K8s原生工作流的SCONE（scone）运行时。这种组合不仅通过Intel TDX和NVIDIA H200在VM级别实现远程证明，还通过使用SCONE在应用层实现远程证明。

这些组件共同通过在释放敏感材料之前验证代码、数据和执行环境的完整性来强制实现强大的数据主权。因此，组织可以在公共云中运行高价值工作负载，同时保持对访问和合规的细粒度控制。其结果是形成一个可扩展、高性能的框架，统一了HPC级计算与强大的安全保障，使AI创新不受传统本地孤岛的限制。

2. 相关工作

CVM内部的基于进程的TEE。 存在若干在AMD SEV-SNP CVM内部创建基于进程的TEE的工作（wang_road_2025; zhao_vsgx_2022; ahmad_veil_2023），使用AMD虚拟机权限级别（VMPL）保护进程免受CVM OS侵害。这些系统除了CVM级证明外，还提供进程级证明。相比之下，EnclaveX与CVM无关，因此与Intel TDX、AMD SEV‑SNP和ARM CCA兼容。先前工作依赖VMPL机制，而EnclaveX使用在CVM引导期间测量的内核模块，避免依赖任何特定CVM指令集扩展。

此外，虽然先前方法将证明限制于基于CPU的TEE，但据我们所知，EnclaveX是首个将基于进程的TEE扩展到CVM内机密GPU的工作。这为CVM带来了SGX风格的进程隔离，并具有完整的机密GPU支持，使进程级TEE的安全保证能够跨越CPU-GPU边界，并确保I/O路径即使面对具有root权限的K8s管理员也保持受保护。

机密GPU基准测试。 大量工作分析了机密GPU性能（chrapek_confidential_2025; ibarra_performance_2025; tan_performance_2024; yang_dissecting_2025; mohan_securing_2024; gu_nvidia_2025; zhuh200），在各种工作负载上剖析NVIDIA H100和H200机密计算模式。EnclaveX在此基础上构建，据我们所知，首次在H200 cGPU上提供了包含完整远程证明测量的机密大型语言模型（LLM）推理基准。重要的是，我们提供了量化H200在机密计算模式下在CVM内运行与在非机密模式下在原生VM中使用H200相比的开销的经验结果。此外，虽然先前研究关注基于CVM的TEE到cGPU执行路径，但据我们所知，EnclaveX是首个评估CVM内部基于进程的TEE到cGPU工作负载的工作，将CVM内部进程级TEE的安全边界扩展到cGPU领域。

3. 系统设计概述

3.1. 威胁模型

我们设计系统以抵御在复杂云虚拟化环境中运行的高能力攻击者。在此模型中，攻击者控制整个系统软件栈，包括操作系统和虚拟机监视器，并可执行物理攻击如内存探测。我们假设K8s管理员保留完整API权限，可调用kubectl exec访问机密VM。我们还假设云网络不可信，使攻击者能够丢弃、注入、重放或修改数据包，并操纵路由。总之，这些假设与经典的Dolev–Yao攻击者模型（dolev-yao）一致。

我们的威胁模型明确排除侧信道攻击（sidechannel-attack1; sidechannel-attack2），这超出了本工作范围。尽管如此，SCONE平台提供了针对基于L1的侧信道威胁（varys）和基于L2的侧信道威胁（使用AEX-Notify（aex-notify））的缓解措施。此外，它还针对Iago攻击（checkoway2013iago）进行了加固。为解决Spectre相关漏洞（Kocher2018spectre; chen2018sgxpectre），我们采用基于LLVM的技术，如推测性加载加固（Kocher2018spectre）。拒绝服务攻击也不在范围内，因为它们可由任何控制基础设施的实体（如OS或虚拟机监视器）轻易执行。

3.2. 构建模块

3.2.1. 可信执行环境（TEE）

作为EnclaveX的安全锚点，基于硬件的TEE包括Intel SGX/TDX、AMD SEV-SNP和ARM CCA，为云部署提供了先进的“使用中”代码和数据完整性与机密性保证。由于TEE扩展了硬件组件，这些扩展将其信任根建立在供应商硬件中，而非云服务提供商（CSP）系统软件。用户还可以通过远程证明断言TEE硬件和封闭应用的真实性，并建立安全通信通道。TEE并非将执行完全与CSP隔离，而是向系统软件提供严格的管理API。因此，TEE在保护其封闭计算的同时，原生地适应CSP部署模型（CCC2022Whitepaper）。

Intel SGX引入了细粒度的进程级隔离，但其采用受到复杂开发模型、有限软件兼容性和性能开销等挑战的阻碍。较新的TEE，如Intel TDX、AMD SEV‑SNP和ARM CCA，转向VM级保护，保护整个Guest操作系统和未修改的应用。

TEE模型正日益扩展到AI加速器，包括NVIDIA的H100/H200和GB100/200 GPU，以及Graphcore IPU。例如，NVIDIA的H100/H200平台支持跨越CPU和GPU的统一TEE，通过PCIe级隔离保护GPU内存和寄存器，并加密CPU–GPU通信通道以确保机密性和完整性。GPU和CPU TEE都使用由硬件AES‑256‑GCM支持的弹跳缓冲区，在原本不可信的PCIe链路上保护其I/O。为建立这些保护，TEE通过安全协议和数据模型（SPDM）协议（nertney2023confidential）协商共享密钥。

3.2.2. SCONE：机密计算平台

屏蔽执行： 在软件核心，SCONE提供了一个屏蔽执行框架，使未修改的应用能够在TEE飞地（如Intel SGX/TDX）内运行。SCONE基于Intel SGX/TDX构建，并与新兴的机密GPU技术兼容，加密使用中的数据代码，保护它们免受主机OS、虚拟机监视器或云提供商的侵害。其特点是具有最小化的可信计算基（TCB），可在微服务级别实现细粒度信任。这隔离了各个组件，与完整VM TEE相比大幅减少了攻击面，同时通过远程证明报告简化了审计，这些报告验证飞地完整性而不暴露其内容。SCONE的架构支持未修改的应用，将它们封装在安全包装器中，无缝处理加密密钥和证明。

3.2.3. 远程证明

EnclaveX通过远程证明证明其可信度的能力是系统安全性的核心。遵循远程证明过程架构（RATS）（rfc9334）和可信执行环境配置（TEEP）架构（rfc9397），远程证明使证明者能够向依赖方提供关于自身的一组可验证声明，依赖方随后可考虑证明者是否可信。在TEE的上下文中，这些声明通常包括TEE属性、TEE制造商或在TEE中运行的受信任应用。最后，依赖方将证据转发给验证者，验证者使用可能外部提供的背书、参考值或证据评估策略来验证证据。验证者随后将证明结果返回给依赖方，依赖方可能再次使用额外的评估策略检查结果。值得注意的是，证明数据流的确切顺序可能有所不同。

EnclaveX的证明建立在CVM（即Intel TDX和AMD SEV-SNP）和cGPU证明之上。为此，我们为这些不同的证明过程介绍必要的背景。

CVM。 CVM证明使依赖方能够确保CVM在真实的支持CVM的硬件上以预期状态运行。CVM证明流程遵循类似模式；依赖方接收CPU签名的包含引导测量的证明报告。依赖方随后使用供应商证书验证报告签名，并检查报告中包含的测量值。

Intel TDX。 对于TDX证明，TD证明者以签名的证明报告（称为quote）的形式向依赖方提供证据。TD通过首先从主机包含的TDX模块获取报告，并将此报告转发给位于主机但TD外部的签名引用飞地（QE）来派生此quote。该QE随后使用Intel配置认证密钥（PCK）签名的证明密钥（AK）签署报告。QE将生成的quote返回给TD，TD再次将此签名证据转发给依赖方。依赖方随后可作为验证者，使用Intel SGX配置认证服务（PCS）验证quote签名，并进一步检查quote中包含的测量值（IntelTDXWhitepaper2022）。

NVIDIA Hopper架构GPU。 通过NVIDIA的cGPU证明，依赖方可以验证证明者GPU确实是NVIDIA制造的、在CC启用模式下运行的Hopper GPU。CVM包含的依赖方通过向证明者cGPU质询一个nonce来发起证明。该cGPU随后生成包含证据和nonce的证明报告，并使用称为证明密钥（AK）的私钥签署此报告。该cGPU在引导期间生成此证明密钥及其对应的公钥，从引导设备硬件测量派生密钥，并最终使用设备嵌入的设备身份密钥签署AK公钥。

cGPU将AK和设备身份密钥的公钥返回给验证者，与NVIDIA GPU驱动程序获取的证书共同形成证书链。验证者随后检查此证书链，同时使用NVIDIA在线证书状态协议（OCSP）（NvidiaOCSPService）服务确保没有证书被撤销。

随后，验证者接收并使用先前验证的AK公钥验证由AK签名的证明报告的签名。在此报告中，验证者获取相应的GPU驱动程序和VBIOS标识，并使用此标识从NVIDIA RIM服务（NvidiaRIMService）请求相应的参考完整性清单（RIM）文件。此外，验证者验证RIM文件并编译由RIM文件派生的黄金测量列表。验证者最终通过将每个报告测量值与验证者编译的黄金测量值进行比较来验证证明报告的测量值。如果所有报告测量值都与黄金测量值匹配，则假定GPU处于预期状态（gu_nvidia_2025; nertney2023confidential）。

3.3. 详细设计

EnclaveX构成了一个安全的机密AI/ML系统，利用CPU和GPU可信执行环境（TEE），保护与GPU交互的基于进程的应用免受具有CVM访问权限的特权管理员侵害。为此，EnclaveX仅在成功证明后向基于进程的应用提供秘密，并在Guest内核中禁用内存转储。因此，此架构在整个ML生命周期（包括推理、训练和微调）中确保敏感数据和计算的保护。

为促进ML应用的强大远程证明，在每个机密VM的Guest OS中实现了一个自定义内核模块。该模块对运行的ML工作负载执行动态测量，生成可验证的quote，证明应用的完整性和真实性。

• 配置和证明服务（CAS）： 作为整个系统信任根的服务。CAS在其自己的TEE内运行，终端用户可直接证明，确保透明性和可验证性。它管理安全策略、处理证明工作流，并在成功验证后配置秘密（如解密密钥）。

• 证明内核模块： 部署在机密VM的Guest OS中，该模块在运行时测量ML应用。它与CAS交互以获取签名密钥，基于应用哈希生成加密quote，并支持整体远程证明链。此外，我们禁用了Guest OS内的所有内存转储能力。Guest OS本身使用底层TEE的证明机制进行证明。

• 安全策略： 用户为CAS定义的可配置配置，指定允许的测量值、证明要求以及机密VM和ML应用的秘密配置规则。

3.4. 系统工作流程

图1：使用SCONE的EnclaveX安全AI/ML系统设计

图1说明了所提议系统架构的高层工作流程。机密AI/ML系统工作流程始于用户为其AI/ML应用定义安全策略，并证明配置和证明服务（CAS）（palaemon）（步骤①），该服务在可信执行环境（TEE）内运行以建立信任。用户随后将策略提交给CAS（步骤②）。当使用Intel TDX生成机密VM时，生成包含VM ID的VM特定策略扩展并上传到CAS（步骤②），随后重新证明CAS（步骤③）。当VM引导时，其硬件测量并证明固件，固件随后证明Guest OS和内核，包括自定义证明内核模块。该模块向GPU驱动程序发起请求以证明机密GPU（nvidia_tee）（步骤④）。系统随后向CAS进行认证（步骤⑤），提交来自机密VM和GPU的证明报告。CAS使用这些报告根据策略颁发签名密钥，并将VM和GPU标记为已证明（步骤⑥）。这保证了机密VM的单例属性（sinclave）。接下来，内核模块测量正在运行的ML应用——在推理或训练期间——生成加密哈希，签名生成quote，并将其发送到CAS（步骤⑦）。CAS根据策略验证quote，如果有效，则配置配置数据和秘密如解密密钥（步骤⑧），使ML应用能够在CPU和GPU TEE内安全处理数据（步骤⑨）。

4. 实现

如图1所示，我们使用SCONE框架（scone; palaemon）实现EnclaveX，在基于软件的飞地内运行原生AI/ML应用，无需对应用代码进行任何修改。关于TEE，我们使用Intel TDX作为CVM，NVIDIA H200 GPU作为cGPU。我们的实现依赖Trustee（trustee）和SCONE证明（palaemon）来构建EnclaveX CAS：Trustee证明CVM，而SCONE证明验证AI/ML应用本身的完整性。为在不同硬件平台上启用此功能，我们还开发了证明内核模块，称为SCONE内核模块，将开源。该模块允许EnclaveX在其他机密计算架构（如AMD SEV-SNP和ARM CCA）上运行，同样无需更改AI/ML应用代码。

5. 基准测试

(a) 吞吐量基准（每秒词元数，TPS）。 批量大小从1到64缩放，输入和输出词元大小固定为128。SCONE到CVM的开销可忽略不计。CVM到原生的开销在62.8%到35.0%之间，随批量增大而减小。

(b) 词元间延迟（即词元间时间，TBT）基准。 批量大小缩放，输入和输出词元大小固定为128。SCONE到CVM的开销可忽略不计。CVM到原生的开销在73.9%到35.2%之间，随批量增大而减小。

(c) 首词元时间（TTFT）延迟基准。 批量大小固定为1，输出词元大小为128，输入词元大小从32到1024缩放。SCONE到CVM的开销可忽略不计。CVM到原生的开销在38.3%到11.2%之间，随输入词元大小增大而减小。

图2：SYS-322GA-NR上的LLM推理基准测试结果。 我们在三种模式下测量性能：（1）原生，Guest为原生VM，GPU未处于CC模式；（2）cvm，Guest为TDX，GPU处于CC模式；（3）scone，包含EnclaveX修改的TDX和处于CC模式的GPU。每个基准发出500×批量大小个请求，例如批量大小64时32000个请求。柱状图显示相对于前一个柱（从左到右）的绝对百分比差异。

我们通过基准测试端到端工作流程来评估EnclaveX，以确认H200 GPU上LLM推理的可忽略开销。安全验证包括完整证明链验证，确保生产级可靠性。

5.1. LLM推理性能

为确定EnclaveX的性能，我们对EnclaveX封闭的LLM进行推理基准测试。作为基线，我们在连接到处于机密模式的cGPU的原生Intel TDX CVM内运行LLM推理。我们测量词元间延迟（ITL）和系统吞吐量指标每秒词元数（TPS），同时变化批量大小。此外，我们测量首词元时间（TTFT），同时变化输入词元大小。对于每个基准，我们发出500×批量大小个请求，例如批量大小64时为32000个请求。

除EnclaveX的开销外，我们还包括H200在非CC模式下非TDX Guest的原生推理结果。为此，我们展示了LLM推理的机密计算开销。

实验设置。 我们对环境包含的NVIDIA优化llama-3.1-8b-instruct（llama3herd2024; nvidia_llama31_fp8_2024）LLM进行基准测试，使用NVIDIA Triton推理服务器v25.01与Triton v2.54.0（triton_server_2501）服务模型，并使用TensorRT-LLM后端v0.17.0（NVIDIA_TensorRT_LLM_2023）。我们进一步使用NVIDIA genai-perf（NVIDIA_GenAI_Perf_2024）基准测试工具发出请求并测量服务器性能。我们通过使用FP8用于模型权重和键值缓存来优化H200的模型引擎。对于模型参数，我们启用动态批处理并将键值空闲GPU内存分数设置为0.95。

关于环境，硬件基础是Supermicro的SYS-322GA-NR（sys322），配备双Intel Xeon 6900系列处理器（P核每CPU高达128核/256线程，500W TDP）和755G内存。服务器进一步配备NVIDIA H200 NVL（141GB HBM3e）GPU，通过PCIe 5.0连接（sys322）。

我们在Ubuntu 25.04主机上运行实验，在Ubuntu 24.04.1 LTS Guest内，由QEMU 9.2.1作为虚拟机监视器托管，Guest以100G RAM和32 vCPU启动。我们使用Docker v29.1.5托管服务器，使用triton推理服务器镜像nvcr.io/nvidia/tritonserver:25.01-trtllm-python-py3。

RQ1. EnclaveX的LLM推理性能（TPS、TBT和TTFT）相对于原生CVM的LLM推理性能有多少开销？ 为测量TPS和TBT，我们设置输入和输出词元大小为128，同时将批量大小从1扩展到64。为进一步测量TTFT，我们设置输出词元大小为128，批量大小为1，同时将输入词元大小从32扩展到1024。

结果。 如图2(a)、2(b)和2(c)所示，与原生CVM部署相比，我们没有测量到EnclaveX的任何开销。任何微小差异都不显著，且在预期标准差范围内。

我们通过在“SIM”模式下执行SCONE运行时实现了这一性能；运行时依赖CVM内存保护，不进一步加密内存。因此，运行时同步执行系统调用而不复制系统调用参数，并将内存管理委托给内核。

RQ1结论：EnclaveX通过仅促进证明且不干预推理，对LLM推理不产生相对于CVM基线的性能开销。

RQ2. 原生CC性能相对于非CC原生推理的开销是多少？

结果。 关于TPS和TBT，我们在图2(a)和2(b)中看到cvm相对于原生有明显的开销。TPS的开销在35.0%到62.8%之间变化，TBT的开销在35.2%到73.9%之间变化。在两个基准中，开销随批量增大而趋于减小。对于TTFT，我们在图2(c)中同样看到cvm相对于原生的开销。此开销在11.2%到38.3%之间，随输入词元大小增大而减小。

因此，我们在NVIDIA H200上重现了与（chrapek_confidential_2025）中NVIDIA H100类似的结果；随着批量大小和输入词元大小的增大，机密计算cGPU性能惩罚减小。特别是，cGPU机密计算模式惩罚CVM与cGPU之间的IO，因为此模式通过CVM和cGPU之间的弹跳缓冲区加密cGPU IO。因此，每次IO需要在可信和不可信内存之间进行额外拷贝。随着批量大小和输入词元大小的增大，cGPU内计算时间增加，从而减小了机密计算IO开销的影响。为此，存在如Intel TDX-Connect（intel_tdx_connect）和AMD SEV-IO（amd_sev_tio）等解决方案，但NVIDIA尚未为其cGPU支持这些技术（nvidia_trusted_solutions_notes）。

RQ2结论：我们展示了与NVIDIA H100相同的cGPU IO瓶颈存在于NVIDIA H200中；cGPU IO开销在小输入词元大小和批量大小时较高，但随着输入词元大小和批量增大而减小，因为GPU计算时间的影响增加。

5.2. 证明

我们进一步研究EnclaveX的证明开销。作为基线，我们选择包含H200 cGPU的TDX CVM的原生证明延迟，并进一步与EnclaveX的证明延迟进行比较。具体而言，我们测量从证明者发起证明到证明者从验证者接收证明结果的持续时间。此过程包括证明者收集证据、证明者将证据发送给验证者、验证者将证据与评估策略进行比较、验证者将证明结果返回给证明者。

实验设置。 我们遵循trustee（trustee）的设置来促进远程证明。CVM作为证明者，trustee作为验证者，两者共享同一主机以避免网络延迟。我们再次使用SYS-322GA-NR作为硬件测试平台，CVM使用TDX，NVIDIA H200作为cGPU。

额外的TD Quote生成和验证组件，即Intel配置认证缓存服务（PCCS）和Quote生成服务（QGS），也由主机OS执行以避免额外延迟。此外，PCCS包含从Intel配置认证服务（PCS）预缓存的辅助材料。

最后，我们需要对trustee进行最小调整以启用对我们系统的证明。由于我们的系统处于预生产阶段，Intel Quote验证库（QvL）（Intel_DCAP_2025）无法验证我们系统的quote；嵌入的Intel根公钥对于预生产quote不同。因此，我们跳过QvL函数以显式验证quote。此外，trustee不完全支持H200报告测量的验证。我们因此跳过未知的报告测量，并验证所有trustee已知的测量。

为评估应用级远程证明，我们在Guest OS内启用SCONE内核模块。该模块需要私钥来签名证明quote。在典型部署中，密钥在CVM被证明后从KBS/Trustee服务获取。然而，为进行基准测试，我们使用专用配置过程手动配置此密钥。然后我们创建一个最小应用，基本上是一个仅执行return 0的程序，以便证明步骤在任何实际应用逻辑运行之前发生。同时，我们定义相应的安全策略并将其上传到SCONE CAS（palaemon）。

RQ3. EnclaveX证明在原生CVM和cGPU证明之上增加了多少开销？ 我们使用hyperfine（Peter_hyperfine_2025）工具作为基准测试框架，测量原生和EnclaveX各100次证明的延迟。对于原生，我们使用trustee kbs-client工具在CVM内发起证明，包括生成和收集TD Quote及cGPU SPDM测量。对于应用级远程证明，最小应用与SCONE运行时动态链接，以便在基于软件的飞地内执行。SCONE运行时测量应用以生成证明quote，然后由SCONE内核模块签名。之后，签名quote被发送到SCONE CAS，根据定义的安全策略进行验证。我们重复此过程100次以基准测试并记录证明延迟。

结果。 对于原生TDX和cGPU证明，我们测量到平均延迟1.1611秒，标准差0.0313秒。我们进行了额外基准测试以评估使用SCONE内核模块和SCONE运行时的应用级远程证明。测量产生平均延迟0.0147秒，标准差0.1508秒。因此，EnclaveX总证明时间约为1.1758秒，增加了约1.27%的可忽略开销。SCONE CAS使用Edwards-curve数字签名算法（EdDSA）加密，如Ed25519，实现非常快速的证明quote验证。

RQ3结论：EnclaveX证明在CVM和cGPU证明之上增加了微不足道（约1%）的开销。

5.3. 结论

EnclaveX通过依赖硬件强制的TEE和细粒度证明最小化了可信计算基（TCB），在支持未修改ML应用的同时减少了攻击面。具体而言，EnclaveX启用了CVM封闭的基于进程的TEE，保护免受具有CVM访问权限的K8s管理员侵害。该系统还支持医疗、金融和研究等领域敏感工作负载的安全多租户云部署。未来增强可包括支持额外TEE技术或联邦学习场景，以进一步扩展分布式环境中的机密性。