吳宇明, 劉宇濤, 陳海波

上海交通大學(xué)并行與分布式系統(tǒng)研究所, 上海 中國 200240

1 引言

長期以來, 如何保護(hù)應(yīng)用程序關(guān)鍵數(shù)據(jù)(如加密密鑰、用戶隱私信息等)的安全一直是一個(gè)重要的問題。例如2014年肆虐全球的Heartbleed[1]心臟滴血攻擊就利用了 OpenSSL中的指針越界錯(cuò)誤, 使程序能夠向攻擊者返回當(dāng)前內(nèi)存中64KB的數(shù)據(jù), 并借此偷取如密鑰等隱私信息, 造成了極為惡劣的影響。除了應(yīng)用程序本身的漏洞, 操作系統(tǒng)(Operating System,OS)本身由于巨大的可信計(jì)算基不可避免的也具有一些漏洞, 這些漏洞同樣會(huì)被攻擊者利用從而造成十分惡劣的影響。如表1所示, 僅2016年一年各主要OS均被發(fā)現(xiàn)上百個(gè)漏洞, OS本身的可信程度令人擔(dān)憂。而除了軟件中暴露的問題以外, 攻擊者還可能利用硬件的缺陷實(shí)施對(duì)應(yīng)用程序關(guān)鍵數(shù)據(jù)的惡意讀取, 如Bus Snooping[2]和Cold Boot[3]攻擊。在大量的漏洞與成功實(shí)施的攻擊下, OS的健壯性也不禁會(huì)引起人們的質(zhì)疑。

對(duì)于軟件層面的攻擊, 一種解決方案是建立一個(gè)相對(duì)獨(dú)立的可信環(huán)境, 在可信環(huán)境內(nèi)部執(zhí)行應(yīng)用程序從而避免外部而來的攻擊。但是由于OS往往處于最高權(quán)限級(jí), 因此在這之上建立的安全環(huán)境往往會(huì)受到來自O(shè)S自身漏洞的影響, 而在同級(jí)建立這樣的可信環(huán)境往往較為困難。Dautenhahn Nathan[4]等人利用CR0中的WP位, 通過將OS的頁表設(shè)置為只讀,保證所有對(duì)頁表的修改必須要經(jīng)過可信環(huán)境 Nested Kernel, 從而建立一個(gè)與OS本身同級(jí)別的可信環(huán)境,將其余大量的OS代碼移出了可信基。這種方法雖然可以阻止惡意的修改, 但是無法阻止攻擊者對(duì)應(yīng)用程序私密數(shù)據(jù)的惡意讀取; 而如Bus Snooping、Cold Boot等物理攻擊則可以完全繞開軟件層面的解決方案。這本質(zhì)上是由于應(yīng)用程序在運(yùn)行時(shí)內(nèi)存中的數(shù)據(jù)均是明文, 攻擊者只要知道應(yīng)用程序私密數(shù)據(jù)的物理地址便可直接讀取應(yīng)用程序在內(nèi)存中的明文數(shù)據(jù)。

表1 2016年主要操作系統(tǒng)CVE數(shù)目Table 1 Number of CVEs in mainstream OS (2016)

虛擬機(jī)監(jiān)控器(Virtual Machine Monitor, VMM)的出現(xiàn)提供了一種新的途徑。由于 VMM 運(yùn)行在高于客戶虛擬機(jī)(Guest Virtual Machine, Guest VM)中OS(Guest OS)的特權(quán)級(jí)并實(shí)際管理物理內(nèi)存, 因此可以利用 VMM 進(jìn)行介入, 對(duì)應(yīng)用程序中的關(guān)鍵數(shù)據(jù)進(jìn)行保護(hù)。但是這類防御措施仍然無法阻止如Bus Snooping或Cold Boot等物理攻擊。

為了更徹底地解決應(yīng)用程序數(shù)據(jù)泄露問題,AMD提出了硬件內(nèi)存加密機(jī)制: 安全內(nèi)存加密(Secure Memory Encryption, SME)與安全加密虛擬化(Secure Encrypted Virtualization, SEV)[5]。SME 主要用于保護(hù)宿主機(jī)(Host)防止物理攻擊, SEV則主要用于虛擬化場(chǎng)景下Guest OS的安全。兩者均使用可信硬件加密內(nèi)存, 并通過頁表進(jìn)行設(shè)置來高效完成對(duì)加密頁的管理。但是現(xiàn)有的SME與SEV均無法保護(hù)運(yùn)行在Guest OS中的應(yīng)用程序的數(shù)據(jù)安全。

本文基于AMD SEV硬件, 利用現(xiàn)有的虛擬化環(huán)境 Xen[6], 對(duì)其進(jìn)行了軟件擴(kuò)展, 提出了一套解決方案Sedora, 在不可信的Guest OS環(huán)境下保護(hù)應(yīng)用程序關(guān)鍵數(shù)據(jù)的安全。Sedora建立一個(gè)獨(dú)立的安全運(yùn)行環(huán)境, 在其中執(zhí)行與應(yīng)用程序關(guān)鍵數(shù)據(jù)相關(guān)的代碼; 而針對(duì)包含物理攻擊在內(nèi)的惡意內(nèi)存讀取, Sedora利用SEV的內(nèi)存加密特性, 對(duì)安全運(yùn)行環(huán)境進(jìn)行內(nèi)存加密。Sedora將應(yīng)用程序進(jìn)行解耦和并建立不可被篡改的通信機(jī)制與應(yīng)用程序直接通信, 將與關(guān)鍵數(shù)據(jù)相關(guān)的代碼邏輯置于安全運(yùn)行環(huán)境來避免潛在的攻擊。安全分析和性能評(píng)估證明了Sedora是切實(shí)有效可行的。

本文的主要貢獻(xiàn)如下:

1) 利用虛擬化環(huán)境下VMM負(fù)責(zé)模擬CPUID的特性, 對(duì)VMM進(jìn)行擴(kuò)展, 通過創(chuàng)建不可被篡改的通信機(jī)制, 使得 VMM 可以與應(yīng)用程序直接安全地進(jìn)行通信。

2) 對(duì)AMD SEV與SME進(jìn)行全面分析, 以及利用 SEV與 SME機(jī)制提出保護(hù)應(yīng)用程序在不可信Guest OS中關(guān)鍵數(shù)據(jù)安全的解決方案。

3) 基于Xen的軟件擴(kuò)展方案Sedora, 通過建立安全的可信環(huán)境, 并利用不可被篡改的通信機(jī)制來解決應(yīng)用程序的數(shù)據(jù)安全問題。

4) 基于Xen實(shí)現(xiàn)的可用原型系統(tǒng), 以及對(duì)應(yīng)的安全和性能評(píng)估。

本文結(jié)構(gòu)如下: 第2章介紹相關(guān)背景技術(shù); 第3章介紹Sedora的設(shè)計(jì)與實(shí)現(xiàn); 第4章介紹Sedora的應(yīng)用場(chǎng)景; 第5章是系統(tǒng)的安全分析; 第6章展示系統(tǒng)的性能評(píng)估; 在第7章介紹與本文相關(guān)的工作; 隨后在第 8章圍繞系統(tǒng)進(jìn)行了簡單的討論和對(duì)系統(tǒng)局限的分析, 并介紹了相應(yīng)的后續(xù)工作; 最后第9章總結(jié)全文。

2 背景

利用虛擬化技術(shù)在脆弱的Guest OS上保護(hù)應(yīng)用程序的關(guān)鍵數(shù)據(jù)安全已經(jīng)在學(xué)術(shù)界被大量討論, 如SeCage[7]、OverShadow[8]等。但是與已有的保護(hù)技術(shù)相比, 硬件加密內(nèi)存具有無可比擬的優(yōu)點(diǎn)。Intel和AMD都在近年提高了對(duì)安全的重視程度并在主流的處理器中加入了硬件內(nèi)存加密機(jī)制[5,9], 基于硬件的內(nèi)存加密將會(huì)在普通用戶中大量部署; 其次, 加密后的內(nèi)存不但能夠抵御傳統(tǒng)的基于軟件的數(shù)據(jù)泄露攻擊, 而且能夠抵御如Bus Snooping、Code Boot這樣的物理攻擊; 最后, 基于硬件的防御手段對(duì)原有系統(tǒng)的修改要求極小, 在現(xiàn)有軟件棧的基礎(chǔ)上只需少量的修改即可部署。

Intel曾提出了軟件防護(hù)擴(kuò)展(Software Guard Extensions, SGX)技術(shù)[9], 該技術(shù)能夠通過可信硬件加密應(yīng)用程序內(nèi)存來抵御數(shù)據(jù)泄露攻擊。而與明確保護(hù)應(yīng)用程序關(guān)鍵數(shù)據(jù)安全的 SGX不同, AMD的SME與SEV機(jī)制旨在保護(hù)操作系統(tǒng)免受來自硬件的物理攻擊, 因此不能直接參考SGX用于保護(hù)應(yīng)用程序的數(shù)據(jù)安全。在本節(jié), 本文將首先介紹AMD硬件內(nèi)存加密相關(guān)機(jī)制與局限, 之后會(huì)簡單介紹與本文相關(guān)的Xen虛擬化技術(shù)。

2.1 AMD硬件內(nèi)存加密機(jī)制

AMD于2016年提出硬件內(nèi)存加密機(jī)制SME與SEV[5]并將其與現(xiàn)有的AMD-V虛擬化技術(shù)[10]進(jìn)行了結(jié)合。如圖1所示, 在原有的CPU中引入了新的片上芯片系統(tǒng)并將其與原有的內(nèi)存控制器進(jìn)行了結(jié)合以支持SEV和SME的實(shí)現(xiàn)。所有內(nèi)存加密密鑰的生成和管理均由一個(gè)專有安全處理器來負(fù)責(zé), 上層的軟件通過相應(yīng)的內(nèi)存映射寄存器對(duì)安全處理器發(fā)送請(qǐng)求來生成、安裝、更換或撤銷密鑰。密鑰被安裝在內(nèi)存控制器上, 當(dāng)CPU經(jīng)由內(nèi)存控制器讀寫內(nèi)存時(shí), 內(nèi)存控制器利用密鑰對(duì)數(shù)據(jù)進(jìn)行解加密。

SME主要用于抵御物理攻擊, 原有頁表項(xiàng)中的某一高位被識(shí)別為加密位C-bit, OS可以通過配置加密位C-bit來設(shè)置對(duì)應(yīng)的物理頁是否開啟SME支持,從而達(dá)到頁粒度的管理。SEV則結(jié)合新增的指令集與Guest頁表, 以類似SME的方式實(shí)現(xiàn)對(duì)Guest VM內(nèi)存的加密保護(hù)。當(dāng)一個(gè)Guest VM以SEV方式啟動(dòng)時(shí), 內(nèi)存加密固件會(huì)初始化Guest VM的SEV上下文, 將其保存到片上系統(tǒng)并返回一個(gè)Handle作為標(biāo)識(shí), 每一個(gè)Handle對(duì)應(yīng)于一個(gè)Guest VM的地址空間ID(Address Space ID, ASID)。當(dāng)VM被調(diào)度的時(shí)候,VMM會(huì)向安全處理器發(fā)送ACTIVATE指令并通過命令緩沖區(qū)傳入對(duì)應(yīng)Guest VM的ASID和Handle, 安全處理器則會(huì)將對(duì)應(yīng)VM SEV上下文中的密鑰裝入內(nèi)存控制器并用ASID進(jìn)行標(biāo)記。如圖1所示, Xen VMM除原有的Domain0外運(yùn)行了三個(gè)Guest VM,其中VM1與VM2分別使用Key1和Key2對(duì)物理內(nèi)存進(jìn)行加密, 通過配置guest頁表中的C-bit, VM1與VM2可以以頁粒度管理物理內(nèi)存加密, 而未開啟SEV的VMn則和原來一樣。需要注意的是, VMM自身也可以通過設(shè)置自身頁表或嵌套頁表(Nested Page Table, NPT)中的C-bit來開啟SME支持以進(jìn)一步抵御物理攻擊, 當(dāng)同一塊物理頁開啟了兩種加密支持時(shí), 內(nèi)存控制器會(huì)優(yōu)先采用與SEV相關(guān)的C-bit并使用對(duì)應(yīng)的密鑰對(duì)內(nèi)存進(jìn)行加解密。

圖1 AMD硬件內(nèi)存加密架構(gòu)Figure 1 AMD memory encryption architecture

2.2 AMD內(nèi)存加密的局限

AMD內(nèi)存加密機(jī)制包含SME與SEV兩種, SME的目的在于保護(hù)OS抵御來自硬件的物理攻擊。如我們?cè)?.1節(jié)所討論的, OS可以通過配置頁表項(xiàng)中的C-bit來管理加密頁, VMM 則可以進(jìn)一步通過配置NPT中的頁表項(xiàng)來啟動(dòng)這一機(jī)制。SME的對(duì)上透明性可以減輕部署的工作量, 但是對(duì)于OS或VMM本身來說, 讀寫內(nèi)存本身不會(huì)受到任何影響。這也就意味著在這之上的應(yīng)用程序或虛擬機(jī)也同樣不會(huì)受到內(nèi)存加密的影響, 因此無法借助SME來實(shí)現(xiàn)對(duì)應(yīng)用程序關(guān)鍵數(shù)據(jù)的保護(hù)。

與SME不同, SEV的設(shè)計(jì)目的在于保護(hù)VM自身, 頁表的配置由 Guest OS完成, 因此它能夠保證VM在運(yùn)行時(shí)的內(nèi)存為密文, 從而防止來自其他VM甚至來自VMM的惡意讀取。但是, SEV之于Guest OS就如SME之于Host OS一樣, SEV對(duì)于運(yùn)行在Guest OS中的應(yīng)用程序來說是透明的, 因而SEV也不能直接用來保護(hù)應(yīng)用程序關(guān)鍵數(shù)據(jù)的安全。

2.3 Xen虛擬化技術(shù)

Xen[6]曾因其提出的半虛擬化概念而一夜成名,通過對(duì)Guest OS進(jìn)行顯式的修改, 使Guest OS能夠利用 Hypercall、影子頁表和半虛擬化 I/O來高效替換在傳統(tǒng)虛擬化中的軟件模擬。而隨著Intel VT-x[11]與 AMD-V[10]的發(fā)布, 當(dāng)前的硬件已經(jīng)能高效支持CPU與內(nèi)存的虛擬化, 而 I/O虛擬化則依舊沿用了Xen中設(shè)計(jì)的半虛擬化方案。

CPU虛擬化:AMD-V將CPU的運(yùn)行模式劃分為guest模式與 host模式, VMM 與負(fù)責(zé)管理 VM 的Domain0運(yùn)行在host模式中, 普通的Guest VM運(yùn)行在guest模式中。兩種模式都具有特權(quán)級(jí)ring3與ring0以分別運(yùn)行應(yīng)用進(jìn)程與內(nèi)核進(jìn)程。在Guest VM啟動(dòng)之前, VMM會(huì)為每一個(gè)虛擬CPU(vCPU)初始化一個(gè)控制塊(Virtual Machine Control Block, VMCB),VMCB中存儲(chǔ)著Guest VM當(dāng)前vCPU運(yùn)行時(shí)的各種狀態(tài)。當(dāng) VMCB被初始化完成后, VMM 可以將VMCB的地址作為參數(shù), 通過VMRUN指令將控制流跳轉(zhuǎn)到guest模式中VM的啟動(dòng)代碼并開始執(zhí)行,硬件則負(fù)責(zé)將 VMCB中的運(yùn)行狀態(tài)同步到當(dāng)前的CPU中。當(dāng)Guest VM遇到特權(quán)指令或觸發(fā)在VMCB中配置過的下陷條件時(shí), 控制流會(huì)下陷到 VMM 中,同時(shí)硬件會(huì)再次將CPU的狀態(tài)同步至對(duì)應(yīng)的VMCB中。之后VMM負(fù)責(zé)讀取VMCB中的退出原因并進(jìn)行處理, 隨后再次通過VMRUN繼續(xù)執(zhí)行Guest VM的代碼。

虛擬化下的 CPUID:作為一條特殊指令,CPUID的目的在于發(fā)現(xiàn) CPU所具有的各項(xiàng)功能特性。查詢時(shí)對(duì)應(yīng)的ID會(huì)作為參數(shù)存入EAX, 在調(diào)用CPUID后, 通過讀取EAX到EDX中的返回值, 系統(tǒng)便可以知道當(dāng)前物理CPU所支持的功能。在虛擬化環(huán)境下, 由于 Guest VM 無法直接獲取硬件的信息,因此CPUID也會(huì)作為特權(quán)指令下陷到VMM中, 由VMM 負(fù)責(zé)填寫對(duì)應(yīng)的信息以供 Guest OS讀取。CPUID的特別之處在于它可以被運(yùn)行在 ring3級(jí)的應(yīng)用程序直接調(diào)用, 控制流則會(huì)直接下陷到 VMM從而繞過Guest OS。

嵌套頁表:AMD使用嵌套頁表(Nested Page Table, NPT)[12]來完成對(duì)內(nèi)存虛擬化的支持。如今的主流 OS均采用頁表系統(tǒng)來管理虛擬地址到物理地址的映射, 這樣可以提高內(nèi)存的使用率并且易于管理,并且所有的應(yīng)用程序均可運(yùn)行在相同的虛擬地址空間中, 從而規(guī)范了程序的設(shè)計(jì)與開發(fā)。負(fù)責(zé)完成地址映射的數(shù)據(jù)結(jié)構(gòu)則是頁表(Page Table, PT), 在虛擬化場(chǎng)景下, 頁表負(fù)責(zé)完成客戶機(jī)虛擬地址(Guest Virtual Address, GVA)到客戶機(jī)物理地址(Guest Physical Address, GPA)的映射, 而NPT則負(fù)責(zé)完成GPA到宿主機(jī)物理地址(Host Physical Address, HPA)的映射。Guest通過guest Control Register 3(gCR3)寄存器來管理自己的頁表, NPT則由 VMM通過 nested CR3(nCR3)寄存器來管理。因此內(nèi)存訪問會(huì)經(jīng)過GVA到GPA再到HPA的兩個(gè)翻譯過程。當(dāng)NPT發(fā)生缺頁錯(cuò)誤時(shí), Guest會(huì)下陷到VMM, VMM則根據(jù)VMCB中的錯(cuò)誤地址與原因, 分配新頁并填寫 NPT來修復(fù)缺頁錯(cuò)誤。

Xen內(nèi)存共享:由于Guest VM都運(yùn)行在各自的地址空間中, 因此VMM必須提供一套供VM之間進(jìn)行內(nèi)存共享的機(jī)制, Xen通過授權(quán)表滿足VM對(duì)內(nèi)存共享的需求。Xen在啟動(dòng) Guest VM 時(shí)會(huì)為每一個(gè)VM創(chuàng)建一張授權(quán)表, 當(dāng)VM準(zhǔn)備共享自己的內(nèi)存時(shí),它會(huì)首先利用相關(guān)Hypercall在自己的授權(quán)表中添加一條包含授權(quán)目標(biāo) ID、將要共享的頁地址和授予權(quán)限的相關(guān)信息, Xen在處理Hypercall時(shí)會(huì)通過共享頁的GPA查詢到HPA并填到目標(biāo)ID VM的NPT中,同時(shí)根據(jù)授權(quán)信息將其映射為對(duì)應(yīng)的權(quán)限。這樣VM間就可以通過授權(quán)表來進(jìn)行安全的內(nèi)存共享。

2.4 CIL靜態(tài)分析

CIL(C Intermediate Language)[13]是一個(gè)用于C語言程序分析和轉(zhuǎn)化的前端工具。CIL能夠分析源代碼并進(jìn)行類型檢查, 同時(shí)還能將程序進(jìn)行等價(jià)的簡化以減少分析的復(fù)雜度。CIL最終的結(jié)果包含三種基本元素: 表達(dá)式、指令和語句, 以及這些基本元素的前繼與后繼。借助這些信息, 使用者可以進(jìn)行污染標(biāo)記并發(fā)現(xiàn)所有訪問被污染對(duì)象的程序部分; 也可以直接根據(jù)已有信息建立程序的控制流圖(CFG, Control Flow Graph)或抽象語法樹(AST, Abstract Syntax Tree)從而為下一步的工作做準(zhǔn)備。

2.5 威脅模型

Sedora的目標(biāo)是保護(hù)應(yīng)用程序中關(guān)鍵數(shù)據(jù) (如加密密鑰、用戶隱私信息等) 的安全, 防止其被攻擊者惡意讀取。對(duì)于應(yīng)用程序, 我們假定攻擊者在系統(tǒng)部署完成后能夠通過網(wǎng)絡(luò)遠(yuǎn)程以及在Guest OS本地阻塞或截取應(yīng)用程序的數(shù)據(jù)。攻擊者可以利用Guest OS本身的信息泄露漏洞, 結(jié)合已有的成熟攻擊手段從而達(dá)到對(duì)Guest OS內(nèi)存數(shù)據(jù)的任意讀取, 進(jìn)而惡意竊取應(yīng)用程序中的關(guān)鍵數(shù)據(jù); 攻擊者也可以借助于其他應(yīng)用程序利用Guest OS與被保護(hù)程序共享同樣的內(nèi)存從而對(duì)共享內(nèi)存中的數(shù)據(jù)進(jìn)行修改。同時(shí),Sedora還考慮Cold Boot與Bus Snooping這樣的物理攻擊。

本文假設(shè)虛擬機(jī)監(jiān)控器 VMM 是可信的, 利用VMM本身的漏洞從VM層面攻擊VMM或攻擊其他VM, 或使Guest OS與VMM配合攻擊應(yīng)用程序等不在本文的討論范圍內(nèi)。此外, 本文也相信AMD內(nèi)存加密的相關(guān)硬件, 側(cè)信道攻擊[14]則不在本文的討論范圍內(nèi)。

3 Sedora設(shè)計(jì)與實(shí)現(xiàn)

3.1 概述

Sedora是基于 AMD硬件內(nèi)存加密機(jī)制, 對(duì)Guest VM中應(yīng)用程序關(guān)鍵數(shù)據(jù)進(jìn)行保護(hù)的一套系統(tǒng)設(shè)計(jì)方案。其主要是通過分離應(yīng)用程序?yàn)殛P(guān)鍵部分與正常部分, 通過建立隔離的安全運(yùn)行環(huán)境來執(zhí)行與關(guān)鍵數(shù)據(jù)相關(guān)的關(guān)鍵部分, 并通過一套由安全通信機(jī)制組成的安全調(diào)用來完成與正常部分的通信,在通信過程中Sedora負(fù)責(zé)維護(hù)安全運(yùn)行環(huán)境的機(jī)密性與安全調(diào)用部分的完整性。

Sedora主體分為兩部分: 運(yùn)行在正常環(huán)境下的正常部分和運(yùn)行在安全運(yùn)行環(huán)境中的關(guān)鍵部分。如圖2所示, 整個(gè)系統(tǒng)分為四個(gè)階段: 1) 需要被保護(hù)的應(yīng)用程序在系統(tǒng)初始化前被解耦和為包含關(guān)鍵數(shù)據(jù)和相關(guān)代碼的關(guān)鍵部分, 和其余不受影響的正常部分; 2) 在應(yīng)用初始化階段, 應(yīng)用程序會(huì)首先與Sedora建立安全通信, 之后與安全運(yùn)行環(huán)境建立共享內(nèi)存; 3) Sedora會(huì)將關(guān)鍵部分加載到安全運(yùn)行環(huán)境中, 關(guān)鍵部分將作為單獨(dú)的調(diào)度單位在需要的時(shí)候被調(diào)度; 4) 應(yīng)用程序正常部分通過安全調(diào)用, 利用共享內(nèi)存向關(guān)鍵部分發(fā)送請(qǐng)求, 而關(guān)鍵部分則負(fù)責(zé)執(zhí)行關(guān)鍵代碼并將結(jié)果通過共享內(nèi)存返回給正常部分, 返回?cái)?shù)據(jù)的完整性由Sedora進(jìn)行保證。

應(yīng)用解耦和:應(yīng)用解耦和的目的在于找到所有與關(guān)鍵數(shù)據(jù)相關(guān)的代碼。僅僅將密鑰或隱私信息本身放入隔離的安全運(yùn)行環(huán)境是不夠的, 密鑰會(huì)被使用或轉(zhuǎn)存成為其他數(shù)據(jù)形式從而被帶出安全運(yùn)行環(huán)境, 因此 Sedora需要將所有與關(guān)鍵數(shù)據(jù)相關(guān)的部分全部放入安全運(yùn)行環(huán)境。

本文通過 CIL[13]靜態(tài)污點(diǎn)追蹤分析技術(shù), 找到所有與關(guān)鍵數(shù)據(jù)相關(guān)的代碼部分, 并借此分離出與關(guān)鍵數(shù)據(jù)相關(guān)的代碼從而對(duì)其進(jìn)行隔離保護(hù)。

安全通信:由于應(yīng)用程序與虛擬機(jī)監(jiān)控器之間需要進(jìn)行必要的通信, 因此 Sedora會(huì)在應(yīng)用初始化階段與應(yīng)用程序建立輕量級(jí)安全通信機(jī)制。本文利用虛擬化場(chǎng)景下 CPUID會(huì)直接從用戶態(tài)下陷到VMM的特點(diǎn)來繞過Guest OS, 在滿足CPUID的調(diào)用條件下, 應(yīng)用程序可以通過寄存器直接獲取VMM的反饋。與安全運(yùn)行環(huán)境的通信則由共享內(nèi)存負(fù)責(zé),兩者一起為正常部分提供安全調(diào)用功能, 最終完成對(duì)關(guān)鍵數(shù)據(jù)的保護(hù)。

安全運(yùn)行環(huán)境:安全運(yùn)行環(huán)境是保護(hù)關(guān)鍵數(shù)據(jù)的核心之一, 其本身基于 VMM 內(nèi)存隔離機(jī)制運(yùn)行在另一個(gè)地址空間中, 從而達(dá)到與原Guest VM的相互隔離。為了減少攻擊面, 安全運(yùn)行環(huán)境相對(duì)封閉,僅能通過共享內(nèi)存與外部進(jìn)行通信, 并采用直連方式使用專有磁盤來存儲(chǔ)關(guān)鍵數(shù)據(jù)。為了抵御來自攻擊者的物理攻擊, Sedora利用AMD的SEV和SME機(jī)制對(duì)安全運(yùn)行環(huán)境進(jìn)行加密, 保證內(nèi)存中的關(guān)鍵數(shù)據(jù)和代碼在運(yùn)行時(shí)均為密文。

數(shù)據(jù)處理與安全控制分離:Sedora將應(yīng)用程序的正常數(shù)據(jù)與關(guān)鍵數(shù)據(jù)進(jìn)行了分離, 同時(shí)保持原有的數(shù)據(jù)處理流不變, 僅在關(guān)鍵數(shù)據(jù)和正常數(shù)據(jù)的邊界, 即共享內(nèi)存部分進(jìn)行完整性校驗(yàn)。校驗(yàn)結(jié)果會(huì)通過輕量級(jí)通信機(jī)制傳送給運(yùn)行在Guest OS的應(yīng)用程序, 最終保證從安全運(yùn)行環(huán)境中返回的結(jié)果不會(huì)被Guest OS惡意篡改, 在保護(hù)關(guān)鍵數(shù)據(jù)不泄露的同時(shí)保證應(yīng)用程序的正常執(zhí)行。本章節(jié)將詳細(xì)介紹使用的相關(guān)技術(shù)設(shè)計(jì)和實(shí)現(xiàn)。

3.2 應(yīng)用解耦和

圖3展示了應(yīng)用解耦和的過程, 在進(jìn)行應(yīng)用解耦和時(shí), 用戶需要定義關(guān)鍵數(shù)據(jù)的范圍, 如隱私數(shù)據(jù)的定義等。本文利用 CIL靜態(tài)代碼分析工具來追蹤程序的數(shù)據(jù)流, 找到關(guān)鍵數(shù)據(jù)的傳遞路徑并對(duì)相關(guān)聯(lián)的數(shù)據(jù)進(jìn)行污染標(biāo)記, 同時(shí)找出所有讀取過污染標(biāo)記的代碼。CIL本身具有強(qiáng)大的功能, 包含宏觀的程序結(jié)構(gòu)信息與具體的控制流信息, 由于本文旨在進(jìn)行較為粗粒度的解耦和, 因此只需找出被標(biāo)記數(shù)據(jù)相關(guān)的程序部分進(jìn)行分離即可。而 CIL本身的抽象語法樹、程序轉(zhuǎn)譯等功能則被本文拋棄使用。

圖2 Sedora系統(tǒng)架構(gòu)Figure 2 Architecture overview of Sedora

圖中①根據(jù)用戶定義, 應(yīng)用程序中的關(guān)鍵數(shù)據(jù)被進(jìn)行了標(biāo)記, 需要注意的是, 標(biāo)記可能不止一處,但所有被標(biāo)記的數(shù)據(jù)均被認(rèn)為是污染源。在②的過程中, 本文使用CIL對(duì)代碼進(jìn)行靜態(tài)分析, 傳播標(biāo)記,找出所有與關(guān)鍵數(shù)據(jù)相關(guān)的代碼和其他數(shù)據(jù)。需要注意的是靜態(tài)分析的結(jié)果會(huì)得到所有可能的路徑,因此被標(biāo)記的代碼和數(shù)據(jù)相較于動(dòng)態(tài)分析會(huì)比較多,但是本文建立的安全運(yùn)行環(huán)境與原有的正常環(huán)境完全隔離, 且安全執(zhí)行環(huán)境本身是個(gè)封閉空間, 因此即使將大部分代碼作為關(guān)鍵部分置入安全運(yùn)行環(huán)境,在面對(duì)惡意的Guest OS時(shí)Sedora仍能保證關(guān)鍵數(shù)據(jù)及相關(guān)代碼的安全。動(dòng)態(tài)分析雖然可以更高效, 但是無法覆蓋所有可能路徑, 因此會(huì)留下些許隱患, 比如與關(guān)鍵數(shù)據(jù)相關(guān)的代碼可能被遺留在正常部分。同時(shí), 本文發(fā)現(xiàn)應(yīng)用程序?qū)τ陉P(guān)鍵數(shù)據(jù)(如密鑰)的訪問往往具有固定的模式, 這也表明靜態(tài)分析足以滿足本文對(duì)應(yīng)用程序解耦和的需要。

在得到分析結(jié)果后, 所有被標(biāo)記的代碼和數(shù)據(jù)均被劃分為關(guān)鍵部分, 而其余代碼和數(shù)據(jù)則被劃歸為正常部分。在分析過程中, 本文發(fā)現(xiàn)對(duì)于關(guān)鍵數(shù)據(jù)的使用一般有兩種情況: 1) 關(guān)鍵部分的代碼與數(shù)據(jù)最終會(huì)返回一個(gè)與關(guān)鍵數(shù)據(jù)本身無關(guān)的返回值。這種情況一般發(fā)生在驗(yàn)證過程, 比如用戶登陸時(shí)的密碼驗(yàn)證, 驗(yàn)證過程作為關(guān)鍵部分被分離, 最終關(guān)鍵部分代碼會(huì)返回一個(gè)成功或失敗的結(jié)果, 在這種情況下關(guān)鍵部分可以與正常部分很好的分離。2) 正常部分利用關(guān)鍵部分進(jìn)行數(shù)據(jù)加工, 并最終要求返回加工后的數(shù)據(jù)。這種情況一般發(fā)生在加密過程, 正常部分將明文傳送給關(guān)鍵部分, 而后要求返回密文。由于密文在與關(guān)鍵數(shù)據(jù)(如密鑰)作用的過程中會(huì)被標(biāo)記從而劃歸為關(guān)鍵部分, 而安全運(yùn)行環(huán)境由于自身封閉, 因此最終無法返回給正常部分。在這種情況下,應(yīng)用程序應(yīng)當(dāng)提前給出最終返回結(jié)果的定義, Sedora會(huì)將關(guān)鍵部分中滿足用戶定義的結(jié)果進(jìn)行返回, 從而滿足應(yīng)用程序?qū)Υ祟惽闆r的需求。

在成功對(duì)應(yīng)用程序進(jìn)行劃分后, 關(guān)鍵部分會(huì)在系統(tǒng)初始化時(shí)被預(yù)加載到安全運(yùn)行環(huán)境中, 并被Sedora保護(hù)起來。如圖2所示, 被預(yù)加載的應(yīng)用程序關(guān)鍵部分與正常部分完全分離, 通過共享內(nèi)存進(jìn)行通信。本文將應(yīng)用程序的關(guān)鍵數(shù)據(jù)部分替換為安全調(diào)用。如圖3 (4)中所示, 原有的應(yīng)用程序在執(zhí)行到需要訪問安全數(shù)據(jù)的部分會(huì)使用安全調(diào)用, 并將參數(shù)通過共享內(nèi)存?zhèn)鬟f給關(guān)鍵部分, 安全運(yùn)行環(huán)境中的關(guān)鍵部分負(fù)責(zé)處理來自正常部分的請(qǐng)求, 在執(zhí)行完成后將結(jié)果存入共享內(nèi)存。由于共享內(nèi)存會(huì)被Guest OS截取并可能被惡意修改, 因此在關(guān)鍵部分執(zhí)行完成返回時(shí), Sedora會(huì)對(duì)共享內(nèi)存中的數(shù)據(jù)進(jìn)行完整性校驗(yàn), 當(dāng)控制流回到正常部分的安全調(diào)用時(shí), 安全調(diào)用會(huì)通過 Sedora實(shí)現(xiàn)的輕量級(jí)安全通信, 利用CPUID繞過Guest OS取回校驗(yàn)碼, 同時(shí)完成對(duì)共享內(nèi)存中結(jié)果的完整性檢查, 以此來保證結(jié)果沒有被惡意的Guest OS修改。

圖3 應(yīng)用解耦和過程Figure 3 Decomposition of application

3.3 安全通信

安全通信機(jī)制是實(shí)現(xiàn)安全調(diào)用的核心, 分為輕量級(jí)安全通信和共享內(nèi)存通信。輕量級(jí)通信是Sedora為了繞過Guest OS與應(yīng)用程序直接通信的機(jī)制; 而共享內(nèi)存通信則是由Sedora為了滿足關(guān)鍵部分和正常部分通信而實(shí)現(xiàn)的 VM 間通信, 共享內(nèi)存通信的完整性安全又由輕量級(jí)安全通信保證。

3.3.1 輕量級(jí)安全通信

輕量級(jí)安全通信的實(shí)現(xiàn)依賴于虛擬化場(chǎng)景下特權(quán)指令的下陷模擬。由于 Xen負(fù)責(zé)管理所有的硬件資源, 因此當(dāng) Guest OS需要進(jìn)行硬件相關(guān)處理, 如CPUID、硬件中斷等場(chǎng)景就需要下陷到 VMM 中由VMM負(fù)責(zé)處理。CPUID作為一條特殊指令, 當(dāng)Guest VM執(zhí)行時(shí), CPU會(huì)產(chǎn)生VMEXIT并下陷到VMM中,VMM會(huì)根據(jù)下陷原因取出EAX中的ID并實(shí)際完成Guest VM所需的工作, 最終將結(jié)果返回。

Sedora選擇CPUID作為輕量級(jí)安全通信具體實(shí)現(xiàn)的原因在于CPUID可以在用戶態(tài)被調(diào)用。由于應(yīng)用程序往往會(huì)根據(jù)CPU的特性從而產(chǎn)生不同的行為,因此為了便于應(yīng)用程序開發(fā)者, 從Guest OS的視角來看, CPUID是一條非特權(quán)指令, 可以被應(yīng)用程序直接調(diào)用。但是CPUID由于與CPU硬件的特性相關(guān),Guest OS無法直接返回這樣的信息, 為了實(shí)現(xiàn)的高效, CPUID會(huì)直接下陷到VMM并由VMM來負(fù)責(zé)處理。這樣一來, 應(yīng)用程序便可通過CPUID繞過Guest OS直接將數(shù)據(jù)通過寄存器傳遞給 VMM, 而 VMM亦可通過寄存器將數(shù)據(jù)繞過Guest OS直接傳遞給應(yīng)用程序, CPUID的這一特性能夠保證通信過程中的數(shù)據(jù)安全。

在 Sedora的實(shí)現(xiàn)中, 由于不同的應(yīng)用程序可能會(huì)使用同一塊共享內(nèi)存, 存在共享內(nèi)存中數(shù)據(jù)被惡意修改的可能性, 因此輕量級(jí)通信主要保證共享內(nèi)存數(shù)據(jù)的完整性。Sedora實(shí)現(xiàn)了新的 CPUID, 當(dāng)應(yīng)用程序調(diào)用該CPUID時(shí), Sedora會(huì)計(jì)算指定的共享內(nèi)存中的校驗(yàn)碼并通過寄存器返回給應(yīng)用程序。在目前的實(shí)現(xiàn)中, Sedora為每一個(gè)Guest OS分配了16組CPUID號(hào)讓應(yīng)用程序用于完整性檢驗(yàn), 其中一組CPUID有CPUID_set與CPUID_get兩種, 分別負(fù)責(zé)計(jì)算共享內(nèi)存的校驗(yàn)值并將結(jié)果存入如表 2所示的校驗(yàn)表, 以及從校驗(yàn)表中獲取校驗(yàn)碼。每個(gè)應(yīng)用程序會(huì)只會(huì)使用一組CPUID號(hào), 不同的運(yùn)行中的應(yīng)用程序不能共享同一組CPUID號(hào)。由于CPUID的數(shù)據(jù)傳遞只能使用EAX到EDX四個(gè)32位寄存器, 因此根據(jù)校驗(yàn)碼的實(shí)現(xiàn)不同, 應(yīng)用程序可能需要調(diào)用不止一次 CPUID以獲取所有的校驗(yàn)碼?？紤]到 MD5校驗(yàn)碼長度恰好為128位, 能夠在一次CPUID中傳輸完畢, 且 MD5的使用非常普及, 表現(xiàn)出相對(duì)強(qiáng)的可靠性, 因此Sedora將其作為目前的默認(rèn)校驗(yàn)碼。

正常部分與關(guān)鍵部分需要傳輸大量數(shù)據(jù)時(shí), 作為輕量級(jí)安全通信實(shí)現(xiàn)的CPUID無法滿足需求, 因此Sedora提供了與安全運(yùn)行環(huán)境間的共享內(nèi)存通信作為大量數(shù)據(jù)的傳輸方式。

3.3.2 共享內(nèi)存通信

共享內(nèi)存的實(shí)現(xiàn)是為了滿足虛擬機(jī)間的通信需要, 在 Xen中共享內(nèi)存使用最多的情況屬于半虛擬化I/O。Guest VM中會(huì)運(yùn)行一個(gè)前端驅(qū)動(dòng), 負(fù)責(zé)處理來自Guest VM自身的I/O請(qǐng)求。而Domain0中在創(chuàng)建Guest VM時(shí)會(huì)創(chuàng)建對(duì)應(yīng)的后端驅(qū)動(dòng), 并初始化與前端內(nèi)存的共享內(nèi)存。當(dāng)前端驅(qū)動(dòng)需要讀寫數(shù)據(jù)時(shí),會(huì)首先將數(shù)據(jù)寫入共享內(nèi)存, 之后通過 Xen中的Event通知后端驅(qū)動(dòng)將共享內(nèi)存中的數(shù)據(jù)寫入實(shí)際的設(shè)備中。

Sedora實(shí)現(xiàn)了類似的通信機(jī)制, 由于輕量級(jí)安全通信能傳輸?shù)臄?shù)據(jù)量十分有限, 因此當(dāng)需要傳遞大量數(shù)據(jù)時(shí), 安全運(yùn)行環(huán)境會(huì)通過共享內(nèi)存與 Guest VM中的應(yīng)用程序通信。如圖6, 當(dāng)應(yīng)用程序在1步調(diào)用CPUID_test并根據(jù)返回值確定Sedora被正確安裝后, 應(yīng)用程序會(huì)通過已有的接口shmget和shmat請(qǐng)求Guest OS幫助其建立共享內(nèi)存。第2步shmget會(huì)使Guest OS分配一個(gè)頁而第3步shmat會(huì)使Guest OS在應(yīng)用程序的地址空間中映射這個(gè)頁, 之后通過調(diào)用Sedora新實(shí)現(xiàn)的syscallsys_setenv并傳入共享頁號(hào)和對(duì)應(yīng)權(quán)限后, Guest OS會(huì)在第5步通過hypercallhypervisor_grant_op將該頁共享給安全運(yùn)行環(huán)境, 根據(jù)需要, 應(yīng)用程序可以分別建立只讀與可寫的共享頁。Sedora在處理hypervisor_grant_op時(shí), 通過查詢授權(quán)表獲取共享頁的權(quán)限, 并修改安全運(yùn)行環(huán)境的NPT對(duì)該共享頁進(jìn)行映射, 同時(shí)Sedora會(huì)將該共享內(nèi)存與該CPUID號(hào)進(jìn)行綁定, 記錄在校驗(yàn)表中。如表2所示, CPUID 3就被綁定了對(duì)應(yīng)的共享頁。至此,安全運(yùn)行環(huán)境就與Guest VM中的應(yīng)用程序建立了共享內(nèi)存通信機(jī)制。

雖然共享內(nèi)存中的數(shù)據(jù)不屬于關(guān)鍵數(shù)據(jù), 因此不用擔(dān)心其機(jī)密性的問題。然而, 由于建立共享內(nèi)存的步驟依賴 Guest OS, 并且在之后的數(shù)據(jù)傳輸過程中Guest OS隨時(shí)可以進(jìn)行介入, 所以如何保證其完整性則是Sedora需要考慮的問題。如圖6所示, 在建立了共享內(nèi)存后, 應(yīng)用程序需要如第 7步向共享內(nèi)存中寫入隨機(jī)測(cè)試數(shù)據(jù), 并在第 8步使用綁定的CPUID_set下陷到VMM中。Sedora會(huì)對(duì)共享內(nèi)存中的數(shù)據(jù)進(jìn)行MD5校驗(yàn), 并將校驗(yàn)碼通過通過寄存器返回給應(yīng)用程序。最后, 應(yīng)用程序會(huì)將 Sedora計(jì)算的校驗(yàn)碼與自己所得的校驗(yàn)碼進(jìn)行對(duì)比以確保共享內(nèi)存確實(shí)被建立。共享內(nèi)存同樣是程序運(yùn)行期間正常部分與安全部分通信的唯一方式。

需要注意的是, 在調(diào)用CPUID后, Sedora會(huì)計(jì)算指定的共享內(nèi)存的校驗(yàn)碼, 因此每個(gè)應(yīng)用程序只能在初始化時(shí)建立與安全運(yùn)行環(huán)境的共享內(nèi)存, 當(dāng)共享內(nèi)存一但被建立, Sedora會(huì)將其與該應(yīng)用程序所使用的CPUID組號(hào)進(jìn)行綁定, 如表2所示。在之后的完整性校驗(yàn)中, Sedora會(huì)根據(jù)CPUID號(hào)直接計(jì)算與之綁定的共享內(nèi)存的校驗(yàn)信息。

表2 校驗(yàn)表Table 2 Checksum table

3.3.3 安全調(diào)用

安全調(diào)用是Sedora使用安全通信機(jī)制對(duì)應(yīng)用程序提供的封裝。由于應(yīng)用程序被解耦和為正常部分和關(guān)鍵部分, 為了將兩部分聯(lián)系起來, Sedora會(huì)在原來的應(yīng)用程序中插入安全調(diào)用。

安全調(diào)用的過程如圖4, 當(dāng)應(yīng)用需要運(yùn)行關(guān)鍵代碼時(shí), 首先將參數(shù)寫入共享內(nèi)存, 之后調(diào)用與應(yīng)用程序綁定的CPUID_set下陷到Sedora中, Sedora會(huì)校驗(yàn)共享內(nèi)存中的數(shù)據(jù)并將校驗(yàn)值填到校驗(yàn)表中, 同時(shí)返回結(jié)果給應(yīng)用程序檢查。應(yīng)用程序確認(rèn)參數(shù)無誤后便可發(fā)送Event以通知安全運(yùn)行環(huán)境。在第6步結(jié)束后, 安全運(yùn)行環(huán)境被調(diào)度, 關(guān)鍵代碼會(huì)從共享內(nèi)存中讀取數(shù)據(jù), 并通過CPUID_get獲取校驗(yàn)表中的校驗(yàn)碼進(jìn)行完整性校驗(yàn)。當(dāng)校驗(yàn)通過后, 關(guān)鍵代碼會(huì)開始運(yùn)行并將最終結(jié)果寫入共享內(nèi)存, 之后的過程與正常部分的過程一樣。安全調(diào)用執(zhí)行完畢后會(huì)將共享內(nèi)存的數(shù)據(jù)返回給應(yīng)用程序的正常部分。

安全調(diào)用的主要目的在于利于安全通信保證共享內(nèi)存的中的數(shù)據(jù)完整性并隱藏其實(shí)現(xiàn)細(xì)節(jié)。使用者不需要關(guān)注下層的具體實(shí)現(xiàn), 只需將所定義的關(guān)鍵數(shù)據(jù)和污染分析所得的關(guān)鍵部分作為參數(shù)交由關(guān)鍵調(diào)用即可。

3.4 安全運(yùn)行環(huán)境

安全運(yùn)行環(huán)境是一個(gè)被保護(hù)的虛擬機(jī), 用以支持其上運(yùn)行的安全部分。如圖5所示, 安全運(yùn)行環(huán)境作為特殊的虛擬機(jī)運(yùn)行在 Sedora之上, 其中運(yùn)行了一個(gè)必要的OS。需要注意的是, 在Sedora的實(shí)現(xiàn)中為了簡化工作量將一個(gè)成熟的 OS作為安全環(huán)境的OS來運(yùn)行, 但是實(shí)際情況中根據(jù)需要可以運(yùn)行一個(gè)僅僅包含支持庫的運(yùn)行時(shí), 以減小安全環(huán)境的資源占用。由于安全運(yùn)行環(huán)境本身僅在被調(diào)度時(shí)運(yùn)行, 且關(guān)鍵部分代碼相對(duì)較小, 因此不會(huì)占用過多資源。

安全環(huán)境自身通過配置PT運(yùn)行在SEV的保護(hù)之下, 所有內(nèi)存中的數(shù)據(jù)均為密文從而保證關(guān)鍵數(shù)據(jù)的安全。同時(shí), Sedora自身會(huì)通過NPT和自身的PT開啟SME保護(hù), 以防止攻擊者通過物理攻擊讀取NPT中的數(shù)據(jù)進(jìn)而破壞安全運(yùn)行環(huán)境的內(nèi)存隔離。SEV與SME由于對(duì)應(yīng)用層透明, 因此關(guān)鍵部分代碼不會(huì)收到任何影響。

圖4 安全調(diào)用過程Figure 4 Secure call procedure

安全運(yùn)行環(huán)境自身運(yùn)行在一個(gè)獨(dú)立的地址空間,Sedora通過NPT保證安全運(yùn)行環(huán)境與其余Guest VM的隔離。運(yùn)行環(huán)境自身相對(duì)封閉, 僅能通過在Sedora控制下的共享內(nèi)存與外界通信, 并且關(guān)鍵部分的預(yù)加載也需要經(jīng)過 Sedora的校驗(yàn)。根據(jù)安全需要,Sedora可以實(shí)施更進(jìn)一步的安全擴(kuò)展, 在預(yù)加載的校驗(yàn)階段攔截執(zhí)行流, 并執(zhí)行擴(kuò)展的安全檢查以保證關(guān)鍵部分代碼不是惡意的。正常Guest VM的I/O操作由3.3.2中所述, 需要使用Xen自身的半虛擬化I/O, 但這樣會(huì)涉及與Domain0的交互從而會(huì)打破安全運(yùn)行環(huán)境的封閉性。為了解決這個(gè)問題, Sedora采用設(shè)備直連的方式將專有的存儲(chǔ)外設(shè)直接連接到安全運(yùn)行環(huán)境, 在其中可以存放安全運(yùn)行環(huán)境 OS鏡像、對(duì)于關(guān)鍵部分的支持庫等。在特殊條件下, 可以通過配置, 將部分應(yīng)用程序數(shù)據(jù)如加密密鑰等存放于專有外部存儲(chǔ)中。

在目前 Sedora的實(shí)現(xiàn)中, 一個(gè)安全運(yùn)行環(huán)境只與一個(gè)Guest VM相對(duì)應(yīng), 由于SEV的限制, 系統(tǒng)目前最多僅支持16個(gè)Guest VM同時(shí)使用該保護(hù)。為了支持關(guān)鍵部分的執(zhí)行, 在預(yù)加載時(shí)支持庫會(huì)與關(guān)鍵部分一起被加載, 在相應(yīng)的初始化完成之后安全環(huán)境會(huì)進(jìn)入阻塞態(tài), 釋放CPU資源并等待來自應(yīng)用程序的安全調(diào)用。最終, 應(yīng)用程序的關(guān)鍵數(shù)據(jù)得以安全的運(yùn)行其中。

圖5 安全運(yùn)行環(huán)境Figure 5 Secure runtime environment

3.5 數(shù)據(jù)處理與安全控制分離

Sedora的設(shè)計(jì)目的在于保護(hù)應(yīng)用程序的關(guān)鍵數(shù)據(jù)安全。如果每次正常部分與關(guān)鍵部分進(jìn)行交互時(shí)Sedora都介入檢查, 頻繁下陷會(huì)帶來極大的性能開銷。因此, Sedora采用了安全控制與數(shù)據(jù)處理相分離的思想, 將主要的數(shù)據(jù)共享通過共享內(nèi)存交由應(yīng)用程序自身完成, 數(shù)據(jù)傳輸過程中不需要 Sedora的介入。而在數(shù)據(jù)傳輸?shù)倪吔?開始傳輸和結(jié)束傳輸),Sedora對(duì)傳輸?shù)臄?shù)據(jù)進(jìn)行完整性檢查, 并將校驗(yàn)碼存放在校驗(yàn)表中以備應(yīng)用程序檢查。整個(gè)傳輸過程與傳統(tǒng)的數(shù)據(jù)傳輸并無二致, 依舊在Guest OS的管理之下, 但是 Sedora通過輕量級(jí)安全通信和完整性檢查保證了數(shù)據(jù)不會(huì)被惡意的Guest OS所篡改。

同時(shí), Sedora使用安全調(diào)用的方式將關(guān)鍵數(shù)據(jù)和代碼均放到了安全運(yùn)行環(huán)境中, 安全控制部分交由安全運(yùn)行環(huán)境執(zhí)行, 應(yīng)用程序原有的處理邏輯保持不變, 這樣在正常數(shù)據(jù)處理中 Sedora和安全運(yùn)行環(huán)境不需要進(jìn)行任何干預(yù), 也減少了相應(yīng)的開銷和應(yīng)用程序開發(fā)者的解耦和工作。受安全檢查影響而帶來的少量開銷也只會(huì)影響占比較小的關(guān)鍵部分。

4 應(yīng)用場(chǎng)景

表3表示的是Sedora新定義的3種新CPUID, 1個(gè)新的syscall與1個(gè)新的hypercall, 通過調(diào)用這些指令Sedora可以為關(guān)鍵數(shù)據(jù)提供安全保護(hù)。整個(gè)應(yīng)用程序的生命周期如圖 6所示, 當(dāng)含有保護(hù)需求的應(yīng)用程序所在Guest VM啟動(dòng)時(shí), Sedora便一并創(chuàng)建對(duì)應(yīng)的安全運(yùn)行環(huán)境。在這個(gè)過程中, Sedora主要負(fù)責(zé)開啟安全運(yùn)行環(huán)境的SEV保護(hù), 使用NPT將其隔離并將專有存儲(chǔ)直接連接到環(huán)境中。在應(yīng)用程序預(yù)加載過程中, 由 Guest OS輔助完成共享內(nèi)存的建立,并將關(guān)鍵部分傳給安全運(yùn)行環(huán)境。在預(yù)加載的過程中應(yīng)用程序會(huì)利用安全通信檢查系統(tǒng)是否為 Sedora并完成自檢, 之后在正常運(yùn)行中使用安全調(diào)用完成功能。最后當(dāng)應(yīng)用程序結(jié)束運(yùn)行時(shí), 由 Sedora回收安全環(huán)境中的資源; 當(dāng) Guest VM 停止運(yùn)行時(shí), Sedora也會(huì)一并撤回安全運(yùn)行環(huán)境。

表3 Sedora中定義的CPUID、syscall與hypercallTable 3 New designed CPUID, syscall and hypercall in Sedora

圖6 應(yīng)用程序生命周期Figure 6 Lifecycle of protected application

4.1 利用Sedora保護(hù)OpenSSH

OpenSSH使用 RSA加密算法進(jìn)行驗(yàn)證, 在OpenSSH服務(wù)器的驗(yàn)證階段, 客戶端使用服務(wù)器的公鑰來加密數(shù)據(jù)并使用自己的私鑰對(duì)密文進(jìn)行簽名,服務(wù)器端使用客戶端的公鑰來驗(yàn)證客戶端身份, 并使用自己的私鑰來解密獲取會(huì)話密鑰。具體實(shí)現(xiàn)為兩個(gè)大質(zhì)數(shù)p和q會(huì)被用于生成兩個(gè)值與密鑰相關(guān)的值e和d, 而p和q的乘積N會(huì)被公開(N = p ×q)。當(dāng)一個(gè)客戶端連接到服務(wù)器端時(shí), 服務(wù)器端會(huì)使用私鑰(d, N)來加密數(shù)據(jù), 客戶端則可以使用對(duì)應(yīng)的公鑰(e, N)來解密數(shù)據(jù)。由于N和質(zhì)數(shù)的長度是公開的, 因此在一個(gè)惡意的Guest OS場(chǎng)景下(如Guest OS被安裝了 rootkit), 當(dāng)攻擊者想獲取私鑰時(shí), 只需要在內(nèi)存中遍歷搜索這個(gè)長度的數(shù)據(jù), 然后看是否能整除N即可快速找出該質(zhì)數(shù), 當(dāng)找到其中一個(gè)質(zhì)數(shù)時(shí), 另一個(gè)只需通過整除N即可獲得, 之后便可自行生成e和d從而獲取密鑰。

本文使用的OpenSSH為openssh-portable-7.5p1,OpenSSH會(huì)將指數(shù)質(zhì)數(shù)d存放在一個(gè)BIGNUM數(shù)據(jù)類型中的指針d中,生成密鑰的上下文則由一個(gè)BN_CTX數(shù)據(jù)結(jié)構(gòu)維護(hù)。在這個(gè)案例中, 我們定義驗(yàn)證過程中所使用的私鑰為關(guān)鍵數(shù)據(jù), 通過應(yīng)用解耦和, 使用私鑰進(jìn)行驗(yàn)證的過程放入安全運(yùn)行環(huán)境中。

我們通過手動(dòng)安裝rootkit來模擬Guest OS被攻擊從而變?yōu)閻阂獾膱?chǎng)景, 攻擊者借由 rootkit達(dá)到提權(quán)并能夠讀取Guest OS的所有內(nèi)存。由于服務(wù)器端的私鑰驗(yàn)證過程都在安全運(yùn)行環(huán)境, 因此攻擊者無法通過掃描Guest OS的內(nèi)存來找到密鑰。如果攻擊者能夠物理接觸服務(wù)器并實(shí)施 Cold Boot或 Bus Snooping等物理攻擊, 由于內(nèi)存中的數(shù)據(jù)均是加過密的, 攻擊者依舊無法讀取其中的數(shù)據(jù)。

4.2 利用Sedora保護(hù)GnuPG

GnuPG是一款加密軟件, 其作用是加密文件以保護(hù)文件中的數(shù)據(jù)隱私。在此例中GnuPG使用AES進(jìn)行加密, AES是一種對(duì)稱加密算法, 與公鑰加密系統(tǒng)不同的是, 對(duì)稱加密加密和解密使用的是同樣的密鑰, 一旦丟失那么攻擊者可以利用密鑰將密文全部解密。AES加密的加密過程一般是將明文t通過一系列與密鑰s的變換(異或、移位等), 最終生成密文e。AES的加密模式有多種, 其中ECB密碼本模式最為簡單, CTR計(jì)數(shù)器模式較為可靠, 因此我們使用這種加密模式來進(jìn)行測(cè)試。通常使用GnuPG是為了保證I/O的數(shù)據(jù)是密文從而防止攻擊者讀取I/O中屬于用戶自己的隱私數(shù)據(jù), 但是GnuPG加密所使用的密鑰存放在內(nèi)存中, 因此當(dāng)攻擊者獲取密鑰后不但可以讀取到本次加密的所有數(shù)據(jù), 所有使用該密鑰加密的文本均可以被攻擊者所讀取。

本文使用的 GnuPG為 2.0版本, 我們定義GnuPG加密所使用的密鑰s為關(guān)鍵數(shù)據(jù), 通過應(yīng)用解耦和, 使用密鑰進(jìn)行加密的代碼和密鑰本身均被加載到安全運(yùn)行環(huán)境中。此案例中對(duì)應(yīng)于3.2中所描述的情況 2), 正常部分要求關(guān)鍵部分返回加工后的數(shù)據(jù), 因此我們定義生成的密文為關(guān)鍵部分所返回的結(jié)果。當(dāng)Guest VM在第一次運(yùn)行GnuPG時(shí), 通過調(diào)用在安全運(yùn)行環(huán)境中的關(guān)鍵部分代碼生成密鑰,并將密鑰存儲(chǔ)于專有外設(shè)中。通過手動(dòng)安裝Rootkit,我們模擬了攻擊者成功攻陷Guest OS的情況, 由于密鑰存儲(chǔ)于安全環(huán)境中, 因此攻擊者無法讀取密鑰的值。即使攻擊者能夠趁機(jī)讀取部分明文, 但是已經(jīng)被加密的數(shù)據(jù)則無法讀取, 而在這段時(shí)間內(nèi), 應(yīng)用程序擁有足夠的時(shí)間來檢測(cè)出攻擊的發(fā)生并實(shí)施相應(yīng)的對(duì)抗措施。

當(dāng)正常部分需要加密數(shù)據(jù)時(shí), 明文會(huì)通過共享內(nèi)存被傳給安全部分進(jìn)行加密, 而后再將密文通過共享內(nèi)存?zhèn)骰亟o正常部分。但是這么做會(huì)產(chǎn)生大量的數(shù)據(jù)拷貝, 從而導(dǎo)致過高的開銷。所幸, 在Xen的半虛擬化I/O實(shí)現(xiàn)中, Guest VM會(huì)將數(shù)據(jù)通過共享內(nèi)存共享給Domain0, 這部分在Guest VM創(chuàng)建時(shí)便被建立并且在 VM 運(yùn)行期間保持不變, 這恰好與Sedora所要求的關(guān)鍵部分與正常部分的共享內(nèi)存特性一致, 因此通過對(duì)半虛擬化I/O中的前端進(jìn)行少量修改, 我們可以讓應(yīng)用程序所使用的共享內(nèi)存與前端共享內(nèi)存保持一致。當(dāng)應(yīng)用程序需要從通過I/O讀取明文進(jìn)行加密并再寫回磁盤時(shí), 可以通過這種復(fù)用共享的方式減少數(shù)據(jù)拷貝從而減少性能開銷。

5 安全分析

抵御物理攻擊:硬件加密內(nèi)存所帶來的最大好處就是程序運(yùn)行時(shí)內(nèi)存中的數(shù)據(jù)均為密文, 應(yīng)用程序可以利用這一特性來抵御如 bus snooping和cold-boot攻擊。這種基于硬件的攻擊一般假設(shè)攻擊者可以直接導(dǎo)出內(nèi)存數(shù)據(jù)從而進(jìn)行離線分析, 而在SEV和SMED的保護(hù)下, 攻擊者能看到的只有密文。對(duì)于如Rowhammer[15]這類bit-flip攻擊, 由于內(nèi)存中數(shù)據(jù)的實(shí)際排布經(jīng)過加密后發(fā)生了變化, 因此獲得物理上相鄰的內(nèi)存地址變得不再簡單, 而精確改變某一位則更為困難。

關(guān)鍵數(shù)據(jù)機(jī)密性:一個(gè)惡意的攻擊者想要讀取如密鑰這類關(guān)鍵數(shù)據(jù), 只能使用映射關(guān)鍵數(shù)據(jù)所在的物理頁, 從而能夠從內(nèi)存中直接讀取關(guān)鍵數(shù)據(jù)、通過網(wǎng)絡(luò)遠(yuǎn)程攻擊或使用物理攻擊直接讀取數(shù)據(jù)這幾類方法。Sedora通過NPT實(shí)現(xiàn)了安全運(yùn)行環(huán)境的內(nèi)存隔離, 攻擊者無法直接映射 Sedora所使用的物理內(nèi)存從而無法對(duì)其進(jìn)行映射; 安全運(yùn)行環(huán)境本身封閉, 對(duì)外交互只能通過共享內(nèi)存, 這使得攻擊者無法通過網(wǎng)絡(luò)等方式遠(yuǎn)程干涉關(guān)鍵代碼的執(zhí)行; 攻擊者使用物理攻擊則能夠被Sedora直接抵御。通過這些方法, 關(guān)鍵數(shù)據(jù)的機(jī)密性可以得到保證。

共享內(nèi)存完整性:由于在 Xen中, 共享內(nèi)存的建立只在Guest OS的內(nèi)核態(tài), 而共享內(nèi)存到應(yīng)用程序之間的聯(lián)系則完全由內(nèi)核來負(fù)責(zé)。因而, 攻擊者可能會(huì)利用漏洞達(dá)到對(duì)共享內(nèi)存的映射, 從而冒充被保護(hù)程序來破壞其傳遞的參數(shù)或破壞其所得結(jié)果,進(jìn)而破壞程序的正確執(zhí)行流程。Sedora通過安全通信機(jī)制, 對(duì)共享內(nèi)存的每次通信都進(jìn)行完整性檢查,并利用輕量級(jí)安全通信繞過Guest OS將檢查結(jié)果交給應(yīng)用程序, 以此來避免與關(guān)鍵代碼相關(guān)的結(jié)果和參數(shù)被惡意修改。

關(guān)閉保護(hù):Sedora提供的保護(hù)依賴于對(duì) CPUID的模擬和AMD硬件內(nèi)存加密的開啟。我們的安全調(diào)用過程不涉及到功能開啟、關(guān)閉和更改, 因此攻擊者無法在使用安全調(diào)用的過程中關(guān)閉保護(hù)機(jī)制。對(duì)于CPUID的模擬全部發(fā)生在 VMM Sedora中, 因此Guest OS無法介入修改; 硬件內(nèi)存加密的開啟和關(guān)閉則只能由VMM在host模式下調(diào)用特權(quán)指令完成,因此攻擊者無法關(guān)閉加密保護(hù); 而加密頁的管理則是由 VMM 和安全運(yùn)行環(huán)境自行維護(hù), 攻擊者無法介入管理。

I/O數(shù)據(jù)竊取:在原有系統(tǒng)中, Guest VM的密鑰需要通過I/O存放在磁盤中, 攻擊者可以在之后讀取磁盤進(jìn)行竊取。Sedora將需要離線保存的數(shù)據(jù)均存放于與安全運(yùn)行環(huán)境綁定的專有外設(shè)中, 而應(yīng)用程序運(yùn)行過程中密鑰只在安全運(yùn)行環(huán)境中被使用, 因此攻擊者無法通過I/O竊取作為關(guān)鍵數(shù)據(jù)的密鑰。

6 性能評(píng)估

6.1 測(cè)試環(huán)境

本文測(cè)試所使用的CPU為8核(16線程) Ryzen 1700X, 頻率為3.4GHz, 內(nèi)存為8G, 虛擬機(jī)監(jiān)控器版本為Xen 4.5.1, Domain0、安全運(yùn)行環(huán)境與Guest VM所使用的Linux內(nèi)核版本為4.10.2, 每個(gè)Guest VM均被分配兩個(gè)虛擬CPU與2G內(nèi)存。

6.2 應(yīng)用性能評(píng)估

對(duì)于 OpenSSH, 本文使用了一個(gè)腳本在同一個(gè)客戶端中連續(xù)使用ssh客戶端向運(yùn)行在Guest VM中的服務(wù)器端發(fā)送驗(yàn)證請(qǐng)求100, 000次并對(duì)比了服務(wù)器端正常運(yùn)行與應(yīng)用Sedora方案后的運(yùn)行情況。為了降低網(wǎng)絡(luò)延遲帶來的誤差, 測(cè)試時(shí)選擇的客戶端為同一物理機(jī)的Domain0, 測(cè)試使用的OpenSSH版本為7.5p1, 結(jié)果顯示在Sedora上運(yùn)行的服務(wù)器端延遲增加了8.68%。

對(duì)于 GnuPG, 本文將加密部分放入安全運(yùn)行環(huán)境并進(jìn)行大量的文件讀寫加解密, 測(cè)試使用了修改后的前端驅(qū)動(dòng)以減少數(shù)據(jù)拷貝帶來的性能開銷。結(jié)果如表4所示, 程序執(zhí)行的速度與文件在磁盤中的分布有關(guān)。當(dāng)文件為順序分布時(shí), 程序執(zhí)行時(shí)的瓶頸在于加解密所花的時(shí)間, 其中解密的開銷為 17.59%,加密的開銷為6.71%。經(jīng)過分析, 本文認(rèn)為造成解密開銷遠(yuǎn)高于加密的原因在于加密后的數(shù)據(jù)可以首先寫入緩沖區(qū), 之后批量寫入磁盤, 而解密所需的數(shù)據(jù)測(cè)必須每次從磁盤上讀取, 因而無法如加密寫入那樣大批量執(zhí)行。而當(dāng)文件為離散分布時(shí), 可以發(fā)現(xiàn)性能的主要的開銷在于不在于軟件而在于磁盤自身的調(diào)度, 在這種情況下 Sedora所帶來的開銷僅有解密時(shí)的2.32%與加密時(shí)的0.91%。

表4 GnuPG性能測(cè)試Table 4 Performance evaluation of GnuPG

6.3 系統(tǒng)性能評(píng)估

Sedora自身由于包含安全調(diào)用時(shí)的完整性驗(yàn)證、參數(shù)拷貝與安全環(huán)境調(diào)度等開銷, 同時(shí)由于使用了AMD的SEV技術(shù), 因此本文將評(píng)估系統(tǒng)本身軟件方面與SEV硬件加密分別帶來的開銷。本文分別在運(yùn)行普通部分的Guest VM與運(yùn)行關(guān)鍵部分的安全運(yùn)行環(huán)境(Secure Env)中運(yùn)行了 SPECCPU 2006與PARSEC 3.0包含的基準(zhǔn)測(cè)試程序, 以未修改的Xen

4.5.1 環(huán)境下的相同Guest VM中的運(yùn)行結(jié)果作為基準(zhǔn), 從而評(píng)估Sedora系統(tǒng)軟件本身與SEV硬件加密分別造成的性能開銷。其中SPECCPU 2006主要用來測(cè)試CPU單個(gè)線程的計(jì)算能力; PARSEC 3.0則是綜合測(cè)試, 包含多線程與大量內(nèi)存讀寫的測(cè)試程序。

圖7 性能測(cè)試SPECCPU2006Figure 7 Evaluation of SPECCPU2006 benchmark

圖8 性能測(cè)試PARSEC 3.0Figure 8 Evaluation of PARSEC 3.0 benchmark

圖7 顯示了 SPECCPU2006測(cè)試集的運(yùn)行結(jié)果,Sedora系統(tǒng)本身所帶來的性能開銷平均不到1%, 在誤差范圍內(nèi)幾乎可以將其忽略。安全運(yùn)行環(huán)境的平均性能開銷有5.49%, 其結(jié)果是可以接受的。其中如CPU密集型的程序如hmmer、h264ref等幾乎沒有性能開銷, 而造成性能降低最多的 mcf (17.82%)與omnetpp(16.52%)均因其存在大量內(nèi)存讀寫且測(cè)試數(shù)據(jù)在內(nèi)存中分布較為離散。被訪問數(shù)據(jù)分散會(huì)造成緩存利用率低, CPU需要頻繁訪問內(nèi)存以獲取數(shù)據(jù),由于安全運(yùn)行環(huán)境的內(nèi)存讀寫需要經(jīng)過加解密, 因此這樣的訪存中硬件加解密會(huì)是主要瓶頸。

圖 8顯示了 PARSEC3.0測(cè)試集的運(yùn)行結(jié)果,Sedora系統(tǒng)本身的軟件性能開銷只有0.68%, 對(duì)于安全運(yùn)行環(huán)境, 大部分情況下幾乎沒有性能開銷, 而總的性能開銷也僅有2.37%。其中canneal測(cè)試的性能降低則也是由大量離散訪存中內(nèi)存加解密造成。

6.4 性能分析

為了分析影響性能的因素, 本文還進(jìn)行了一些相關(guān)指令及過程的微測(cè)試以分析造成性能下降的原因。其中CPUID、MD5校驗(yàn)、安全運(yùn)行環(huán)境調(diào)度均在VM中執(zhí)行了100, 000次并取平均值作為結(jié)果。安全運(yùn)行環(huán)境的調(diào)度由于實(shí)際為一個(gè)時(shí)鐘中斷產(chǎn)生的 CPU調(diào)度, 這與一個(gè) Hypercall的調(diào)用過程類似,因此本文測(cè)量了一個(gè)空Hypercall所需的Cycle數(shù)作為替代。對(duì)于MD5校驗(yàn), 本文以256B的數(shù)據(jù)校驗(yàn)作為基準(zhǔn)。而對(duì)于硬件內(nèi)存加密的訪存開銷, 本文通過拷貝連續(xù)256M的數(shù)據(jù)并取一個(gè)4K頁的內(nèi)存拷貝作為基準(zhǔn)。

表5 指令/過程微測(cè)試Table 5 Instruction/Procedure micro-benchmark

測(cè)試的結(jié)果如表5所示, 本文的安全調(diào)用會(huì)涉及4次CPUID的調(diào)用與至少2次的MD5校驗(yàn)檢查和2次環(huán)境調(diào)度, 因此每次調(diào)度所需的 CPU開銷約為12000個(gè) cycle, 而根據(jù)與安全運(yùn)行環(huán)境共享頁大小的不同, 校驗(yàn)所需的時(shí)間也會(huì)不同, 因此應(yīng)用程序應(yīng)當(dāng)根據(jù)自己需要選擇合適大小的共享頁以提高系統(tǒng)的性能。

而運(yùn)行在安全運(yùn)行環(huán)境中程序的訪存, 每次訪問一個(gè)物理頁大約需要1989個(gè)cycle, 與沒有加密時(shí)的情況相比, 其開銷為 8.70%。因此為了提高性能,一方面, 應(yīng)用程序在解耦和時(shí)應(yīng)謹(jǐn)慎劃分關(guān)鍵部分,減小安全運(yùn)行環(huán)境中的數(shù)據(jù)和代碼; 另一方面, 減少安全運(yùn)行環(huán)境中的內(nèi)存訪問并提高緩存的命中率,這樣可以盡可能避免由內(nèi)存加密所帶來的性能下降。

7 相關(guān)工作

7.1 硬件內(nèi)存加密

安全處理器過去的幾年里在學(xué)術(shù)界已經(jīng)被廣泛研究和討論, AEGIS[16]提出了一種單芯片處理器, 該處理器能提供一個(gè)防止修改、能夠被驗(yàn)證的安全環(huán)境。XOMOS[17]利用其提出的安全處理器架構(gòu)XOM[17], 在現(xiàn)有的操作系統(tǒng)中支持共享庫、進(jìn)程間通信等等?；谟布?nèi)存加密, 研究者們也不停改進(jìn)內(nèi)存加密與完整性驗(yàn)證。Brian等人[19]利用與地址無關(guān)的種子加密(Address Independent Seed Encryption,AISE)來進(jìn)一步優(yōu)化計(jì)數(shù)加密模式并結(jié)合 Bonsai 默克爾樹, 通過保護(hù)交換內(nèi)存來提高基于默克爾樹的內(nèi)存完整性驗(yàn)證的性能和安全。基于安全處理器架構(gòu), 相應(yīng)的出現(xiàn)了保護(hù)關(guān)鍵安全應(yīng)用程序不受不可信操作系統(tǒng)和物理攻擊影響的 Bastion[20]與SecureME[21], 其中SecureME還結(jié)合了如內(nèi)存隱身、系統(tǒng)調(diào)用保護(hù)等手段。HyperCoffer[22-23]則首先提出利用安全加密內(nèi)存器, 在不可信的虛擬機(jī)監(jiān)控器上運(yùn)行虛擬機(jī), 它同樣基于高效的內(nèi)存加密機(jī)制 AISE和完整性驗(yàn)證技術(shù)BMT, 通過在虛擬機(jī)中引入shim層來解決VM與VMM之間的語義斷層, 最終能夠支持不加修改的、包含商業(yè)軟件在內(nèi)的虛擬化技術(shù)。

在學(xué)術(shù)界對(duì)于硬件內(nèi)存加密如火如荼地研究推動(dòng)下, 各主流處理器廠商也推出了相應(yīng)的具有內(nèi)存加密支持的產(chǎn)品。Intel推出了SGX, 一種對(duì)CPU的硬件擴(kuò)展和一系列在用戶態(tài)可以使用的新指令, 它能夠讓應(yīng)用程序在用戶態(tài)直接申請(qǐng)被稱為“飛地”的私有內(nèi)存。其啟動(dòng)時(shí), CPU內(nèi)生成加密密鑰并用其來加密飛地內(nèi)的數(shù)據(jù), 數(shù)據(jù)僅能被創(chuàng)建它的應(yīng)用程序自身訪問, 即使是權(quán)限級(jí)更高的操作系統(tǒng)也無法進(jìn)行讀取和修改?；?SGX, 有大量的工作來用其保護(hù)軟件的安全[24,29], 或者提高SGX本身的安全[29-30]。SCONE[24]利用 SGX 來提高容器機(jī)制存在的一些局限性; Haven[25]能夠?qū)⑽葱薷牡膽?yīng)用程序的代碼和數(shù)據(jù)置于SGX中, 以此來提防脆弱的操作系統(tǒng); M2R[26]和VC3[27]都使用了SGX來增強(qiáng)MapReduce框架從而能夠保護(hù)分布式計(jì)算中隱私數(shù)據(jù)的安全; Ryoan[28]利用 SGX, 在面對(duì)不可信的服務(wù)提供商的情況下,保護(hù)數(shù)據(jù)處理服務(wù)的隱私數(shù)據(jù)安全。另一方面, 為了增強(qiáng)SGX飛地本身的安全, 如SGX-Shiled[29]被用于為運(yùn)行在飛地內(nèi)的應(yīng)用程序提供地址空間隨機(jī)化;T-SGX[30]則利用了硬件事物內(nèi)存來根除針對(duì)于運(yùn)行在飛地內(nèi)應(yīng)用程序、基于頁錯(cuò)誤的側(cè)信道攻擊。

正如本文在第2.1節(jié)所介紹的, AMD也推出了具有硬件內(nèi)存加密支持SME和SEV的處理器, 具有特權(quán)級(jí)的代碼能夠通過設(shè)置頁表項(xiàng)中的C-bit來管理加密頁, 雖然與已經(jīng)現(xiàn)世幾年的 SGX相比, SME與SEV還沒有經(jīng)過足夠多的測(cè)試和驗(yàn)證, 支持SEV的對(duì)應(yīng)硬件甚至還沒有發(fā)售, 但是相比于SGX的復(fù)雜過程, SME與SEV簡單易用, 對(duì)上層透明的特點(diǎn)依舊具有極強(qiáng)的吸引力。Sedora是首先提出利用 SEV與SME來保護(hù)應(yīng)用程序在不可信Guest OS中數(shù)據(jù)安全的解決方案, 并利用硬件加密機(jī)制測(cè)試了相應(yīng)的性能開銷。

7.2 應(yīng)用數(shù)據(jù)保護(hù)

對(duì)于應(yīng)用關(guān)鍵數(shù)據(jù)保護(hù), 學(xué)術(shù)界已有諸多研究。SeCage[7]利用Intel推出的VMFUNC指令, 對(duì)kvm進(jìn)行安全擴(kuò)展, 達(dá)到高效的敏感數(shù)據(jù)隔離, 但是 AMD卻沒有VMFUNC的支持, 甚至實(shí)現(xiàn)嵌套頁表的方法與Intel也有非常大的差異; Mimosa[31]將使用密鑰的過程置于硬件事務(wù)內(nèi)存中, 利用攻擊者惡意讀取密鑰時(shí)產(chǎn)生的事務(wù)中斷來發(fā)現(xiàn)攻擊者; Shred[32]通過修改編譯器并結(jié)合內(nèi)核模塊, 建立新的程序原語, 保證一個(gè)Shred內(nèi)的內(nèi)存僅能被Shred內(nèi)的代碼訪問;DieHarder[33]提出了一個(gè)面向安全的內(nèi)存分配器來抵御基于堆的內(nèi)存攻擊而 CRYPTON[34]則設(shè)計(jì)了一個(gè)新的數(shù)據(jù)抽象和讀取原語來保證數(shù)據(jù)的隔離, 但是這兩者都要依賴操作系統(tǒng)本身的龐大的庫。

其他的一些軟件的加密手段則是嘗試將加密密鑰僅存放在CPU中并通過加密來保證應(yīng)用數(shù)據(jù)的機(jī)密性。Safekeeping[35]利用了x86的SSE MMX寄存器來保證密鑰自始至終只存在于寄存器中, 在保證高效加密的同時(shí)也避免了密鑰的泄露。類似的,Copker[36]在CPU中實(shí)現(xiàn)了非對(duì)稱加密, 無論明文或密鑰均不會(huì)出現(xiàn)在內(nèi)存中。這些方法的核心是利用緩存只對(duì)CPU可見的特點(diǎn), 將加解密過程置于緩存中以達(dá)到對(duì)密鑰和明文的保護(hù), 但是這些方法在編程時(shí)需要極為小心, 并且加密過程本身仍然依賴于操作系統(tǒng)本身。

由于 VMM 運(yùn)行在更高的特權(quán)級(jí), 因此有許多學(xué)者嘗試?yán)锰摂M化技術(shù)來實(shí)現(xiàn)對(duì)應(yīng)用數(shù)據(jù)保護(hù),比如 CHAOS[37-38]、OverShadow[8]和 Appshield[39]等系統(tǒng)就利用了虛擬化技術(shù)提供的內(nèi)存隔離并介入被保護(hù)程序和OS之間的切換來應(yīng)用安全策略, 達(dá)到保護(hù)應(yīng)用程序的目標(biāo); HyperCrypt[40]從Hypervisor層面直接對(duì)整個(gè)Guest OS進(jìn)行加密來抵御針對(duì)內(nèi)存的物理攻擊。與Sedora相比, 這些方案均具有更大的TCB,且內(nèi)存中的數(shù)據(jù)依舊為明文, 因此無法抵御如 Bus Snooping等物理攻擊。

8 討論與局限

部署工作量:Sedora的部署需要應(yīng)用解耦和, 因此需要應(yīng)用程序的使用者定義關(guān)鍵數(shù)據(jù), 并將應(yīng)用程序進(jìn)行分離, 雖然這一過程還不能純自動(dòng)化實(shí)現(xiàn),但是一些現(xiàn)有半自動(dòng)化工具如 CIL能夠一定程度上簡化工作。與本文工作相比, SeCage[7]僅支持僅允許有限的少量代碼作為隱秘部分, 而 Sedora支持更加粗粒度的應(yīng)用解耦, 并保證運(yùn)行在安全環(huán)境中的數(shù)據(jù)和代碼不會(huì)受到攻擊者攻擊, 但是應(yīng)用程序需要對(duì)關(guān)鍵部分大小與性能開銷進(jìn)行權(quán)衡。而OverShadow[8]與Appshield[39]等基于虛擬化技術(shù)的方案則需要對(duì)系統(tǒng)做更多改動(dòng)。

保護(hù)范圍:Sedora被設(shè)計(jì)用于保護(hù)應(yīng)用程序的關(guān)鍵數(shù)據(jù)如密鑰、與用戶相關(guān)的隱私信息等, 相關(guān)的代碼和數(shù)據(jù)被劃分為關(guān)鍵部分運(yùn)行在隔離的安全運(yùn)行環(huán)境中。安全運(yùn)行環(huán)境本身的封閉性以及硬件加密保護(hù)保證了其中的數(shù)據(jù)不會(huì)被攻擊者竊取。但Sedora不提供關(guān)鍵部分返回結(jié)果的機(jī)密性保護(hù), 也不保護(hù)通過網(wǎng)絡(luò)等其他方式傳送的數(shù)據(jù)。

惡意應(yīng)用程序調(diào)用:由于 Sedora的安全運(yùn)行環(huán)境為虛擬機(jī)粒度, 因而存在惡意的應(yīng)用程序冒充被保護(hù)應(yīng)用程序的CPUID號(hào)來發(fā)起計(jì)算請(qǐng)求, 從而獲取計(jì)算后的結(jié)果。然而這些結(jié)果本身不屬于關(guān)鍵數(shù)據(jù), 并且攻擊者即使獲取這些結(jié)果對(duì)其本身而言意義不大。而且, 這個(gè)問題可以通過強(qiáng)制每個(gè)應(yīng)用程序進(jìn)程號(hào)與其共享內(nèi)存、CPUID唯一綁定來解決。

關(guān)鍵部分支持庫:在安全運(yùn)行環(huán)境中運(yùn)行的代碼如果需要用到其他的庫, 那么用戶需要在預(yù)加載時(shí)同時(shí)提供這些庫。因此Sedora不支持關(guān)鍵部分對(duì)正常部分的數(shù)據(jù)訪問, 這在一定程度上限制了Sedora的應(yīng)用場(chǎng)景。但是好的應(yīng)用設(shè)計(jì)和解耦和能夠解決這一問題, 同時(shí)相對(duì)隔離的系統(tǒng)設(shè)計(jì)對(duì)于安全方面也是更高的保護(hù)。

安全運(yùn)行環(huán)境:由于AMD硬件限制, SEV目前僅支持最多16個(gè)VM, 而安全運(yùn)行環(huán)境與VM相對(duì)應(yīng), 因此Sedora目前也僅支持最多16個(gè)安全運(yùn)行環(huán)境同時(shí)運(yùn)行。但是通過更改設(shè)計(jì), 可以實(shí)現(xiàn)多個(gè)VM共享一個(gè)安全運(yùn)行環(huán)境以此來提高資源的利用率,這也是本文的后續(xù)工作之一。除此之外, 隨著更新一代CPU的發(fā)布, 隨著SEV支持的VM數(shù)量上升, 這種情況也能得到一定程度的緩解。

應(yīng)用程序支持:在目前的實(shí)現(xiàn)中, 應(yīng)用程序通過CPUID進(jìn)行區(qū)分, 一個(gè)VM支持16個(gè)應(yīng)用程序同時(shí)使用 Sedora提供的安全保護(hù), 雖然本文認(rèn)為同一VM 中需要被保護(hù)的應(yīng)用程序數(shù)量往往有限, 但這一限制亦可通過配置更多的CPUID號(hào)進(jìn)行緩解。本文發(fā)現(xiàn)目前保留的CPUID非常多, 可以被大量使用,因此在后續(xù)工作中我們將借此提供一個(gè)用戶可配置的參數(shù)以支持更多CPUID的需求。

硬件內(nèi)存加密:由于硬件內(nèi)存加密是在發(fā)生內(nèi)存訪問時(shí)實(shí)時(shí)進(jìn)行的, 加密的復(fù)雜度會(huì)嚴(yán)重影響用戶的使用體驗(yàn), 因此目前AMD的硬件內(nèi)存加密使用的是較為高效的AES加密。加密時(shí)硬件會(huì)將內(nèi)存頁的物理地址作為加密的相關(guān)信息納入計(jì)算, 因此同樣的數(shù)據(jù)在不同的物理頁中得到的密文也不相同,攻擊者無法通過直接拷貝物理頁來達(dá)到復(fù)制數(shù)據(jù)的目的。然而, 目前的硬件不支持對(duì)加密頁的完整性保護(hù), 這意味著攻擊者可以使用同一物理頁進(jìn)行重放攻擊, 比如向服務(wù)器驗(yàn)證端發(fā)送同樣的加密后的密碼來攻擊驗(yàn)證程序。不過, 物理內(nèi)存頁由虛擬機(jī)監(jiān)控器管理, 攻擊者不得不在獲取Guest OS權(quán)限后進(jìn)一步獲取 VMM 權(quán)限才有實(shí)施這種攻擊的可能, 這已超出了本文的討論范圍。

AMD硬件內(nèi)存加密的加密單位為4K頁, 明文數(shù)據(jù)的變動(dòng)僅影響該物理頁對(duì)應(yīng)的密文變動(dòng)。因此通過頻繁改寫某一內(nèi)存數(shù)據(jù), 攻擊者雖然無法定位明文的具體位置, 但仍可以精確到頁粒度, 這在一定程度上降低了加密的安全度。不過, 與傳統(tǒng)的內(nèi)存相比, 由于任何數(shù)據(jù)的變動(dòng)都會(huì)影響整個(gè)物理頁的密文, 因此這在一定程度上也提高了基于內(nèi)存數(shù)據(jù)位跳變的 Rowhammer[15]攻擊, 和基于內(nèi)存訪問模式推測(cè)密鑰的側(cè)信道[14]攻擊的門檻, 從而提升了系統(tǒng)對(duì)物理攻擊的抵抗性。

目前, 硬件內(nèi)存加密依賴于對(duì)VMM的信任, 但是 VMM 本身亦可能存在漏洞, 所以硬件內(nèi)存加密的安全性仍有提升的空間。所幸, AMD已經(jīng)提出了下一代 SEV-ES, 它能夠?yàn)橐恍┲匾募用軘?shù)據(jù)提供完整性保護(hù), 并將更多的 VMM 代碼排除在可信基之外, 因此本文相信硬件加密的安全性將越來越高。

對(duì)比Intel SGX: 除了AMD的SME與SEV機(jī)制, Intel在早先已經(jīng)發(fā)布了安全防護(hù)擴(kuò)展SGX[9]。相比較AMD的硬件內(nèi)存加密, SGX能夠在非虛擬化的情況下直接保護(hù)應(yīng)用程序免受惡意操作系統(tǒng)的攻擊。但是SGX的API眾多, 使用繁復(fù), 且需要應(yīng)用程序重新設(shè)計(jì)編寫以利用 SGX提供的安全保護(hù)功能。在現(xiàn)有版本中, 大規(guī)模的應(yīng)用SGX會(huì)對(duì)應(yīng)用開發(fā)者提出過高的要求。而SEV與SME則將這部分工作轉(zhuǎn)交給更加熟悉系統(tǒng)的系統(tǒng)開發(fā)人員, 從而減輕應(yīng)用開發(fā)人員的工作難度。

SGX通過通過將物理內(nèi)存頁標(biāo)記為“飛地”并進(jìn)行加密并提供完整性保護(hù), 只有對(duì)應(yīng)的應(yīng)用程序可以進(jìn)行訪問, 以此來保證應(yīng)用程序的數(shù)據(jù)安全。但是申請(qǐng)的內(nèi)存數(shù)量有限, 因此SGX不能實(shí)現(xiàn)如SEV一般的全虛擬機(jī)保護(hù), 這也反映出兩者之間的側(cè)重不同。

9 結(jié)論

本文設(shè)計(jì)并實(shí)現(xiàn)了一個(gè)在虛擬化環(huán)境下, 保護(hù)應(yīng)用程序關(guān)鍵數(shù)據(jù)安全的方案 Sedora。該方案是第一個(gè)使用 AMD硬件內(nèi)存加密來保護(hù)應(yīng)用程序關(guān)鍵數(shù)據(jù)安全的方案。通過將應(yīng)用程序解耦和為正常部分與關(guān)鍵部分, 將關(guān)鍵部分部署在安全運(yùn)行環(huán)境中從而其安全。該方案實(shí)現(xiàn)的安全運(yùn)行環(huán)境相對(duì)封閉并由AMD的硬件內(nèi)存加密機(jī)制提供保護(hù), 通過系統(tǒng)實(shí)現(xiàn)的安全通信機(jī)制中的共享內(nèi)存與正常部分進(jìn)行通信, 其完整性受安全調(diào)用的保護(hù)。應(yīng)用場(chǎng)景展示了該方案可以被應(yīng)用于常見應(yīng)用程序, 安全分析證明了該方案能夠保護(hù)應(yīng)用程序關(guān)鍵數(shù)據(jù)免受惡意操作系統(tǒng)和部分物理攻擊的侵害, 性能評(píng)估則證明了該方案的可行性。

在后續(xù)工作中, 安全調(diào)用將被優(yōu)化以支持更多的應(yīng)用程序, 而安全運(yùn)行環(huán)境則被重構(gòu)為支持更多的虛擬機(jī)。對(duì)于應(yīng)用解耦和過程, 后續(xù)也將考慮尋找更加自動(dòng)化的工具對(duì)應(yīng)用進(jìn)行解耦和。

[1]Durumeric, Zakir, et al. “The matter of heartbleed.”Proceedings of the 2014 Conference on Internet Measurement Conference. ACM,2014.

[2]Ledbetter Jr, William B., and Russell A. Reininger. “Method for data bus snooping in a data processing system by selective concurrent read and invalidate cache operation.” U.S. Patent No.5,119,485. 2 Jun. 1992.

[3]Halderman, J. Alex, et al. “Lest we remember: cold-boot attacks on encryption keys.”Communications of the ACM52.5 (2009): 91-98.

[4]Dautenhahn, Nathan, et al. “Nested kernel: An operating system architecture for intra-kernel privilege separation.” ACM SIGPLAN Notices 50.4 (2015): 191-206.

[5]Kaplan, David, Jeremy Powell, and Tom Woller. “AMD memory encryption.” White paper, Apr (2016).

[6]Barham, Paul, et al. “Xen and the art of virtualization.”ACM SIGOPS operating systems review. Vol. 37. No. 5. ACM, 2003.

[7]Liu, Yutao, et al. “Thwarting memory disclosure with efficient hypervisor-enforced intra-domain isolation.”Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security. ACM, 2015.

[8]Chen, Xiaoxin, et al. “Overshadow: a virtualization-based approach to retrofitting protection in commodity operating systems.”ACM SIGARCH Computer Architecture News. Vol. 36. No.1. ACM, 2008.

[9]Ittai Anati, Shay Gueron, Simon Johnson, and Vincent Scarlata.2013. Innova- tive technology for CPU based attestation and sealing.In Proceedings of the 2nd international workshop on hardware and architectural support for security and privacy, Vol. 13.

[10]Virtualization, AMD64. “Secure virtual machine architecture reference manual.”AMD Publication33047 (2005).

[11]Uhlig, Rich, et al. “Intel virtualization technology.”Computer38.5(2005): 48-56.

[12]Virtualization, A. M. D. “Amd-v nested paging.” White paper.[Online]Available: http://sites. amd. com/us/business/it-solutions/virtualization/Pages/amd-v. aspx (2008).

[13]Necula, George, et al. “CIL: Intermediate language and tools for analysis and transformation of C programs.”Compiler Construction. Springer Berlin/Heidelberg, 2002.

[14]Cherednichenko, Oksana, A. A. Baranov, and T. I. Morozova.“Side-channel Attack.” (2013).

[15]Kim, Yoongu, et al. “Flipping bits in memory without accessing them: An experimental study of DRAM disturbance errors.”ACM SIGARCH Computer Architecture News. Vol. 42. No. 3. IEEE Press, 2014.

[16]Suh, G. Edward, et al. “AEGIS: architecture for tamper-evident and tamper-resistant processing.”Proceedings of the 17th annual international conference on Supercomputing.ACM, 2003.

[17]Lie, David, Chandramohan A. Thekkath, and Mark Horowitz.“Implementing an untrusted operating system on trusted hardware." ACM SIGOPS Operating Systems Review 37.5 (2003):178-192.

[18]Lie, David, et al. “Architectural support for copy and tamper resistant software.” ACM SIGPLAN Notices 35.11 (2000): 168-177.

[19]Rogers, Brian, et al. “Using address independent seed encryption and bonsai merkle trees to make secure processors os-and performance-friendly.” Microarchitecture, 2007. MICRO 2007.40th Annual IEEE/ACM International Symposium on. IEEE, 2007.

[20]Champagne, David, and Ruby B. Lee. “Scalable architectural support for trusted software.”High Performance Computer Architecture (HPCA), 2010 IEEE 16th International Symposium on. IEEE,2010.

[21]Chhabra, Siddhartha, et al. “SecureME: a hardware-software approach to full system security.”Proceedings of the international conference on Supercomputing. ACM, 2011.

[22]Xia, Yubin, Yutao Liu, and Haibo Chen. “Architecture support for guesttransparent VM protection from untrusted hypervisor and physical attacks.”High Performance Computer Architecture (HPCA2013),2013 IEEE 19th International Symposium on. IEEE, 2013.

[23]Xia, Yubin, et al. “Secure outsourcing of virtual appliance.”IEEE Transactions on Cloud Computing(2015).

[24]Arnautov, Sergei, et al. “SCONE: Secure Linux Containers with Intel SGX.” OSDI. 2016.

[25]Baumann, Andrew, Marcus Peinado, and Galen Hunt. “Shielding applications from an untrusted cloud with haven.” ACM Transactions on Computer Systems (TOCS) 33.3 (2015): 8.

[26]Dinh, Tien Tuan Anh, et al. “M2R: Enabling Stronger Privacy in MapReduce Computation.”USENIX Security Symposium. 2015.

[27]Schuster, Felix, et al. “VC3: Trustworthy data analytics in the cloud using SGX.”Security and Privacy (SP), 2015 IEEE Symposium on. IEEE, 2015.

[28]Hunt, Tyler, et al. “Ryoan: A Distributed Sandbox for Untrusted Computation on Secret Data.” OSDI. 2016.

[29]Seo, Jaebaek, et al. “SGX-Shield: Enabling address space layout randomization for SGX programs.”Proceedings of the 2017 Annual Network and Distributed System Security Symposium (NDSS),San Diego, CA. 2017.

[30]Shih, Ming-Wei, et al. “T-SGX: Eradicating controlled-channel attacks against enclave programs.”Proceedings of the 2017 Annual Network and Distributed System Security Symposium (NDSS), San Diego, CA. 2017.

[31]Guan, Le, et al. “Protecting private keys against memory disclosure attacks using hardware transactional memory.”Security and Privacy (SP), 2015 IEEE Symposium on. IEEE, 2015.

[32]Chen, Yaohui, et al. “Shreds: Fine-grained execution units with private memory.”Security and Privacy (SP), 2016 IEEE Symposium on. IEEE, 2016.

[33]Novark, Gene, and Emery D. Berger. “DieHarder: securing the heap.”Proceedings of the 17th ACM conference on Computer and communications security. ACM, 2010.

[34]Dong, Xinshu, et al. “Protecting sensitive web content from client-side vulnerabilities with CRYPTONS.”Proceedings of the 2013 ACM SIGSAC conference on Computer & communications security. ACM, 2013.

[35]Parker, T. Paul, and Shouhuai Xu. “A Method for Safekeeping Cryptographic Keys from Memory Disclosure Attacks.”INTRUST.2009.

[36]Guan, Le, et al. “Copker: Computing with Private Keys without RAM.”NDSS. 2014.

[37]Chen, Haibo, et al. “Daonity–Grid security from two levels of virtualization.”information security technical report12.3 (2007):123-138.

[38]Chen, Haibo, et al. “Tamper-resistant execution in an untrusted operating system using a virtual machine monitor.” (2007).

[39]Cheng, Yueqiang, Xuhua Ding, and R. Deng. “Appshield: Protecting applications against untrusted operating system.”Singaport Management University Technical Report, SMU-SIS-13101 (2013).

[40]G?tzfried, Johannes, et al. “HyperCrypt: Hypervisor-based Encryption of Kernel and User Space.”Availability, Reliability and Security (ARES), 2016 11th International Conference on. IEEE,2016.