TEE简明手册：从基础概念到安全使用的最佳实践指南

原文标题：Securing TEE Apps: A Developer's Guide

原文作者：prateek, roshan, siddhartha & linguine (Marlin), krane (Asula)

编译：Shew，仙壤GodRealmX

自从Apple宣布推出私有云以及NVIDIA在GPU中提供机密计算以来，可信执行环境（TEE）变得越来越流行。它们的机密性保证有助于保护用户数据（可能包括私钥），而隔离性确保部署在其上的程序的执行不会被篡改——无论是人类、其他程序还是操作系统。因此，Crypto x AI领域大量使用TEE构建产品也不足为奇。

与任何新技术一样，TEE正在经历一段乐观的实验期。本文希望为开发人员和一般读者提供基础的概念指南，让他们了解什么是TEE、TEE的安全模型、常见的漏洞和安全使用TEE的最佳实践方式。（注意：为了使文本易于理解，我们有意识地用更简单的等价词替换了TEE术语）。

什么是TEE

TEE是处理器或数据中心中的隔离环境，程序可以在其中运行，而不会受到系统其余部分的任何干涉。为了避免TEE被其他部分干涉，我们需要一系列的设计，主要包括严格的访问控制，即控制系统其他部分对TEE内程序和数据的访问。目前TEE在手机、服务器、PC和云环境中无处不在，因此非常易于访问且价格合理。

上面的内容听起来可能很模糊和抽象，实际上不同的服务器和云供应商实施TEE的方式不同，但其根本目的是为了避免TEE被其他程序干涉。

大多数读者可能会用生物识别信息登录设备，比如通过指纹解锁手机。但我们如何保证恶意应用程序、网站或越狱操作系统无法访问和窃取这些生物识别信息？事实上，除了把数据加密之外，TEE设备中的电路根本不允许任何程序访问敏感数据占用的内存和处理器区域。

硬件钱包是TEE应用场景的另一个示例。硬件钱包连接到计算机并与其进行沙盒通信，但计算机无法直接访问硬件钱包内存储的助记词。在上述两种情况下，用户都相信设备制造商能够正确设计芯片并提供适当的固件更新，以防止TEE内的机密数据被导出或查看。

安全模型

遗憾的是，TEE实现种类非常多，这些不同的实现（IntelSGX、IntelTDX、AMDSEV、AWSNitroEnclaves、ARMTrustZone）都需要独立的安全模型建模分析。在本文的其余部分，我们将主要讨论IntelSGX、TDX和AWSNitro，因为这些TEE系统具有较多的用户，也具有完整可用开发工具。上述系统也是Web3内最常用的TEE系统。

一般而言，在TEE中部署的应用程序的工作流如下：

1. “开发人员”编写了一些代码，这些代码可能已经开源，也可能没有
2. 然后，开发者将代码打包到Enclave映像文件（EIF）中，该文件可以在TEE中运行
3. EIF被托管在某台带有TEE系统的服务器上。某些情况下，开发者可以直接使用带有TEE的个人计算机托管EIF来对外提供服务
4. 用户可以通过预定义的界面与应用程序进行交互。

显然，这里面有3个潜在的风险：

• 开发人员：用于准备EIF的代码到底有什么作用？EIF代码可能并不符合项目方对外宣传的业务逻辑，可能会窃取用户的隐私数据
• 服务器：TEE服务器是否运行与预期一致的EIF文件？或者EIF是否真的在TEE内被执行？服务器也可能在TEE内运行其他程序
• 供应商：TEE的设计是否安全？是否有后门将TEE内所有数据泄露给供应商？

值得庆幸的是，现在的TEE已经有了消除上述风险的方案，即可重复构建(Reproducible Builds)和远程证明(Remote Atteststations)。

那么什么是可重复构建？现代软件开发往往需要导入大量依赖，比如外部工具、库或框架等，这些依赖文件也可能存在隐患。现在npm等方案使用了依赖文件对应的代码哈希作为唯一标识符。当npm发现某个依赖文件与记录的哈希值不一致时，就可以认为该依赖文件已被修改。

而可重复构建可以被认为是一组标准，目标是当任意代码在任何设备上跑时，只要按照事先规定的流程进行构建，最终都可以得到一致的哈希值。当然，在实操中我们也可以使用哈希之外的产物作为标识符，此处我们称之为代码度量(code measurement)。

Nix是可重复构建的常用工具。当程序的源码公开后，任何人都可以检查代码，以确保开发人员没有插入异常内容，任何人都可以使用Nix构建代码，检查构建出的产物是否与项目方在生产环境中部署的产物有相同的代码度量/Hash。但我们如何知道TEE中程序的代码度量值呢？这里就涉及到称为“远程证明”的概念。

远程证明是来自TEE平台（受信任方）的签名消息，其中包含程序的代码度量值、TEE平台版本等。远程证明让外部观察者知道，某个程序正在任何人都无法访问的安全位置（xx版本的真实TEE）中执行。

可重复构建和远程证明使得任何用户都可以知道TEE内运行的实际代码和TEE平台版本信息，从而防止开发者或者服务器作恶。

但是， 在TEE的情况下，始终需要信任其供应商。如果TEE供应商作恶，可以直接伪造远程证明。因此，如果将供应商视为可能的攻击媒介，应避免仅依赖TEE，最好将它们与ZK或共识协议相结合。

TEE的魅力

在我们看来，TEE特别受欢迎的特性，尤其是对于AI Agent的部署友好性主要在于以下几点：

• 性能：TEE可以运行LLM模型，其性能和成本开销与普通服务器相似。而zkML则需要消耗大量算力生成LLM的zk证明
• GPU支持：NVIDIA在其最新的GPU系列（Hopper、Blackwell等）中提供TEE计算支持
• 正确性：LLMs是非确定性的;多次输入同一提示词会得到不同的结果。因此，多个节点（包括试图创建欺诈证明的观察者）可能永远不会对LLM的运行结果达成共识。在这种场景下，我们可以信任TEE中运行的LLM无法被作恶者操纵，TEE内的程序始终按编写的方式运行，这使得TEE比opML或共识更适合保障LLM推理结果的可靠性
• 保密性：TEE中的数据对外部程序不可见。因此，在TEE中生成或接收的私钥始终安全。此特性可用于向用户保证，由该密钥签名的任何消息都来自TEE的内部程序。用户可以放心将私钥托管给TEE并设置一些签名条件，并且可以确认来自TEE的签名合预先设定的签名条件
• 联网：通过一些工具，在TEE中运行的程序可以安全地访问互联网（无需向TEE运行的服务器透露查询或响应，同时仍可为第三方提供正确的数据检索保证）。这对于从第三方API检索信息非常有用，可用于将计算外包给受信任但专有的模型提供商
• 写入权限：与zk方案相反，在TEE中运行的代码可以构建消息（无论是推文还是交易）并通过API和RPC网络访将它们发送出去
• 开发者友好：TEE相关的框架和SDK允许人们以任何语言编写代码，像在云服务器中一样将程序轻松地部署到TEE中

无论好坏，相当多使用TEE的用例目前很难找到替代方案。我们相信TEE的引入进一步扩展了链上应用程序的开发空间，这可能推动新应用场景的产生。

TEE不是银弹

在TEE中运行的程序仍然容易受到一系列攻击和错误的影响。 就像智能合约一样，它们容易遇到一系列问题。为简单起见，我们将可能的漏洞分类如下：

• 开发者疏忽
• 运行时漏洞
• 架构设计缺陷
• 运营问题

开发人员疏忽

无论是有意还是无意，开发人员都可以通过有意或无意的代码来削弱TEE中程序的安全保证。这包括：

• 不透明代码：TEE的安全模型依赖于外部可验证的。代码的透明度对于外部第三方的验证至关重要。
• 代码度量存在问题：即使代码是公开的，如果没有第三方重新构建代码并检查远程证明中的代码度量值，然后根据远程证明中提供的代码度量进行检查，。这类似于收到zk证明但不验证它。
• 不安全代码：即使您小心翼翼地在TEE中正确生成和管理密钥，代码中包含的逻辑也可能在外界调用过程中泄漏TEE内的密钥。此外，代码内可能包含后门或漏洞。与传统后端开发相比，它要求软件开发和审计过程具有高标准，类似于智能合约开发。
• 供应链攻击：现代软件开发使用大量第三方代码。供应链攻击对TEE的完整性构成重大威胁。

运行时漏洞

开发人员再谨慎也可能成为运行时漏洞的牺牲品。开发人员必须仔细考虑以下任何一项是否会影响其项目的安全保证：

• 动态代码：可能并不总能保持所有代码透明。有时，用例本身需要在运行时动态执行加载到TEE中的不透明代码。此类代码很容易泄露机密或破坏不变量，必须非常小心地防止这种情况。
• 动态数据：大多数应用程序在执行过程中使用外部API和其他数据源。安全模型扩展到包括这些数据源，这些数据源与DeFi中的预言机处于同一地位，不正确甚至过时的数据可能会导致灾难。例如，在AI Agent的用例下，过度依赖LLM服务，如Claude。
• 不安全和不稳定的通信：TEE需要在包含TEE组件的服务器内运行。从安全角度来看，运行TEE的服务器实际上是TEE和外部交互之间的完美中间人（MitM）。服务器不仅能够窥视TEE的对外连接并查看正在发送的内容，还可以审查特定IP、限制连接并在连接中注入数据包，旨在欺骗一方让其认为它来自xx。

例如，在TEE中运行可以处理加密交易的匹配引擎，该引擎无法提供公平的排序保证（抗MEV），因为路由器/网关/主机仍然可以根据数据包来源的IP地址丢弃、延迟或优先处理之。

架构缺陷

TEE应用程序所使用的技术栈应该谨慎。在构建TEE应用程序时，可能出现以下问题:

• 具有较大攻击面的应用：应用程序的攻击面是指需要保证完全安全的代码模块数量。具有较大攻击面的代码非常难审计，可能会隐藏bug或可利用的漏洞。这通常也与开发人员的体验相冲突。例如，与不依赖Docker的TEE程序相比，依赖Docker的TEE程序攻击面要大得多。与使用最轻量操作系统的TEE程序相比，依赖于成熟操作系统的Enclaves具有更大的攻击面
• 可移植性和活跃性：在Web3中，应用程序必须具有抗审查性。任何人都可以启动TEE并接管不活跃的系统参与者，并使TEE内的应用程序可移植。这里最大的挑战是密钥的可移植性。一些TEE系统内存在密钥派生机制，但一旦使用TEE内的密钥派生机制，那么其他服务器就无法在本地生成外部TEE程序内的密钥，这使得TEE程序通常仅限于同一台机器，这不足以保持可移植性
• 不安全的信任根：例如，在TEE中运行AI Agent时，如何验证给定地址是否属于该Agent？如果此处不仔细设计，会导致真正的信任根可能是外部第三方或密钥托管平台，而不是TEE本身。

运营问题

最后但并非最不重要的一点是，关于如何真正运行一台执行TEE程序的服务器，也有一些实际注意事项：

• 不安全的平台版本：TEE平台偶尔会收到安全更新，这些更新会反映为远程证明中的平台版本。如果您的TEE未在安全平台版本上运行，则黑客可以利用已知攻击媒介从TEE中盗取密钥。更糟糕的是，您的TEE今天可能在安全的平台版本上运行，明天可能就会不安全。
• 没有物理安全性：尽管您尽了最大努力，但TEE可能受到侧信道攻击，者通常需要对TEE所在的服务器进行物理访问和控制。因此，物理安全是一个重要的深度防御层。一个相关的概念是云证明，您可以在其中证明TEE正在云数据中心运行，而该云平台具有物理安全保证。

构建安全的TEE程序

我们将我们的建议分为以下几点：

• 最安全的方案
• 采取的必要预防措施
• 依赖于用例的建议

1. 最安全的方案：无外部依赖项

创建高度安全的应用程序可能涉及消除外部依赖项，如外部输入、API或服务，从而减少攻击面。此方法可确保应用程序以独立方式运行，没有可能损害其完整性或安全性的外部交互。虽然此策略可能会限制程序的功能多样性，但它可以提供极高的安全性。

如果模型在本地运行，则对于大部分CryptoxAI用例，可以实现此级别的安全性。

2. 采取的必要预防措施

无论应用程序是否具有外部依赖项，以下内容都是必须的！

将TEE应用程序视为智能合约，而不是后端应用程序;保持较低的更新频率，严格测试。

构建TEE程序应与编写、测试和更新智能合约时一样严格。与智能合约一样，TEE在高度敏感且不可篡改的环境中运行，其中错误或意外行为可能导致严重后果，包括资金完全损失。彻底的审计、广泛的测试以及最少的、经过仔细审计的更新对于确保基于TEE的应用程序的完整性和可靠性至关重要。

审计代码并检查构建管道

应用程序的安全性不仅取决于代码本身，还取决于构建过程中使用的工具。安全的构建管道对于防止漏洞至关重要。TEE仅保证提供的代码将按预期的流程运行，但无法修复构建过程中引入的缺陷。

为了降低风险，必须对代码进行严格的测试和审计，以消除错误并防止不必要的信息泄露。此外，可重复构建起着至关重要的作用，尤其是当代码由一方开发并由另一方使用时。可重复构建允许任何人验证TEE内执行的程序是否与原始源代码匹配，从而确保透明度和信任度。如果没有可重复构建，确定TEE内执行程序的确切内容是几乎是不可能的，从而危及应用程序的安全。

例如，DeepWorm（在TEE中运行蠕虫大脑模拟模型的项目）的源代码是完全开放的。TEE内的执行程序是使用Nix管道以可重现方式构建的。

使用经过审计或验证的库

在TEE程序中处理敏感数据时，请仅使用经过审计的库进行密钥管理和私有数据处理。未经审计的库可能会暴露密钥并损害应用程序的安全性。优先考虑经过充分审查、以安全为中心的依赖项，以维护数据的机密性和完整性。

始终验证来自TEE的证明

与TEE交互的用户必须验证TEE产生的远程证明或验证机制，以确保安全可信的交互。如果没有这些检查，服务器可能会操纵响应，从而无法区分真实的TEE输出和被篡改的数据。远程证明为在TEE中运行的代码库和配置提供了关键证明，我们可以基于远程证明判断TEE内执行的程序是否与预期一致。

具体的鉴证可以在链上（IntelSGX、AWSNitro）、使用ZK证明（IntelSGX、AWSNitro）在链下验证，也可以由用户自己或托管服务（如t16z或MarlinHub）进行验证。

3. 依赖于用例的建议

根据应用程序的目标用例及其结构，以下提示可能有助于使您的应用程序更安全。

确保始终在安全通道执行用户与TEE的交互

TEE所在的服务器本质上不受信任。服务器可以拦截和修改通信。在某些情况下，服务器读取数据但不更改数据可能是可以接受的，而在其他情况下，即使读取数据也可能是不可取的。为了降低这些风险，在用户和TEE之间建立安全的端到端加密通道至关重要。至少，请确保消息包含签名以验证其真实性和来源。此外，用户需要始终检查TEE给出远程证明来验证自己是否正在与正确的TEE通信。这确保了通信的完整性和机密性。

例如，Oyster能够通过使用CAA记录和RFC8657来支持安全的TLS颁发。此外，它还提供了一个名为Scallop的TEE原生TLS协议，该协议不依赖于WebPKI。

知道TEE内存是瞬态的

TEE内存是瞬态的，这意味着当TEE关闭时，其内容（包括加密密钥）会丢失。如果没有一个安全的机制来保存这些信息，关键数据可能会永久无法访问，从而可能使资金或运营陷入困境。

具有IPFS等去中心化存储系统的多方计算（MPC）网络可以用作此问题的解决方案。MPC网络将密钥拆分到多个节点，确保没有单个节点持有完整密钥，同时允许网络在需要时重建密钥。使用此密钥加密的数据可以安全地存储在IPFS上。

如果需要，MPC网络可以向运行相同映像的新TEE服务器提供密钥，前提是满足特定条件。这种方法可确保弹性和强大的安全性，即使在不受信任的环境中也能保持数据的可访问性和机密性。

还有另一种解决方案，即TEE将相关交易分别交给不同的MPC服务器，MPC服务器签名后进行聚合签名并将交易最终上链。这种方法的灵活性要低得多，不能用于保存API密钥、密码或任意数据（没有受信任的第三方存储服务）。

减少攻击面

对于安全关键型使用案例，值得以牺牲开发人员体验为代价尝试尽可能多地减少外围依赖。例如，Dstack附带了一个基于Yocto的最小内核，其中仅包含Dstack工作所需的模块。甚至可能值得使用像SGX（超过TDX）这样的旧技术，因为该技术不需要引导加载程序或操作系统成为TEE的一部分。

物理隔离

通过将TEE与可能的人类干预进行物理隔离，可以进一步增强TEE的安全性。虽然我们可以通过将TEE服务器托管在数据中心和云提供商，相信数据中心可以提供物理安全。但像Spacecoin这样的项目正在探索一个相当有趣的替代方案——太空。SpaceTEE的论文依靠安全措施，例如测量发射后的惯性矩，以验证卫星在进入轨道的过程是否偏离预期。

多重证明者

正如以太坊依赖多个客户端实现来降低影响整个网络的bug风险一样，multiprovers使用不同的TEE实现方案来提高安全性和弹性。通过跨多种TEE平台运行相同的计算步骤，多重验证可确保某一个TEE实现中的漏洞不会危及整个应用程序。虽然这种方法要求计算流程是确定性的，或者在非确定性情况下定义不同TEE实现方案间的共识，但它也提供了故障隔离、冗余和交叉验证等显著优势，使其成为需要可靠性保证的应用程序的不错选择。

展望未来

TEE显然已成为一个非常令人兴奋的领域。如前所述，AI的无处不在及其对用户敏感数据的持续访问意味着Apple和NVIDIA等大型科技公司正在其产品中使用TEE，并将TEE作为其产品的一部分提供。

另一方面，加密社区一直非常注重安全。随着开发人员尝试扩展链上应用程序和用例，我们已经看到TEE作为一种在功能和信任假设之间提供正确权衡的解决方案而变得流行。虽然TEE不像完整的ZK解决方案那样信任最小化，但我们预计TEE将成为首次慢慢融合Web3公司和大型科技公司产品的途径。