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

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

2(北京大學 信息科學技術學院,北京 100871)

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

4(高可信軟件技術教育部重點實驗室(北京大學),北京 100871)

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

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

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

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

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

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

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

1 SGX 概述

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

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

Fig.1 Architecture description of SGX圖1 SGX 整體架構

1.1 SGX安全機制

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

1.1.1 隔離執(zhí)行

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

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

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

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

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

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

1.1.2 認 證

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

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

1.1.3 密封

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

1.2 SGX管理機制

1.2.1 SGX 內存管理機制

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

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

1.2.2 EPC 頁驅逐(eviction)

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

Fig.3 EPC pages evicted into non-PRM DRAM圖3 EPC 頁驅逐到非PRM 內存

1.3 SGX SDK

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

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

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

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

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

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

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

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

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

SGX 技術目前被廣泛地應用到各個領域,同時,SGX 技術在應用中也暴露了諸多瓶頸問題.如何解決SGX在應用中的瓶頸問題,也成為學術界的研究熱點.本文首先對目前SGX 技術相關應用和研究工作進行了梳理和總結,將SGX 技術應用的瓶頸總結為以下3 個方面.

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

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

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

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

Table 1 Related researchs of SGX application supporting techniques表1 SGX 應用支持技術相關研究工作

? 安全增強:分析SGX 應用存在的安全風險和面臨的安全威脅,并提出增強SGX 應用安全性的相關方案.目前,SGX 應用安全增強方案主要有TCB 最小化、對外接口最少化、敏感代碼安全生成與檢測和潛在安全威脅的分析與防護等;

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

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

通過上述對SGX 應用支持技術研究現(xiàn)狀的總結和分類,可以將SGX 應用程序支持技術的目標歸納為安全、性能和易用性這3 個方面.這3 個目標不是相互獨立的,而是互相關聯(lián)和影響的,如TCB 大小就會關系到應用的安全和性能.

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

3 SGX 應用安全防護技術

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

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

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

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

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

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

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

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

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

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

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

3.1 TCB最小化

3.1.1 TCB 安全風險分析

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

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

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

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

另外,目前SGX v1 版本支持的enclave 最大為128M(應用程序實際能使用約93M),一旦TCB 大小超過93M,就會觸發(fā)頻繁的頁替換,增加了安全風險和性能開銷.SGX v2 有可能進一步擴展SGX 的可用物理內存,但目前Intel 官方還未發(fā)布相關資料.

3.1.2 最小化TCB 的安全方案

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

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

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

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

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

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

3.2 對外接口最少化

3.2.1 Enclave 接口的安全風險分析

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

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

Fig.6 Design alternatives for the use of enclaves圖6 Enclave 設計選擇方案

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

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

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

3.2.2 減少對外接口的安全解決方案

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

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

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

文獻[64]在enclave 接口的安全設計方面給出了3 個建議.

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

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

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

3.3 敏感代碼的自動化生成與安全檢測

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

? 開發(fā)工作量大:針對每一個應用程序進行開發(fā),不僅需要開發(fā)人員具備豐富的開發(fā)經驗和安全背景,同時也需要進行大量的開發(fā)工作;

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

? 敏感代碼劃分的合理性和安全性:劃分的敏感代碼需要進行安全性和合理性驗證,以確認劃分出的敏感代碼是否存在安全漏洞.

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

3.3.1 敏感代碼自動劃分技術

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

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

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

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

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

Fig.7 Overview of the Glamdring framework圖7 Glamdring 架構

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

3.3.2 Enclave 代碼安全檢測技術

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

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

3.4 潛在安全威脅的分析與防護

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

3.4.1 側信道攻擊和防護方案

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

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

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

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

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

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

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

3.4.2 內存攻擊和防護方案

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

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

3.5 小結

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

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

? 敏感代碼自動劃分工具能夠減少程序員的工作量,但其劃分結果的準確性和可靠性難以驗證,而且目前也缺乏普遍認可的劃分標準.如何更準確、更可靠和更細粒度地自動劃分應用程序,是需要實現(xiàn)的目標;

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

Table 2 Security enhancement solutions of SGX application表2 SGX 應用安全增強方案

4 SGX 應用性能優(yōu)化技術

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

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

? Enclave 頁替換開銷.內存要求超過EPC 大小的應用程序必須在EPC 和未受保護的內存之間替換頁面.EPC 頁換出的代價高昂,因為它們必須在被復制到外部內存之前被加密并得到完整性保護.為了防止地址轉換攻擊,替換協(xié)議中斷所有enclave 線程并刷新TLB.并且,頁替換同樣會導致enclave 模式的切換.在enclave 執(zhí)行期間的頁替換,由于額外的轉換和加密操作而開銷巨大;

? 內存加密開銷.由于MEE 必須加密和解密高速緩存線,會導致加密內存訪問存在高昂的開銷,enclave代碼也會由于寫入內存和高速緩存未命中而產生開銷.

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

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

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

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

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

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

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

Table 3 SGX ecall and ocall performance evaluation表3 SGX ecall 和ocall 性能測試

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

4.1.1 無切換調用

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

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

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

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

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

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

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

4.1.3 輕量級細粒度的并行減少enclave 之間模式轉換

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

4.2 內存頁替換開銷優(yōu)化技術

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

頁替換會導致過高的性能開銷,因此,enclave 設計應盡可能地避免遇到頁替換.本文分析了頁替換開銷的原因以及相關的解決方案,具體如下.

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

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

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

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

4.2.1 高效的完整性驗證結構減少分頁開銷技術

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

? 用于存儲EPC 元信息的完整性樹深度和大小限制:完整性樹的深度和大小隨著受保護的內存的增大而增大.過大的樹大小和深度導致可緩存性差以及帶寬損失更高;

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

? 性能要求:由于EPC 頁面訪問開銷巨大,因此不適合非敏感頁面.在設計時將大部分內存指定為EPC,會導致敏感頁面需求較少的應用程序不能充分利用EPC 和更高的性能開銷.

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

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

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

4.2.2 安全用戶管理虛擬內存技術

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

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

Fig.9 Eleos high-level design圖9 Eleos 架構示意圖

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

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

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

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

Fig.10 Normalized overhead of memory accesses with SGX enclaves圖10 SGX encalve 內存的標準化開銷

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

Table 4 Performance evaluation of SGX memory read/write operation表4 SGX 內存讀寫操作性能測試

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

4.4 小結

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

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

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

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

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

? 頁替換開銷目前的解決方案是,通過高效的數(shù)據(jù)存儲結構來增大EPC 和采用更高效的內存管理機制;

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

5 SGX 應用輔助開發(fā)技術

SGX 技術目前應用的場景越來越廣泛,但是安全且簡便地使用SGX 并不容易,錯誤或者不合適的使用方式甚至會導致安全風險.因此,輔助用戶更好地使用SGX 技術,也是一個非常重要的需求.目前,SGX 應用輔助開發(fā)技術主要包括安全開發(fā)語言、輔助開發(fā)工具和通用的操作系統(tǒng)庫和函數(shù)庫等.

5.1 安全開發(fā)語言

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

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

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

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

5.2 輔助開發(fā)工具

5.2.1 安全劃分與檢測工具

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

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

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

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

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

5.3 系統(tǒng)庫支持

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

5.4 小結

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

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

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

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

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

6 SGX 應用功能擴展技術

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

6.1 支持虛擬機遷移

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

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

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

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

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

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

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

6.2 支持容器

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

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

文獻[35]設計了一個用于Docker 的安全容器環(huán)境SCONE,基于SGX 實現(xiàn)在安全容器中運行Linux 應用程序,SCONE 內部架構如圖11 所示.

SCONE 的內部組件如下.

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

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

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

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

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

Fig.11 SCONE architecture圖11 SCONE 架構圖

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

6.3 構建可信的外部路徑

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

6.4 小結

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

通過總結和分析上述研究工作,并結合云平臺等典型的計算場景,本文總結和分析了SGX 應用功能擴展技術未來的研究方向.

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

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

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

Table 7 Feature extension techiques for SGX application表7 SGX 應用功擴展技術

7 SGX 應用支持技術研究展望

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

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

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

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

SGX 應用支持技術在學術界和工業(yè)界都引起廣泛關注,我們認為,SGX 應用支持技術在未來的研究工作可能會偏重以下幾個方面.

(1)對硬件能力的擴展

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

(2)對各種應用場景的有效支持

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

(3)與區(qū)塊鏈等技術結合擴展SGX 能力

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

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

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

8 結束語

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

致謝在此,我們向對本文工作給予支持并給出寶貴建議的評審老師和同行表示衷心的感謝.