作者：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中部署的應用程式的工作流程如下：
-
「開發人員」編寫了一些程式碼，這些程式碼可能已經開源，也可能沒有
-
然後，開發者將程式碼打包到Enclave映像檔（EIF）中，該檔案可以在TEE中執行
-
EIF被託管在某台有TEE系統的伺服器上。在某些情況下，開發者可以直接使用具有TEE的個人電腦託管EIF來對外提供服務
-
使用者可以透過預先定義的介面與應用程式進行互動。
顯然，這裡面有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公司和大型科技公司產品的途徑。