可信硬體何以可信？相比純軟體隱私保護解決方案，結合可信硬體的解決方案有何優勢？可信硬體是否真的堅不可摧？可信硬體的使用又會引入哪些技術風險和商業顧慮？
可信硬體執行環境（TEE，Trusted Execution Environment）透過硬體隔離手段對涉及隱私資料的運算和操作進行保護。在不破解硬體的前提下，攻擊者無法直接讀取其中的隱私資料和系統金鑰，由此保障了資料的機密性。同時，攻擊者無法透過固化的硬體邏輯和硬體層面篡改檢測，以此確保相關係統執行過程不被惡意篡改。
基於以上特性，相比純軟體隱私保護解決方案，結合TEE的解決方案通常表現出更好的效能和擴充套件性，因此受到廣大平臺服務商的青睞。從諸多方案展示的效果來看，結合TEE的解決方案似乎已經可以滿足隱私保護在資料內容保護方面的任意業務需求。
值得注意的是，比較成熟的TEE已經面世近5年，然而在多方協作的實際應用中，TEE並未“一統江湖”，其背後是否還蘊含著不廣為人知的重大風險？且隨本文一探究竟。
TEE安全模型
為了深入瞭解TEE的能力邊界，第一個需要回答的問題就是，TEE如何實現安全可信，即TEE的安全模型是什麼？
儘管不同的硬體供應商提供的TEE硬體功能不盡相同，但其安全特性主要依賴以下幾類硬體功能：
物理隔離的金鑰儲存空間。
物理隔離的程式碼執行環境，也常稱之為飛地（Enclave）。飛地具有獨立的內部資料通路和計算所需儲存空間，確保程式碼在飛地中執行產生的內部資料不會被飛地之外的程式輕易讀取。
硬體裝置繫結的裝置金鑰，配合外部軟體驗證服務驗證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建立的飛地中對引數解密、執行程式邏輯、返回結果。
如果平臺服務商能夠提供前兩個階段的標準化服務，應用開發者只需關注自身業務的開發即可。因此，TEE的應用開發和業務適配過程，相當直白高效。
但是，作為構建隱私保護解決方案中的一類核心技術，如果TEE只能滿足功能性需求是遠遠不夠的，關鍵還要看是否能夠同時滿足安全性和其他非功能性業務需求。TEE在這些方面表現如何？我們在下一節風險披露中，對此一一展開。
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的重要前提。
至此，金鑰學原語和相關基礎技術介紹已經過半，自下一論起，我們將對數字化業務系統中無處不在的數字簽名進行分期解析，欲知詳情，敬請關注下文分解。
---END---
《隱私保護週三見》
“科技聚焦人性，隱私迴歸屬主”，這是微眾銀行區塊鏈團隊聯合01區塊鏈推出《隱私保護週三見》深度欄目的願景與初衷。每週三晚8點，專家團隊將透過欄目，圍繞即時可用場景式隱私保護高效解決方案WeDPR的核心技術點，和各位一起探尋隱私保護的發展之道。
欄目內容含括以下五大模組：關鍵概念、法律法規、理論基礎、技術剖析和案例分享，如您有好的建議或者想學習的內容，歡迎隨時提出。
往期集錦
第1論｜隱私和效用不可兼得？隱私保護開闢商業新境地
第2論｜隱私合規風險知幾何？資料合規商用需過九重關
第3論｜密碼學技術何以為信？深究背後的計算困難性理論
第4論｜密碼學技術如何選型？初探理論能力邊界的安全模型
第5論｜密碼學技術如何選型？再探工程能力邊界的安全模型
第6論｜密碼學技術如何選型？終探量子計算通訊的安全模型
第7論｜密碼金鑰傻傻分不清？認識密碼學中的最高機密
第8論｜金鑰繁多難記難管理？認識高效金鑰管理體系
第9論｜密碼學原語如何應用？解析單向雜湊的妙用
第10論｜密碼學原語如何應用？解析密碼學特有的資料編解碼
第11論｜密碼學原語如何應用？解析密碼學承諾的妙用
第12論｜密碼學原語如何應用？解析密文同態性的妙用
第13論｜密碼學原語如何應用？走近門限密碼演算法
上下滑動檢視更多
