硬件化方案堅不可摧？揭祕可信硬件TEE的是非功過

可信硬件何以可信？相比純軟件隱私保護解決方案，結合可信硬件的解決方案有何優勢？可信硬件是否真的堅不可摧？可信硬件的使用又會引入哪些技術風險和商業顧慮？

可信硬件執行環境（TEE，Trusted Execution Environment）通過硬件隔離手段對涉及隱私數據的運算和操作進行保護。在不破解硬件的前提下，攻擊者無法直接讀取其中的隱私數據和系統密鑰，由此保障了數據的機密性。同時，攻擊者無法通過固化的硬件邏輯和硬件層面篡改檢測，以此確保相關係統運行過程不被惡意篡改。

基於以上特性，相比純軟件隱私保護解決方案，結合TEE的解決方案通常表現出更好的性能和擴展性，因此受到廣大平臺服務商的青睞。從諸多方案展示的效果來看，結合TEE的解決方案似乎已經可以滿足隱私保護在數據內容保護方面的任意業務需求。

值得注意的是，比較成熟的TEE已經面世近5年，然而在多方協作的實際應用中，TEE並未“一統江湖”，其背後是否還蘊含着不廣爲人知的重大風險？且隨本文一探究竟。

01. TEE安全模型

爲了深入瞭解TEE的能力邊界，第一個需要回答的問題就是，TEE如何實現安全可信，即TEE的安全模型是什麼？

儘管不同的硬件供應商提供的TEE硬件功能不盡相同，但其安全特性主要依賴以下幾類硬件功能：

物理隔離的密鑰存儲空間。
物理隔離的代碼運行環境，也常稱之爲飛地（Enclave）。飛地具有獨立的內部數據通路和計算所需存儲空間，確保代碼在飛地中運行產生的內部數據不會被飛地之外的程序輕易讀取。
硬件設備綁定的設備密鑰，配合外部軟件驗證服務驗證TEE硬件設備的真實性，以此鑑別由軟件惡意模擬出來的虛假設備。
物理篡改檢測自毀機制，當TEE存儲數據的模塊的傳感器檢測到外部硬件攻擊時，會對其中的數據進行清零保護。

基於以上功能，在實際業務應用中，開發者通常將可信硬件看作一個安全的黑盒，假定其滿足如下特性：

可信硬件中存儲的數據，其明文形式僅存在於硬件內部，無法被外界讀取或截獲。
可信硬件中進行的運算過程，可以通過相關的遠程代碼認證協議進行驗證，確保如果運算過程的功能邏輯和約定的不符，一定會被檢測出，惡意篡改之後的運算過程無法通過檢測。

在功能層面上，TEE對支持的運算過程沒有任何限制，可以方便地適配豐富的應用場景，是一類通用性十分優異的技術。

在理論層面上，基於TEE的隱私保護方案的核心優勢，是把方案的安全性歸約到TEE硬件設備自身的安全性上。只要TEE承諾的硬件功能和配套的軟件功能不出任何安全問題，那隱私保護方案也將是安全的。

看似完美的假設，其背後涉及到三個關鍵問題：

TEE承諾的硬件功能一定是完美無缺的嗎？
TEE配套的軟件功能，如TEE硬件設備的真實性驗證服務，是否也是完美無缺的？
TEE承諾的硬件功能和配套的軟件功能一旦出現問題，如何從用戶的角度進行有效驗證？

對於這三個問題的解答將引出一系列關於TEE的技術風險，爲了更深刻地理解其對實際業務的影響，我們先在下一節中，瞭解一下TEE常見的應用模式。

02. TEE應用模式

TEE的應用模式十分多樣化，但在常用方案構造過程中，一般都離不開經典的飛地計算模式，即把所有隱私數據相關的計算放入物理隔離的飛地中執行，完整的流程大致可以抽象爲以下三個階段：

TEE硬件設備註冊

TEE硬件設備向遠程硬件認證服務請求設備註冊，這一服務通常由硬件廠商或者平臺服務商自己提供。
遠程硬件認證服務根據TEE硬件設備的內置綁定密鑰，結合其他系統參數，判斷該設備是否爲真實物理設備，而不是軟件模擬出來的虛擬設備。
遠程硬件認證服務根據黑名單機制，判斷該TEE硬件設備不是已知的被破解或遺失的設備。
如果以上驗證都通過，則註冊完成，遠程硬件認證服務與TEE硬件設備進行密鑰協商，各自生成未來進行遠程設備認證所需的密鑰，並在自身存儲介質中保存對應的數據。

可信執行程序部署

應用提供方將可信執行程序作爲輸入，調用創建飛地的系統接口，進行可信執行程序的部署。
可信執行程序在部署過程中，一般情況下，至少會生成一對公私鑰用於未來調用過程中的通信數據加解密，其中私鑰的明文僅存在於飛地中，公鑰作爲返回值，返回給應用提供方。
部署完成之後，應用提供方通過TEE硬件設備提供的飛地測量接口，對已部署的可信執行程序做一個整體測量，生成的測量報告包含一系列部署後的軟硬件屬性和內存中代碼的哈希值。
應用提供方將上一步產生的測量報告，發送給遠程硬件認證服務，並請求對已經部署的可信執行程序進行認證，認證可信執行程序二進制數據確實是在未被破解的TEE物理硬件設備上部署成功，認證通過之後，會對測量報告進行簽名。

可信執行程序調用

用戶從應用提供方獲得附帶遠程硬件認證服務簽名的可信執行程序測量報告，驗證其簽名的有效性。
認證通過之後，用戶使用可信執行程序在部署階段生成的公鑰，對調用的所需的參數進行加密，並可以選擇性地附加一個返回值加密密鑰，用以調用結果的密文返回。
用戶將加密後的調用參數，發送給TEE硬件設備，在飛地的隔離運行環境中，可信執行程序用部署階段生成的私鑰，將密文參數解密成明文，並完成約定的計算，返回結果。
除了直接返回結果明文，可信執行程序也可以使用調用參數中附加的返回值加密密鑰對結果進行加密，然後以密文的形式返回結果，確保結果只有用戶才能解密。
用戶可以酌情在實際調用的前後，請求TEE硬件設備對飛地已部署中的可信執行程序進行新一輪測量，並聯系遠程硬件認證服務獲得最新的認證結果。

從用戶的視角來看，以上使用TEE的過程可以進一步簡化成以下三個步驟：

獲得可信執行程序的公鑰，對調用參數加密。
將加密後的密文參數，發送給可信執行程序。
等待可信執行程序在TEE創建的飛地中對參數解密、執行程序邏輯、返回結果。

如果平臺服務商能夠提供前兩個階段的標準化服務，應用開發者只需關注自身業務的開發即可。因此，TEE的應用開發和業務適配過程，相當直白高效。

但是，作爲構建隱私保護解決方案中的一類核心技術，如果TEE只能滿足功能性需求是遠遠不夠的，關鍵還要看是否能夠同時滿足安全性和其他非功能性業務需求。TEE在這些方面表現如何？我們在下一節風險披露中，對此一一展開。

03. TEE風險披露

TEE將保障數據運算過程中的機密性和抗篡改性問題歸約到保障TEE硬件設備自身的安全性問題上。這一設計是把雙刃劍，在提供優異方案通用性的同時，不可避免地對安全性和可用性造成巨大影響。

安全性風險

用戶使用TEE的過程，看似直白高效，但其安全性和隱私保障，與前兩個階段——TEE硬件設備註冊和可信執行程序部署的有效性密不可分。

設想一下，如果一個攻擊者基於被破解的TEE硬件設備提供了一個服務接口，而用戶完全不知情，使用了被攻擊者控制的公鑰來加密隱私數據，那麼對於用戶而言，是沒有任何隱私可言的。

這就帶來了一個很有挑戰的問題，用戶如何才能知情？

解答這一問題的關鍵，在於理解認證過程爲什麼有效：

註冊階段認證了TEE硬件設備是真實物理硬件（在遠程硬件認證服務的白名單中），且未被破解（不在遠程硬件認證服務的黑名單中）。
部署階段認證了可信執行程序確實在通過遠程硬件認證服務認證的TEE硬件設備中完成了部署，且代碼和部署的參數與約定的一致。

除開TEE硬件設備的設計和生產缺陷，這兩個階段的有效性很大程度上依賴遠程硬件認證服務是否誠實、是否被破解、是否有最新的黑名單信息。由於這一服務通常由硬件廠商或者平臺服務商提供，因此形成一箇中心化的信任問題。

這就是第一方面的風險，用戶必須相信硬件廠商和平臺服務商的信譽。

即便硬件廠商和平臺服務商未能履行約定，甚至可信執行程序根本沒有在TEE硬件設備中執行，用戶都是無法感知。

到底由哪一方來提供這一中心化的信任服務？對於需要多方平等協作的場景，就引入了一個非常現實的信任問題。

多個同時提供TEE可信硬件解決方案的平臺服務商，如果他們之間需要基於TEE進行多方數據合作，可能出現的情況是：

遠程硬件認證服務不會由這些參與數據交換的平臺服務商中的任意一個來提供，而是需要另尋一個沒有商業利益衝突的可信第三方，如果找不到，業務就可能無法開展。

第二方面，TEE硬件設備的設計和生產過程中也難免有安全缺陷。

由於這一技術相對較新，所以前期攻擊者對其關注度也不高。但隨着隱私保護的業務需求日漸人心，諸多業務方案問世，自2017開始，相關安全缺陷陸續報出。在國際漏洞數據庫CVE（Common Vulnerabilities and Exposures）中，絕大部分TEE相關的硬件漏洞都與本地物理訪問相關，可能造成密鑰泄露、數據泄露、權限提升等問題。

最近值得關注的有CacheOut和SGAxe攻擊（漏洞識別號CVE-2020-0549）。

這些已知的硬件漏洞對基於TEE平臺服務商的自我約束提出了更高的要求。

第三方面，TEE一旦曝光新的安全風險，可能難以及時修復。

其原因主要可能有以下三個因素：

無法升級的硬件模塊：雖然可以通過升級固件的形式對絕大部分密碼學算法進行升級，但對於其中的一些性能攸關的關鍵模塊卻可能無法通過軟件升級，只能替換硬件。比較典型的例子有內存加密（MEE，Memory Encryption Engine）硬件模塊，目前主流的硬件實現是128位安全長度的密碼學算法，相比目前軟件算法實現中普遍的256位安全長度，其抗暴力破解的安全性弱了不少。如果此類模塊出現安全風險，短時間內沒有新的硬件產品替換或者好的軟件過渡修復方案，那原有的方案就只能暴露在對應的安全風險之下。面對可能面世的量子計算機，現有TEE硬件設備中固化的非抗量子硬件算法模塊，可能會面臨比較顯著的安全風險。
硬件進出口限制：目前主要的TEE廠商都是海外芯片製造商，如果國際貿易關係發生惡化，即便最新的TEE硬件設備已經修復了安全性問題，也可能因爲進出口限制，而無法得到及時的修復。
硬件替換操作成本高昂：如果需要大規模替換物理硬件設備，其綜合成本將遠高於大規模替換軟件實現。

除了以上硬件漏洞之外，TEE還有不少安全漏洞源自官方配套的SDK軟件。所以，即便硬件沒有缺陷，如果與其配套的軟件組件出現安全漏洞，或者配置數據未能及時的更新（如已知被破解TEE硬件設備黑名單），也會嚴重地影響TEE的安全性。

所以不能簡單地認爲，只要程序在TEE硬件設備中執行，數據一定是安全的。

可用性風險

除了安全性風險之外，基於TEE隱私保護方案還有可能遇到可用性風險。

其主要原因是，TEE方案的黑盒設計通常會限定隱私數據相關的密鑰只能在一個TEE硬件設備中使用，而且這些密鑰不能離開這一設備。這在一定程度上保障了密鑰的安全，但同時帶了可用性難題。

這種情況下，如果這一個TEE硬件設備發生損壞或斷電，那對應的數據是不是都不可用了？

答案肯定是不可用，這對於需要高可用性的數據平臺類業務往往是難以接受的。

對於這一可用性問題，可以通過使用門限密碼學方案（參見上一論）進行一定程度上的緩解，但不能從根本上解決問題。所以在實際方案設計中，往往需要引入一個外部密鑰管理服務，用於密鑰的備份和再分發，這樣就與TEE倡導的密鑰從不離開硬件設備的理念產生了矛盾。

由此可見，爲了保持系統高可用性，TEE的安全性可能會被進一步降低。

雖然在一定程度上，TEE依舊能保證程序執行過程中不被篡改，但對於數據機密性的保護就弱了很多。理論上來看，使用外部密鑰管理服務的TEE方案，與純軟件隱私保護方案持平，沒有任何相對優勢。

結合之前提到的，TEE的有效性必須依賴中心化的遠程硬件認證服務，如果該認證服務未能履行職責，那基於TEE隱私保護方案對於程序執行過程中抗篡改性也無法保證。

在這些不利條件下，即便使用了TEE硬件設備，其隱私保護效果與純軟件方案也沒有太大差別，而且作爲終端用戶的客戶也難以驗證TEE是否真正發揮了應有的作用。

如果我們考慮可能出現的最差情況，信賴由外部平臺服務商提供基於TEE的隱私保護方案，實際的信賴基礎往往是該平臺服務商的信譽，而不是TEE硬件設備和相關技術本身。

正是：安全硬件黑盒難自證，隱私風險固化易潰堤！

TEE相對還是比較年輕的技術，相比已經發展了幾十年的現代密碼學，其成熟度有待提升。本文對基於TEE的隱私保護方案中的技術細節進行展開，並對其相關風險進行了較爲全面的披露，並非想說明該技術缺乏價值。恰恰相反，隱私保護作爲一項全方位的系統工程，構建安全可用的隱私保護技術方案需要結合多種不同的技術，TEE作爲其中一類重要的安全加固工具，可以用來強化數據保護的效果。

這裏需要特別注意的是，TEE在固化安全特性的同時，也固化了各類隱私風險。作爲設計上的取捨，TEE通過引入中心化的可信硬件執行環境認證體系，優化了該類技術方案對各類業務需求的適配性，但與此同時，相比純軟件密碼學方案，也引入了更強的安全假設，弱化了安全性和可用性。

如果隱私保護方案的安全性只是依賴TEE的硬件特性，用戶不僅僅要相信硬件廠商，還需要相信其他由平臺服務商提供的一系列中心化軟硬件配套服務，因此難免會面臨顯著的安全性和可用性風險。而且，一旦風險發生，極有可能難以在短時間內修復，用戶也很難有所感知。

這些風險對於業務數字化潮流中倡導的公平、對等商業合作模式來說，將帶來不小的挑戰。如果TEE方案提供的“數據可用不可見”效果僅限於用戶之間，平臺服務商依舊有能力看到這些隱私數據，那將大大打擊作爲數據貢獻者的用戶積極參與合作的動機，對應的商業模式創新和產業應用落地也將面臨阻力。

作爲隱私保護方案設計開發者，充分了解以上技術風險和商業顧慮，是用好TEE的重要前提。

至此，密鑰學原語和相關基礎技術介紹已經過半，自下一論起，我們將對數字化業務系統中無處不在的數字簽名進行分期解析，欲知詳情，敬請關注下文分解。