近日，Linux基金會宣佈全球多家巨頭企業成立機密計算聯盟（Confidential Computing Consortium），在對於數據安全和隱私擔憂的不斷增長下，基於可信執行環境技術的機密計算作爲一種可行的解決方案，成爲互聯網巨頭關注的焦點。螞蟻金服很早就關注此類技術，並基於機密計算打造了螞蟻金服新一代可信編程中間件SOFAEnclave，爲金融業務保駕護航。
機密計算是螞蟻安全計算的一環，也是金融級雲原生的一塊重要版圖，螞蟻金服表示：相信未來機密計算將和HTTPS一樣，成爲雲計算的標配。
1. 引言
互聯網金融本質上是對大量敏感數據的處理以及由此沉澱的關鍵業務智能。近年來涌現出來的新業態更是將數據處理的範疇從單方數據擴展到了涉及合作方的多方數據。另一方面，從GDPR到HIPAA，數據隱私監管保護的範圍愈加擴大，力度日益增強。可見，對金融數據和關鍵業務智能的安全保護，不僅是互聯網金融業務的基礎，也是其創新發展的依託，更是攸關合規的關鍵因素。
近年來迅速發展的機密計算技術是一種創新的數據隔離和加密處理技術，其重要特點是，TCB(trusted computing base可信計算基)中僅包含應用自身和基礎硬件，即使OS kernel、Hypervisor、甚至BIOS等特權軟件都已經遭到破壞甚至本來就是惡意的，敏感數據和代碼依然能安全無虞。螞蟻金服在自身的實踐過程中，基於機密計算底層技術發展出金融級的機密計算中間件，確保金融應用數據和代碼的機密性和完整性，爲關鍵業務提供易用、安全、集羣化的計算環境。
本文從機密計算的技術背景、關鍵問題、螞蟻的技術突破、以及典型應用場景等方面展開。
2. 機密計算的技術背景
隨着雲計算的快速發展，越來越多的關鍵性服務和高價值數據被遷移到了雲端。雲安全也因此成爲學術界和工業界關注的一個焦點。
近年來，雲安全領域最重要的一項技術進展名爲機密計算（Confidential Computing）。機密計算填補了當前雲安全的一項空白——使用中數據（Data-in-use）的加密。過去通行的做法是對數據在存儲中（比如硬盤）和傳輸中（比如網絡）加密，而在使用中（比如內存）解密，以便處理。而機密計算可以保護使用中數據的機密性和完整性。
目前，多家雲計算巨頭都在不約而同地推廣這項技術：微軟已於2017年7月宣佈開始接受Azure機密計算的早期試用申請；IBM於2017年12月宣佈IBM雲數據保護（Cloud Data Guard）的預覽版；谷歌也於2018年5月開源了名爲Asylo的機密計算框架。
那麼，機密計算究竟是如何實現的呢？
實際上，上述所有云計算巨頭在實現機密計算時都離不開一種稱爲“可信執行環境（TEE）”的技術。
顧名思義，TEE提供一種與不可信環境隔離的安全計算環境，正是這種隔離和可信驗證機制使得機密計算成爲可能。
TEE一般是直接基於硬件實現的，比如Intel SGX，AMD SEV，ARM TrustZone，以及RISC-V Keystone等；基於虛擬化技術也可以構造TEE，比如微軟的VSM，Intel的Trusty for iKGT & ACRN，但尚不能匹敵硬件TEE的安全性。
其中，Intel軟件防護拓展（Software Guard Extensions，簡稱SGX）是目前商用CPU中最爲先進的TEE實現，它提供了一套新的指令集使得用戶可以定義稱爲Enclave的安全內存區域。CPU保證Enclave與外界隔離，從而保護其中的代碼和數據的機密性、完整性和可驗證性。不同於之前的TEE實現，比如ARM TrustZone，SGX每個APP都可以有自己獨立的TEE，甚至可以創建多個TEE，而TrustZone是整個系統有一個TEE；這裏也省去了向設備廠商申請將TA裝入TEE的過程。由於SGX的先進性，目前雲端機密計算領域甚至已公認用Enclave這個詞來指代TEE。
典型的Enclave達到的安全目標可以用CIA概括，即機密性（Confidentiality）、完整性（Integrity）和真實性（Authenticity）。在實現上具有以下基本要求：
- Enclave內存保護
Enclave內存只有Enclave本身的代碼可以訪問。CPU通過內存隔離和加密來防止對安全內存的軟件攻擊和硬件嗅探。SGX更通過內存控制器的integrity tree防止了對Enclave內存的物理篡改。
- Enclave的可信驗證
CPU支持對Enclave中數據和代碼的測量，以及對Enclave合法性的本地或遠程驗證。有了測量和驗證，本地的Enclave之間、客戶端與遠程Enclave之間，就可以認證身份，進而建立安全的通信信道。
如何開發受Enclave保護的應用程序呢？
以SGX爲例，其中一種方法是利用Intel SGX SDK。如下圖所示，基於SGX SDK的應用程序分爲兩部分：Enclave外的不可信組件（左邊黃色部分）和Enclave內的可信組件（右邊綠色部分）。兩邊可以通過跨Enclave的函數調用通信：不可信組件可以通過ECall調用可信組件中定義的函數；反之，可信組件也可以通過OCall調用不可信組件中定義的函數。
3. 機密計算面臨的關鍵問題
Enclave給我們帶來了前文所謂CIA的安全保障，但是目前面臨較大的易用性問題。主要體現在幾個方面。
第一，需要將原有應用分割成兩部分，一部分是enclave外的untrusted 部分，一部分在enclave裏面作爲trusted 部分；
第二，需要精心設計兩部分之間的接口，規劃好什麼時候進入Enclave，什麼時候退出Enclave——這存在一定技術門檻，而且比較繁瑣容易出錯；
第三，即使我們做了完美的分割， Enclave裏面的環境相對於我們熟悉的通常的Linux運行環境來說是非常受限的。例如，enclave裏面不能進行系統調用，libc、pthread不完整，沒有openmp，多進程支持欠缺等等。
可見，把應用移植到Enclave裏面是極具挑戰的，在某些時候甚至是不可能做到的。而且，由於開發過程中必須考慮業務無關的繁雜瑣細的方面，即使最終能完成應用開發移植目標，也會導致低下的開發效率，極高的開發成本，這對於快節奏的互聯網業務來說是難以接受的。
機密計算走向工程實用面臨的另一較大問題是，如何將機密計算從單節點向集羣擴展。由於缺乏標準的做法，或者沒有一個best practice作爲參考，很多時候各個業務不得不各自從頭造輪子，搭建跟業務邏輯過度耦合的Enclave集羣基礎設施。從而導致低下的開發效率和重複的資源投入。
另一方面，互聯網業務日趨雲原生化，越來越多地採用雲原生的container->k8s->serverless技術棧，機密計算集羣如何跟雲原生技術棧相結合，目前仍然是較爲棘手的問題。
4. SOFAEnclave：螞蟻金服的機密計算創新
螞蟻金服作爲中國互聯網金融領導企業，對於數據保護有大量的需求，因此圍繞機密計算進行了豐富的業務創新和技術探索。本節針對上面提到的機密計算面臨的關鍵問題，主要介紹螞蟻金服在這方面的創新性成果，即SOFAEnclave機密計算中間件。
SOFAEnclave屬於螞蟻金服金融級分佈式架構SOFAStack的一環，從2007年開始，SOFAStack 產生於螞蟻金服內部需求，起初是爲了解決高速發展下的業務問題。到 2019 年，已經歷12年的業務錘鍊，是一套成熟的金融級最佳實踐。從2018年起，螞蟻金服宣佈將SOFAStack貢獻給開源社區，目前已貢獻出超過10個核心項目，受到社區廣泛關注。
SOFAEnclave主要關注底層基礎設施的安全防護，爲數據和代碼打造一層可信中間件。我們的總體目標是通過易用性的提升，向業務屏蔽Enclave開發挑戰和機密計算集羣複雜性，使業務保持原有開發部署習慣。用一句話總結就是，使業務只需關注業務。
SOFAEnclave的核心包括三部分，Enclave內核Occlum，雲原生機密計算集羣KubeTEE，以及安全測試和分析框架。這裏主要介紹Occlum和KubeTEE。
4.1 Occlum LibOS：安全高效的機密計算內核
針對Enclave易用性問題，我們設計了一個名爲Occlum的Enclave內核，並將其作爲一個開源項目採用社區模式開發。類比操作系統內核，Occlum LibOS向 Enclave內的可信應用提供完整的系統服務，應用不需要分割和修改即可得到Enclave保護。
Occlum兼容POSIX編程接口，並支持多線程、OpenMP、和多進程；同時，Occlum實現了多進程隔離機制，使得多個可信應用之間可以相互隔離。Occlum使得開發者方便利用Enclave的 CIA能力，達到可用不可見、可用不可攻的效果，使數據保護能真正得到落實。
目前，Occlum可輕鬆支持大型人工智能框架，例如XGBoost、TensorFlow等，也可支持大型服務器應用例如Shell, GCC，Web Server等。Occlum具有如下技術特點：
- 內存安全
內存安全問題是系統軟件中最常見的安全隱患。競態條件、緩衝區溢出、空指針、棧溢出、堆耗盡、釋放後訪問、或重複釋放，這些術語都用於描述內存安全漏洞。微軟2019年2月表示，在過去12年裏，微軟所有補丁中大約70%是針對內存安全漏洞的。因此，防範內存安全問題對系統軟件的安全性和健壯性非常重要。
Occlum是業界首個內存安全的SGX LibOS。Occlum LibOS是基於保證內存安全的Rust語言開發，只包含極少量的Unsafe Rust、C和彙編代碼（小於1000行）。這使得Occlum難以出現最底層的內存安全相關的bug和漏洞。因此，相比使用C/C++開發的傳統SGX LibOS（如Graphene-SGX和SCONE），Occlum更值得開發者信賴，作爲開發高安全應用的基礎。
- 簡單易用
Occlum LibOS使得Linux應用程序在只修改少量代碼或者完全不修改代碼的情況下運行於Enclave安全環境中。用戶只需使用Occlum工具鏈（occlum-clang）編譯應用程序，並使用名爲occlum的命令行工具在SGX enclave中運行該應用程序。該命令行工具提供了諸多子命令，其中最重要的三個是：
occlum init：初始化Occlum的上下文
occlum build：製作Occlum的可信鏡像和enclave
occlum run <program_name> <program_args>：在enclave中運行Occlum可信鏡像中的一個程序
Occlum大大降低了爲Enclave開發應用的開發成本。我們以一個最簡單的Hello World爲例說明。使用Intel SGX SDK開發的SGX Hello World工程包含10個左右的文件，300行左右的代碼；使用百度的Rust SGX SDK需要200行左右的代碼；Google的Asylo也需要100行左右的代碼。相比之下，Occlum不要求用戶給Linux版本Hello World（5行代碼）增加任何額外的代碼，並且只需三行命令即可將Linux版的Hello World程序運行於SGX enclave中，效果如下：
- 高效多進程
任何應用程序在LibOS上都是作爲進程運行的，而應用程序往往又由多個進程組成。因此，LibOS對多進程的高效支持就顯得至關重要了。然而，現有SGX LibOS對多進程的支持並不能令人滿意。閉源的SCONE只支持多線程，尚不支持多進程。開源的Graphene-SGX是目前最成熟的SGX LibOS，且能夠支持多進程，但它的每個LibOS進程必須在一個單獨的SGX enclave中運行，且每個enclave中必須運行一個獨立的LibOS實例。這種N進程-N enclave的架構雖然保證了LibOS進程之間的強隔離，但也導致了性能和功能方面的問題：
進程啓動慢：Graphene-SGX要爲每個LibOS進程創建一個單獨的enclave，而創建enclave的開銷非常高，因此Graphene-SGX的LibOS進程啓動極慢（比Linux啓動進程慢接近10,000倍）。
IPC開銷高：Graphene-SGX的每個LibOS進程都被一個enclave同外界完全隔離，因此LibOS進程間通信必須藉助於enclave外的不可信緩存，並傳輸加密數據。加密解密大大增加了進程間通信的開銷。
難保證一致性：Graphene-SGX有N個進程就有N個LibOS實例，而原則上來講，這N個LibOS實例應該向上層的應用程序提供一致的OS狀態，比如加密文件系統。但顯然在多個LibOS實例之間同步文件系統的狀態（比如每個文件塊的密鑰）是困難的。這也是爲什麼Graphene-SGX至今都未提供加密文件系統。
與Graphene-SGX不同，Occlum是一個單地址空間LibOS，即在同一個enclave中運行多個LibOS進程。該架構特別適用於多進程協作的使用場景，即多個互信的進程組成同一個應用或服務。這個“多進程共享enclave”的架構爲Occlum的多進程支持帶來了三個優勢：
進程啓動快：Occlum的進程啓動比Graphene-SGX快13-6600倍（圖4）；
IPC開銷低：Occlum的進程間通信帶寬是Graphene-SGX的3倍（圖5）；
加密文件系統：Occlum支持對應用透明的、可寫加密文件系統，保證文件系統的元數據與數據的機密性和完整性。
4.2 KubeTEE：金融級雲原生的機密計算集羣
針對Enclave集羣化方面的問題，我們思考如何能更高效和簡潔的使用TEE資源提供機密計算服務，我們的解決方法是KubeTEE——結合雲原生，提供機密計算集羣服務。
一方面避免了業務用戶重複進行基礎設施建設，另一方面用戶註冊賬號即可使用機密計算集羣服務，大大降低了機密計算門檻，提高了易用性和利用率。 KubeTEE爲了更高效的使用物理資源，基於k8s + container更優雅地部署和管理機密計算鏡像和EPC資源。基於k8s的容器調度能力，KubeTEE可以快速實現機密計算服務資源的橫向擴縮容。概括來說，我們希望以一種更加雲原生的方式來使用Enclave和機密計算集羣資源。
1）提供基於Enclave Container的業務部署能力，基礎設施運維和業務無感知升級等能力
2）提供Serverless機密計算服務，基於通用的機密計算資源池支持業務服務
3）基於通用的機密計算組件、中間件服務和研發流程結合提供平臺化的業務開發能力
上圖中描述了我們實現Serverless機密計算集羣的過程，我們一方面提供最終態的機密計算服務，同時將過程中積累的組件抽象化爲可複用模塊，應對不同業務的定製化需求，提升機密計算業務的Enclave開發效率。
5. 典型應用場景
機密計算應用場景非常廣泛，常見的應用有基於Enclave的版權保護、生物識別保護、基因數據處理、密鑰保護、密鑰管理系統、隱私保護的機器學習、加密數據分析、以及保密數據庫等。其他如區塊鏈隱私計算、區塊鏈+AI、隱私邊緣計算等都可以構建在機密計算技術基礎上，以更好的服務應用場景。這一節結合互聯網業務探討兩個略微複雜的應用場景。
基於Enclave的多方競合學習
衆所周知，人工智能能發展到今天，有兩個原因：一個是算力的提高，另一個就是數據規模的增長。但是，單一機構的業務領域和業務受衆是有限的，因此其數據積累一方面是不全面的，另一方面也是難以形成規模的。
爲了發揮數據的更大價值，一個自然的想法就是匯聚多方數據進行集中挖掘。但是，機構之間出於業務保密以及行業競爭的顧慮，又不可能把自己的數據無保留分享給別人。
這導致了一種看似不可思議的矛盾局面：多個機構既競爭又合作，既數據共享又數據保密（圖6）——我們將其稱爲多方競合學習。
怎麼解決這種矛盾呢？一種方案是，把各自加密的數據導入Enclave，在Enclave內解密、匯聚、並挖掘。具體實現細節可以參考螞蟻金服共享智能團隊的文章。
AI模型安全保護
對外部署的AI模型攜帶大量知識產權，一旦被逆向或泄露，既會對技術護城河造成破壞，也會降低對抗性樣本攻擊的難度，導致安全問題。
應對這種威脅的一種方案是，使用方把AI模型和訓練/預測數據加密存儲，只有在使用時纔將其輸入Enclave，在Enclave裏面解密，由Enclave中運行的AI框架處理，結果根據具體場景需求以明文返回或加密返回並在使用方本地解密。這要求Enclave能支持常見的AI框架，而要做到這一點極爲挑戰——一方面是因爲這些AI框架一般使用了複雜的多線程、OpenMP等性能優化的運行環境，另一方面是因爲Enclave又偏偏難以提供這些支撐環境。這就是爲什麼市面上很多Enclave支撐系統難以支持（或難以高效支持）AI框架的原因。
如前所述，Occlum LibOS在這方面取得了一定的進展，可以較爲輕鬆的高效運行常見AI框架。
6. 總結與展望
機密計算方興未艾，學術界的研究如火如荼，工業界的應用也日益豐富和實際。螞蟻金服在機密計算領域是技術的探索者和業務的先行者，我們仍有諸多問題需要整個生態的合作。
我們正在逐步將SOFAEnclave裏的模塊貢獻給開源社區，歡迎行業和學術同仁聯繫合作。希望合作伙伴向Occlum項目提出反饋並貢獻代碼，一起利用Occlum LibOS來支持更多實際應用，實現Enclave保護的安全容器Enclave Container。在KubeTEE方面，希望能與合作伙伴共建生態，維護可信應用和鏡像倉庫，推進機密計算集羣方案的實用化標準化。
注：
[1] 圖片來源https://keystone-enclave.org/files/keystone-risc-v-summit.pdf