SGX 應(yīng)用支持技術(shù)研究進(jìn)展*

董春濤,沈晴霓,羅 武,吳鵬飛,吳中海1,

1(北京大學(xué) 軟件與微電子學(xué)院,北京 102600)

2(北京大學(xué) 信息科學(xué)技術(shù)學(xué)院,北京 100871)

3(北京大學(xué) 軟件工程國(guó)家工程研究中心,北京 100871)

4(高可信軟件技術(shù)教育部重點(diǎn)實(shí)驗(yàn)室(北京大學(xué)),北京 100871)

隨著云計(jì)算與大數(shù)據(jù)技術(shù)的快速發(fā)展,越來越多的應(yīng)用程序被部署到第三方數(shù)據(jù)中心和云平臺(tái)中,如Amazon AWS[1]和Microsoft Azure[2].但是,這也帶來了一系列安全問題,例如:應(yīng)用程序在云平臺(tái)以明文方式處理敏感數(shù)據(jù),容易被云服務(wù)提供商或其他攻擊者攻擊.因此,應(yīng)用程序必須能夠抵御云服務(wù)提供商和其他攻擊者的攻擊.傳統(tǒng)手段中,基于加密的保護(hù)技術(shù)[3-5]只能支持有限的運(yùn)算操作,全同態(tài)加密[6]可以支持任意操作,但增加了大量的開銷.當(dāng)前,基于CPU 提供的可信執(zhí)行機(jī)制是不可信環(huán)境中保護(hù)應(yīng)用程序的重要手段,例如Intel 推出的SGX(software guard extensions)指令集擴(kuò)展[7].

SGX 是一種基于內(nèi)存加密和證明的硬件機(jī)制,可以為應(yīng)用程序提供用戶空間的可信執(zhí)行環(huán)境enclave[8],并將程序執(zhí)行和狀態(tài)與底層操作系統(tǒng)(operating system,簡(jiǎn)稱OS)、虛擬機(jī)管理程序、固件、I/O 設(shè)備等隔離開來,保障用戶關(guān)鍵代碼和數(shù)據(jù)的機(jī)密性與完整性不受惡意軟件的破壞.SGX 的可信計(jì)算基(trusted computing base,簡(jiǎn)稱TCB)僅包括CPU,避免了基于軟件的TCB 自身存在安全漏洞的風(fēng)險(xiǎn),提升了系統(tǒng)的安全性.同時(shí),SGX 可以保障運(yùn)行時(shí)的可信執(zhí)行環(huán)境,抵御惡意代碼對(duì)程序被保護(hù)內(nèi)容的訪問與篡改,進(jìn)一步增強(qiáng)了系統(tǒng)的安全性.SGX強(qiáng)大的安全保障能力與性能保證,使其得到了廣泛的應(yīng)用與發(fā)展.但是SGX 在應(yīng)用中也暴漏出諸多的瓶頸問題,如何解決這些瓶頸問題也成為了學(xué)術(shù)界和工業(yè)界的重要研究方向.本文通過整理和歸納相關(guān)研究工作,總結(jié)了目前SGX 應(yīng)用面臨的瓶頸問題,主要包括應(yīng)用安全問題、應(yīng)用性能瓶頸、應(yīng)用開發(fā)的困難性和應(yīng)用功能的局限性,并對(duì)這4 類問題的解決方案分別進(jìn)行了分析和總結(jié).

安全性是SGX 最基本和最重要的目標(biāo).SGX 可以為代碼和數(shù)據(jù)提供機(jī)密性和完整性保證,但其在實(shí)際應(yīng)用中依然會(huì)面臨諸多的安全風(fēng)險(xiǎn)和威脅,例如過大的TCB、暴露過多的對(duì)外接口和敏感代碼的安全劃分與驗(yàn)證以及側(cè)信道攻擊[9-11]等.針對(duì)上述安全風(fēng)險(xiǎn)與安全威脅,學(xué)術(shù)界已經(jīng)提出了多種方案,本文將其歸納為TCB 最小化、對(duì)外接口最少化、敏感代碼的自動(dòng)化生成與安全檢測(cè)以及潛在的安全威脅分析與防護(hù)這4 種類型.

性能開銷是目前制約SGX 應(yīng)用推廣的重要因素.SGX 為代碼和數(shù)據(jù)提供機(jī)密性和完整性保證,同時(shí)也帶來了較高的性能開銷.SGX 性能開銷主要包括進(jìn)入和退出enclave 導(dǎo)致的enclave 切換開銷、內(nèi)存加解密開銷和頁(yè)替換(paging)開銷這3 個(gè)方面.針對(duì)上述性能開銷的原因,本文總結(jié)和梳理了目前研究工作中的性能優(yōu)化方案,將SGX 性能優(yōu)化歸納為模式(enclave)切換性能優(yōu)化、內(nèi)存加密優(yōu)化和內(nèi)存頁(yè)替換這3 種技術(shù).

應(yīng)用開發(fā)困難也是制約 SGX 發(fā)展和推廣的重要原因.Intel 公司為用戶提供了軟件開發(fā)包(software development kit,簡(jiǎn)稱SDK),但是使用該SDK 開發(fā)SGX 應(yīng)用程序卻并不容易,甚至錯(cuò)誤的使用方式會(huì)導(dǎo)致安全風(fēng)險(xiǎn).目前,SGX 應(yīng)用開發(fā)的困難問題主要包括敏感代碼劃分工作量大且無法直接支持舊有的應(yīng)用程序、缺少安全檢測(cè)與性能測(cè)試等輔助開發(fā)工具、支持的語(yǔ)言類型有限和缺少操作系統(tǒng)庫(kù)(library OS)支持.本文總結(jié)了相關(guān)研究工作提出的SGX 應(yīng)用輔助開發(fā)技術(shù),主要包括安全開發(fā)語(yǔ)言、輔助開發(fā)工具和通用系統(tǒng)庫(kù)等.

云環(huán)境是SGX 技術(shù)應(yīng)用的主要場(chǎng)景,但是目前SGX 技術(shù)自身缺乏對(duì)虛擬機(jī)(vitual machine,簡(jiǎn)稱VM)遷移和容器(container)等云平臺(tái)常用功能的支持.很多研究工作針對(duì)SGX 缺乏的功能支持,對(duì)其功能進(jìn)行了擴(kuò)展,主要包括虛擬機(jī)遷移支持技術(shù)和容器支持技術(shù).

本文第1 節(jié)對(duì)SGX 的相關(guān)概念進(jìn)行概述,并介紹SGX 的關(guān)鍵機(jī)制和SDK.第2 節(jié)對(duì)SGX 的應(yīng)用現(xiàn)狀以及瓶頸問題進(jìn)行總結(jié).第3 節(jié)對(duì)SGX 應(yīng)用的安全風(fēng)險(xiǎn)以及已有的安全防護(hù)技術(shù)進(jìn)行總結(jié).第4 節(jié)分析SGX 性能開銷的原因,并對(duì)相關(guān)性能優(yōu)化技術(shù)進(jìn)行歸納.第5 節(jié)總結(jié)SGX 應(yīng)用開發(fā)的困難性問題以及已有的SGX 應(yīng)用輔助開發(fā)技術(shù).第6 節(jié)總結(jié)目前已有的SGX 應(yīng)用功能擴(kuò)展技術(shù).最后對(duì)全文進(jìn)行總結(jié),闡述SGX 應(yīng)用支持技術(shù)仍然需要解決的問題并展望未來的研究方向.

1 SGX 概述

SGX 是在原有Intel 架構(gòu)上擴(kuò)展了一組新的指令集和內(nèi)存訪問機(jī)制[11],這些擴(kuò)展能夠在計(jì)算平臺(tái)上提供一個(gè)可信的隔離空間,允許應(yīng)用程序使用enclave[7]保障用戶關(guān)鍵代碼和數(shù)據(jù)的機(jī)密性和完整性,不受特殊權(quán)限惡意軟件的破壞[12].SGX 整體架構(gòu)如圖1 所示.SGX 擴(kuò)展指令集包括17 條新指令,其中5 條指令是用戶指令,包括進(jìn)入enclave(EENTER)、退出enclave(EEXIT)、恢復(fù)enclave(ERESUME)、獲取密鑰(EGETKEY)和證明時(shí)獲取enclave 度量報(bào)告(EREPORT).其他12 條指令是系統(tǒng)指令,用戶通過操作系統(tǒng)的SGX 驅(qū)動(dòng)(driver)調(diào)用執(zhí)行,主要包括 enclave 創(chuàng)建(ECREATE,EADD,EEXTEND,EINIT)、enclave 異步退出(AEX)、enclave 銷毀(EREMOVE)、資源管理(EPA,ELDB/U,EWB,EBLOCK,ETRACK).因?yàn)閑nclave 的創(chuàng)建必須在內(nèi)核空間中進(jìn)行,而enclave 的交互僅限于用戶空間應(yīng)用程序,特權(quán)代碼無法進(jìn)入enclave,非特權(quán)代碼無法創(chuàng)建enclave.

所有的enclave 代碼和數(shù)據(jù)都存儲(chǔ)在EPC(enclave page cache)中,EPC 是一塊用來存放enclave 和SGX 數(shù)據(jù)結(jié)構(gòu)[7]的被保護(hù)的物理內(nèi)存區(qū)域,EPC 內(nèi)存以頁(yè)為單位進(jìn)行管理,對(duì)EPC 頁(yè)進(jìn)行訪問控制的元數(shù)據(jù)信息保存在硬件結(jié)構(gòu)EPCM(enclave page cache metadata)里.SXG 應(yīng)用開發(fā)需要將應(yīng)用程序分為可信和不可信兩個(gè)部分,兩部分之間通過用戶定義的Ecall 和Ocall 代碼進(jìn)行調(diào)用.

Fig.1 Architecture description of SGX圖1 SGX 整體架構(gòu)

1.1 SGX安全機(jī)制

SGX 旨在保護(hù)enclave 內(nèi)計(jì)算的機(jī)密性和完整性,抵御惡意軟件攻擊和物理攻擊.SGX 技術(shù)主要包括隔離執(zhí)行、認(rèn)證(attestation)和密封(sealing)這3 個(gè)核心機(jī)制.本小節(jié)對(duì)SGX 的相關(guān)核心安全機(jī)制進(jìn)行介紹.

1.1.1 隔離執(zhí)行

SGX 的核心概念就是enclave,它是一個(gè)被保護(hù)的安全容器,用于存儲(chǔ)應(yīng)用程序的敏感數(shù)據(jù)和代碼[13,14].Enclave 內(nèi)除代碼和數(shù)據(jù)以外,還包括元數(shù)據(jù)和TCS(thread control structure),TCS 用于保存進(jìn)入或退出enclave時(shí)恢復(fù)enclave 線程的特殊信息(如圖2 所示).EPC 是PRM(processor reserved memory)的一部分,PRM 則是內(nèi)存的一部分,BIOS 通過配置一組范圍寄存器分配PRM,系統(tǒng)軟件或外圍設(shè)備無法訪問.

Fig.2 SGX sample layout of PRM and EPC圖2 PRM 和EPC 布局示意圖

圖2 是一個(gè)PRM 和EPC 布局示意圖.EPC 內(nèi)存以頁(yè)為單位進(jìn)行管理,對(duì)EPC 頁(yè)進(jìn)行訪問控制的元數(shù)據(jù)信息保存在硬件結(jié)構(gòu)EPCM 里,一個(gè)enclave 頁(yè)面對(duì)應(yīng)一個(gè)EPCM 表項(xiàng).通過處理器的訪問控制,可以保證每個(gè)EPC頁(yè)面只能映射到特定的虛擬地址,確保每一個(gè)EPC 頁(yè)只允許與其相關(guān)聯(lián)的enclave 訪問.

Enclave 中的代碼、數(shù)據(jù)和TCS 等在運(yùn)行過程中始終被加密存儲(chǔ)在內(nèi)存中.處理器緩存(cache)中的數(shù)據(jù)在寫到內(nèi)存之前,處理器中的內(nèi)存加密單元(memory encryption engine,簡(jiǎn)稱MEE)會(huì)對(duì)其進(jìn)行加密,因此操作系統(tǒng)無法直接獲取EPC 中的內(nèi)容,保證了應(yīng)用程序代碼和數(shù)據(jù)在運(yùn)行過程中不受特權(quán)系統(tǒng)軟件的攻擊.SGX 的內(nèi)存保護(hù)機(jī)制可以保證enclave 外部的應(yīng)用程序不能訪問enclave 內(nèi)存,enclave 內(nèi)部的代碼在EPC 范圍內(nèi)只能訪問屬于自己的內(nèi)存,不能訪問其他enclave 的內(nèi)存.這樣的內(nèi)存保護(hù)機(jī)制防止了enclave 內(nèi)部運(yùn)行的程序被其他惡意軟件盜取和篡改隱私信息;同時(shí),保證了在物理上鎖住EPC 內(nèi)存區(qū)域,將外部的訪問請(qǐng)求視為訪問了不存在的內(nèi)存,使得外部的實(shí)體(直接存儲(chǔ)器訪問等)無法訪問.

應(yīng)用程序在申請(qǐng)創(chuàng)建一個(gè)enclave 時(shí),需要進(jìn)行頁(yè)面分配(ECREATE)、復(fù)制程序代碼與數(shù)據(jù)(EADD)和度量操作(EEXTEND).Enclave 被加載以后,需要進(jìn)行完整性驗(yàn)證,以判斷特權(quán)軟件在創(chuàng)建enclave 過程中是否篡改了程序和數(shù)據(jù).在enclave 初始化之后(EINIT),不可信任的代碼(在enclave 外)執(zhí)行可信代碼(在enclave 內(nèi))的唯一方法是調(diào)用EENTER 指令.EENTER 執(zhí)行上下文切換到enclave,保存不可信代碼的狀態(tài),并恢復(fù)可信代碼的最后已知狀態(tài).該上下文切換在概念上類似于用于英特爾 VTX 技術(shù)中的虛擬機(jī)上下文切換的VMENTER 和VMEXIT[15].

SGX SDK 提供了封裝代碼,稱為ecall[16],用于準(zhǔn)備執(zhí)行環(huán)境并調(diào)用EENTER 指令.由于enclave 以用戶級(jí)權(quán)限運(yùn)行可信代碼,因此enclave 無法訪問硬件或其他系統(tǒng)資源.為了訪問外部資源,例如文件系統(tǒng)、網(wǎng)絡(luò)或時(shí)鐘,enclave 必須退出到不可信代碼,它可以通過EEXIT 指令完成.EEXIT 執(zhí)行反向上下文切換并切換回不可信的代碼.執(zhí)行此操作的SDK 封裝代碼稱為ocall[16].為了避免泄漏隱私數(shù)據(jù),正在執(zhí)行enclave 代碼的CPU 不直接處理中斷、故障(例如頁(yè)面錯(cuò)誤)或虛擬機(jī)退出.相反,CPU 首先執(zhí)行AEX(asynchronous enclave exit)從enclave 代碼切換到非enclave 代碼,然后才處理中斷故障或VM 退出.

1.1.2 認(rèn) 證

在enclave 初始化之前,代碼和數(shù)據(jù)是公開的,敵手可竊取和篡改.SGX 提供一個(gè)證明指令EREPORT 來抵御敵手竊取和篡改初始化之前的代碼和數(shù)據(jù).具體地,enclave 通過調(diào)用EREPORT 產(chǎn)生一個(gè)硬件簽名的enclave 度量值報(bào)告,并發(fā)送給驗(yàn)證方進(jìn)行證明.SGX 支持本地認(rèn)證和遠(yuǎn)程認(rèn)證兩種類型的身份認(rèn)證方式[7,17]:本地認(rèn)證用于平臺(tái)內(nèi)部enclave 之間,用來認(rèn)證報(bào)告的enclave 和自己是否運(yùn)行在同一個(gè)平臺(tái)上;遠(yuǎn)程認(rèn)證則是用于平臺(tái)之間,用于遠(yuǎn)程認(rèn)證者認(rèn)證enclave 的身份信息.

當(dāng)enclave 向平臺(tái)上其他enclave 報(bào)告身份時(shí),首先要獲取自身的身份信息和屬性以及平臺(tái)硬件TCB 信息,附加上用戶希望交互的數(shù)據(jù),生成報(bào)告結(jié)構(gòu)(report structure).然后獲取目標(biāo)enclave 的報(bào)告密鑰,對(duì)報(bào)告結(jié)構(gòu)生成一個(gè)消息認(rèn)證碼(message authentication code,簡(jiǎn)稱MAC)標(biāo)簽,形成最終的報(bào)告結(jié)構(gòu),傳遞給目標(biāo)enclave,由目標(biāo)enclave 驗(yàn)證請(qǐng)求報(bào)告身份的enclave 與自己是否運(yùn)行于同一平臺(tái).遠(yuǎn)程認(rèn)證則需要引入一個(gè)引用(quoting)enclave,由引用enclave 創(chuàng)建用于平臺(tái)認(rèn)證的簽名密鑰EPID(enhanced privacy identification).被認(rèn)證enclave 首先執(zhí)行EREPORT 指令,將身份和附加信息生成報(bào)告結(jié)構(gòu),并利用引用enclave 的報(bào)告密鑰生成一個(gè)MAC 標(biāo)簽,一起發(fā)給引用enclave.引用enclave 通過該結(jié)構(gòu)驗(yàn)證被認(rèn)證enclave 是否運(yùn)行于同一平臺(tái),然后將它封裝為一個(gè)引用結(jié)構(gòu)體QUOTE,并使用EPID 進(jìn)行簽名,將QUOTE 和簽名一同發(fā)送給遠(yuǎn)程認(rèn)證者.遠(yuǎn)程認(rèn)證者驗(yàn)證enclave報(bào)告是否由可靠的Intel 處理器生成.

1.1.3 密封

密封是指enclave 使用EGETKEY 指令獲取一個(gè)硬件產(chǎn)生的封裝密鑰對(duì)enclave 數(shù)據(jù)進(jìn)行加密,并將加密數(shù)據(jù)存儲(chǔ)在enclave 之外不可信存儲(chǔ)中的過程[17].Enclave 數(shù)據(jù)根據(jù)enclave 的標(biāo)識(shí)(MRENCLAVE)或簽名標(biāo)識(shí)(MRSIGNER)進(jìn)行密封,對(duì)MRENCLAVE 加密的數(shù)據(jù)只能由相同的enclave 解密,而對(duì)MRSIGNER 加密的數(shù)據(jù)可以由同一開發(fā)人員簽名的任何enclave 解密.在這兩種情況下,密封密鑰都來自特定于CPU 的密鑰,因此數(shù)據(jù)只能在它被密封的同一臺(tái)物理機(jī)器上打開.SGX 密封保證了密封數(shù)據(jù)的機(jī)密性和完整性,但不會(huì)自動(dòng)提供回放(roll-back)保護(hù).如果需要,enclave 開發(fā)人員必須檢查已提供的密封數(shù)據(jù)的版本是否正確,通常通過使用安全單調(diào)計(jì)數(shù)器(monotonic counter)來實(shí)現(xiàn).

1.2 SGX管理機(jī)制

1.2.1 SGX 內(nèi)存管理機(jī)制

Enclave 與主機(jī)程序共用一片虛擬地址空間,部分enclave 中映射到EPC 頁(yè)的虛擬內(nèi)存稱為enclave 線性地址空間(enclave linear address range,簡(jiǎn)稱ELRANGE).這段地址空間在EPC 分配終止后,對(duì)于主機(jī)進(jìn)程來說是不能訪問的.任何試圖讀寫ELRANGE 地址空間的enclave 外部代碼都會(huì)產(chǎn)生一個(gè)未定義行為的錯(cuò)誤.

Enclave 執(zhí)行總是在受保護(hù)模式下,并由OS 內(nèi)核或hypervisor 進(jìn)行地址轉(zhuǎn)換.SGX 為了不影響傳統(tǒng)OS 對(duì)平臺(tái)資源的管理和分配,實(shí)現(xiàn)enclave 中的頁(yè)到EPC 中幀轉(zhuǎn)換的頁(yè)表(page table)仍由OS 管理[7].OS 和hypervisor完全控制頁(yè)表和擴(kuò)展頁(yè)表(extended page table,簡(jiǎn)稱EPT),enclave 代碼使用與其主機(jī)應(yīng)用程序相同的地址轉(zhuǎn)換過程和頁(yè)表.由于操作系統(tǒng)或hypervisor 是不可信的,因此CPU 必須要防止對(duì)enclave 的地址轉(zhuǎn)換攻擊[10].當(dāng)從EPC 頁(yè)地址轉(zhuǎn)換到物理地址時(shí),CPU 使用在SGX enclave 控制結(jié)構(gòu)(SGX enclave control structure,簡(jiǎn)稱SECS)中存儲(chǔ)的初始分配信息來保證傳遞給地址轉(zhuǎn)換過程的EPC 頁(yè)虛擬地址與EPCM 中保留的EPC 入口地址相匹配.以此來防止操作系統(tǒng)將ELRANGE 地址映射到不受保護(hù)的內(nèi)存,使得ELRANGE 內(nèi)存對(duì)enclave 之外的軟件不可見.

1.2.2 EPC 頁(yè)驅(qū)逐(eviction)

操作系統(tǒng)可以將EPC 頁(yè)面驅(qū)逐到不可信的DRAM 中,并將其加載回來,如圖3 所示.系統(tǒng)軟件使用EWB 指令驅(qū)逐EPC 頁(yè)面,該指令產(chǎn)生ELDU 指令恢復(fù)被驅(qū)逐頁(yè)面所需的所有數(shù)據(jù)[7].SGX 通過加密(EGETKEY)來保證被驅(qū)逐的EPC 頁(yè)面存儲(chǔ)在不可信內(nèi)存中時(shí)的機(jī)密性和完整性.EWB 和ELDU/ELDB 指令使用一個(gè)ID 來識(shí)別擁有被換出頁(yè)面的enclave.EWB 驅(qū)逐EPC 的內(nèi)容時(shí),會(huì)創(chuàng)建一個(gè)8 字節(jié)的隨機(jī)數(shù),稱為頁(yè)面版本(page version).SGX 的新鮮度(freshness)保證則建立在安全存儲(chǔ)頁(yè)面版本的假設(shè)之上,因此,EWB 將其存儲(chǔ)在一個(gè)版本數(shù)組(version array,簡(jiǎn)稱VA)中,VA 頁(yè)面也可以驅(qū)逐.被驅(qū)逐的頁(yè)面依賴于存儲(chǔ)其頁(yè)面版本的VA 頁(yè)面,在VA 頁(yè)面被重新加載之前無法被重加載到EPC 中.基于這種依賴關(guān)系創(chuàng)建的關(guān)系圖稱為驅(qū)逐樹(eviction tree).驅(qū)逐樹將EPC 頁(yè)面作為葉子,將VA 頁(yè)面作為內(nèi)部節(jié)點(diǎn).頁(yè)面的父節(jié)點(diǎn)是存儲(chǔ)其頁(yè)面版本的VA 頁(yè)面[7].

Fig.3 EPC pages evicted into non-PRM DRAM圖3 EPC 頁(yè)驅(qū)逐到非PRM 內(nèi)存

1.3 SGX SDK

為了簡(jiǎn)化SGX 應(yīng)用程序的開發(fā),Intel 發(fā)布了SDK[14].它向開發(fā)人員隱藏了SGX 硬件細(xì)節(jié)信息,并引入了ecall 和ocall 的概念,分別用于進(jìn)入和退出enclave,如同普通的函數(shù)調(diào)用那樣.通過使用SGX SDK,開發(fā)人員可以創(chuàng)建加載到enclave 的代碼,并定義enclave 代碼與其他不可信的應(yīng)用程序代碼之間的ecall 和ocall 接口.

Intel 提供了一個(gè)名為edger8r 的邊緣函數(shù)創(chuàng)建工具,用于自動(dòng)生成ecall 和ocall 的安全封裝代碼.要自動(dòng)生成ecall 和ocall 代碼,開發(fā)人員必須使用SGX 規(guī)定的語(yǔ)法,在enclave 描述語(yǔ)言(enclave description language,簡(jiǎn)稱EDL)擴(kuò)展文件中聲明ecall 和ocall 函數(shù).然后,edger8r 解析EDL 文件生成封裝代碼,如圖4 所示.Ecall 和ocall被認(rèn)為是邊緣函數(shù)(edge function),因?yàn)閷?duì)它們的執(zhí)行會(huì)跨越安全邊界.函數(shù)的參數(shù)需要編組(marshall),并從加密內(nèi)存復(fù)制到明文內(nèi)存,反之亦然.為了邊界交互的安全,需要對(duì)調(diào)用的參數(shù)執(zhí)行多項(xiàng)安全檢查,特別是在參數(shù)是指針的情況下.Enclave 代碼必須驗(yàn)證所訪問數(shù)據(jù)的完整性,如ecall 的參數(shù)、ocall 的返回值和從不可信內(nèi)存讀取的數(shù)據(jù).

Fig.4 Process of edger8r generates wrapper code from EDL file圖4 Edger8r 解析EDL 文件生成封裝代碼的過程

Enclave 支持多線程,因此需要同步原語(yǔ).由于在enclave 內(nèi)部無法進(jìn)行睡眠等待,因此,SGX SDK 提供的enclave 內(nèi)部同步原語(yǔ)實(shí)現(xiàn)了通過ocall 以在enclave 外部進(jìn)行睡眠等待.SDK 提供的互斥鎖的工作方式如下:如果線程嘗試鎖定未鎖定的互斥鎖,則此操作成功完成而無需離開enclave.每當(dāng)線程嘗試鎖定已鎖定的互斥鎖時(shí),它將進(jìn)入隊(duì)列并通過ocall 退出enclave 進(jìn)入睡眠狀態(tài);然后,持有互斥鎖的線程需要通過進(jìn)入隊(duì)列并通過ocall離開enclave 來喚醒睡眠線程.因此,SGX SDK 提供的互斥鎖會(huì)導(dǎo)致兩次ocall,開銷比較大.

2 SGX 應(yīng)用現(xiàn)狀及瓶頸問題

SGX 技術(shù)推出以來,受到了學(xué)術(shù)界和工業(yè)界的極大關(guān)注,目前在很多領(lǐng)域已經(jīng)得到了廣泛的應(yīng)用,如文獻(xiàn)[18]重點(diǎn)討論了SGX 在保障應(yīng)用與網(wǎng)絡(luò)安全方面的應(yīng)用研究進(jìn)展.但是,SGX 在應(yīng)用的同時(shí)也暴露出很多安全缺陷,如Wang 等人重點(diǎn)討論了針對(duì)SGX 的側(cè)信道攻擊和防御方面的研究進(jìn)展[19].事實(shí)上,除了側(cè)信道問題,SGX應(yīng)用還暴露出了許多其他安全性問題、性能瓶頸、開發(fā)困難、功能局限等諸多應(yīng)用方面的問題.本節(jié)首先介紹SGX 目前的應(yīng)用現(xiàn)狀,然后總結(jié)SGX 在應(yīng)用中暴露出的諸多問題,最后對(duì)SGX 應(yīng)用支持技術(shù)的研究方向進(jìn)行總結(jié).

從應(yīng)用的場(chǎng)景來看,SGX 可以用于構(gòu)建安全的云應(yīng)用[20-22],用于保護(hù)網(wǎng)絡(luò)通信[23-27]以及增強(qiáng)本地應(yīng)用的安全性[28-31].SGX 首先被應(yīng)用在云計(jì)算安全領(lǐng)域,如構(gòu)建云平臺(tái)應(yīng)用安全隔離執(zhí)行環(huán)境[32]、構(gòu)建云平臺(tái)大數(shù)據(jù)安全可信計(jì)算環(huán)境[33,34]和對(duì)虛擬化技術(shù)的支持[35].例如,Hunt 等人提出的Ryoan 系統(tǒng)[32],利用enclave 實(shí)現(xiàn)了一個(gè)分布式沙箱來保護(hù)沙箱實(shí)例不受潛在惡意平臺(tái)的攻擊.Schuster 等人提出的VC3 框架[33],基于SGX 實(shí)現(xiàn)了保護(hù)代碼和數(shù)據(jù)的機(jī)密性和完整性mapreduce[36]框架.Brenner 等人提出的Securekeeper 框架[21],通過設(shè)計(jì)存儲(chǔ)數(shù)據(jù)的加解密方案和在enclave 中對(duì)數(shù)據(jù)處理的方式,實(shí)現(xiàn)了對(duì)管理數(shù)據(jù)隱私性和完整性的保護(hù).Arnautov 等人設(shè)計(jì)了一個(gè)用于Docker[37]的安全容器環(huán)境SCONE[35],利用SGX 來保護(hù)Docker 容器內(nèi)進(jìn)程免受外部攻擊.微軟與英特爾協(xié)作利用SGX 以增強(qiáng)云中的安全性,幫助數(shù)據(jù)和代碼在使用過程中得到更強(qiáng)的保護(hù)[38].IBM 利用英特爾SGX 配合IBM Cloud Data Shield 以幫助保護(hù)使用中的數(shù)據(jù)[39].

SGX 也被用于保護(hù)網(wǎng)絡(luò)通信安全和本地應(yīng)用安全.如在文獻(xiàn)[23]中,作者提出一種保護(hù)方案(S-NFV),利用SGX 對(duì)網(wǎng)絡(luò)功能虛擬化(network function virtualization,簡(jiǎn)稱NFV)產(chǎn)生的狀態(tài)進(jìn)行安全隔離保護(hù).Andrew 等人提出的Haven 系統(tǒng)[30],通過修改Drawbridge 沙箱[40]實(shí)現(xiàn)了Windows 應(yīng)用直接在沙箱中的enclave 內(nèi)安全運(yùn)行,為Windows 應(yīng)用提供了安全保障.

除了應(yīng)用于云計(jì)算、網(wǎng)絡(luò)通信和本地應(yīng)用以外,許多解決方案都受益于SGX 提供的安全保護(hù),包括多方計(jì)算[41]、機(jī)器學(xué)習(xí)[42,43]、區(qū)塊鏈[44-46]、人工智能和生物識(shí)別技術(shù)保護(hù)等.例如,文獻(xiàn)[44]介紹了一種基于SGX 區(qū)塊鏈資源挖掘框架REM(resource-efficient mining),REM 利用SGX 的安全保證實(shí)現(xiàn)了有效工作量證明(proof-ofuseful-work,簡(jiǎn)稱PoUW),以提供可信的工作負(fù)載報(bào)告.UCloud 引入了SGX 技術(shù),為智能合約提供了區(qū)塊鏈所不能提供的機(jī)密性,可拓展的計(jì)算節(jié)點(diǎn)也解決了區(qū)塊鏈本身無法應(yīng)對(duì)復(fù)雜應(yīng)用場(chǎng)景的問題.在保留區(qū)塊鏈去中心化、用戶互信的基礎(chǔ)之上,通過可信硬件執(zhí)行機(jī)密性高、需要相對(duì)復(fù)雜計(jì)算能力的程序,并通過區(qū)塊鏈對(duì)執(zhí)行結(jié)果進(jìn)行記錄和驗(yàn)證,實(shí)現(xiàn)可追溯的特性[96].Ekiden 同樣使用SGX 保證智能合約的機(jī)密性,并利用SGX 可信性提高區(qū)塊鏈的共識(shí)效率[47].螞蟻金服金融科技推出的可信計(jì)算云服務(wù)則是將螞蟻區(qū)塊鏈自主研發(fā)的虛擬機(jī)內(nèi)嵌在SGX 可信執(zhí)行環(huán)境中,在數(shù)據(jù)保密的通用鏈下能夠?qū)崿F(xiàn)智能合約[48].

SGX 技術(shù)目前被廣泛地應(yīng)用到各個(gè)領(lǐng)域,同時(shí),SGX 技術(shù)在應(yīng)用中也暴露了諸多瓶頸問題.如何解決SGX在應(yīng)用中的瓶頸問題,也成為學(xué)術(shù)界的研究熱點(diǎn).本文首先對(duì)目前SGX 技術(shù)相關(guān)應(yīng)用和研究工作進(jìn)行了梳理和總結(jié),將SGX 技術(shù)應(yīng)用的瓶頸總結(jié)為以下3 個(gè)方面.

? 應(yīng)用安全問題.SGX 在TCB 大小、enclave 接口等SGX 應(yīng)用程序設(shè)計(jì)方面存在諸多安全隱患,同時(shí)也面臨側(cè)信道攻擊、內(nèi)存攻擊和硬件攻擊等傳統(tǒng)的安全威脅;

? 應(yīng)用性能瓶頸.SGX 在內(nèi)存加密、執(zhí)行模式切換(包括ecall、ocall 和AEX)和內(nèi)存頁(yè)替換等方面存在高昂的性能開銷,這嚴(yán)重制約了SGX 的應(yīng)用和推廣;

? 應(yīng)用開發(fā)的困難性和功能的局限性.Intel 公司提供的SDK 雖然簡(jiǎn)化了SGX 的使用,但仍需程序員手動(dòng)地將應(yīng)用程序劃分為可信和不可信兩部分,不能直接無縫對(duì)接原有的應(yīng)用程序,導(dǎo)致SGX 應(yīng)用程序的開發(fā)工作量很大.SGX 提供了強(qiáng)大的安全功能,但對(duì)虛擬機(jī)遷移和容器等云平臺(tái)常用技術(shù)支持不足,難以滿足當(dāng)前云平臺(tái)應(yīng)用對(duì)SGX 的需求.

針對(duì)SGX 技術(shù)的上述應(yīng)用瓶頸問題,工業(yè)界和學(xué)術(shù)界進(jìn)行了具體的分析,并提出了相應(yīng)的解決方案.本文總結(jié)了相關(guān)文章,主要包括CCS、S&P、NDSS 等頂級(jí)會(huì)議,對(duì)這些工作進(jìn)行了總結(jié)和分類,見表1,主要可以分為三大類.

Table 1 Related researchs of SGX application supporting techniques表1 SGX 應(yīng)用支持技術(shù)相關(guān)研究工作

? 安全增強(qiáng):分析SGX 應(yīng)用存在的安全風(fēng)險(xiǎn)和面臨的安全威脅,并提出增強(qiáng)SGX 應(yīng)用安全性的相關(guān)方案.目前,SGX 應(yīng)用安全增強(qiáng)方案主要有TCB 最小化、對(duì)外接口最少化、敏感代碼安全生成與檢測(cè)和潛在安全威脅的分析與防護(hù)等;

? 性能優(yōu)化:分析SGX 性能開銷的原因,并提出相應(yīng)的性能優(yōu)化方案.目前,改進(jìn)SGX 應(yīng)用性能的解決方案主要包括減少模式切換(enclave 切換)開銷、減少頁(yè)替換開銷以及減少對(duì)enclave 內(nèi)存頁(yè)的使用和訪問等;

? 易用性改進(jìn):主要包括SGX 應(yīng)用輔助開發(fā)技術(shù)和功能擴(kuò)展技術(shù).應(yīng)用程序輔助開發(fā)技術(shù)主要包括安全開發(fā)語(yǔ)言、輔助開發(fā)工具以及通用系統(tǒng)庫(kù)和函數(shù)庫(kù)等;功能擴(kuò)展則主要包括對(duì)虛擬機(jī)遷移和容器等云平臺(tái)常用技術(shù)的支持方案等.

通過上述對(duì)SGX 應(yīng)用支持技術(shù)研究現(xiàn)狀的總結(jié)和分類,可以將SGX 應(yīng)用程序支持技術(shù)的目標(biāo)歸納為安全、性能和易用性這3 個(gè)方面.這3 個(gè)目標(biāo)不是相互獨(dú)立的,而是互相關(guān)聯(lián)和影響的,如TCB 大小就會(huì)關(guān)系到應(yīng)用的安全和性能.

本節(jié)首先介紹了SGX 技術(shù)的應(yīng)用研究現(xiàn)狀,分析了SGX 應(yīng)用中暴露出的安全性問題、性能瓶頸、開發(fā)困難、功能局限等諸多方面的問題,然后將SGX 應(yīng)用支持技術(shù)的研究方向概括為SGX 應(yīng)用安全增強(qiáng)技術(shù)、SGX應(yīng)用性能優(yōu)化技術(shù)、SGX 應(yīng)用程序輔助開發(fā)支持技術(shù)和SGX 應(yīng)用功能擴(kuò)展技術(shù)這4 個(gè)方向.本文第3 節(jié)～第6節(jié)將分別從這4 個(gè)方面進(jìn)行詳細(xì)的分析和總結(jié).

3 SGX 應(yīng)用安全防護(hù)技術(shù)

SGX 通過一系列技術(shù)來保護(hù)程序的安全,并且將系統(tǒng)的可信計(jì)算基縮小到CPU,相比以往將整個(gè)操作系統(tǒng)或特權(quán)軟件(如hypervisor)視為可信計(jì)算基,可以避免更多的系統(tǒng)攻擊帶來的危害.但是SGX 在實(shí)際應(yīng)用中依然會(huì)面臨諸多的安全風(fēng)險(xiǎn),如過大的TCB 和暴露過多的外部接口等.本文將SGX 應(yīng)用程序設(shè)計(jì)和開發(fā)時(shí)需要考慮的安全風(fēng)險(xiǎn)歸納為以下4 個(gè)方面.

? TCB 的大小.有研究[70,71]表明,軟件漏洞的數(shù)量以及潛在的安全漏洞會(huì)與代碼大小成比例地增加.盡可能地減小TCB,可以有效地減少enclave 內(nèi)部代碼漏洞潛在的安全風(fēng)險(xiǎn);

? 外部接口的多少.由于enclave 需要與不可信區(qū)域進(jìn)行交互,外部接口就成為不可信操作系統(tǒng)的攻擊面,控制主機(jī)操作系統(tǒng)的攻擊者可以使用此接口來破壞在enclave 內(nèi)運(yùn)行的進(jìn)程或者推測(cè)出敏感信息.因此,設(shè)計(jì)enclave 程序時(shí)需要考慮到該隱患;

? 開發(fā)的工作量和可靠性.SGX 程序開發(fā)最重要的是需要將代碼劃分為敏感和非敏感兩部分,SGX SDK目前不支持現(xiàn)有的應(yīng)用程序直接運(yùn)行在SGX 環(huán)境中,SGX 程序開發(fā)需要經(jīng)驗(yàn)和時(shí)間,并且不合理的敏感代碼劃分可能會(huì)破壞enclave 代碼的安全性.因此,開發(fā)時(shí)需要充分考慮敏感代碼劃分的工作量和可靠性;

? 面臨的安全威脅.有研究表明,SGX 面臨著側(cè)信道攻擊[9-11]、內(nèi)存攻擊[55,72]等多種攻擊的威脅.開發(fā)SGX 應(yīng)用程序時(shí)也需要考慮到這些安全威脅.比如,enclave 中的數(shù)據(jù)處理過程如果依賴于外部數(shù)據(jù),攻擊者可以通過一些不合法輸入,發(fā)起對(duì)enclave 的緩沖區(qū)溢出攻擊,這些攻擊可能會(huì)改變可信區(qū)中程序的執(zhí)行流程以及獲取可信區(qū)中的敏感信息.

針對(duì)SGX 目前在應(yīng)用中存在的上述安全問題,工業(yè)界和學(xué)術(shù)界提出了很多解決方案,本文對(duì)相關(guān)解決方案進(jìn)行了梳理和總結(jié),具體分類如下.

? TCB 最小化.SGX 應(yīng)用程序的TCB 由enclave 代碼和可信硬件組成.根據(jù)最小特權(quán)原則[73],只有應(yīng)用程序中需要訪問敏感數(shù)據(jù)的代碼才應(yīng)在enclave 內(nèi)執(zhí)行.最小化TCB,可以保證enclave 內(nèi)部代碼面臨盡可能少的威脅;

? 對(duì)外接口最少化.除了TCB 大小外,enclave 對(duì)外接口的復(fù)雜性同樣會(huì)影響enclave 內(nèi)部代碼和數(shù)據(jù)的安全性.減小enclave 和不可信操作系統(tǒng)之間的接口,可以減小暴露的攻擊面,從而減小攻擊者成功攻擊的可能性[70];

? 敏感代碼的安全生成與檢測(cè).利用自動(dòng)化的開發(fā)工具對(duì)SGX 應(yīng)用程序的代碼進(jìn)行自動(dòng)劃分,可以極大地減少開發(fā)人員的工作量;通過對(duì)enclave 代碼進(jìn)行安全檢測(cè),可以有效地增強(qiáng)敏感代碼的安全性;

? 潛在的安全威脅防護(hù).本文針對(duì)常見的潛在安全威脅進(jìn)行了分析和總結(jié),并給出了目前研究中已有的防護(hù)方案和相關(guān)的開發(fā)建議.

本節(jié)下面將對(duì)這4 類方案進(jìn)行詳細(xì)的介紹和分析.

3.1 TCB最小化

3.1.1 TCB 安全風(fēng)險(xiǎn)分析

本小節(jié)首先來分析TCB 大小對(duì)SGX 應(yīng)用程序安全性的影響.目前使用SGX 的應(yīng)用在TCB 中enclave 代碼部分的大小設(shè)計(jì)方面有3 種選擇.

? 預(yù)定義的少量專用敏感代碼:將盡可能少的代碼放入enclave 中,一般只將需要直接處理敏感數(shù)據(jù)的代碼放入enclave 中,如VC3[33],只將處理數(shù)據(jù)的map/reduce 函數(shù)放入enclave,而將其他不完全可信的平臺(tái)代碼排除在enclave 外,這樣可以避免平臺(tái)可能存在的安全漏洞威脅enclave 內(nèi)代碼和數(shù)據(jù)安全;

? 完整的應(yīng)用程序及其依賴的庫(kù):將應(yīng)用程序和enclave 內(nèi)程序運(yùn)行時(shí)所依賴的系統(tǒng)庫(kù)和函數(shù)庫(kù)等部署在enclave 內(nèi),如Haven[30]、SCONE[35]和Graphene[51]等系統(tǒng),采用的方案是,在enclave 內(nèi)部署函數(shù)庫(kù)或系統(tǒng)庫(kù)來支持執(zhí)行完整的應(yīng)用程序.安全敏感和不敏感的應(yīng)用程序代碼和數(shù)據(jù)都位于enclave 內(nèi),提高了性能,但從TCB 的角度來看,卻增加了enclave 內(nèi)部代碼和數(shù)據(jù)面臨的安全風(fēng)險(xiǎn);

? 從特定應(yīng)用中劃分出敏感代碼:將應(yīng)用程序中的敏感代碼劃分出來作為TCB,這里的敏感代碼除直接處理敏感數(shù)據(jù)的代碼外,還可能包括其他間接處理敏感數(shù)據(jù)的代碼以及與enclave 內(nèi)部代碼交互頻繁的代碼等.這類方案需要程序開發(fā)人員手動(dòng)劃分應(yīng)用程序,開發(fā)工作量大,并且劃分敏感代碼缺乏參考標(biāo)準(zhǔn),如果敏感代碼劃分得不夠合理,可能會(huì)破壞enclave 內(nèi)代碼和數(shù)據(jù)的安全性.

另外,目前SGX v1 版本支持的enclave 最大為128M(應(yīng)用程序?qū)嶋H能使用約93M),一旦TCB 大小超過93M,就會(huì)觸發(fā)頻繁的頁(yè)替換,增加了安全風(fēng)險(xiǎn)和性能開銷.SGX v2 有可能進(jìn)一步擴(kuò)展SGX 的可用物理內(nèi)存,但目前Intel 官方還未發(fā)布相關(guān)資料.

3.1.2 最小化TCB 的安全方案

最小特權(quán)原則下,應(yīng)該最小化TCB,從而減少enclave 內(nèi)部漏洞造成的威脅.最小化TCB 的相關(guān)安全方案一般僅把支持功能,或者敏感部分放入enclave.應(yīng)用程序必須遵守預(yù)定義的受限制的enclave 接口[21,33,49].這些工作的核心是使用SGX 提供的enclave 保證運(yùn)算的機(jī)密性,同時(shí)保證enclave 盡可能地小.

Schuster 等人提出的VC3 系統(tǒng)[33]就是采用了最小化TCB 的設(shè)計(jì)方案.VC3 使用分布式系統(tǒng)Hadoop[36]中計(jì)算節(jié)點(diǎn)提供的enclave 來保護(hù)map/reduce 任務(wù)的代碼和數(shù)據(jù),并嚴(yán)格限制map/reduc 任務(wù)僅通過特定的接口與不可信的環(huán)境進(jìn)行交互.VC3 將未經(jīng)修改的Hadoop 和操作系統(tǒng)均排除在TCB 之外,最小化了TCB,從而減少了enclave 內(nèi)部代碼和數(shù)據(jù)面臨的安全風(fēng)險(xiǎn).因此,即使Hadoop 和操作系統(tǒng)受到損害,也可以保證map/reduce 任務(wù)代碼和數(shù)據(jù)的機(jī)密性和完整性.并且,VC3 通過部署協(xié)議以保護(hù)分布式MapReduce 計(jì)算結(jié)果的安全性和可驗(yàn)證性.VC3 在TCB 最小的情況下,保證了數(shù)據(jù)和代碼的完整性和機(jī)密性,并保證了計(jì)算結(jié)果的可驗(yàn)證性,但是由于map/ reduce 任務(wù)只能通過特定的接口與不可信環(huán)境交互,因此其支持的功能非常有限.

Brenner 等人提出的保證所管理數(shù)據(jù)的隱私性和完整性的ZooKeeper[74]框架Securekeeper[21]同樣采用最小化TCB 的設(shè)計(jì)方案.SecureKeeper 系統(tǒng)通過設(shè)計(jì)所存儲(chǔ)數(shù)據(jù)的加解密方案和在enclave 中對(duì)所管理數(shù)據(jù)進(jìn)行處理的方式,將輕量修改的ZooKeeper 和操作系統(tǒng)排除在TCB 之外,將系統(tǒng)的TCB 保持在很小的水平,從而使在不可信環(huán)境下數(shù)據(jù)的隱私性和完整性得到了有效的保證.

Shinde 等人提出的PANOPLY 系統(tǒng)[49]旨在最小化SGX enclave 應(yīng)用程序TCB,同時(shí)又能為enclace 代碼提供豐富的操作系統(tǒng)抽象.PANOPLY 提出了一種稱為微容器(micro-container or micron)的新概念,微容器是運(yùn)行在enclave 中應(yīng)用程序的邏輯單元,微容器將標(biāo)準(zhǔn)的Linux 抽象提供給應(yīng)用程序.例如,除支持標(biāo)準(zhǔn)Linux 系統(tǒng)調(diào)用外,啟用微容器的應(yīng)用程序還可以使用多進(jìn)程、多線程、事件注冊(cè)/回調(diào)(例如信號(hào)).PANOPLY 可以將應(yīng)用程序分成一個(gè)或多個(gè)微容器,或者通過導(dǎo)入微容器庫(kù)來增強(qiáng)安全性,如圖5 所示.同時(shí),PANOPLY 保證enclave 間交互的完整性,確保即使操作系統(tǒng)出現(xiàn)異常,應(yīng)用程序的執(zhí)行也仍然遵循合法的控制和數(shù)據(jù)流.

PANOPLY 將最小化TCB 優(yōu)先于性能作為目標(biāo).與以前的系統(tǒng)(例如操作系統(tǒng)庫(kù)解決方案SGXKernel[50]、Graphene[51])不同,PANOPLY 使用了一種簡(jiǎn)單的委托而不是模擬的設(shè)計(jì)理念,將操作系統(tǒng)抽象的實(shí)現(xiàn)委托給底層操作系統(tǒng),而不是在enclave 內(nèi)進(jìn)行仿真.PANOPLY 微容器只需要通過執(zhí)行少量檢查來抵御操作系統(tǒng)的惡意響應(yīng).這種設(shè)計(jì)消除了在enclave 內(nèi)模擬基礎(chǔ)操作系統(tǒng)的大量工作.通過這種設(shè)計(jì),PANOPLY 提供的應(yīng)用程序TCB 比以前的操作系統(tǒng)庫(kù)系統(tǒng)的數(shù)量級(jí)小2 個(gè)數(shù)量級(jí).

Fig.5 Panoply system overview圖5 Panoply 系統(tǒng)概況

3.2 對(duì)外接口最少化

3.2.1 Enclave 接口的安全風(fēng)險(xiǎn)分析

由于enclave 處于用戶態(tài),自身無法執(zhí)行系統(tǒng)調(diào)用,需要與不可信區(qū)域進(jìn)行交互,enclave 必須向主機(jī)操作系統(tǒng)公開外部接口.外部接口則會(huì)成為不可信操作系統(tǒng)的攻擊面,控制主機(jī)操作系統(tǒng)的攻擊者可以使用此接口來破壞在enclave 內(nèi)運(yùn)行的進(jìn)程并推測(cè)敏感信息,增大了安全風(fēng)險(xiǎn)和性能開銷.如Iago 攻擊[75],這是來自不受信任的操作系統(tǒng)對(duì)應(yīng)用程序的語(yǔ)義攻擊,其中未經(jīng)檢查的系統(tǒng)調(diào)用返回值或許會(huì)影響應(yīng)用程序.Iago 攻擊難以進(jìn)行全面檢測(cè),至少對(duì)于當(dāng)前的可移植操作系統(tǒng)接口(portable operating system interface,簡(jiǎn)稱POSIX)[76]或Linux 系統(tǒng)調(diào)用表接口而言是這樣.因此,任何SGX 框架都必須提供隔離支持,以驗(yàn)證或拒絕來自不受信任的操作系統(tǒng)的輸入.接口復(fù)雜性直接影響隔離的復(fù)雜性,如操作系統(tǒng)庫(kù)或填充(shim)庫(kù)可以減小enclave 接口的數(shù)量和復(fù)雜性,從而降低Iago 攻擊成功的風(fēng)險(xiǎn).

總之,系統(tǒng)調(diào)用的返回值必須進(jìn)行檢查以防止Iago 攻擊.創(chuàng)建有原則的enclave 接口可以更容易地抵御特定攻擊.決定是否采用特定方案,使用enclave 保護(hù)應(yīng)用程序安全的重要判定原則是開發(fā)工作量及其是否適用于任何應(yīng)用程序.目前主要有3 種enclave 接口方案.如圖6 所示.

Fig.6 Design alternatives for the use of enclaves圖6 Enclave 設(shè)計(jì)選擇方案

? 完整的enclave 接口:在enclave 為應(yīng)用程序提供完整的系統(tǒng)庫(kù)支持,減少enclave 與不可信的系統(tǒng)之間的交互,如在enclave 提供庫(kù)支持.例如,Graphene[51]是在enclave 中使用一個(gè)操作系統(tǒng)庫(kù)來支持快速部署未修改的Linux 應(yīng)用程序;

? 預(yù)定義的enclave 接口:如圖6(b)所示,遵守預(yù)定義的受限制的enclave 接口.例如,VC3[33]強(qiáng)制map/reduce 任務(wù)僅通過特定的接口與不可信的環(huán)境進(jìn)行交互;

? 特定應(yīng)用程序的enclave 接口:如圖6(c)所示,針對(duì)特定的應(yīng)用程序劃分可信與不可信代碼,并設(shè)計(jì)相關(guān)的enclave 接口.該方案開發(fā)要求高、工作量大,且無法在應(yīng)用程序之間通用.

3.2.2 減少對(duì)外接口的安全解決方案

減少enclave 接口方案一般會(huì)在enclave 內(nèi)設(shè)置操作系統(tǒng)庫(kù)或者標(biāo)準(zhǔn)函數(shù)庫(kù)來支持enclave 內(nèi)應(yīng)用程序的執(zhí)行,從而減少enclave 內(nèi)代碼與操作系統(tǒng)之間的交互,例如Haven[30]、SGXKernel[50]、Graphene[51]和SCONE[35]等等.

Haven[30]使用Drawbridge[40]操作系統(tǒng)庫(kù)直接運(yùn)行未修改的Windows 應(yīng)用程序.Haven 基于drawbridge 沙箱機(jī)制,為用戶程序的運(yùn)行提供了一個(gè)微處理(picoprocess)容器,從而保證運(yùn)行在里面的用戶程序無法對(duì)外界系統(tǒng)造成破壞;再在容器中創(chuàng)建一個(gè)enclave,將用戶程序、系統(tǒng)庫(kù)和防護(hù)模塊(shield module)放進(jìn)enclave 中,以防止這些數(shù)據(jù)和代碼被外界的特權(quán)軟件或惡意程序所訪問和篡改.系統(tǒng)庫(kù)通過向下調(diào)用(downcalls)和向上調(diào)用(upcalls)的方式與drawbridge 主機(jī)進(jìn)行交互,用來完成用戶程序需要的系統(tǒng)功能,防護(hù)模塊配合檢查函數(shù)的參數(shù)和返回結(jié)果,進(jìn)而保護(hù)用戶程序的安全執(zhí)行.

Graphene[51]則是在enclave 中部署一個(gè)操作系統(tǒng)庫(kù)來支持在SGX 上快速部署未修改的Linux 應(yīng)用程序.Graphene 為SGX 提供了一個(gè)端口以及一些SGX 改進(jìn)措施,例如動(dòng)態(tài)加載庫(kù)(dynamically-loaded libraries)的完整性支持和安全多進(jìn)程(secure multi-process)支持.Graphene 開銷與使用填充層(shim library)的應(yīng)用程序相近,大多數(shù)單進(jìn)程應(yīng)用的性能開銷小于2 倍,Graphene 目前已經(jīng)開源.SGXKernel[50]也是在enclave 內(nèi)實(shí)現(xiàn)了一個(gè)操作系統(tǒng)庫(kù),通過結(jié)合異步交叉enclave 通信和可搶占的enclave 多線程避免enclave 切換,其性能明顯優(yōu)于Haven和Graphene.SCONE[35]則是在enclave 中配置了標(biāo)準(zhǔn)C 函數(shù)庫(kù)的修改版本來支持重新編譯的Linux 應(yīng)用程序.

文獻(xiàn)[64]在enclave 接口的安全設(shè)計(jì)方面給出了3 個(gè)建議.

(1)SDK 允許將ecall 定義為公有或私有[16]:公有ecall 可以隨時(shí)被調(diào)用,而私有ecall 只能在ocall 中被調(diào)用.將ecall 定義為私有可以限制調(diào)用ecall 的途徑來增強(qiáng)enclave 的安全性;

(2)開發(fā)人員必須精確指定每個(gè)ocall 中允許哪些ecall 調(diào)用.如果沒有指定特定的ecall,則在執(zhí)行期間會(huì)觸發(fā)錯(cuò)誤.如果開發(fā)人員未考慮特定的ecall/ocall 組合,則攻擊者可能會(huì)利用它來更改程序執(zhí)行的控制流并獲得對(duì)特定機(jī)密的訪問權(quán)限;

(3)EDL 文件定義了作為ecall 和ocall 參數(shù)傳遞的指針的行為,其中,user_check 標(biāo)明是否將指針留給開發(fā)人員.然而,user_check 可能帶來安全漏洞,例如緩沖區(qū)溢出、time-of-check-to-time-of-use 攻擊[77]或傳遞enclave 內(nèi)地址[78].因此,在進(jìn)行enclave 接口設(shè)計(jì)時(shí),需要檢查并限制指針如何在enclave 接口中傳遞和使用.

3.3 敏感代碼的自動(dòng)化生成與安全檢測(cè)

SGX 應(yīng)用程序開發(fā)的關(guān)鍵是將應(yīng)用程序劃分為敏感代碼與非敏感代碼兩部分,到底將哪些代碼作為敏感代碼放入enclave 中目前還缺乏標(biāo)準(zhǔn)化的方法,并且劃分的敏感代碼是否安全和合理也缺乏相應(yīng)的驗(yàn)證方法.總的來說,SGX 應(yīng)用程序開發(fā)所面臨的困難主要有以下3 個(gè)方面.

? 開發(fā)工作量大:針對(duì)每一個(gè)應(yīng)用程序進(jìn)行開發(fā),不僅需要開發(fā)人員具備豐富的開發(fā)經(jīng)驗(yàn)和安全背景,同時(shí)也需要進(jìn)行大量的開發(fā)工作;

? 通用性:目前需要開發(fā)人員針對(duì)每一個(gè)應(yīng)用程序進(jìn)行手動(dòng)劃分,缺乏通用性的解決方案.當(dāng)前,SGX SDK 沒有提供相關(guān)支持;

? 敏感代碼劃分的合理性和安全性:劃分的敏感代碼需要進(jìn)行安全性和合理性驗(yàn)證,以確認(rèn)劃分出的敏感代碼是否存在安全漏洞.

因此,如何對(duì)enclave 的敏感代碼進(jìn)行自動(dòng)化劃分且保證劃分結(jié)果的可靠性,是SGX 應(yīng)用程序開發(fā)需要解決的問題.目前,相關(guān)工作分別實(shí)現(xiàn)了對(duì)程序敏感代碼的自動(dòng)化劃分和對(duì)enclave 代碼的安全檢查等.

3.3.1 敏感代碼自動(dòng)劃分技術(shù)

文獻(xiàn)[52]提出了一個(gè)用于開發(fā)C 語(yǔ)言SGX 應(yīng)用程序的源碼劃分框架Glamdring.通過開發(fā)人員對(duì)安全敏感應(yīng)用程序數(shù)據(jù)的注釋,Glamdring 可以自動(dòng)地將應(yīng)用程序劃分為可信和不可信代碼兩部分,如圖 7 所示,Glamdring 的操作分為4 步.

(1)代碼注釋:開發(fā)人員通過注釋需要機(jī)密性和完整性保護(hù)的變量來提供有關(guān)安全敏感數(shù)據(jù)的輸入和輸出信息;

(2)代碼分析:Glamdring 基于帶注釋的源代碼,使用數(shù)據(jù)流分析來識(shí)別可能處理敏感數(shù)據(jù)的函數(shù),并使用向后切片來識(shí)別可能會(huì)間接影響敏感數(shù)據(jù)的函數(shù).將直接或者間接訪問或者影響敏感數(shù)據(jù)的代碼標(biāo)記為敏感代碼.因此,Glamdring 獲得了處理敏感數(shù)據(jù)或影響其完整性的最小代碼集;

(3)代碼劃分:接下來,Glamdring 創(chuàng)建一個(gè)劃分規(guī)范(partition specification,簡(jiǎn)稱PS),該規(guī)范定義了必須由enclave 保護(hù)的代碼.PS 會(huì)根據(jù)程序分析枚舉敏感的函數(shù)、內(nèi)存分配和全局變量;

(4)代碼生成:Glamdring 使用源到源編譯器(source-to-source compiler)基于PS 將代碼分為敏感和非敏感的代碼,然后將敏感代碼放置在enclave 內(nèi),并在enclave 邊界自動(dòng)添加運(yùn)行時(shí)檢查和加密操作,以保護(hù)其免受攻擊.

Fig.7 Overview of the Glamdring framework圖7 Glamdring 架構(gòu)

Glamdring 保護(hù)了敏感輸入數(shù)據(jù)的機(jī)密性和敏感輸出數(shù)據(jù)的完整性,基于最小特權(quán)原則,最小化訪問敏感數(shù)據(jù)的代碼,自動(dòng)更改應(yīng)用程序代碼,極大地減少了程序開發(fā)人員的開發(fā)工作量,增強(qiáng)了SGX 的易用性.Liu 等人則在其源碼自動(dòng)劃分方案PtrSplit[79]中,提出了一系列支持全局指針的方法.

3.3.2 Enclave 代碼安全檢測(cè)技術(shù)

SGX 可以為enclave 內(nèi)部代碼和數(shù)據(jù)提供機(jī)密性和完整性保護(hù),以抵御來自enclave 外部的攻擊.但是enclave 代碼本身的漏洞也可能會(huì)泄露機(jī)密,例如enclave 可能受到Heartbleed[80]之類的攻擊,這些攻擊已被證明會(huì)從內(nèi)存中泄露秘密密鑰.開發(fā)人員也必須采取必要的措施來抵御協(xié)議和應(yīng)用程序攻擊,包括正確使用SGX 指令、使用安全的加密協(xié)議、避免由于違反內(nèi)存安全性而造成錯(cuò)誤等.

文獻(xiàn)[53]開發(fā)了一個(gè)靜態(tài)enclave 代碼安全性驗(yàn)證工具M(jìn)oat,用以驗(yàn)證enclave 代碼是否滿足機(jī)密性要求,即是否存在將秘密泄露給敵手可見的非enclave 內(nèi)存的代碼.Moat 分析了enclave 二進(jìn)制代碼的指令級(jí)行為,采用信息流敏感類型檢查算法自動(dòng)驗(yàn)證enclave 程序是否提供機(jī)密性保證.對(duì)于類型錯(cuò)誤的程序,Moat 會(huì)利用漏洞程序證明機(jī)密可能會(huì)泄露給非enclave 內(nèi)存.Moat 為程序員編寫安全的enclave 提供了驗(yàn)證方法和工具支持.

3.4 潛在安全威脅的分析與防護(hù)

SGX 原則上能夠提供安全的隔離計(jì)算環(huán)境,但實(shí)際上同樣面臨各種各樣的安全威脅,比如側(cè)信道攻擊、內(nèi)存攻擊和回放攻擊等.當(dāng)前,學(xué)術(shù)界的相關(guān)工作也已經(jīng)進(jìn)行了證實(shí)[9-11,77].針對(duì)每類攻擊,相關(guān)研究工作提出了一系列防御措施,但目前仍缺少通用的解決方案.因此,需要SGX 應(yīng)用開發(fā)人員在開發(fā)SGX 應(yīng)用程序時(shí)充分考慮相關(guān)的安全威脅,并采取一定的防御措施.

3.4.1 側(cè)信道攻擊和防護(hù)方案

SGX 面臨的最大威脅是側(cè)信道攻擊.側(cè)信道攻擊的主要手段是通過攻擊面獲取數(shù)據(jù),推導(dǎo)獲得控制流和數(shù)據(jù)流信息,最終獲取enclave 的代碼和數(shù)據(jù)的信息,比如加密密鑰、隱私數(shù)據(jù)等.Wang 等人對(duì)相關(guān)的SGX 側(cè)信道攻擊進(jìn)行了詳細(xì)的分析和總結(jié)[19].本文只介紹典型的攻擊面,包括頁(yè)表、緩存(cache)以及CPU 內(nèi)部結(jié)構(gòu),這幾種側(cè)信道攻擊的方式如下.

? 基于頁(yè)表的攻擊:利用頁(yè)表對(duì)enclave 頁(yè)面的訪問控制權(quán),設(shè)置enclave 頁(yè)面為不可訪問.之后,任何訪問都會(huì)觸發(fā)缺頁(yè)異常,從而能夠區(qū)分enclave 訪問了哪些頁(yè)面.按照時(shí)間順序把這些信息組合,就能夠反推出enclave 的某些狀態(tài)和保護(hù)的數(shù)據(jù).該類攻擊包括controlled-channel 攻擊[10]和pigeonhole 攻擊[11]等;

? 基于Cache 的攻擊.在SGX 環(huán)境中,大部分基于Cache 的側(cè)信道技術(shù)仍然適用,例如文獻(xiàn)[81]證明,SGX易受Cache-timing 攻擊;

? 基于CPU 內(nèi)部結(jié)構(gòu)的攻擊.CPU 內(nèi)部有大量的結(jié)構(gòu)是在enclave 和非enclave 之間共用的,這就給側(cè)信道攻擊提供了大量的攻擊面,例如文獻(xiàn)[82]實(shí)現(xiàn)的側(cè)信道攻擊.

這些側(cè)信道攻擊有的需要從SGX 設(shè)計(jì)的角度來解決,有的則可以在應(yīng)用程序內(nèi)部進(jìn)行解決.更加合理地設(shè)計(jì)應(yīng)用程序,可以減少攻擊者能夠收集的有效信息,極大地降低攻擊者成功攻擊的幾率.SGX 現(xiàn)有的部分側(cè)信道防御方法可以按照不同層次進(jìn)行分類,主要包括:

? 軟件層:應(yīng)用程序可以進(jìn)行自我防御,通過合理地設(shè)計(jì)應(yīng)用程序,避免泄露過多的差異信息,使得攻擊者難以成功.例如:像Opaque[34]等分析平臺(tái)通過內(nèi)部混淆讓攻擊者無法獲取相關(guān)的差異信息,有效地保護(hù)了enclave 內(nèi)部數(shù)據(jù)的安全性;Chandra 等人提出的方案[42]在訓(xùn)練機(jī)器學(xué)習(xí)模型時(shí)充分考慮到了側(cè)信道攻擊,將決策樹的數(shù)據(jù)結(jié)構(gòu)進(jìn)行重新設(shè)計(jì),保證敵手無法觀察到差異信息,以避免應(yīng)用程序泄露相關(guān)模型信息;ORAM[83]技術(shù)同樣通過無差別的訪問等方法避免泄露差異信息,從而有效地抵御SGX 面臨的側(cè)信道攻擊,但是目前在性能方面仍然需要加以提高;

? 硬件層:通過優(yōu)化SGX 硬件設(shè)計(jì),可以避免某些側(cè)信道攻擊.例如,在enclave 的切換過程中,CPU 清除共用的內(nèi)部結(jié)構(gòu)體信息,避免非enclave 得到任何殘留記錄.同時(shí)還要注意一些細(xì)節(jié),比如清除的時(shí)間也必須是穩(wěn)定不變的[82].硬件層為每個(gè)enclave 隔離出一個(gè)cache,也是側(cè)信道攻擊的解決方案之一,雖然文獻(xiàn)[84]已經(jīng)進(jìn)行了一些嘗試,但仍然還未能徹底解決該問題.

3.4.2 內(nèi)存攻擊和防護(hù)方案

基于SGX 的隔離執(zhí)行,為應(yīng)用程序在不可信平臺(tái)上的運(yùn)行提供了強(qiáng)大的安全保障.但是隔離執(zhí)行不能保護(hù)程序免受內(nèi)存攻擊[72],這些攻擊很普遍,特別是用非安全語(yǔ)言(如C/C++)編寫的應(yīng)用程序.例如,Heartbleed[80]之類的內(nèi)存安全攻擊可能會(huì)使隔離執(zhí)行的機(jī)密性和完整性保障完全失效.遠(yuǎn)程攻擊者可以通過利用現(xiàn)有的程序漏洞來調(diào)用越界內(nèi)存訪問,以破壞內(nèi)存安全性.然后,攻擊者可以劫持程序控制流程或泄露機(jī)密數(shù)據(jù)[85].

所有內(nèi)存攻擊的基礎(chǔ)條件是能夠訪問禁止訪問的內(nèi)存區(qū)域,因此,可以通過邊界檢查技術(shù)[86]限制enclave 程序可訪問的內(nèi)存范圍.具體地,為每個(gè)分配對(duì)象的邊界維護(hù)數(shù)據(jù)結(jié)構(gòu)用于邊界檢查,確認(rèn)指針是否仍在邊界范圍內(nèi).但是該數(shù)據(jù)結(jié)構(gòu)可能會(huì)變得很大,并且查找成本很高.文獻(xiàn)[55]基于SGX設(shè)計(jì)了一種用于enclave 的高效邊界檢查技術(shù),可有效抵御來自于enclave 內(nèi)部漏洞的威脅,并且結(jié)合標(biāo)記指針和緊湊內(nèi)存布局來提高性能.

3.5 小結(jié)

本節(jié)總結(jié)的以上4 種SGX 應(yīng)用安全防護(hù)技術(shù)概括了目前常見的SGX 應(yīng)用安全增強(qiáng)方案,為了更加直觀地表述每一種技術(shù)的優(yōu)缺點(diǎn)和性能,本小節(jié)給出如下總結(jié)(見表2).通過分析這4 種常見的SGX 應(yīng)用安全增強(qiáng)技術(shù)的方案與優(yōu)劣性,可以將這4 種技術(shù)的研究總結(jié)為以下3 個(gè)方面.

? 最小化TCB 和最少化對(duì)外接口,都可以降低SGX 應(yīng)用面臨的安全風(fēng)險(xiǎn).但是兩者之間存在一定的沖突,例如,要最小化TCB 就難以提供enclave 內(nèi)部豐富的系統(tǒng)調(diào)用支持,難以做到最少化對(duì)外接口.目前缺少能夠自動(dòng)平衡TCB 大小和對(duì)外接口的開發(fā)工具,主要還是依賴程序員的開發(fā)經(jīng)驗(yàn)來設(shè)計(jì)TCB 和enclave 接口.同樣,也缺乏能夠兼顧兩個(gè)方面的安全增強(qiáng)方案;

? 敏感代碼自動(dòng)劃分工具能夠減少程序員的工作量,但其劃分結(jié)果的準(zhǔn)確性和可靠性難以驗(yàn)證,而且目前也缺乏普遍認(rèn)可的劃分標(biāo)準(zhǔn).如何更準(zhǔn)確、更可靠和更細(xì)粒度地自動(dòng)劃分應(yīng)用程序,是需要實(shí)現(xiàn)的目標(biāo);

? 開發(fā)人員設(shè)計(jì)SGX 應(yīng)用程序時(shí)應(yīng)該充分考慮到側(cè)信道攻擊等未知安全威脅,根據(jù)不同的場(chǎng)景進(jìn)行相應(yīng)調(diào)整,以抵御可能面臨的安全威脅.這需要開發(fā)人員具有足夠的安全知識(shí),當(dāng)前還缺乏自動(dòng)化支持工具以輔助開發(fā)人員實(shí)現(xiàn)對(duì)潛在安全威脅的抵御.

Table 2 Security enhancement solutions of SGX application表2 SGX 應(yīng)用安全增強(qiáng)方案

4 SGX 應(yīng)用性能優(yōu)化技術(shù)

SGX 性能一直是學(xué)術(shù)界和工業(yè)界關(guān)注和研究的重要方向之一,也是制約SGX 應(yīng)用的重要因素.對(duì)SGX 性能進(jìn)行優(yōu)化是必不可少的.相關(guān)研究[21,35,56-58]分析了SGX 潛在的性能問題,并提出了多種技術(shù)來優(yōu)化SGX 性能.本文總結(jié)了優(yōu)化SGX 性能相關(guān)的研究工作,將SGX 性能開銷的問題和相關(guān)原因概括為以下幾個(gè)方面.

? 模式切換開銷.模式切換即enclave 切換,原因主要包括ecall、ocall 和AEX.模式切換出于安全原因,必須執(zhí)行一系列檢查和更新,包括TLB(translation lookaside buffer)刷新,基于內(nèi)存的enclave 參數(shù)也必須在可信和不可信的內(nèi)存之間進(jìn)行復(fù)制,從而導(dǎo)致模式切換需要付出高昂的代價(jià);

? Enclave 頁(yè)替換開銷.內(nèi)存要求超過EPC 大小的應(yīng)用程序必須在EPC 和未受保護(hù)的內(nèi)存之間替換頁(yè)面.EPC 頁(yè)換出的代價(jià)高昂,因?yàn)樗鼈儽仨氃诒粡?fù)制到外部?jī)?nèi)存之前被加密并得到完整性保護(hù).為了防止地址轉(zhuǎn)換攻擊,替換協(xié)議中斷所有enclave 線程并刷新TLB.并且,頁(yè)替換同樣會(huì)導(dǎo)致enclave 模式的切換.在enclave 執(zhí)行期間的頁(yè)替換,由于額外的轉(zhuǎn)換和加密操作而開銷巨大;

? 內(nèi)存加密開銷.由于MEE 必須加密和解密高速緩存線,會(huì)導(dǎo)致加密內(nèi)存訪問存在高昂的開銷,enclave代碼也會(huì)由于寫入內(nèi)存和高速緩存未命中而產(chǎn)生開銷.

針對(duì)上述開銷原因,相應(yīng)地,本文將目前SGX 性能優(yōu)化方案也總結(jié)為3 種技術(shù)——模式切換性能優(yōu)化技術(shù)、內(nèi)存頁(yè)替換優(yōu)化技術(shù)和內(nèi)存加密優(yōu)化技術(shù).

? 模式切換開銷優(yōu)化技術(shù).模式切換需要付出高昂的代價(jià),因此應(yīng)盡量避免模式切換,可以通過異步調(diào)用[56-58]來加以避免;

? 頁(yè)替換開銷優(yōu)化技術(shù).頁(yè)替換的開銷很大,應(yīng)盡量避免頁(yè)替換,可以通過多種技術(shù)來減少頁(yè)替換.如盡量將enclave 保持得較小,通過EPC 頁(yè)面預(yù)加載以避免enclave 內(nèi)部發(fā)生頁(yè)錯(cuò)誤,在enclave 內(nèi)部使用替換的內(nèi)存管理機(jī)制,如STANlite[20]和Eleos[58];

? 內(nèi)存加密開銷優(yōu)化技術(shù).內(nèi)存加密開銷是因SGX 的內(nèi)存加密保護(hù)機(jī)制所致,可以通過減少對(duì)enclave內(nèi)存的不必要使用、使用節(jié)省空間的數(shù)據(jù)結(jié)構(gòu)或?qū)⑤^小的數(shù)據(jù)塊加載到enclave 來進(jìn)行優(yōu)化.

4.1 模式切換性能優(yōu)化技術(shù)

模式切換是SGX 能夠在enclave 中執(zhí)行代碼的基本保障機(jī)制,但是模式切換也是SGX 應(yīng)用程序性能開銷的主要原因,尤其是對(duì)于系統(tǒng)調(diào)用密集型SGX 應(yīng)用程序而言,導(dǎo)致的開銷會(huì)達(dá)到幾倍、幾十倍甚至上百倍.只要CPU 進(jìn)入或退出enclave,就會(huì)發(fā)生模式切換.模式切換開銷的主要原因是復(fù)雜的狀態(tài)保存和安全檢查、保存和恢復(fù)CPU 狀態(tài)以及由刷新TLB 引起的TLB 緩存未命中.

SGX SDK[16]提供的用于進(jìn)行跨enclave 函數(shù)調(diào)用的標(biāo)準(zhǔn)方法ecall 和ocall 都會(huì)觸發(fā)enclave 上下文切換.文獻(xiàn)[35,44,50]分別對(duì)SGX 的ecall 和ocall 的性能開銷進(jìn)行了評(píng)測(cè).任何ecall 和ocall 都會(huì)導(dǎo)致性能開銷,因?yàn)橛布仨殘?zhí)行某些操作來維護(hù)SGX 的安全保障.Enclave 代碼還必須驗(yàn)證所訪問數(shù)據(jù)的完整性,例如ecall 的參數(shù)、ocall 的返回值和從不可信內(nèi)存讀取的數(shù)據(jù).本文對(duì)評(píng)測(cè)結(jié)果進(jìn)行了總結(jié),具體見表3.從表中總結(jié)結(jié)果來看,直接使用SGX SDK 的邊緣函數(shù)性能開銷高達(dá)8 000 到17 000 個(gè)時(shí)鐘周期(CPU cycle).Ecall 的開銷大約為8 000個(gè)時(shí)鐘周期,ocall 的開銷大約為10 000 個(gè)時(shí)鐘周期,這相比于系統(tǒng)調(diào)用150 個(gè)時(shí)鐘周期來說是非常高的.因此,減少模式切換導(dǎo)致的開銷變得非常重要.目前,避免或降低模式切換的技術(shù)主要有通過共享內(nèi)存和專用線程避免切換、增加庫(kù)操作系統(tǒng)來減少切換操作以及合理地設(shè)計(jì)enclave 接口.

Table 3 SGX ecall and ocall performance evaluation表3 SGX ecall 和ocall 性能測(cè)試

文獻(xiàn)[64]則在3 種設(shè)置中直接測(cè)量了EENTER 和EEXIT 指令的時(shí)間開銷:(1)在未修改的支持SGX 的處理器上,使用一個(gè)熱高速緩存(warm cache)進(jìn)行了一次往返,測(cè)得的切換時(shí)間約為5 850 個(gè)時(shí)鐘周期(約為2 130ns);(2)SDK 更新修復(fù)Spectre[87]漏洞補(bǔ)丁(patchs)后(該漏洞影響了SGX[88]),測(cè)得的切換時(shí)間約為10 170個(gè)時(shí)鐘周期(約為3 850ns),是沒有補(bǔ)丁情況下切換時(shí)間的1.74 倍;(3)更新修復(fù)Foreshadow[89]漏洞的補(bǔ)丁后,在同時(shí)抵御Spectre 和Foreshadow 漏洞的情況下,enclave 切換變得更加緩慢,約為13 100 個(gè)時(shí)鐘周期(約4 890ns),約2.24 倍,這些測(cè)試結(jié)果進(jìn)一步說明了避免模式切換的必要性.

4.1.1 無切換調(diào)用

為了最大限度地降低模式切換帶來的性能損失,文獻(xiàn)[35,56-58]分別提出了解決方案,這些方案具有相同的核心思想:調(diào)用線程將ecall/ocall 的請(qǐng)求發(fā)送到共享的不可信緩沖區(qū),工作線程則從該緩沖區(qū)異步接收和處理請(qǐng)求.由于采用這種方式調(diào)用eall/ocall 不會(huì)觸發(fā)模式切換,故稱為無切換調(diào)用(switchless calls)[57].如文獻(xiàn)[56]提出一個(gè)由請(qǐng)求者和響應(yīng)者組成的體系結(jié)構(gòu)HotCalls,通過未加密共享內(nèi)存進(jìn)行通信,采用同步自旋鎖機(jī)制,相比于SGX 默認(rèn)的接口加速13～27 倍.

Eleos[58]則采用遠(yuǎn)程過程調(diào)用(remote procedure call,簡(jiǎn)稱RPC)的方式處理系統(tǒng)調(diào)用,RPC 機(jī)制允許在不退出enclave 的情況下,將調(diào)用阻塞到不可信代碼中執(zhí)行,實(shí)際調(diào)用被委托給工作線程,該工作線程在enclave 所有者進(jìn)程的不可信內(nèi)存區(qū)域中執(zhí)行.由于enclave 可執(zhí)行多個(gè)線程,因此,Eleos 維護(hù)一個(gè)具有多個(gè)工作線程的線程池,通過位于不可信內(nèi)存中的共享作業(yè)隊(duì)列與enclave 交互.線程池中的線程輪詢隊(duì)列,調(diào)用請(qǐng)求的函數(shù),并通過不可信的共享緩沖區(qū)傳回結(jié)果.因?yàn)閑nclave 的線程不能使用互斥等標(biāo)準(zhǔn)的OS 同步原語(yǔ),可信和不可信上下文之間的同步是通過輪詢執(zhí)行的.為了降低輪詢成本,Eleos 通過簡(jiǎn)單的ocall 機(jī)制調(diào)用長(zhǎng)時(shí)間運(yùn)行的系統(tǒng)調(diào)用.

上述通過使用共享內(nèi)存作為通信信道和專門設(shè)置線程輪詢消息的方案被證明是有效的,但是這種無切換調(diào)用技術(shù)在效率方面存在疑問,用額外的CPU 內(nèi)核來減少模式切換未必總是合理的.無切換調(diào)用必須由工作線程執(zhí)行,因此需要額外的CPU 內(nèi)核.實(shí)現(xiàn)的加速比隨著工作量的減少而減小.在幾乎空閑的工作負(fù)載的極端情況下,使用的額外CPU 內(nèi)核顯然是浪費(fèi)資源的.文獻(xiàn)[56]建議:如果工作線程長(zhǎng)時(shí)間沒有收到任何請(qǐng)求,則將其置于休眠狀態(tài).但是,可能存在請(qǐng)求稀疏卻不足以觸發(fā)超時(shí)睡眠的情況;并且,是否喚醒休眠工作線程處理一個(gè)或兩個(gè)請(qǐng)求然后再次睡眠也存在疑問,這種情況下,浪費(fèi)CPU 問題變得更加嚴(yán)重.工作線程使用額外CPU 核心可能已用于為同臺(tái)機(jī)器上其他應(yīng)用程序的線程.由于上述原因,enclave 應(yīng)用程序會(huì)遇到各種動(dòng)態(tài)工作負(fù)載,是否采用無切換調(diào)用則需要進(jìn)一步加以分析.

Intel 的研究團(tuán)隊(duì)將無切換調(diào)用作為一種實(shí)用技術(shù),確保它能夠有效地提高性能[57].通過數(shù)學(xué)和模擬分析建立性能模型,研究無切換調(diào)用可以有效提高性能的條件,并設(shè)計(jì)了一種基于效率的調(diào)度算法,該算法可以自動(dòng)調(diào)整工作線程數(shù)量以響應(yīng)不斷變化的工作量.Intel 公司目前已將無切換調(diào)用及其優(yōu)化算法集成到SDK,從SDK 2.2 開始,正式提供這一功能.

4.1.2 增加操作系統(tǒng)庫(kù)/函數(shù)庫(kù)減少模式切換

SGX 提供了強(qiáng)大的安全保證,但SGX 的一個(gè)限制是enclave 內(nèi)缺乏系統(tǒng)調(diào)用支持,這導(dǎo)致SGX 在性能方面并不理想.為解決這一問題,Haven[30]、SGXKernel[50]和Graphene[51]通過提供用于enclave 執(zhí)行的兼容層,為SGX內(nèi)部的應(yīng)用程序提供操作系統(tǒng)庫(kù)支持,無需修改應(yīng)用程序代碼.

SGXKernel[50]在enclave 內(nèi)部提供了一個(gè)操作系統(tǒng)庫(kù),從而可以減少enclave 切換,使應(yīng)用程序不再需要進(jìn)行頻繁的模式切換.這種減少模式切換的設(shè)計(jì)是通過結(jié)合兩個(gè)設(shè)計(jì)實(shí)現(xiàn)的:即異步進(jìn)行enclave 通信和可搶占的enclave 內(nèi)部多線程.Graphene[51]除了提供一個(gè)操作系統(tǒng)庫(kù)支持之外,還提供了一些使SGX 更加可用的改進(jìn)措施,例如動(dòng)態(tài)加載庫(kù)的完整性支持以及安全的多進(jìn)程支持,有效地減少了模式切換.

4.1.3 輕量級(jí)細(xì)粒度的并行減少enclave 之間模式轉(zhuǎn)換

文獻(xiàn)[60]提出了一個(gè)針對(duì)SGX 的框架EActors,提出新的概念actor,實(shí)現(xiàn)輕量級(jí)細(xì)粒度的并行,從而避免了SGX SDK 提供的同步功能的高開銷問題,解決了enclave 內(nèi)部和多個(gè)enclave 之間執(zhí)行模式轉(zhuǎn)換的高開銷問題.最后,EActors 提供了基于安全和性能要求的高度選擇自由來執(zhí)行可信或不可信的actor.性能評(píng)估結(jié)果表明:基于EActors 實(shí)現(xiàn)的安全消息傳遞服務(wù)與基于SGX SDK 實(shí)現(xiàn)的版本性能提高了40 倍,EActor 可以更加無縫、靈活和高效地使用SGX,特別是對(duì)于需要多個(gè)enclave 的應(yīng)用程序.

4.2 內(nèi)存頁(yè)替換開銷優(yōu)化技術(shù)

Enclave 性能開銷高的另一個(gè)重要原因是enclave 內(nèi)存空間比較小,尤其是應(yīng)用程序本身可用工作空間比較小.Enclave 所在的EPC 大小有限,當(dāng)前SGX v1 最大可設(shè)置為128M,實(shí)際約93M 可供應(yīng)用程序使用,其他空間用于存儲(chǔ)完整性保護(hù)的元數(shù)據(jù)[7].SGX 支持從EPC 到主內(nèi)存的頁(yè)替換,以滿足不適合EPC 的enclave.當(dāng)程序代碼數(shù)量和規(guī)模增大時(shí),敏感頁(yè)面會(huì)在內(nèi)存中的EPC 和非EPC 區(qū)域之間頻繁交換.Enclave 執(zhí)行期間的頁(yè)替換開銷巨大(約4 萬時(shí)鐘周期),因?yàn)樗枰M(jìn)行系統(tǒng)調(diào)用、頁(yè)面復(fù)制、完整性樹和元數(shù)據(jù)的更新等.文獻(xiàn)[59]分析表明:頁(yè)替換開銷使系統(tǒng)平均減慢5 倍,內(nèi)存密集型應(yīng)用的速度更慢,對(duì)enclave 的性能有很大影響[21,35].

頁(yè)替換會(huì)導(dǎo)致過高的性能開銷,因此,enclave 設(shè)計(jì)應(yīng)盡可能地避免遇到頁(yè)替換.本文分析了頁(yè)替換開銷的原因以及相關(guān)的解決方案,具體如下.

? Enclave 太大可能是由于內(nèi)部的數(shù)據(jù)集太大或數(shù)據(jù)處理不當(dāng)所致.保持enclave 較小以始終適合EPC,可以避免發(fā)生頁(yè)替換,如通過使用節(jié)省空間的數(shù)據(jù)結(jié)構(gòu)或?qū)⑤^小的數(shù)據(jù)塊加載到enclave 來實(shí)現(xiàn).但是EPC 在所有運(yùn)行的enclave 之間共享,很難確定enclave 大小是否合適,因?yàn)镋PC 可能已被其他enclave阻塞,從而無法避免頁(yè)替換,尤其是在多租戶的云平臺(tái)中;

? EPC 空間太小的問題也可以通過增加EPC 大小和增加并發(fā)線程來加以解決.鑒于大量的頁(yè)替換開銷,可以讓EPC 更大以提高其命中率.如直接提供更大的EPC 空間或支持創(chuàng)建enclave 后再進(jìn)行擴(kuò)展[90],VAULT[59]提供了支持EPC 擴(kuò)展的數(shù)據(jù)結(jié)構(gòu)支持,但enclave 超出EPC 大小仍然會(huì)導(dǎo)致頁(yè)替換;

? 在enclave 內(nèi)使用替換的內(nèi)存管理機(jī)制,取代SGX 采用的系統(tǒng)內(nèi)存管理機(jī)制.例如,STANlite[20]和Eleos[58],這些系統(tǒng)在enclave 內(nèi)部提供了新的內(nèi)存管理機(jī)制,從而消除了EPC 硬件頁(yè)面故障和enclave退出導(dǎo)致的性能開銷;

? 通過預(yù)加載頁(yè)到EPC 中來防止enclave 執(zhí)行期間發(fā)生頁(yè)面錯(cuò)誤.例如,可以通過在發(fā)出ecall 之前加載所需的頁(yè)面來實(shí)現(xiàn).這樣可以防止執(zhí)行過程中enclave 內(nèi)部發(fā)生頁(yè)面錯(cuò)誤和AEX.

4.2.1 高效的完整性驗(yàn)證結(jié)構(gòu)減少分頁(yè)開銷技術(shù)

通過增加EPC 的大小來匹配物理內(nèi)存的大小,允許EPC 容納非敏感頁(yè)面,可以有效地減少分頁(yè)開銷.Taassori 等人提出了解決方案VAULT[54],他們首先分析了目前EPC 最大只支持128M 的原因,具體如下.

? 用于存儲(chǔ)EPC 元信息的完整性樹深度和大小限制:完整性樹的深度和大小隨著受保護(hù)的內(nèi)存的增大而增大.過大的樹大小和深度導(dǎo)致可緩存性差以及帶寬損失更高;

? 內(nèi)存容量開銷:每個(gè)EPC 塊所需要的完整性樹和MAC 可占據(jù)受保護(hù)內(nèi)存的四分之一(約占128MB 中的32MB);

? 性能要求:由于EPC 頁(yè)面訪問開銷巨大,因此不適合非敏感頁(yè)面.在設(shè)計(jì)時(shí)將大部分內(nèi)存指定為EPC,會(huì)導(dǎo)致敏感頁(yè)面需求較少的應(yīng)用程序不能充分利用EPC 和更高的性能開銷.

因此,為了支持啟用更大的EPC,必須解決至少兩個(gè)重要問題:(1)改進(jìn)完整性樹的深度及其可緩存性以保持內(nèi)存容量和帶寬開銷較低;(2)減少完整性驗(yàn)證的空間開銷(包括完整性樹和MAC).

VAULT[59]首先引入了用于完整性驗(yàn)證的可變?cè)y(tǒng)一加密葉子樹(variable arity unified encrypted-leaf tree,簡(jiǎn)稱VAULT)計(jì)數(shù)器,如圖8 所示.VAULT 可以有效平衡管理樹深度和計(jì)數(shù)器溢出問題.SGX 完整性樹的參數(shù)(arity)為8,VAULT 則將完整性樹的arity 設(shè)計(jì)為16 到64 可變,從而實(shí)現(xiàn)一個(gè)更緊湊且深度更低的VAULT,每次讀取和寫入的可緩存性和帶寬開銷都得到了提高.并且,VAULT 提出了壓縮共享 MAC(shared MAC with compression,簡(jiǎn)稱SMC)技術(shù),用以壓縮數(shù)據(jù)塊并將其MAC 打包到單個(gè)高速緩存行中,從而減少帶寬開銷,通過在多個(gè)數(shù)據(jù)塊之間共享MAC 來減少存儲(chǔ)開銷,并證明了基于壓縮的技術(shù)可以在大多數(shù)情況下消除或減少帶寬損失.因此,SMC 可以同時(shí)減少帶寬和內(nèi)存容量開銷.最后,VAULT 僅為敏感頁(yè)面按需分配MAC,以進(jìn)一步減少M(fèi)AC 容量開銷.通過結(jié)合VAULT 和MAC 共享和壓縮,VAULT 實(shí)現(xiàn)了擴(kuò)展EPC 到整個(gè)物理內(nèi)存,并且可以解決SGX 內(nèi)存訪問中的大多數(shù)低效問題,相對(duì)于SGX,整體性能提高3.7 倍,而內(nèi)存空間開銷僅為4.7%.

Fig.8 VAULT schematic diagram圖8 VAULT 示意圖

4.2.2 安全用戶管理虛擬內(nèi)存技術(shù)

Orenbach 等人提出了用于enclave 的無退出(exit-less)運(yùn)行時(shí)系統(tǒng)服務(wù)Eleos[58],通過透明且安全地將系統(tǒng)調(diào)用委派給運(yùn)行在一個(gè)應(yīng)用程序線程中的RPC 服務(wù),實(shí)現(xiàn)了無退出系統(tǒng)調(diào)用,即無需退出enclave.Eleos 包含3個(gè)部分(如圖9 所示):可信的運(yùn)行時(shí)負(fù)責(zé)在enclave 內(nèi)提供RPC 和SUVM;在單獨(dú)的應(yīng)用程序線程中運(yùn)行的不可信運(yùn)行時(shí)負(fù)責(zé)處理RPC 請(qǐng)求并與SGX 驅(qū)動(dòng)程序進(jìn)行交互;SGX 驅(qū)動(dòng)程序模塊公開了用于在多個(gè)協(xié)調(diào)SUVM內(nèi)存分配的接口.

Eleos 還提出一種安全用戶管理虛擬內(nèi)存(secure user-managed virtual memory,簡(jiǎn)稱SUVM)抽象,這種抽象通過引入enclave 子頁(yè)面訪問粒度,消除了EPC 硬件頁(yè)面故障和enclave 退出導(dǎo)致的性能開銷.用戶通過特殊的分配器,在SUVM 中分配緩沖區(qū),并獲得安全指針;然后可以將其用作應(yīng)用程序中的常規(guī)指針,指針訪問被逐出的SUVM 頁(yè)面會(huì)觸發(fā)軟件頁(yè)面錯(cuò)誤,并且完全在enclave 內(nèi)部進(jìn)行處理.這些機(jī)制提高了enclave 性能,且不會(huì)削弱SGX 安全保證.Eleos 只在TCB 中添加了幾百行代碼,與SGX SDK 或Graphene[51]等操作系統(tǒng)庫(kù)(約1 000 行代碼)相比,Eleos 在TCB 中添加的代碼相對(duì)較少.

Fig.9 Eleos high-level design圖9 Eleos 架構(gòu)示意圖

Sartakov 等人提出了在機(jī)架規(guī)模環(huán)境中進(jìn)行安全數(shù)據(jù)處理的內(nèi)存數(shù)據(jù)庫(kù)引擎STANlite[20].STANlite 通過在enclave 內(nèi)使用可擴(kuò)展的虛擬內(nèi)存引擎(virtual memory engine,簡(jiǎn)稱VME),替代了操作系統(tǒng)提供的內(nèi)存頁(yè)替換機(jī)制,并使其對(duì)內(nèi)存具有完全控制權(quán),從而避免巨大的模式轉(zhuǎn)換開銷.STANlite 在不需要考慮機(jī)密性的情況下,提供了一種純粹的完整性保護(hù)數(shù)據(jù)管理模式,以提高性能.STANlite 還具有基于遠(yuǎn)程直接內(nèi)存訪問(remote direct memory access,簡(jiǎn)稱RDMA)、無切換和零拷貝的通信層,可在機(jī)架級(jí)環(huán)境中進(jìn)行快速的遠(yuǎn)程數(shù)據(jù)庫(kù)訪問.

4.3 安全內(nèi)存訪問開銷優(yōu)化

文獻(xiàn)[35]使用SGX SDK 微基準(zhǔn)測(cè)試評(píng)估了enclave 內(nèi)存訪問開銷.該基準(zhǔn)測(cè)試了順序讀/寫和隨機(jī)讀/寫操作的時(shí)間開銷,并與未部署enclave 安全內(nèi)存的訪問時(shí)間進(jìn)行了對(duì)比.所有操作總共處理256MB 數(shù)據(jù),但訪問的內(nèi)存區(qū)域大小不同.

如圖10 所示:只要訪問的內(nèi)存大小不超過3 級(jí)(L3)緩存(8MB),enclave 內(nèi)存訪問開銷就可以忽略不計(jì).如果L3 緩存未命中,隨機(jī)存儲(chǔ)器訪問的性能開銷可高達(dá)12 倍左右.當(dāng)訪問的內(nèi)存超出可用的EPC 大小時(shí),觸發(fā)的頁(yè)錯(cuò)誤會(huì)導(dǎo)致3 個(gè)數(shù)量級(jí)(1 000 倍)左右的開銷.連續(xù)內(nèi)存訪問由于CPU 預(yù)讀取實(shí)現(xiàn)了更好的性能,這隱藏了一些解密開銷,在EPC 大小范圍內(nèi)幾乎沒有內(nèi)存訪問開銷,而超出EPC 大小的內(nèi)存訪問大約有2 倍左右的性能開銷.

Fig.10 Normalized overhead of memory accesses with SGX enclaves圖10 SGX encalve 內(nèi)存的標(biāo)準(zhǔn)化開銷

文獻(xiàn)[56,58]也對(duì)enclave 內(nèi)存訪問開銷進(jìn)行了測(cè)試,見表4.文獻(xiàn)[56]采用SPEC[91]測(cè)試集進(jìn)行測(cè)試,表明內(nèi)存寫操作的開銷(30%～102%)要比內(nèi)存讀操作(6.5%～19.5%)高5 倍左右,但是沒有區(qū)分連續(xù)訪問和隨機(jī)訪問操作.文獻(xiàn)[58]則采用生成10 萬個(gè)隨機(jī)數(shù)進(jìn)行enclave 內(nèi)存訪問開銷測(cè)試,內(nèi)存隨機(jī)訪問和連續(xù)訪問以及讀和寫操作的開銷相近,大約在5.6 倍～9.5 倍開銷之間.

Table 4 Performance evaluation of SGX memory read/write operation表4 SGX 內(nèi)存讀寫操作性能測(cè)試

以上結(jié)果表明,enclave 內(nèi)存加密開銷由SGX 設(shè)計(jì)本身所致,難以作進(jìn)一步的優(yōu)化.出于性能原因,安全程序設(shè)計(jì)應(yīng)盡量減少對(duì)enclave 內(nèi)存的使用和訪問.例如,SCONE[35]通過將加密的應(yīng)用程序數(shù)據(jù)(如緩存文件和網(wǎng)絡(luò)緩沖區(qū))存儲(chǔ)在enclave 之外,以減少enclave 昂貴的內(nèi)存訪問.如果必須使用enclave 內(nèi)存,應(yīng)盡量采用連續(xù)訪問的數(shù)據(jù)結(jié)構(gòu),避免采用隨機(jī)訪問的數(shù)據(jù)結(jié)構(gòu).

4.4 小結(jié)

本節(jié)總結(jié)的以上3 種SGX 性能優(yōu)化技術(shù)概括了目前常見的SGX 應(yīng)用性能優(yōu)化方案,為了更加直觀地對(duì)比每一種技術(shù)的性能提升程度和對(duì)安全性的影響,本節(jié)作了如下總結(jié)(見表5).

Table 5 SGX performance optimization solutions表5 SGX 性能優(yōu)化方案

通過分析這3 種常見的SGX 應(yīng)用性能優(yōu)化技術(shù)的性能提升與安全性影響,可以將這3 種技術(shù)的研究總結(jié)為以下4 個(gè)方面.

? Enclave 的開銷主要?dú)w結(jié)為模式切換、頁(yè)替換和內(nèi)存加解密開銷.目前,主要的研究工作集中在對(duì)模式切換和頁(yè)替換開銷優(yōu)化方面;

? 模式切換開銷目前的主要解決方案是將同步執(zhí)行改為異步執(zhí)行,最大化enclave 內(nèi)部和外部的執(zhí)行時(shí)間,從而減少頻繁的模式切換導(dǎo)致的性能開銷;

? 頁(yè)替換開銷目前的解決方案是,通過高效的數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)來增大EPC 和采用更高效的內(nèi)存管理機(jī)制;

? Enclave 內(nèi)存加解密開銷是由于SGX 本身的設(shè)計(jì),目前主要通過合理使用加密內(nèi)存來有效避免這些開銷.要從根本上降低加密內(nèi)存訪問開銷,需要從SGX 設(shè)計(jì)層面來優(yōu)化,如重新設(shè)計(jì)加解密算法等.

5 SGX 應(yīng)用輔助開發(fā)技術(shù)

SGX 技術(shù)目前應(yīng)用的場(chǎng)景越來越廣泛,但是安全且簡(jiǎn)便地使用SGX 并不容易,錯(cuò)誤或者不合適的使用方式甚至?xí)?dǎo)致安全風(fēng)險(xiǎn).因此,輔助用戶更好地使用SGX 技術(shù),也是一個(gè)非常重要的需求.目前,SGX 應(yīng)用輔助開發(fā)技術(shù)主要包括安全開發(fā)語(yǔ)言、輔助開發(fā)工具和通用的操作系統(tǒng)庫(kù)和函數(shù)庫(kù)等.

5.1 安全開發(fā)語(yǔ)言

通過使用SGX SDK[16],開發(fā)人員可以創(chuàng)建加載到enclave 的代碼.雖然SDK 簡(jiǎn)化了SGX 的使用,但SGX 所提供的編程支持有限,如不提供enclave 內(nèi)部交互的編程支持、要求將可信代碼硬編碼到enclave 中,這限制了靈活性.開發(fā)SGX 應(yīng)用需要對(duì)程序進(jìn)行改造,當(dāng)程序規(guī)模比較大時(shí),帶來的編程成本非常高.為了方便用戶進(jìn)行SGX 應(yīng)用的開發(fā)并增強(qiáng)SGX 的安全性,目前學(xué)術(shù)界和工業(yè)界提出了支持SGX 應(yīng)用開發(fā)的安全開發(fā)語(yǔ)言.

Rust SGX SDK[61]是百度安全實(shí)驗(yàn)室開發(fā)的一個(gè)SGX Rust 語(yǔ)言開發(fā)工具包.通過將Rust 語(yǔ)言和SGX 技術(shù)相結(jié)合,開發(fā)人員可通過用Rust 語(yǔ)言編寫SGX 應(yīng)用程序.開發(fā)人員基于Rust 語(yǔ)言可以快速開發(fā)出沒有內(nèi)存安全漏洞的SGX 應(yīng)用程序,即使在操作系統(tǒng)被惡意控制時(shí)也能提供強(qiáng)大的安全防護(hù)能力,避免敏感數(shù)據(jù)被竊取.

MesaPy[62]也是百度安全實(shí)驗(yàn)室開發(fā)的一個(gè)安全開源項(xiàng)目,是一個(gè)內(nèi)存安全的Python 實(shí)現(xiàn).Python 包含超過30 萬行C 代碼,含有很多安全漏洞和隱患.MesaPy 基于Python 編譯器PyPy,通過使用內(nèi)存安全語(yǔ)言重寫外部庫(kù)和形式化驗(yàn)證保障代碼的內(nèi)存安全等方法,全面提升Python 解釋器的安全性,避免內(nèi)存問題引發(fā)的高危安全漏洞.基于這些安全特性,MesaPy 也支持運(yùn)行在SGX 中,開發(fā)者可以使用Python 輕松地開發(fā)SGX 應(yīng)用運(yùn)行于可信運(yùn)行環(huán)境中.

Ghosn 等人為增強(qiáng)SGX 的可用性,提出了一種將可信執(zhí)行環(huán)境(trusted execution environment,簡(jiǎn)稱TEE)集成到語(yǔ)言中的方案Secured Routines[63].該工作擴(kuò)展了Go 語(yǔ)言,允許開發(fā)人員依靠編譯器自動(dòng)提取安全代碼和數(shù)據(jù).其原型GOTEE 是基于Go 編譯器進(jìn)行的擴(kuò)展.GOTEE 為TEE 提供了一種簡(jiǎn)單的編程模型,開發(fā)人員可以直接通過關(guān)鍵字定義敏感代碼.

5.2 輔助開發(fā)工具

5.2.1 安全劃分與檢測(cè)工具

自動(dòng)化安全開發(fā)和檢測(cè)工具也是SGX 應(yīng)用輔助開發(fā)工具的重要類型,該類工具的主要目標(biāo)是實(shí)現(xiàn)對(duì)應(yīng)用敏感代碼的自動(dòng)化分析和劃分,以及對(duì)enclave 代碼的安全性檢測(cè).本文第3.3 節(jié)介紹了用于SGX 應(yīng)用程序的源碼劃分框架Glamdring,可以基于開發(fā)人員對(duì)敏感數(shù)據(jù)的注釋,自動(dòng)地將應(yīng)用程序劃分為不可信和可信兩部分.

SGX 為enclave 內(nèi)的代碼和數(shù)據(jù)提供硬件保護(hù),以抵御來自底層操作系統(tǒng)的攻擊,但是應(yīng)用程序本身中的漏洞(例如SGX 指令使用不正確或內(nèi)存安全錯(cuò)誤)也存在泄露機(jī)密的風(fēng)險(xiǎn).文獻(xiàn)[53]基于自動(dòng)定理證明和信息流分析,提出了一套SGX 的使用規(guī)范,設(shè)計(jì)了Moat 這一檢測(cè)工具,通過在匯編語(yǔ)言層面對(duì)程序進(jìn)行分析,從而檢測(cè)應(yīng)用程序是否存在泄露SGX 區(qū)域中秘密信息的可能.

5.2.2 性能測(cè)試與優(yōu)化工具

SGX 目前所提供的開發(fā)支持工具非常有限,這會(huì)導(dǎo)致耗時(shí)的反復(fù)實(shí)驗(yàn)開發(fā)和調(diào)試,并存在性能下降的風(fēng)險(xiǎn).SDK 自帶了一個(gè)調(diào)試器插件,可用于檢查enclave、設(shè)置斷點(diǎn)等,但是該插件僅適用于使用SDK 開發(fā)的應(yīng)用程序.Intel 提供的性能分析器VTune Amplifier[92]也可用于測(cè)試SGX 應(yīng)用程序(包括enclave)性能.VTune Amplifier支持一種稱為熱點(diǎn)(hotspots)的新分析類型,可用于分析enclave 應(yīng)用程序.熱點(diǎn)是一段頻繁執(zhí)行的代碼,例如循環(huán)主體,由類似于每條指令的總周期數(shù)或高速緩存未命中等指標(biāo)來定義.開發(fā)人員可以使用熱點(diǎn)的默認(rèn)設(shè)置來深入了解SGX 應(yīng)用程序與熱點(diǎn)有關(guān)的enclave 函數(shù),確定要進(jìn)一步優(yōu)化的代碼.VTune 專注于代碼片段的底層分析,未充分考慮SGX 特性,不足以幫助開發(fā)人員編寫高效的enclave 域代碼.

文獻(xiàn)[64]介紹了一組用于SGX 應(yīng)用程序的動(dòng)態(tài)性能分析的工具sgx-perf,它可以對(duì)enclave 中的性能關(guān)鍵事件進(jìn)行細(xì)粒度分析,允許開發(fā)人員跟蹤enclave 執(zhí)行并記錄影響性能的關(guān)鍵事件,例如enclave 切換和頁(yè)替換.它通過隱藏SGX SDK 的特定功能并重定向控制流來實(shí)現(xiàn),分析記錄的數(shù)據(jù)可以發(fā)現(xiàn)潛在的性能瓶頸.此外,sgx-perf 提供了改進(jìn)enclave 代碼和接口提高性能的建議.測(cè)試表明:使用sgx-perf 提供的建議最多可以將應(yīng)用程序的性能提高2.66 倍,這有助于開發(fā)出性能良好的SGX 應(yīng)用程序.

5.3 系統(tǒng)庫(kù)支持

相關(guān)工作中提供操作系統(tǒng)庫(kù)和函數(shù)庫(kù)來支持enclave 內(nèi)通用應(yīng)用程序的執(zhí)行,如Haven[30]、SGXKernel[50]、Graphene[51]和SCONE[35]等.本文已在上文中有所介紹,這里再進(jìn)行一些簡(jiǎn)單梳理.Haven 將drawbridge 系統(tǒng)庫(kù)部署到enclave 內(nèi)部,支持在enclave 內(nèi)直接運(yùn)行未修改的Windows 應(yīng)用程序.Graphene 則是在enclave 中部署了一個(gè)支持Linux 應(yīng)用程序運(yùn)行的操作系統(tǒng)庫(kù),可以實(shí)現(xiàn)在SGX 上快速部署未修改的Linux 應(yīng)用程序.SGXKernel同樣也是在enclave 內(nèi)部署了一個(gè)支持Linux 應(yīng)用程序操作系統(tǒng)庫(kù),且其性能明顯優(yōu)于Haven 和Graphene.SCONE 則是在enclave 中配置了標(biāo)準(zhǔn)C 函數(shù)庫(kù)[79]的修改版本,以支持重新編譯的Linux 應(yīng)用程序.

5.4 小結(jié)

本文將SGX 應(yīng)用輔助開發(fā)技術(shù)總結(jié)為安全開發(fā)語(yǔ)言、輔助開發(fā)工具以及系統(tǒng)庫(kù)和函數(shù)庫(kù)這3 類(見表6).通過分析總結(jié)上述研究工作,并結(jié)合目前SGX 應(yīng)用需求,本文分析了SGX 應(yīng)用輔助開發(fā)技術(shù)的發(fā)展方向.

? 開發(fā)語(yǔ)言目前已經(jīng)支持C/C++、Python、GO 語(yǔ)言,并且GOTEE 已將可信的開發(fā)環(huán)境集成到了GO 語(yǔ)言中,可以通過關(guān)鍵字直接定義敏感函數(shù).相關(guān)工作都考慮到將內(nèi)存安全功能集成到開發(fā)語(yǔ)言中,簡(jiǎn)便使用和更多的功能集成,是安全開發(fā)語(yǔ)言的發(fā)展方向;

? 輔助開發(fā)工具目前主要有SGX 應(yīng)用程序自動(dòng)劃分工具、enclave 機(jī)密性驗(yàn)證工具和程序性能測(cè)試工具,但是這些工具仍存在一些問題需要解決,如自動(dòng)劃分工具代碼劃分粒度不夠細(xì)、缺乏劃分標(biāo)準(zhǔn)等;

? 操作系統(tǒng)庫(kù)和函數(shù)庫(kù)目前主要有通用Linux 系統(tǒng)庫(kù)、Windows 系統(tǒng)庫(kù)和標(biāo)準(zhǔn)C 函數(shù)庫(kù),并且基本能夠支持90%以上的常用系統(tǒng)庫(kù)和函數(shù)庫(kù)API.

Table 6 SGX application-assisted development techniques表6 SGX 應(yīng)用輔助開發(fā)技術(shù)

6 SGX 應(yīng)用功能擴(kuò)展技術(shù)

SGX 的主要功能是創(chuàng)建可信執(zhí)行空間,抵御特權(quán)軟件的威脅,應(yīng)用的主要場(chǎng)景是云平臺(tái).然而,目前SGX 自身缺乏對(duì)虛擬機(jī)遷移和容器等云平臺(tái)常用技術(shù)的支持.目前很多研究工作對(duì)SGX 進(jìn)行了功能擴(kuò)展,使其支持常用的云平臺(tái)技術(shù).

6.1 支持虛擬機(jī)遷移

SGX 可以解決云計(jì)算中的信息泄露問題,但是現(xiàn)有的虛擬機(jī)管理器(virtual machine manager,簡(jiǎn)稱VMM)不提供啟用SGX 虛擬機(jī)(vitual machine,簡(jiǎn)稱VM)的高效管理操作,如實(shí)時(shí)遷移.隨著SGX 越來越多地部署到云平臺(tái)中,內(nèi)部運(yùn)行enclave 的VM 失去了實(shí)時(shí)遷移的能力,而VM 實(shí)時(shí)遷移在云計(jì)算中被廣泛使用,例如用于負(fù)載平衡、容錯(cuò).這是由于SGX 硬件防止不可信的虛擬機(jī)管理程序或操作系統(tǒng)訪問enclave 的運(yùn)行狀態(tài)所致,而這是傳統(tǒng)VM 實(shí)時(shí)遷移所必需的.啟用SGX 的VM 能夠?qū)崟r(shí)遷移不是一個(gè)簡(jiǎn)單的問題,也面臨著如下困難.

? 加密內(nèi)存頁(yè)在目的主機(jī)解密問題:Enclave 綁定到單個(gè)物理CPU,使用特定于CPU 的唯一密鑰加密,如果VMM 以現(xiàn)有方式遷移enclave,則由于密鑰不匹配,另一主機(jī)無法從源主機(jī)解密enclave 內(nèi)存頁(yè);

? 抵御回放攻擊(roll-back attack):Enclave 存儲(chǔ)空間有限,有時(shí)需要將enclave 內(nèi)部的數(shù)據(jù)加密并換出enclave,然后在需要處理時(shí)再換入enclave 并解密.但這樣會(huì)面臨回放攻擊,惡意系統(tǒng)使用舊版本的數(shù)據(jù)欺騙enclave,enclave 需要使用硬件計(jì)數(shù)器來抵御;

? 持久狀態(tài)的遷移:包括密封數(shù)據(jù)和單調(diào)計(jì)數(shù)器,前者存在數(shù)據(jù)丟失風(fēng)險(xiǎn),后者破壞了SGX 的安全保障.

Park 等人提出了一種支持SGX VM 遷移的方法及其實(shí)現(xiàn)模型[65],基于KVM(kernel-based virtual machine)實(shí)現(xiàn)了相關(guān)設(shè)計(jì),為應(yīng)用程序和支持SGX 的KVM 客戶操作系統(tǒng)提供了SGX 庫(kù),并為開發(fā)人員提供了SDK,以便他們編寫enclave 代碼時(shí)無需了解相關(guān)的遷移機(jī)制,例如控制線程.其系統(tǒng)性能開銷可以忽略不計(jì),遷移內(nèi)部運(yùn)行64 個(gè)enclave 的虛擬機(jī),遷移的總時(shí)間增長(zhǎng)了4.7%,而停機(jī)時(shí)間僅增加了3ms.

Chen 等人設(shè)計(jì)了一個(gè)基于軟件的VM 安全遷移機(jī)制,允許enclave 遷移其運(yùn)行狀態(tài)[66].遷移過程需要enclave 和不可信特權(quán)軟件之間的合作.該機(jī)制在每個(gè)enclave 中引入一個(gè)控制線程來幫助VM 遷移,從內(nèi)部安全地轉(zhuǎn)存所有enclave 的狀態(tài).對(duì)于enclave 中的數(shù)據(jù)和CPU 上下文等狀態(tài),控制線程將對(duì)它們進(jìn)行加密,并在轉(zhuǎn)存之前進(jìn)行完整性保護(hù);對(duì)于不能由軟件直接訪問的狀態(tài),例如由CPU 維護(hù)的當(dāng)前狀態(tài)保存區(qū)域(CSSA),設(shè)計(jì)記賬機(jī)制來推斷 enclave 內(nèi)的值,并通過兩階段檢查點(diǎn)方案強(qiáng)化設(shè)計(jì),利用遠(yuǎn)程證明和自我銷毀來保證每個(gè)enclave 實(shí)例在遷移后不會(huì)回放或生成多個(gè)實(shí)例,以此來防御回放攻擊.該工作采用純軟件方法實(shí)現(xiàn)密封數(shù)據(jù)和單調(diào)計(jì)數(shù)器遷移,并且維持SGX 的安全保證,最大限度地減少了開發(fā)人員的工作量,性能開銷可以忽略不計(jì).

Alder 等人則將SGX 計(jì)數(shù)器作為持久狀態(tài),實(shí)現(xiàn)了相應(yīng)的遷移方案[67],并設(shè)計(jì)和實(shí)現(xiàn)一個(gè)框架,實(shí)現(xiàn)具有持久狀態(tài)enclave 的遷移,同時(shí)保持SGX 相同的安全性保證.該遷移方案解決了一些實(shí)際挑戰(zhàn),例如從VM 訪問enclave,并將enclave 遷移到目標(biāo)計(jì)算機(jī)的性能開銷限制在12.3%以下,大大減少了enclave 開發(fā)人員的工作量.

6.2 支持容器

基于容器的虛擬化技術(shù)變得越來越流行[93].許多多租戶環(huán)境使用容器來實(shí)現(xiàn)應(yīng)用程序的性能隔離,比如使用Docker[37]來封裝容器、使用Docker Swarm[94]或Kubernetes[95]進(jìn)行部署.盡管硬件虛擬化得到了改進(jìn),但容器在虛擬機(jī)管理程序上仍然比虛擬機(jī)(VM)具有性能優(yōu)勢(shì):啟動(dòng)時(shí)間更短、I/O 吞吐量更高且延遲也更低[96].但提供的安全屬性比VM 要弱,因?yàn)橹鳈C(jī)OS 通常只使用軟件機(jī)制進(jìn)行隔離[97].現(xiàn)有的容器隔離機(jī)制主要保護(hù)環(huán)境免受不可信容器的訪問,但是租戶希望保護(hù)其應(yīng)用程序數(shù)據(jù)的機(jī)密性和完整性,防止未授權(quán)方的訪問,不僅來自其他容器,還來自更高權(quán)限的系統(tǒng)軟件.攻擊者會(huì)攻擊虛擬化系統(tǒng)軟件中的漏洞,或損害特權(quán)系統(tǒng)管理員的安全憑證[98].

SGX 可以保護(hù)應(yīng)用程序代碼和數(shù)據(jù)免受其他軟件的訪問,包括更高權(quán)限的軟件.使用enclave 可以保護(hù)容器不受更高權(quán)限軟件的威脅.容器的應(yīng)用程序可以在enclave 內(nèi)執(zhí)行,以確保數(shù)據(jù)的機(jī)密性和完整性.但是,使用SGX 設(shè)計(jì)安全容器機(jī)制面臨著兩個(gè)挑戰(zhàn):(1)最小化enclave 內(nèi)TCB 的大小,同時(shí)支持安全容器中的現(xiàn)有應(yīng)用程序;(2)保證安全容器的低性能開銷.

文獻(xiàn)[35]設(shè)計(jì)了一個(gè)用于Docker 的安全容器環(huán)境SCONE,基于SGX 實(shí)現(xiàn)在安全容器中運(yùn)行Linux 應(yīng)用程序,SCONE 內(nèi)部架構(gòu)如圖11 所示.

SCONE 的內(nèi)部組件如下.

? 對(duì)主機(jī)OS 系統(tǒng)調(diào)用的外部接口.SCONE 在將參數(shù)傳遞給應(yīng)用程序之前執(zhí)行完整性檢查,并將所有基于內(nèi)存的返回值復(fù)制到安全區(qū)內(nèi)部來抵御攻擊.為保護(hù)通過文件描述符處理的數(shù)據(jù)的完整性和機(jī)密性,SCONE 通過屏蔽(shield)來支持?jǐn)?shù)據(jù)的透明加密和身份驗(yàn)證;

?M:N線程模型.M個(gè)enclave 綁定的應(yīng)用程序線程在N個(gè)OS 線程之間進(jìn)行多路復(fù)用.當(dāng)應(yīng)用程序線程發(fā)出系統(tǒng)調(diào)用時(shí),SCONE 檢查是否存在另一個(gè)可以喚醒并執(zhí)行的應(yīng)用程序線程,直到系統(tǒng)調(diào)用的結(jié)果是可用為止,從而避免了不必要的模式切換開銷;

? 異步系統(tǒng)調(diào)用接口.異步系統(tǒng)調(diào)用通過使用共享內(nèi)存來傳遞系統(tǒng)調(diào)用參數(shù)和返回值,并發(fā)出信號(hào)請(qǐng)求執(zhí)行系統(tǒng)調(diào)用實(shí)現(xiàn).系統(tǒng)調(diào)用由 SCONE 內(nèi)核模塊中單獨(dú)運(yùn)行的線程執(zhí)行.因此,執(zhí)行系統(tǒng)調(diào)用時(shí),enclave 內(nèi)的線程不必退出;

? 與現(xiàn)有的Docker 容器環(huán)境集成,并確保與標(biāo)準(zhǔn)Linux 容器兼容.但是Linux SGX 驅(qū)動(dòng)程序和SCONE內(nèi)核模塊必須運(yùn)行在主機(jī)OS 上,因此,除了Linux SGX 驅(qū)動(dòng)程序以外,SCONE 不使用SDK[16]中的任何功能.

SCONE 在保證安全容器的TCB 較小的情況下,通過線程異步執(zhí)行等操作實(shí)現(xiàn)了很低的性能開銷,且對(duì)Docker 是透明的,與普通容器類似.由于容器鏡像通常由專家生成,因此,缺乏經(jīng)驗(yàn)的用戶可以從SCONE 中受益,只要信任安全容器鏡像的創(chuàng)建者即可.

Fig.11 SCONE architecture圖11 SCONE 架構(gòu)圖

在異構(gòu)集群上部署和調(diào)度容器,混合使用具有和不具有SGX 功能的計(jì)算機(jī)存在挑戰(zhàn).需要使用SGX 的容器將會(huì)存在爭(zhēng)奪enclave 內(nèi)存的可能性,因此,必須使用具有度量資源使用功能的調(diào)度管理器跟蹤SGX 內(nèi)存請(qǐng)求并相應(yīng)地調(diào)度容器.但是現(xiàn)有的容器協(xié)調(diào)器都沒有提供有關(guān)的SGX 資源使用運(yùn)行時(shí)監(jiān)控,只能依賴用戶在部署時(shí)提供的靜態(tài)信息.這些信息可能是錯(cuò)誤的或不符合容器的實(shí)際使用,導(dǎo)致分配過多或分配不足.文獻(xiàn)[68]提出了一種用于調(diào)度容器的SGX 感知架構(gòu),并提供了該框架的開源實(shí)現(xiàn),包括修改SGX 的Linux 驅(qū)動(dòng)程序作為Kubernetes 設(shè)備插件.

6.3 構(gòu)建可信的外部路徑

在本地應(yīng)用環(huán)境中,用戶可以使用SGX 保護(hù)應(yīng)用程序不被受到破壞的操作系統(tǒng)的影響.但是SGX 缺乏對(duì)通用可信I/O 路徑的支持,以保護(hù)用戶在enclave 和I/O 設(shè)備之間的輸入和輸出.文獻(xiàn)[69]介紹了一種SGX 通用可信路徑架構(gòu)SGXIO,允許用戶應(yīng)用程序在不可信的操作系統(tǒng)上安全運(yùn)行.SGXIO 將SGX 編程模型的優(yōu)勢(shì)與傳統(tǒng)的基于hypervisor 的可信路徑架構(gòu)相結(jié)合,實(shí)現(xiàn)了支持通用I/O 設(shè)備的可信路徑.SGXIO 超越了云計(jì)算中的傳統(tǒng)用例,使SGX 技術(shù)可用于保護(hù)以用戶為中心的本地應(yīng)用程序,以防止內(nèi)核級(jí)別的鍵盤記錄程序等攻擊手段的使用.

6.4 小結(jié)

本節(jié)對(duì)SGX 的相關(guān)功能擴(kuò)展技術(shù)進(jìn)行了總結(jié)和分析.當(dāng)前,SGX 的功能擴(kuò)展技術(shù)主要包括虛擬機(jī)遷移支持技術(shù)、容器支持技術(shù)和通用I/O 可信路徑支持技術(shù).具體擴(kuò)展的功能和優(yōu)勢(shì)見表7.

通過總結(jié)和分析上述研究工作,并結(jié)合云平臺(tái)等典型的計(jì)算場(chǎng)景,本文總結(jié)和分析了SGX 應(yīng)用功能擴(kuò)展技術(shù)未來的研究方向.

? 目前,SGX VM 遷移主要基于軟件模擬的方式實(shí)現(xiàn),并不能完美地解決SGX VM 遷移問題,VM 遷移等操作需要SGX 設(shè)計(jì)和實(shí)現(xiàn)的進(jìn)一步支持;

? 容器技術(shù)與SGX 基本的結(jié)合問題得到了有效的解決,但在性能方面仍然有進(jìn)一步優(yōu)化的空間;

? SGX 技術(shù)在很多方面仍然缺乏一定的功能支持,尤其是在某些具體的應(yīng)用場(chǎng)景,如多方計(jì)算場(chǎng)景下,需要多個(gè)enclave 之間進(jìn)行交互,而多個(gè)enclave 之間的切換開銷高昂,目前,SGX 缺乏有效的支持技術(shù).

Table 7 Feature extension techiques for SGX application表7 SGX 應(yīng)用功擴(kuò)展技術(shù)

7 SGX 應(yīng)用支持技術(shù)研究展望

SGX 技術(shù)的推出,為遠(yuǎn)程可信計(jì)算問題提供了解決方案.本文對(duì)SGX 技術(shù)的研究現(xiàn)狀及瓶頸問題進(jìn)行了總結(jié)和歸納,如何完美地解決SGX 技術(shù)應(yīng)用的瓶頸問題,需要進(jìn)一步的研究.本文從安全防護(hù)、性能優(yōu)化和易用性這3 個(gè)方面進(jìn)行了分析.

(1)安全防護(hù):應(yīng)用安全是SGX 應(yīng)用所面臨的最基本的問題.如何有效地解決SGX 應(yīng)用所面臨的側(cè)信道攻擊、內(nèi)存攻擊等安全威脅,增強(qiáng)SGX 應(yīng)用的安全性,依然是該技術(shù)應(yīng)用研究的重要研究方向,具體的研究方向包括:SGX 代碼運(yùn)行時(shí)的安全性分析與檢測(cè)、SGX 應(yīng)用代碼合理劃分、抵御側(cè)信道攻擊等問題;

(2)性能優(yōu)化:性能開銷高是制約SGX 應(yīng)用的重要瓶頸.如何減小SGX 技術(shù)的內(nèi)在開銷,實(shí)現(xiàn)其性能優(yōu)化的一般性解決方案,是后續(xù)的研究方向.具體的研究方向包括:通過硬件加速或可選加解密算法等方式降低enclave 內(nèi)存加解密開銷、具備性能調(diào)優(yōu)功能的自動(dòng)化代碼劃分和更加高效的加密內(nèi)存頁(yè)管理方式等;

(3)易用性:SGX 應(yīng)用開發(fā)的困難性和功能的局限性也是制約其應(yīng)用的重要原因.如何增強(qiáng)SGX 技術(shù)的易用性和擴(kuò)展SGX 功能,是該技術(shù)研究的熱點(diǎn)問題.具體的研究方向包括:對(duì)遺留應(yīng)用中敏感代碼自動(dòng)化識(shí)別劃分和安全性分析、避免重構(gòu)代碼支持原有程序直接運(yùn)行的方案、更簡(jiǎn)潔易用的開發(fā)語(yǔ)言和動(dòng)態(tài)可調(diào)整的庫(kù)支持、對(duì)虛擬化等云平臺(tái)常用技術(shù)的有效支持以及輔助用戶開發(fā)安全和性能良好的SGX 應(yīng)用的開發(fā)工具等.

SGX 應(yīng)用支持技術(shù)在學(xué)術(shù)界和工業(yè)界都引起廣泛關(guān)注,我們認(rèn)為,SGX 應(yīng)用支持技術(shù)在未來的研究工作可能會(huì)偏重以下幾個(gè)方面.

(1)對(duì)硬件能力的擴(kuò)展

SGX 目前的功能主要是基于17 條指令來實(shí)現(xiàn)的,SGX 本身不支持虛擬機(jī)遷移,雖然基于軟件模擬的方案實(shí)現(xiàn)了相關(guān)功能,但是更好的解決方案是對(duì)SGX 的硬件能力進(jìn)行擴(kuò)展,提供支持相應(yīng)操作的SGX 指令及安全機(jī)制.目前,SGX v1 可以支持的最大EPC 為128M,但仍然無法滿足應(yīng)用對(duì)SGX 的需求,EPC 需要進(jìn)一步地加以擴(kuò)展.這其中,有一些挑戰(zhàn)性問題需要解決,如高效的完整性驗(yàn)證結(jié)構(gòu)以及無安全需求的代碼對(duì)EPC 的浪費(fèi)和高開銷問題.

(2)對(duì)各種應(yīng)用場(chǎng)景的有效支持

SGX 目前的主要應(yīng)用場(chǎng)景是云計(jì)算,但是目前可信計(jì)算的需求越來越廣泛,IoT、邊緣計(jì)算等都需要可信支持.SGX 由于性能等限制難以直接應(yīng)用到相關(guān)場(chǎng)景中,需要對(duì)SGX 技術(shù)進(jìn)行擴(kuò)展和改進(jìn).目前,SGX 已經(jīng)應(yīng)用到的場(chǎng)景中,如多方計(jì)算,SGX 主要起到基本的安全隔離作用.但在多方計(jì)算場(chǎng)景下,應(yīng)用本身交互頻繁,SGX 的設(shè)計(jì)無法直接對(duì)這些場(chǎng)景提供有效的支持,性能開銷很高.SGX 的密鑰管理同樣面臨性能問題,在復(fù)雜場(chǎng)景和應(yīng)用中,性能開銷過高、實(shí)用性差,SGX 需要更加高效的密鑰管理方案.

(3)與區(qū)塊鏈等技術(shù)結(jié)合擴(kuò)展SGX 能力

SGX 與區(qū)塊鏈等新興技術(shù)的結(jié)合,目前是SGX 技術(shù)的研究熱點(diǎn)之一.SGX 提供的可信環(huán)境可以為智能合約等提供區(qū)塊鏈所不具備的機(jī)密性保證[99],可信的計(jì)算節(jié)點(diǎn)也可以支持區(qū)塊鏈應(yīng)用于更加復(fù)雜的應(yīng)用場(chǎng)景[47].目前,利用SGX 提高區(qū)塊鏈安全性和性能的研究工作還有很多瓶頸問題需要解決,如不支持enclave 內(nèi)部智能合約之間的調(diào)用問題[47]、利用SGX 的可信性替代區(qū)塊鏈共識(shí)機(jī)制可信性的合理性問題等[47].SGX 可以為區(qū)塊鏈提供機(jī)密性和可信性保證,同樣,區(qū)塊鏈技術(shù)也可以為SGX 提供持久化存儲(chǔ)和可信性驗(yàn)證方法,對(duì)計(jì)算結(jié)果進(jìn)行記錄和驗(yàn)證,從而實(shí)現(xiàn)可追溯等.這些都是對(duì)SGX 非常重要的能力擴(kuò)展,可以使其應(yīng)用到更加廣泛的場(chǎng)景.如何結(jié)合區(qū)塊鏈等技術(shù)對(duì)SGX 能力進(jìn)行擴(kuò)展,也是后續(xù)研究的重要研究方向.

(4)如何解決SGX 固有的信任問題

SGX 自公布以來在很多方面受到質(zhì)疑,例如固件的不可審計(jì)、對(duì)Intel 管理引擎(management engine)代碼模塊的依賴導(dǎo)致會(huì)受到安全漏洞的威脅以及必須信任Intel 作為遠(yuǎn)程證明的前提.尤其是SGX 必須使用Intel認(rèn)證服務(wù)(Intel attestation service,簡(jiǎn)稱IAS)使其可信性受到廣泛質(zhì)疑,Intel 公司作為SGX 技術(shù)遠(yuǎn)程證明服務(wù)提供方,用戶也無法對(duì)其進(jìn)行審計(jì),因此很難完全信任SGX.目前,Intel 公司在固件中實(shí)現(xiàn)的新特性FLC(flexible launch control)可以實(shí)現(xiàn)開放第三方驗(yàn)證服務(wù),一定程度上增強(qiáng)了SGX 的可信性.但是,固件的不可審計(jì)和對(duì)Intel 管理引擎代碼模塊的依賴,仍然沒有得到有效解決.

8 結(jié)束語(yǔ)

本文對(duì)SGX 應(yīng)用支持技術(shù)的研究進(jìn)展進(jìn)行了深入分析和總結(jié).首先介紹了SGX 技術(shù)的相關(guān)機(jī)制和SDK,分析了SGX 技術(shù)應(yīng)用現(xiàn)狀及瓶頸問題的研究進(jìn)展;接著,分別介紹了SGX 應(yīng)用安全防護(hù)技術(shù)、性能優(yōu)化技術(shù)、輔助開發(fā)技術(shù)和功能擴(kuò)展技術(shù);最后,展望了SGX 應(yīng)用支持技術(shù)的未來研究方向.從我們的總結(jié)來看,SGX 應(yīng)用支持技術(shù)仍然有一系列的挑戰(zhàn)問題,未來有很多工作值得繼續(xù)加以研究.期望通過我們的工作,能夠給以后的研究者提供有益的借鑒與參考,為SGX 技術(shù)的進(jìn)一步應(yīng)用和發(fā)展做出貢獻(xiàn).

致謝在此,我們向?qū)Ρ疚墓ぷ鹘o予支持并給出寶貴建議的評(píng)審老師和同行表示衷心的感謝.