面向TEE的開發者指南

作者：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公司和大型科技公司產品的途徑。