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