簡介：?汪少軍：如何為Java業(yè)務(wù)提供機密計算保護？

寫在前面

在信息世界里，數(shù)據(jù)存在三種狀態(tài)：?存儲態(tài)、傳輸態(tài)和計算態(tài)。存儲在數(shù)據(jù)庫或磁盤中的數(shù)據(jù)屬于存儲狀態(tài)，在網(wǎng)絡(luò)中傳輸?shù)臄?shù)據(jù)屬于傳輸狀態(tài)，正在被計算處理的數(shù)據(jù)屬于計算狀態(tài)。我們需要從數(shù)據(jù)三種狀態(tài)出發(fā)進行系統(tǒng)的安全保護，才能確保真正的數(shù)據(jù)安全。對于存儲態(tài)和傳輸態(tài)數(shù)據(jù)安全問題，我們可以利用被廣泛使用的數(shù)據(jù)加密技術(shù)進行有效保護。對于計算態(tài)的數(shù)據(jù)安全保護仍舊屬于新的前沿領(lǐng)域。

基于硬件的機密計算技術(shù)(TEE)，通過提供一個可信執(zhí)行環(huán)境，在該環(huán)境下運行的代碼和數(shù)據(jù)會得到硬件級的保護，任何軟件包括內(nèi)核和Hypervisor都無權(quán)限窺探該環(huán)境中的數(shù)據(jù)信息，從而實現(xiàn)對計算態(tài)數(shù)據(jù)的保護。

全球主流的芯片廠商都紛紛推出了各自的機密計算解決方案，比如Intel SGX和Arm TrustZone等。TrustZone主要用在終端領(lǐng)域，而SGX技術(shù)則可以應(yīng)用于服務(wù)器領(lǐng)域。SGX技術(shù)能夠提供極高的機密計算保護等級，但由于SGX技術(shù)在內(nèi)存資源和編程模型上的限制，無法有效支撐Java生態(tài)的機密計算業(yè)務(wù)，不得不說是一個遺憾。隨著阿里云神龍架構(gòu)第七代ECS實例的發(fā)布，所搭載的Intel新一代SGX2技術(shù)，為我們構(gòu)建基于Java生態(tài)的機密計算服務(wù)提供了條件。

Java機密計算Demo演示

現(xiàn)在，讓我們通過一個具體的例子來演示如何為Java業(yè)務(wù)提供機密計算保護。該實例基于第三代神龍架構(gòu)第七代ECS實例構(gòu)建，在SGX2提供的機密計算可信執(zhí)行環(huán)境內(nèi)運行Java SpringBoot網(wǎng)絡(luò)服務(wù)。

準備工作

申請一臺支持SGX2的神龍架構(gòu)第七代ECS實例，EPC內(nèi)存規(guī)格不要過小24G；

下載LibOS: Occlum容器鏡像
occlum/occlum：0.20.0-ubuntu18.04；

下載JDK: Alibaba Dragonwell11(Alpine)，Alibaba發(fā)布的基于Alpine平臺Dragonwell11鏡像版本；

下載SpringBoot源碼: Demo，該Demo展示了一個基于SpringBoot框架構(gòu)建的簡單網(wǎng)絡(luò)服務(wù)；

其中SpringBoot Demo源碼下載到本地后，進入initial目錄后進行編譯打包，在target目錄下會生成spring-boot-0.0.1-SNAPSHOT.jar，我們先在普通環(huán)境下運行jar包驗證其功能：

mvn clean packagejava -jar spring-boot-0.0.1-SNAPSHOT.jar

構(gòu)建SGX執(zhí)行環(huán)境

首先登錄到ECS實例；

在ECS環(huán)境下，通過docker命令進入Occlum容器；

docker run -it --rm --privileged --network host \-v `pwd`:`pwd` \-v /dev/sgx_enclave:/dev/sgx/enclave \-v /dev/sgx_provision:/dev/sgx/provision \-v /var/run/aesmd:/var/run/aesmd \occlum/occlum:0.20.0-ubuntu18.04

在Occlum容器中，創(chuàng)建一個enclave實體。該實例包含一個json配置文件和image鏡像文件夾；

mkdir occlum_instance cd occlum_instance occlum init

4. 對Occlum.json文件進行修改，修改內(nèi)容包括堆的大小、entry point和env環(huán)境變量等；

resource_limits.user_space_size = "1680MB" resource_limits.kernel_space_heap_size="64MB" resource_limits.max_num_of_threads = 64 process.default_heap_size = "256MB" process.default_mmap_size = "1400MB" entry_points = [ "/usr/lib/jvm/java-11-alibaba-dragonwell/jre/bin" ] env.default = [ "LD_LIBRARY_PATH=/usr/lib/jvm/java-11-alibaba- \ dragonwell/jre/lib/server:/usr/lib/jvm/java-11-alibaba-dragonwell/jre/lib:/usr/lib/jvm/java-11- \ alibaba-dragonwell/jre/../lib" ]

運行Java需要配置更大的內(nèi)存空間。entry_points選項表示Occlum LibOS里面JDK的放置路徑。JDK的路徑必須是xx/xx/jre/bin模式，而且需要設(shè)置LD_LIBRARY_PATH環(huán)境變量。由于目前的Occlum LibOS還不支持exec系統(tǒng)調(diào)用，因此JDK的路徑需要滿足一定條件，這樣可以避免JVM虛擬機啟動時出現(xiàn)exec系統(tǒng)調(diào)用。

進入image文件夾，在此目錄下創(chuàng)建usr/lib/jvm/java-11-alibaba-dragonwell文件目錄，用于放置Dragonwell11 Alpine JDK，注意將JDK壓縮文件解壓后的文件夾名重命名為jre，保證與.json配置文件一致；創(chuàng)建usr/lib/spring文件目錄，用于放置之前準備的SpringBoot spring-boot-0.0.1-SNAPSHOT.jar文件。

? 注意，image文件目錄將作為SGX LibOS運行起來后的根目錄。

將Occlum容器環(huán)境下的libz.so.1文件拷貝到image/lib；

cp /usr/local/occlum/x86_64-linux-musl/lib/libz.so.1 image/lib

構(gòu)建image機密鏡像；

occlum build

啟動SGX機密計算業(yè)務(wù)；

occlum run /usr/lib/jvm/java-11-alibaba-dragonwell/jre/bin/java -Xmx512m -XX:- \ UseCompressedOops -XX:MaxMetaspaceSize=64m -Dos.name=Linux -jar /usr/lib/spring/spring- \ boot-0.0.1-SNAPSHOT.jar

SpringBoot啟動完成后，使用命令curl localhost:8080請求SpringBoot服務(wù)，得到?"Greetings from Spring Boot!"?的回復(fù)，表示運行成功。其中，-XX:-UseCompressedOops參數(shù)是為了優(yōu)化Java在Occlum下的啟動時間；-Dos.name=Linux參數(shù)是為了告知JVM虛擬機LibOS的系統(tǒng)類型；

? ??

圖(1) SpringBoot啟動示意圖

整個SpringBoot網(wǎng)絡(luò)服務(wù)的運行過程都在機密計算環(huán)境下進行，ECS實例自帶的底層軟件沒有權(quán)限對保護中的服務(wù)進行窺探，實現(xiàn)了云上服務(wù)的運行態(tài)數(shù)據(jù)保護。

神龍架構(gòu)第七代ECS與Java機密計算

阿里云發(fā)布的神龍架構(gòu)第七代ECS實例，其搭載的是Intel第三代至強可擴展處理器(代號為Ice Lake)。該處理器提供的下一代Intel SGX安全技術(shù)(SGX2)，在核數(shù)和EPC內(nèi)存容量上皆有非常可觀的提升，具體規(guī)格見圖(2)所示。Ice Lake處理器在核數(shù)上提供了最多80物理核(160邏輯核)的處理能力，而第一代SGX可用處理器至多只有6個物理核；EPC內(nèi)存容量則增加到了1TB，而第一代SGX EPC內(nèi)存容量只有128M。用戶可根據(jù)需求選擇不同規(guī)格的核數(shù)和EPC內(nèi)存容量。

圖(2) SGX技術(shù)規(guī)格對比圖

由于SGX1提供的EPC內(nèi)存容量和核數(shù)太少，不適應(yīng)Java這種比較重的編程語言。長期以來，只有基于C/C++這類native語言更適合在SGX1中運行。此外，SGX SDK定義的Host Enclave編程模型，需要將業(yè)務(wù)代碼進行分割，對代碼侵入性較大，進一步限制了SGX1的使用范圍。由于SGX2技術(shù)在核數(shù)和EPC內(nèi)存容量上的提升，使得我們可以突破Host Enclave編程模型的束縛，同時滿足Java業(yè)務(wù)對硬件資源的要求，基于SGX部署Java機密計算業(yè)務(wù)成為了可能，可以預(yù)期公有云場景下的機密計算服務(wù)會迎來蓬勃發(fā)展。

機密計算模型

機密計算編程模型

機密計算主要有兩種編程模型，如圖(3)所示:

圖(3) 機密計算編程模型

一種是Host-Enclave編程模型，該模型將整個應(yīng)用分割成Host和Enclave兩部分。Host運行在普通環(huán)境下，負責(zé)大部分應(yīng)用邏輯處理，只將一些需要安全保護的業(yè)務(wù)邏輯(比如加解密等)放到Enclave環(huán)境中執(zhí)行，通過ecall和ocall操作實現(xiàn)二者的切換和信息傳遞；這種編程模型下，用戶需要將業(yè)務(wù)分割成Host和Enclave兩部分進行編程，還需要編寫ecall(ocall)代碼實現(xiàn)Host和Enclave之間的切換和信息交互，編程難度較大，對存量業(yè)務(wù)進行改造也有一定困難。但優(yōu)點是Enclave TCB足夠小，安全等級較高。

// enclave.cint function(int a, int b) {return a + b; }// host.cint main() {... ...enclave ec = create_enclave();int c = function(&enclave, 3, 5);destroy_enclave(ec);... ...printf("sum is: %d\n", c); }

另一種是Full-Feature編程模型，它將整個完整的應(yīng)用都放到Enclave中運行，Host只負責(zé)Enclave的管理和ocall等操作，一般由底層框架的工具鏈提供，用戶不用感知Host的存在；該編程模型與傳統(tǒng)編程模型一致，無需進行分割，沒有增加額外的編程難度，對已有業(yè)務(wù)代碼進行改造也很容易。但該模型需要在Enclave中駐留一個功能強大的SDK或LibOS，才能支撐完整應(yīng)用的正常運行，加上業(yè)務(wù)代碼自身的體量，會導(dǎo)致Enclave中TCB較大，安全等級下降。

// App.cint function(int a, int b) {return a + b; }int main() {int c = function(3, 5); printf("sum is: %d\n", c); }

兩種機密計算編程模型各有利弊，用戶需要在易用性和安全性兩個指標上進行權(quán)衡。

機密計算需求模型

魚和熊掌不可兼得，需要在易用性和安全性兩個需求維度進行取舍。我們將機密計算業(yè)務(wù)需求按照安全等級進行分級，不同安全等級的需求，選擇不同的編程模型，見圖(4)所示。當業(yè)務(wù)中只有少量計算邏輯需要安全保護，且要求較高的安全等級時，可以選擇Host-Enclave編程模型；當用戶不希望對業(yè)務(wù)代碼進行大量改造，同時可以接受相對較低的安全等級時，可以選擇Full-Feature編程模型。

圖(4) 機密計算需求模型

SGX機密計算軟件生態(tài)

神龍架構(gòu)第七代ECS實例提供的第二代SGX技術(shù)，在硬件能力上已不存在瓶頸。那么接下來的一段時期，圍繞SGX技術(shù)軟件生態(tài)的發(fā)展，將決定SGX技術(shù)是否能得到廣泛使用，產(chǎn)生業(yè)務(wù)價值。

SGX SDK

Intel在發(fā)布第一代SGX技術(shù)之時，就推出了Intel SGX SDK，它定義了面向C/C++語言的SGX機密計算Host-Enclave編程模型，用.edl文件定義Host與Enclave之間的交互接口；之后微軟云Azure推出了OpenEnclave，它是對Intel SGX SDK進行的功能擴展和平臺抽象。可以在Enclave中運行更加復(fù)雜的業(yè)務(wù)，同時擴展了安全計算硬件平臺的支持(SGX和TrustZone等)；Google云推出了Asylo編程模型，與OpenEnclave類似，同樣是進行了平臺抽象和功能擴展。Asylo最大的特點是將Encalve抽象成一種遠端服務(wù)，與Host通過GRPC方式進行交互。可以讓Host和Enclave兩個模塊在物理上分離，不必限制在一個芯片內(nèi)部，而且還屏蔽了Host和Enclave的編程語言差異，使得Asylo編程模型更具靈活性，非常具有借鑒意義。

縱觀Intel SGX SDK、OpenEnclave和Asylo的發(fā)展，不難看出OpenEnclave和Asylo是對Intel SGX SDK的繼承和發(fā)展，上述三種SDK滿足了部分機密計算應(yīng)用場景，比如使用C/C++語言編寫且只有少量計算需要安全保護的業(yè)務(wù)場景。又由于Enclave SDK能力限制，無法支持復(fù)雜Enclave業(yè)務(wù)邏輯。主要有如下幾個特點：

都屬于Host-Enclave編程模型，Asylo在一定程度上也支持Full-Feature編程模型；

開發(fā)難度大，Host-Enclave編程模型需要對應(yīng)用程序做二分；

僅支持C/C++編程語言，無法支持像Java/Go等高級編程語言；

不支持Full-Feature編程模型，無法滿足易用性要求高的業(yè)務(wù)場景；

SGX LibOS

SGX運行環(huán)境與普通運行環(huán)境有許多不同之處，是否可以在Enclave中引入一個OS屏蔽掉SGX執(zhí)行環(huán)境的差異，讓應(yīng)用程序感知不到SGX的存在，就像在普通環(huán)境下運行一樣呢? 業(yè)界有很多這樣的先行者，目前比較知名的SGX LibOS項目有Occlum、Graphene和SGX-LKL等。其中Occlum是由螞蟻自研的開源TEE-OS系統(tǒng)，采用Rust編程語言，功能較完善，已支持多種編程語言，同時還具備高性能和內(nèi)存安全等特點。

SGX LibOS的目的是讓整個應(yīng)用方便的運行在SGX Enclave中，符合Full-Feature機密計算編程模型，易用性高、支持多種編程語言和復(fù)雜的應(yīng)用。這種解決方案主要存在以下問題:

TCB增大，犧牲了一定的安全性；

需要消耗更多的SGX硬件資源；

頻繁的ecall和ocall操作（比如IO）影響業(yè)務(wù)性能；

Alibaba Dragonwell機密計算

SGX1存在核數(shù)和EPC大小等的限制，如果將內(nèi)存需求量大、邏輯復(fù)雜的應(yīng)用部署在LibOS平臺上，必然會出現(xiàn)頻繁的EPC內(nèi)存swap和ecall(ocall)切換，導(dǎo)致業(yè)務(wù)性能下降嚴重，很難投入實際的生產(chǎn)環(huán)境。因此SGX1硬件條件決定了它只能支持C/C++編程語言實現(xiàn)的簡單Enclave業(yè)務(wù)場景。隨著神龍架構(gòu)第七代ECS實例的發(fā)布，來到SGX2時代后，得益于核數(shù)和EPC內(nèi)存大小的提升，基于Java編程語言的機密計算服務(wù)具備了實用的條件。

Java機密計算解決方案

阿里巴巴Java虛擬機團隊推出的Java機密計算解決方案如圖(5)所示。該方案采用Full-Feature編程模型，通過在Enclave中引入LibOS，支撐Alibaba Dragonwell11的運行，上層應(yīng)用則對SGX環(huán)境無感知。

圖(5) Java機密計算解決方案

Alibaba Dragonwell是阿里巴巴Java虛擬機團隊開源的OpenJDK實現(xiàn)，目前支持8和11兩個LTS版本。針對Alibaba Dragonwell11，發(fā)布了兼容glibc與musl兩種libc的JDK版本，目的是為了讓Alibaba Dragonwell11能適配更多的LibOS。由于musl相比glibc更輕量，代碼易維護，在機密計算領(lǐng)域更受青睞，很多LibOS優(yōu)先選擇musl作為基礎(chǔ)庫進行支持(比如Occlum)。Alibaba Dragonwell11 musl版本不僅僅可以作為機密計算JDK的首選版本，而且還能用于構(gòu)建Alpine容器鏡像，有效減小容器鏡像的大小。

Java機密計算性能評估

性能是繞不開的話題，運行在SGX2中的Java業(yè)務(wù)性能表現(xiàn)如何呢？我們對Java SpringBoot業(yè)務(wù)分別在SGX1/SGX2/Linux三種運行環(huán)境下的性能進行了壓力測試。設(shè)置相同的測試壓力（并發(fā)數(shù)400, 壓測時間40s），從系統(tǒng)吞吐量（MB/秒）和RPS（請求數(shù)/秒）兩個壓測指標維度進行對比分析。壓測結(jié)果如圖(6)所示:

圖(6) Java機密計算SGX壓測性能對比圖

在相同的測試壓力下，Linux平臺的吞吐量為26.91MB/秒、RPS為12.84K/秒；SGX2吞吐量為是18.53MB/秒、RPS為8.84K/秒；SGX1吞吐量為1.26MB/秒、RPS為602.10K/秒。可以看到SGX2相比SGX1獲得了巨大的性能提升，但與Linux平臺還存在一定差距。相信隨著Alibaba Dragonwell11的持續(xù)優(yōu)化，性能也會進一步提升。

總結(jié)

在阿里云發(fā)布神龍架構(gòu)第七代ECS實例后，阿里巴巴Java虛擬機團隊提出了面向Java語言的機密計算編程模型和解決方案，并進行了深入的實踐，發(fā)布了用于Java機密計算的Alibaba Dragonwell11 JDK版本。從實踐結(jié)果看，基于SGX2的Java機密計算解決方案，在性能上提升明顯，可以支撐復(fù)雜的Java機密計算服務(wù)穩(wěn)定運行。相信基于SGX2的Java機密解決方案將有力推動Java機密計算的發(fā)展，希望對Java機密計算感興趣或者有需求的開發(fā)者嘗試我們的方案，期待與大家進一步的交流。

原文鏈接
本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的当Java遇上机密计算，又一段奇幻之旅开始了！的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。