何 運(yùn), 賈曉啟, 劉 鵬, 張偉娟

1中國(guó)科學(xué)院信息工程研究所 北京 中國(guó) 100093

2中國(guó)科學(xué)院大學(xué)網(wǎng)絡(luò)空間安全學(xué)院 北京 中國(guó) 100049

3賓夕法尼亞州立大學(xué) 賓夕法尼亞 美國(guó) 16802

1 引言

云計(jì)算作為一種新興計(jì)算模式, 由于其低成本、靈活性、高度自動(dòng)化等特點(diǎn)而備受關(guān)注。越來(lái)越多的企業(yè)將其應(yīng)用程序和數(shù)據(jù)遷移到云平臺(tái), 文獻(xiàn)[1]調(diào)查顯示幾乎有一半的公司表示其IT系統(tǒng)中有31%～60%是基于云平臺(tái)進(jìn)行部署的。此外, 預(yù)計(jì)到2024年全球云計(jì)算市場(chǎng)將突破1萬(wàn)億美元[2]。然而, 云計(jì)算迅速發(fā)展的過(guò)程中也面臨著諸多安全挑戰(zhàn)。近期的調(diào)查報(bào)告[3-5]指出云計(jì)算安全問(wèn)題已成為企業(yè)部署或使用云平臺(tái)時(shí)首要考慮的因素。云安全聯(lián)盟(Cloud Security Alliance, 簡(jiǎn)稱CSA)發(fā)布的一份報(bào)告[6]歸納了云計(jì)算中的12大安全威脅, 其中惡意內(nèi)部人員攻擊(Insider Attacks)排名第六。此類攻擊通常由某個(gè)組織中(如云服務(wù)提供商)的惡意內(nèi)部人員發(fā)起。例如, DuPont公司的商業(yè)機(jī)密被一位前工程師偷走并泄露給競(jìng)爭(zhēng)對(duì)手[7]。2016年美國(guó)網(wǎng)絡(luò)犯罪狀況調(diào)查發(fā)現(xiàn), 27%的網(wǎng)絡(luò)犯罪是由內(nèi)部人士造成的[8], 該調(diào)查還顯示, 30%的受訪者認(rèn)為內(nèi)部人員攻擊造成的損害比外部攻擊造成的損害更加嚴(yán)重。針對(duì)云平臺(tái)環(huán)境, 云服務(wù)提供商的惡意內(nèi)部人員很容易竊取客戶虛擬機(jī)的敏感數(shù)據(jù)[9-10]?？紤]一個(gè)常見(jiàn)場(chǎng)景: 當(dāng)客戶虛擬機(jī)中的某個(gè)進(jìn)程正在執(zhí)行加密(或解密)操作, 此時(shí)云服務(wù)提供商的某些惡意內(nèi)部人員, 如云平臺(tái)運(yùn)維人員(Cloud Operators), 可能會(huì)對(duì)客戶虛擬機(jī)執(zhí)行內(nèi)存快照(Memory Dump)操作, 然后可以輕松地從內(nèi)存快照文件中恢復(fù)密鑰, 本文將此類攻擊稱作內(nèi)存快照攻擊(Memory Dump Attacks)。

針對(duì)惡意內(nèi)部攻擊, 文獻(xiàn)[11-14]通過(guò)分析內(nèi)部人員的行為記錄來(lái)檢測(cè)未經(jīng)授權(quán)或非法訪問(wèn)云租戶數(shù)據(jù)的異常事件。然而, 這些方法并不總是奏效, 因?yàn)榭蛻籼摂M機(jī)中的敏感數(shù)據(jù)已經(jīng)被竊取, 即便后續(xù)發(fā)現(xiàn)了此類攻擊行為。為了防止惡意內(nèi)部人員對(duì)云租戶數(shù)據(jù)進(jìn)行窺探或篡改, TCCP[15]為客戶虛擬機(jī)提供一個(gè)封閉的執(zhí)行環(huán)境, 將客戶虛擬機(jī)運(yùn)行于該執(zhí)行環(huán)境中。但TCCP尚未實(shí)現(xiàn)其方案的原型系統(tǒng), 并且該方案需要依賴第三方信任代理。Overshadow[16]設(shè)計(jì)了一種mutli-shadowing機(jī)制, 該機(jī)制為物理內(nèi)存的提供不同視圖(view)。 具體而言, Overshadow為應(yīng)用程序提供其內(nèi)存頁(yè)的明文視圖, 而為客戶操作系統(tǒng)提供加密視圖, 其目的在于保護(hù)客戶操作系統(tǒng)內(nèi)運(yùn)行的應(yīng)用程序的機(jī)密性和完整性。然而, Overshadow機(jī)制中的加密計(jì)算過(guò)程都是在內(nèi)存中完成, 用于加密的密鑰也存儲(chǔ)在內(nèi)存中。換句話說(shuō), Overshadow也不能抵御內(nèi)存快照攻擊。

Intel SGX[17]是Intel CPU的一套指令集擴(kuò)展, 它提供硬件支持的可信執(zhí)行環(huán)境(被命名為Enclave)來(lái)運(yùn)行受信任的代碼。受信任的代碼和數(shù)據(jù)駐留在受CPU保護(hù)內(nèi)存區(qū)域中, 該內(nèi)存區(qū)域?yàn)镋nclave Page Cache(EPC)。SGX僅允許在Enclave中執(zhí)行的受信任代碼訪問(wèn)EPC。EPC內(nèi)存區(qū)域受硬件加密引擎(Memory Encryption Engine)保護(hù)。即使是不受信任的操作系統(tǒng)或虛擬機(jī)管理程序(Virtual Machine Monitor, 也稱作 Hypervisor)也不能破壞受硬件保護(hù)的Enclave。理論上, 內(nèi)存快照攻擊對(duì)SGX無(wú)效, 但將SGX應(yīng)用到云平臺(tái)時(shí)會(huì)存在一些限制, 主要有以下幾個(gè)方面。a) 內(nèi)存資源限制。為Intel SGX保留的物理內(nèi)存最多為128MB, 而實(shí)際可用的為93MB。雖然可通過(guò)在EPC和非EPC之間執(zhí)行內(nèi)存換入/換出來(lái)支持Enclave訪問(wèn)超過(guò)128MB的虛擬地址空間。但這將導(dǎo)致代價(jià)高昂的上下文切換(即Enclave進(jìn)入/退出操作), 并導(dǎo)致性能顯著下降[18]。b) 側(cè)信道攻擊威脅。Intel SGX無(wú)法抵御側(cè)信道攻擊(side-channel)。例如, 在基于頁(yè)面錯(cuò)誤(page fault)的側(cè)信道攻擊[19]中, 不受信任的操作系統(tǒng)可以通過(guò)頁(yè)面錯(cuò)誤信息推測(cè)Enclave訪問(wèn)內(nèi)存頁(yè)面的規(guī)律進(jìn)而竊取敏感數(shù)據(jù)。此外, 最近的研究[20-21]表明, Intel SGX也容易受到基于緩存的側(cè)信道攻擊。c) 實(shí)際部署限制。在客戶操作系統(tǒng)中運(yùn)行SGX應(yīng)用程序需要虛擬機(jī)管理程序(Hypervisor)的支持。然而, 支持SGX的開源虛擬機(jī)管理程序, 如kvm-sgx[22]和xen-sgx[23]還處在研發(fā)階段尚不能用于實(shí)際部署支持SGX的云虛擬機(jī)。

針對(duì)上述由惡意內(nèi)部人員發(fā)起的內(nèi)存快照攻擊(Memory Dump Attacks), 本文提出并實(shí)現(xiàn)了一個(gè)名為HCoper(Hypervisor Cryptographic operations outside RAM)的解決方案, 該方案在內(nèi)存外部執(zhí)行加密算法, 整個(gè)加密運(yùn)算過(guò)程僅在CPU內(nèi)部完成, 只涉及CPU寄存器和緩存(Cache)的使用, 進(jìn)而使得整個(gè)加密計(jì)算過(guò)程中不會(huì)將任何機(jī)密數(shù)據(jù)(如數(shù)據(jù)加密密鑰)或中間結(jié)果導(dǎo)出到系統(tǒng)內(nèi)存中。從而使得內(nèi)存快照攻擊無(wú)法從內(nèi)存鏡像文件中恢復(fù)出數(shù)據(jù)加密密鑰。此外, HCoper不受側(cè)信道攻擊的影響(將在第6.2節(jié)中討論), HCoper可方便地部署, 而無(wú)任何內(nèi)存限制。具體地, HCoper采用一種通用的key-encryption- key結(jié)構(gòu), 主密鑰存儲(chǔ)在寄存器中, 數(shù)據(jù)加密密鑰由主密鑰加密后以密文狀態(tài)存儲(chǔ)在RAM中。本文中的主密鑰特指用于加密其他密鑰的密鑰, 主密鑰不用于數(shù)據(jù)加密用途。相應(yīng)地, 數(shù)據(jù)加密密鑰(也稱加密密鑰)特指用于數(shù)據(jù)加密用途的密鑰, 數(shù)據(jù)加密密鑰是主密鑰加密的對(duì)象。執(zhí)行加密(或解密)計(jì)算任務(wù)時(shí), 密文狀態(tài)的數(shù)據(jù)加密密鑰會(huì)被動(dòng)態(tài)解密后直接加載到寄存器中, 使得明文態(tài)的密鑰永遠(yuǎn)不會(huì)被加載到RAM中。存儲(chǔ)主密鑰或數(shù)據(jù)加密密鑰的寄存器屬于特權(quán)資源, 只允許HCoper對(duì)其進(jìn)行訪問(wèn)。對(duì)這些寄存器的任何讀寫操作都將被HCoper捕獲并攔截(見(jiàn)4.2節(jié))。此外, HCoper提供動(dòng)態(tài)調(diào)度密鑰的機(jī)制, 以支持多應(yīng)用多密鑰場(chǎng)景。

本文利用Intel AES-NI[24]機(jī)制實(shí)現(xiàn)了HCoper的原型系統(tǒng), Intel AES-NI支持在CPU內(nèi)完成加密算法(即AES)。特別地, HCoper將主密鑰存儲(chǔ)在MSR寄存器(即x86 Model Specific Registers)中。當(dāng)HCoper運(yùn)行時(shí), 數(shù)據(jù)加密密鑰臨時(shí)加載到調(diào)試寄存器(Debug Registers)中完成加密運(yùn)算。HCoper以一個(gè)內(nèi)核模塊的形式集成到開源虛擬機(jī)管理程序Xen[25]內(nèi)核中, 并為客戶虛擬機(jī)提供加密接口。理論上, 其他虛擬機(jī)管理程序(如kvm[26]也適用于HCoper。此外, 本文已經(jīng)將HCoper提供的加密接口集成到OpenSSL庫(kù)中, 以便于開發(fā)第三方應(yīng)用程序。本文在Intel Core i7 4790 CPU上運(yùn)行并評(píng)估HCoper原型系統(tǒng)。實(shí)驗(yàn)結(jié)果表明, HCoper能夠有效防御內(nèi)存快照攻擊。與原始的加密實(shí)現(xiàn)方案(OpenSSL)相比, HCoper具有良好的加密運(yùn)算性能。同時(shí), HCoper對(duì)并發(fā)型應(yīng)用程序性能的影響很小(不影響實(shí)用性)。

2 相關(guān)工作

2.1 云環(huán)境中的內(nèi)部人員攻擊

內(nèi)部人員攻擊通常指由內(nèi)部人員濫用組織給予的信任和權(quán)力實(shí)施的非法活動(dòng)[9], 如竊取、窺探用戶隱私數(shù)據(jù)等。例如, 惡意的云平臺(tái)運(yùn)維人員(Cloud Operator)可能會(huì)實(shí)施精心策劃的攻擊, 以竊取客戶的敏感數(shù)據(jù)。這種攻擊通常比較隱秘且難以察覺(jué), 但極具破壞性, 因?yàn)檫\(yùn)維人員通常對(duì)云平臺(tái)中不同的系統(tǒng)有著不同級(jí)別的訪問(wèn)權(quán)限, 并且他們對(duì)云平臺(tái)的基礎(chǔ)設(shè)施部署情況有比較詳細(xì)的了解, 這使得惡意運(yùn)維人員可以更加容易地實(shí)施竊密攻擊。相對(duì)而言, 外部攻擊者則需要花費(fèi)很長(zhǎng)時(shí)間才能探查出云平臺(tái)基礎(chǔ)設(shè)施的部署情況。

正如文獻(xiàn)[10]所述, 惡意內(nèi)部人員可以很輕易地破壞客戶虛擬機(jī)內(nèi)部數(shù)據(jù)的機(jī)密性而不需要實(shí)施任何高超的滲透手段。其中, 比較簡(jiǎn)單卻有效的攻擊手段通常是從客戶虛擬機(jī)內(nèi)存快照或內(nèi)存鏡像文件中提取敏感數(shù)據(jù)。實(shí)施此類攻擊時(shí), 惡意內(nèi)部人員通常通過(guò)執(zhí)行一些Hypervisor提供的管理指令(如Xen提供的“xl save”指令)先獲取目標(biāo)虛擬機(jī)的內(nèi)存快照(Memory Dump)。接著, 可以使用簡(jiǎn)單的文本分析工具從內(nèi)存快照文件中提取隱私數(shù)據(jù)(如明文口令等)。更進(jìn)一步, 攻擊者可以使用類似冷啟動(dòng)攻擊[27]中介紹的攻擊手段或工具從客戶虛擬機(jī)內(nèi)存快照文件中恢復(fù)出加密密鑰, 如AES的加密密鑰。文獻(xiàn)[27]已證實(shí)可從內(nèi)存快照文件中恢復(fù)出AES加密密鑰。

在虛擬機(jī)克隆攻擊[9](IaaS VM Cloning Attacks)中, 客戶虛擬機(jī)本質(zhì)上也是存儲(chǔ)在磁盤上的文件, 可能會(huì)被備份、復(fù)制或轉(zhuǎn)移到其他服務(wù)器上。相應(yīng)地, 惡意內(nèi)部人員可能會(huì)復(fù)制客戶虛擬機(jī)對(duì)應(yīng)的鏡像文件, 并在外部私有的Hypervisor上重新加載和啟動(dòng)該虛擬機(jī)。利用暴力破解工具獲得虛擬機(jī)登錄口令后, 進(jìn)入克隆虛擬機(jī)中窺探用戶隱私數(shù)據(jù)。類似的, 針對(duì)DaaS(Data Storage as a Service)場(chǎng)景, 惡意內(nèi)部人員可能會(huì)濫用權(quán)限非法訪問(wèn)客戶文件, 再借助一些取證技術(shù)或工具從文件中盜取隱私數(shù)據(jù)(如口令, 密鑰等), 此類攻擊被稱作DaaS File Copying Attacks[9]。本文將重點(diǎn)關(guān)注內(nèi)存快照攻擊(Memory Dump Attacks), 虛擬機(jī)克隆攻擊(VM Cloning Attacks)和DaaS File Copying Attacks這三類攻擊。

2.2 云環(huán)境中的內(nèi)部威脅緩解方案

文獻(xiàn)[28]分析了不同級(jí)別管理人員及其所對(duì)應(yīng)的潛在安全威脅等級(jí)。文獻(xiàn)[9]討論了不同類型的內(nèi)部攻擊向量以及不同類型的惡意內(nèi)部人員。針對(duì)惡意內(nèi)部人員帶來(lái)的安全威脅, 一些研究者提出基于內(nèi)部人員行為分析來(lái)檢測(cè)和識(shí)別內(nèi)部威脅。如基于圖的分析(Graph-based analysis)方案[12], 主動(dòng)分析(Proactive analysis)方案[13]和蜜罐(Honeypot)分析方案[11]等。文獻(xiàn)[14]通過(guò)記錄系統(tǒng)調(diào)用(System call analysis)活動(dòng)來(lái)分析用戶行為特性進(jìn)而檢測(cè)出惡意內(nèi)部人員實(shí)施的異常行為。在文獻(xiàn)[29-30]中, 類似的度量和策略, 如心理分析(Psychological Profiling)、用戶分類(User Taxonomy)被用于預(yù)測(cè)和檢測(cè)潛在的惡意內(nèi)部人員。在文獻(xiàn)[31]中, 擊鍵動(dòng)態(tài)技術(shù)(keystroke dynamic technology)被用來(lái)檢測(cè)惡意的內(nèi)部人員。

TCCP[15]設(shè)計(jì)一個(gè)可信的云計(jì)算平臺(tái)(trusted cloud computing platform, 簡(jiǎn)稱TCCP), 使IaaS服務(wù)提供商能夠?yàn)榭蛻舻奶摂M機(jī)提供一個(gè)封閉的執(zhí)行環(huán)境。即使IaaS服務(wù)提供商的管理人員也無(wú)權(quán)訪問(wèn)客戶虛擬機(jī)內(nèi)部的機(jī)密執(zhí)行環(huán)境。然而, 該方案僅從理論層面提出TCCP構(gòu)想, 并未實(shí)現(xiàn)原型系統(tǒng)。此外, TCCP需依賴于第三方可信機(jī)構(gòu)。文獻(xiàn)[32]得出結(jié)論: 將技術(shù)與有效的管理策略相結(jié)合才是緩解內(nèi)部威脅的最好的解決方案。文章建議管理員在執(zhí)行任何操作之前必須向參與管理的其他k個(gè)管理員提交申請(qǐng)?jiān)S可。只有其他k個(gè)管理員都許可該操作時(shí)才能繼續(xù)往下執(zhí)行。但該方案需要較長(zhǎng)的時(shí)間來(lái)響應(yīng)客戶的請(qǐng)求。

Fog Computing[33]利用誘騙信息(decoy information)技術(shù)對(duì)惡意內(nèi)部人員進(jìn)行虛假信息攻擊(disinformation attacks), 使得攻擊者無(wú)法區(qū)分出真實(shí)的敏感數(shù)據(jù)和虛假無(wú)用的數(shù)據(jù)。MyCloud[34]提出一種新的虛擬化架構(gòu)削減云服務(wù)提供商的管理特權(quán), 使控制域虛擬機(jī)(類似于Dom0)沒(méi)有訪問(wèn)其他客戶虛擬機(jī)資源(如內(nèi)存)的特權(quán)。此外, MyCloud還提供了一個(gè)訪問(wèn)控制矩陣, 供客戶根據(jù)需要配置隱私策略, 該矩陣定義了能夠訪問(wèn)虛擬機(jī)的實(shí)體。理論上, MyCloud可以抵御內(nèi)部威脅, 但MyCloud不具備和Xen一樣的實(shí)用性。

表1將HCoper與其他現(xiàn)有的針對(duì)云環(huán)境內(nèi)部威脅的緩解方案進(jìn)行了比較。本文主要關(guān)注第2.1節(jié)中描述的三種類型的內(nèi)部攻擊(Memory Dump Attacks, VM Cloning Attacks, DaaS File Copying Attacks)。如表1所示, HCoper可以有效防御此三種內(nèi)部攻擊。此外, HCoper是一種適用于云平臺(tái)的實(shí)用性解決方案。雖然TCCP[15]可以抵御這三類內(nèi)部攻擊, 但其無(wú)原型系統(tǒng)并需依賴第三方機(jī)構(gòu)。MyCloud[34]實(shí)用性較弱。其他基于策略的[29-30,32]方法、行為分析方法[12-14,31]或基于蜜罐的[11]方法均專注于檢測(cè)惡意內(nèi)部人員, 但它們無(wú)法抵御內(nèi)存快照攻擊。

表1 三種典型攻擊向量下的現(xiàn)有緩解方案對(duì)比 Table 1 Comparison of Mitigation under Three Attack Vectors

2.3 保護(hù)加密密鑰

為了防御冷啟動(dòng)攻擊[27], TRESOR[35]、AESSE[36]和Amnesia[37]通過(guò)將AES密鑰存儲(chǔ)在寄存器中來(lái)增強(qiáng)全盤加密的安全性。值得注意的是, 冷啟動(dòng)攻擊本質(zhì)上也是內(nèi)存快照攻擊。Copker[38]使用受TRESOR[35]保護(hù)的AES密鑰作為主密鑰來(lái)加密RSA的私鑰, 并在CPU緩存中實(shí)現(xiàn)RSA算法。PRIME[39]與Copker類似, 它在AVX[40]寄存器中完成RSA中安全敏感(Security-sensitive)的操作, 將不影響安全性的中間值保存在RAM中, 實(shí)現(xiàn)一種memory-less的RSA方案。Mimosa[41]通過(guò)使用Intel TSX[42]機(jī)制進(jìn)一步增強(qiáng)Copker的安全性, 以確保一旦檢測(cè)到攻擊者試圖讀取Cache中的密鑰, 敏感數(shù)據(jù)將被自動(dòng)清除。Mimosa的目的是阻止惡意線程竊取CPU緩存中的私鑰。

基于寄存器的AES實(shí)現(xiàn)方案容易受到基于DMA的高級(jí)攻擊[43], 這些攻擊可以將惡意代碼注入操作系統(tǒng)內(nèi)核中, 然后訪問(wèn)存放密鑰的寄存器。但是, BARM[44]提供了一種檢測(cè)基于DMA的攻擊的方法。另外, 還可以通過(guò)配置IOMMU[45]和SMM[46]來(lái)防御高級(jí)DMA攻擊。

PixeValut[47]在GPU中執(zhí)行整個(gè)加密計(jì)算過(guò)程, 所有敏感數(shù)據(jù)都存儲(chǔ)在GPU的緩存和寄存器中。保證CPU上運(yùn)行的惡意進(jìn)程無(wú)法訪問(wèn)GPU上的數(shù)據(jù), 即使惡意的或被攻陷OS內(nèi)核也無(wú)法竊取任何敏感數(shù)據(jù)。CaSE[48]利用ARM處理器的TrustZone[49]技術(shù)創(chuàng)建了一個(gè)基于緩存的獨(dú)立執(zhí)行環(huán)境。將加密算法(例如, AES、RSA、SHA1)運(yùn)行在該獨(dú)立的執(zhí)行環(huán)境中。CaSE能有效地防御軟件級(jí)和硬件級(jí)內(nèi)存泄漏攻擊(如冷啟動(dòng)攻擊)。

上述現(xiàn)有工作均主要集中在個(gè)人計(jì)算機(jī)或移動(dòng)設(shè)備上實(shí)現(xiàn)抵御內(nèi)存攻擊的加密運(yùn)算, 均需要進(jìn)一步的擴(kuò)展和改進(jìn), 因此無(wú)法直接適用于云計(jì)算平臺(tái)。

3 系統(tǒng)設(shè)計(jì)

3.1 系統(tǒng)模型

如文獻(xiàn)[50]所述, 云平臺(tái)中的管理任務(wù)主要由三個(gè)不同組別的成員完成:

(1)云平臺(tái)管理員(Cloud Administrator): 云管理員通常是云服務(wù)提供商指定的極少數(shù)高級(jí)別員工(人數(shù)少, 易受監(jiān)控)。云服務(wù)提供商授予其配置、初始化和啟動(dòng)云平臺(tái)的權(quán)限。云管理員負(fù)責(zé)創(chuàng)建云平臺(tái)服務(wù)條款, 并監(jiān)管、審查服務(wù)條款的執(zhí)行情況。

(2)云平臺(tái)運(yùn)維人員(Cloud Operator): 云運(yùn)維人員負(fù)責(zé)完成來(lái)自用戶的配置請(qǐng)求(例如, 創(chuàng)建虛擬機(jī)等)。云運(yùn)維人員負(fù)責(zé)管理和維護(hù)云平臺(tái)的日常運(yùn)營(yíng)工作, 例如, 解決在資源調(diào)配或虛擬機(jī)運(yùn)行過(guò)程中發(fā)生的錯(cuò)誤。更重要的是, 它們通常代表客戶執(zhí)行一些敏感操作, 例如, 當(dāng)執(zhí)行云平臺(tái)故障修復(fù)任務(wù)時(shí), 云運(yùn)維人員可能會(huì)暫停, 終止, 重啟虛擬機(jī); 該過(guò)程中會(huì)伴有獲取和恢復(fù)虛擬機(jī)快照等操作。通常云運(yùn)維人員的數(shù)量遠(yuǎn)超過(guò)云管理員的數(shù)量, 這使得云服務(wù)提供商難以監(jiān)督所有云運(yùn)維人員的日常操作行為。

(3)云用戶(Cloud User): 或云租戶, 他們向云服務(wù)提供商申請(qǐng)?zhí)摂M機(jī)資源, 并使用云服務(wù)提供商提供的用戶管理接口來(lái)管理分配給他們的任何虛擬機(jī)。

顯然, 我們可以區(qū)分受信任的云管理員和不受信任的云運(yùn)維人員。云服務(wù)提供商通常只會(huì)委派少數(shù)且可信云管理員進(jìn)行初始化云平臺(tái)。云管理員最能代表云服務(wù)提供商的利益。通常云管理員(即代表云服務(wù)提供商)有責(zé)任保護(hù)客戶的隱私, 以維護(hù)企業(yè)良好的形象和聲譽(yù)。本文假設(shè)云平臺(tái)管理員為可信的, 不會(huì)主動(dòng)實(shí)施內(nèi)存快照攻擊。然而, 云平臺(tái)啟動(dòng)結(jié)束后云平臺(tái)運(yùn)維工作交給其他運(yùn)維人員, 云運(yùn)維人員不可信且數(shù)量通常較多, 甚至運(yùn)維工作可能會(huì)被外包給第三方人員。因此, 數(shù)目眾多的(難監(jiān)控的)云運(yùn)維人員可能會(huì)惡意實(shí)施內(nèi)存快照攻擊, 竊取客戶虛擬機(jī)中的敏感數(shù)據(jù)。本文主要目標(biāo)是防御惡意云運(yùn)維人員發(fā)起的內(nèi)存快照攻擊。

3.2 威脅模型

云運(yùn)維人員通常有機(jī)會(huì)訪問(wèn)云平臺(tái)設(shè)施(如Dom0), 其可能會(huì)有意濫用職權(quán)執(zhí)行違規(guī)操作從而對(duì)云平臺(tái)的保密性和完整性產(chǎn)生負(fù)面影響。例如, 借助專業(yè)工具, 如aeskeyfind[27], 從客戶虛擬機(jī)的內(nèi)存快照文件中提取隱私數(shù)據(jù)(如口令, 密鑰等)。此外, 遠(yuǎn)程攻擊者也有可能對(duì)客戶虛擬機(jī)發(fā)起類似的內(nèi)存攻擊, 他們通常利用虛擬機(jī)管理程序的軟件漏洞來(lái)攻擊客戶虛擬機(jī), 然后對(duì)整個(gè)客戶虛擬機(jī)的內(nèi)存數(shù)據(jù)或者某一個(gè)受害進(jìn)程作內(nèi)存快照, 以從內(nèi)存快照文件中提取敏感數(shù)據(jù)。此外, 硬件平臺(tái)(如CPU)的漏洞也可能為攻擊者提供一種可行的方法來(lái)轉(zhuǎn)儲(chǔ)(Dump)整個(gè)系統(tǒng)內(nèi)存。如針對(duì)Intel CPU的meltdown[51]漏洞, 攻擊者可以利用該漏洞轉(zhuǎn)儲(chǔ)系統(tǒng)內(nèi)存以竊取隱私數(shù)據(jù)。

本文假設(shè)Hypervisor具備代碼完整性, 且無(wú)任何漏洞可供攻擊者利用以執(zhí)行惡意代碼來(lái)破壞Hypervisor的內(nèi)核。本文假設(shè)惡意的云運(yùn)維人員(其職責(zé)如第3.1節(jié)中所述)能夠執(zhí)行常規(guī)的維護(hù)管理shell命令(例如“xl save”)。此外, 本文還假設(shè)在密鑰初始化期間(很短的時(shí)間), 整個(gè)Hypervisor系統(tǒng)都是安全的。在此期間, 獲得云服務(wù)提供商授權(quán)的云管理員會(huì)初始化HCoper的主密鑰和密鑰。一旦密鑰初始化完成, 即使在特權(quán)域(Dom0)內(nèi)安裝rootkit也無(wú)法竊取密鑰。這是因?yàn)镈om0內(nèi)核的CPU權(quán)限級(jí)別比Hypervisor低。因此, Dom0內(nèi)核中的rootkit不可能篡改Hypervisor的內(nèi)核內(nèi)存(例如, hook超級(jí)調(diào)用表)。據(jù)本文所知, 在不利用Hypervisor內(nèi)核漏洞的情況下無(wú)法直接將rootkit安裝到Hypervisor(如Xen)中。而如何挖掘和修復(fù)Hypervisor的漏洞超出了本文的研究范圍。

3.3 設(shè)計(jì)目標(biāo)與原則

云平臺(tái)場(chǎng)景中, 攻擊者對(duì)云虛擬機(jī)作內(nèi)存快照, 內(nèi)存快照通常是無(wú)語(yǔ)義信息的二進(jìn)制數(shù)據(jù), 攻擊者需要還原出二進(jìn)制數(shù)據(jù)的語(yǔ)義信息才可獲取到有價(jià)值的信息(如加密密鑰等)。再次, 攻擊者通常不會(huì)無(wú)休止地對(duì)云虛擬機(jī)作內(nèi)存快照, 這一方面增大攻擊成本(時(shí)間開銷和存儲(chǔ)開銷), 另一方面, 頻繁的內(nèi)存快照操作容易暴露攻擊行為。相反, 加密計(jì)算過(guò)程(如AES算法)通常表現(xiàn)出固定的規(guī)律, 加密算法使用的參數(shù)、密鑰等會(huì)以某種特定的格式存儲(chǔ)在內(nèi)存中, 這使得攻擊者能以可接受的攻擊成本恢復(fù)出加密密鑰的語(yǔ)義信息, 如文獻(xiàn)[27]中根據(jù)AES加密密鑰在內(nèi)存中存儲(chǔ)的特定規(guī)律和格式成功從內(nèi)存快照中恢復(fù)出AES密鑰。因此, 竊取加密密鑰成為攻擊者的首選目標(biāo)。此外, 從云用戶的角度來(lái)說(shuō), 通常采用加密處理(如加密傳輸)的數(shù)據(jù)都是少量但重要的隱私數(shù)據(jù), 一旦攻擊者獲取到加密密鑰, 再輔以其他攻擊手段可獲取到更多的隱私數(shù)據(jù)(如網(wǎng)站的登錄憑證等)。因此, 針對(duì)云平臺(tái)環(huán)境, 密鑰泄露對(duì)云用戶造成的破壞性更大。

為保護(hù)客戶虛擬機(jī)在執(zhí)行加密運(yùn)算時(shí), 其使用的加密密鑰不被竊取。首要的設(shè)計(jì)目標(biāo)是確保主密鑰和加密密鑰在任何時(shí)候都不會(huì)被加載到系統(tǒng)內(nèi)存(RAM)中。此外, 加密計(jì)算過(guò)程中的中間結(jié)果也不能出現(xiàn)在RAM中。本文提出的方案中, 將主密鑰永久存儲(chǔ)在CPU寄存器中, 而加密密鑰和計(jì)算過(guò)程的中間狀態(tài)都只是臨時(shí)暫存在寄存器中。然而, 虛擬化平臺(tái)(如Xen)通常會(huì)允許虛擬機(jī)之間共享硬件資源, 目前Xen的實(shí)現(xiàn)方案默認(rèn)允許虛擬機(jī)直接訪問(wèn)CPU的寄存器(如Debug寄存器)。因此, 另一個(gè)設(shè)計(jì)目標(biāo)需要防止客戶虛擬機(jī)(包括特權(quán)域Dom0)訪問(wèn)存儲(chǔ)著密鑰的寄存器以竊取密鑰?？傮w而言, HCoper的目標(biāo)是為云租戶提供一個(gè)通用、高效的加密計(jì)算服務(wù), 同時(shí)保證該加密運(yùn)算服務(wù)使用的密鑰不會(huì)被攻擊者(特別是惡意內(nèi)部人員)竊取?；谏鲜瞿繕?biāo), HCoper的設(shè)計(jì)需要滿足以下幾個(gè)要求(準(zhǔn)則):

(1)在執(zhí)行數(shù)據(jù)塊加密運(yùn)算(通常是最小的加密運(yùn)算執(zhí)行單位)時(shí), 該運(yùn)算過(guò)程不能被中斷。否則, 很可能在執(zhí)行進(jìn)程調(diào)度的過(guò)程中, 在將進(jìn)程狀態(tài)(包括寄存器狀態(tài))導(dǎo)出(swap)到RAM中時(shí)也將密鑰或運(yùn)算的中間結(jié)果導(dǎo)出到RAM中, 從而導(dǎo)致密鑰被竊取。

(2)針對(duì)多核(multi-core)CPU, 同一個(gè)加密進(jìn)程可能會(huì)被調(diào)度到不同的核(core)上去執(zhí)行。而不同的CPU核內(nèi)部維護(hù)著不同的寄存器狀態(tài)。因此, 需要確保當(dāng)同一個(gè)加密進(jìn)程不同時(shí)刻運(yùn)行在不同的CPU核上時(shí), 其加密運(yùn)算使用的加密密鑰仍保持一致。

(3)客戶虛擬機(jī)可能會(huì)有意訪問(wèn)存儲(chǔ)著密鑰的寄存器。因此, 需要確保客戶虛擬機(jī)訪問(wèn)保存有密鑰的寄存器的行為能被捕獲并攔截。

為了滿足原則(1), HCoper的塊加密計(jì)算必須在 一個(gè)原子域中運(yùn)行, 在該原子域中將暫時(shí)禁用所有中斷, 并暫時(shí)禁用CPU搶占。同樣, 加密密鑰的加載和調(diào)度也需要放置在原子域中執(zhí)行, 以確保數(shù)據(jù)加密密鑰不被泄露, 同時(shí)保證在執(zhí)行塊加密之前數(shù)據(jù)加密密鑰正確無(wú)誤地被載入到寄存器中。需注意的是, 塊加密運(yùn)算(最小加密運(yùn)算執(zhí)行單位)通常很小, 如AES為16字節(jié)(128bit), 塊加密計(jì)算的原子域是在極短暫的時(shí)間內(nèi)完成, 完成塊加密計(jì)算后會(huì)立即恢復(fù)中斷和CPU搶占, 而不是在運(yùn)行整個(gè)加密進(jìn)程的過(guò)程中都禁用CPU搶占和中斷。塊加密(原子操作)計(jì)算完成后恢復(fù)中斷和CPU搶占, 使得加密進(jìn)程和其他進(jìn)程一樣處于同等的地位, 系統(tǒng)執(zhí)行進(jìn)程調(diào)度算法正常調(diào)度進(jìn)程(包括加密進(jìn)程)獲取CPU執(zhí)行權(quán)限, 對(duì)系統(tǒng)內(nèi)其他進(jìn)程的影響很小。在下一節(jié)(第3.4節(jié))中, 將介紹滿足原則(2)的設(shè)計(jì)細(xì)節(jié)。滿足原則(3)所使用的技術(shù)實(shí)現(xiàn)細(xì)節(jié)將在第4.2節(jié)中給出。

3.4 HCoper設(shè)計(jì)細(xì)節(jié)

如圖1所示, HCoper主要由五個(gè)組件構(gòu)成。同時(shí), HCoper是一個(gè)三層模型結(jié)構(gòu): 用戶層(User Space), 虛擬機(jī)內(nèi)核層(Guest Kernel)和虛擬化平臺(tái)層(Hypervisor)。位于用戶層的應(yīng)用程序通過(guò)ioctl接口將數(shù)據(jù)加密請(qǐng)求提交給虛擬機(jī)內(nèi)核中的gCoper(guest Coper)模塊, gCoper模塊負(fù)責(zé)將接收到的加密請(qǐng)求通過(guò)調(diào)用Coper提供的超級(jí)調(diào)用(hypercall)接口提交給Hypervisor內(nèi)核中的加密模塊Coper。Coper模塊在CPU內(nèi)部完成相應(yīng)的加密計(jì)算任務(wù)。HCoper的執(zhí)行流程主要分為兩個(gè)階段: 初始化階段(initialization phase)和數(shù)據(jù)加密階段(data-encryption phase)。

圖1 HCoper系統(tǒng)架構(gòu)圖 Figure 1 The Architecture of HCoper

在初始化階段, 獲得云服務(wù)提供商授權(quán)的云平臺(tái)管理員在特權(quán)域(Dom0)中臨時(shí)安裝Key Initializer模塊, 該模塊的主要功能是負(fù)責(zé)接收管理員輸入的長(zhǎng)字符串(如password)并將該password提交該Hypervisor內(nèi)核中的Key Generator模塊。Key Generator模塊利用收到的password生成主密鑰和數(shù)據(jù)加密密鑰。具體地, Key Generator首先生成主密鑰, 并立即將主密鑰加載到MSR寄存器中。HCoper中只有一份主密鑰用于加密解密其他數(shù)據(jù)加密密鑰, HCoper中維護(hù)著多個(gè)加密密鑰(理論上加密密鑰個(gè)數(shù)不受限制)。接著利用再次收到的password生成加密密鑰, 加密密鑰將會(huì)被主密鑰加密后以密文的形式存儲(chǔ)在系統(tǒng)內(nèi)存(RAM)中。HCoper支持多應(yīng)用多密鑰場(chǎng)景, 因此在初始化階段云管理員會(huì)輸入多次password并相應(yīng)的生成多個(gè)數(shù)據(jù)加密密鑰。值得注意的是, 密鑰初始化工作是在一個(gè)很短的時(shí)間內(nèi)完成, 本文假設(shè)在此短暫的初始化期間, 整個(gè)Hypervisor平臺(tái)是安全的。另外密鑰的初始化工作通常在系統(tǒng)啟動(dòng)期間完成(即Boot階段), 在此期間云平臺(tái)管理員通過(guò)外設(shè)輸入password, 在此短暫期間內(nèi)password會(huì)暫留RAM, 一旦根據(jù)password生成主密鑰或數(shù)據(jù)加密密鑰后, RAM中的password會(huì)被徹底清除。密鑰初始化階段通常是Hypervisor平臺(tái)的啟動(dòng)階段, 此時(shí)平臺(tái)尚未啟動(dòng)完成, 云虛擬機(jī)尚未啟動(dòng), 通過(guò)云虛擬機(jī)的攻擊在此階段無(wú)效。此外, 系統(tǒng)啟動(dòng)工作尚未結(jié)束使得無(wú)法實(shí)施內(nèi)存快照攻擊, 因?yàn)閮?nèi)存快照?qǐng)?zhí)行過(guò)程中需要調(diào)用Hypervisor向外提供的接口。

Key Initializer模塊是云平臺(tái)管理員臨時(shí)安裝到Dom0中的, 只有云管理員有權(quán)限使用該模塊。該模塊調(diào)用Key Generator提供的隱式hypercall完成密鑰的初始化工作, 該hypercall不對(duì)外公開, 即云運(yùn)維人員不知道該hypercall的任何細(xì)節(jié)。需注意的是, 該hypercall每次被調(diào)用時(shí)都會(huì)先執(zhí)行合法性驗(yàn)證, 驗(yàn)證調(diào)用者是否運(yùn)行在特權(quán)域(Dom0)中, 如果是非特權(quán)域的調(diào)用則直接拒絕, 若是來(lái)自特權(quán)域的調(diào)用還需要進(jìn)一步判斷調(diào)用者是否是Key Initializer模塊, 具體地當(dāng)Key Initializer模塊調(diào)用隱式hypercall時(shí), HCoper能捕獲到調(diào)用者EIP寄存器信息, 進(jìn)而可以獲取調(diào)用者執(zhí)行hypercall時(shí), 控制流上下文信息, HCoper預(yù)先保存了一份Key Initializer調(diào)用該隱式hypercall時(shí)的控制流上下文信息, 每次都以同樣的方式獲取調(diào)用者執(zhí)行hypercall時(shí)的控制流上下文信息, 然后再進(jìn)行對(duì)比(匹配)進(jìn)而判斷調(diào)用者是否是Key Initializer模塊。云管理員后續(xù)可以隨時(shí)在重新安裝Key Initializer模塊更新主密鑰和數(shù)據(jù)加密密鑰。另外, 在完成密鑰初始化工作之后, Key Initializer模塊會(huì)被從Dom0中卸載并移除。Key Generator模塊生成密鑰時(shí), 對(duì)收到的password執(zhí)行一定次數(shù)(在本方案中至少計(jì)算2000次)的SHA-256哈希計(jì)算后獲得的摘要值(digest)作為最終的密鑰。HCoper將主密鑰存儲(chǔ)在原本用于硬件性能計(jì)數(shù)[52](hardware performance counter)的MSR寄存器(涉及4個(gè)MSR寄存器)中。本文選擇該組MSR寄存器時(shí)主要考慮到硬件性能計(jì)數(shù)特性并不是大多數(shù)軟件必需依賴的特性。存儲(chǔ)主密鑰僅占用4個(gè)用于硬件性能計(jì)數(shù)功能的MSR寄存器而不是所有的MSR寄存器。另外, 部署在云場(chǎng)景中的業(yè)務(wù)很少使用該組MSR寄存器, 在云虛擬機(jī)內(nèi)部進(jìn)行性能評(píng)測(cè)(如, 評(píng)測(cè)虛擬機(jī)內(nèi)程序運(yùn)行時(shí)間開銷)是不推薦的。這是由于云虛擬機(jī)運(yùn)行在Hypervisor之上, 云虛擬機(jī)占用的資源均由Hypervisor調(diào)度, 云虛擬機(jī)性能受云平臺(tái)整體負(fù)載情況的影響。因此, 即使HCoper關(guān)閉了硬件計(jì)數(shù)功能也不會(huì)對(duì)大多數(shù)軟件的正常運(yùn)行造成影響。數(shù)據(jù)加密密鑰的初始化過(guò)程和主密鑰基本一致, 不同點(diǎn)在于生成主密鑰后直接加載到MSR寄存器中, 而數(shù)據(jù)加密密鑰生成后先被主密鑰加密后以密文形式存儲(chǔ)在系統(tǒng)內(nèi)存中。只有在執(zhí)行加密運(yùn)算時(shí)才會(huì)被解密后加載到Debug寄存器內(nèi)(該加載過(guò)程是寄存器之間的數(shù)據(jù)拷貝行為, 不涉及內(nèi)存的讀寫)。數(shù)據(jù)加密密鑰的解密過(guò)程也是在CPU內(nèi)部完成, 因此, 不會(huì)造成密鑰泄露的風(fēng)險(xiǎn)。HCoper同樣獨(dú)占了Debug寄存器, 使得硬件調(diào)試功能被禁用, 軟件調(diào)試功能不受影響。對(duì)于大多數(shù)軟件來(lái)言, 硬件調(diào)試也不是必需的功能, 因此, HCoper并不會(huì)破壞大多數(shù)軟件的兼容性?？傮w而言, HCoper的密鑰初始化工作可以簡(jiǎn)要的歸納為三個(gè)步驟, 如圖2所示: (1)Key Generator利 用password生成主密鑰(master key)并立即將其載入MSR寄存器; (2)Key Generator利用再次收到的password生成數(shù)據(jù)加密密鑰, 接著使用MSR寄存器中的主密鑰對(duì)數(shù)據(jù)加密密鑰進(jìn)行加密處理; (3)密文態(tài)的數(shù)據(jù)加密密鑰被存儲(chǔ)到系統(tǒng)內(nèi)存中。

圖2 密鑰初始化 Figure 2 Initialization of Keys

數(shù)據(jù)加密階段, 用戶層應(yīng)用程序通過(guò)ioctl接口提交加密請(qǐng)求, 該請(qǐng)求中包含待加密明文的內(nèi)存地址, 密文存儲(chǔ)地址以及所使用的加密密鑰標(biāo)識(shí)符。HCoper對(duì)每個(gè)加密密鑰都用唯一的key-id進(jìn)行標(biāo)識(shí)。gCoper將加密請(qǐng)求提交該Coper模塊后, Coper根據(jù)key-id載入對(duì)應(yīng)的數(shù)據(jù)加密密鑰并完成相應(yīng)的加密運(yùn)算。數(shù)據(jù)加密密鑰的載入與調(diào)度工作實(shí)際上是由Key Scheduler模塊完成。

加密密鑰調(diào)度, 為了支持多應(yīng)用多密鑰場(chǎng)景, Key Scheduler模塊維護(hù)了一個(gè)加密密鑰使用記錄列表。該列表記錄了最近被使用過(guò)的加密密鑰, 列表記錄的只是加密密鑰對(duì)應(yīng)的key-id, 而列表的索引值為CPU核序號(hào)(core-id)。例如, 某一時(shí)刻, CPU 核2上運(yùn)行的加密進(jìn)程使用的加密密鑰的key-id為3, 則該列表中索引值(或下標(biāo))為2的元素值為3。當(dāng)在處理某個(gè)加密請(qǐng)求時(shí), Key Scheduler首先需要獲取當(dāng)前加密進(jìn)程所在的CPU核的core-id, 然后以此core-id為索引到列表中進(jìn)行查詢獲得最近被載入到該CPU核上的加密密鑰的key-id(記為L(zhǎng)-key-id)。再將L-key-id與用戶提交的加密請(qǐng)求中指定的加密密鑰的key-id(記為R-key-id)進(jìn)行對(duì)比。若L-key-id與R-key-id一致, 則直接使用該CPU核中存留在Debug寄存器中的加密密鑰, 需注意的是, 為了減少?gòu)南到y(tǒng)內(nèi)存解密并載入加密密鑰的次數(shù), 存儲(chǔ)在Debug寄存器中的加密密鑰在加密運(yùn)算任務(wù)結(jié)束后依舊存留而不會(huì)被清除。若L-key-id與R-key-id不一致, 則需要使用MSR寄存器中主密鑰解密系統(tǒng)內(nèi)存中的密文態(tài)的加密密鑰, 并將解密后的加密密鑰直接載入Debug寄存器。由于整個(gè)解密(或加密)運(yùn)算過(guò)程都是在CPU內(nèi)部完成, 具體而言, 均使用CPU內(nèi)存的寄存器來(lái)暫存密鑰、中間狀態(tài)值以及最后的解密結(jié)果都是暫存在寄存器中。因此, 解密后的加密密鑰也是暫存在寄存器中, 在將其載入Debug寄存器時(shí)也僅僅是寄存器之間的數(shù)據(jù)拷貝而不會(huì)涉及任何內(nèi)存讀寫操作。因此, 解密后的加密密鑰被直接拷貝到Debug寄存器而不會(huì)泄漏到系統(tǒng)內(nèi)存中。

圖3簡(jiǎn)要地歸納了數(shù)據(jù)加密階段中的密鑰調(diào)度過(guò)程: 1)當(dāng)L-key-id和R-key-id不一致時(shí), Key Scheduler模塊使用MSR寄存器中的主密鑰解密加密密鑰。加密密鑰的密文存儲(chǔ)在RAM中, 本質(zhì)上是一個(gè)密文列表, 使用key-id(如R-key-id)為索引載入對(duì)應(yīng)加密密鑰的密文。2)解密后的加密密鑰被直接載入Debug(簡(jiǎn)記為db)寄存器, 該過(guò)程不涉及任何內(nèi)存讀寫操作。3)Coper完成最后的加密計(jì)算任務(wù), 從內(nèi)存中載入待加密數(shù)據(jù)(Input), 將加密結(jié)果寫回內(nèi)存中(Output)。在完成加密計(jì)算后, Coper會(huì)將計(jì)算過(guò)程中使用到的寄存器(如Streaming SIMD Extensions[53], 簡(jiǎn)稱SSE)的狀態(tài)值都清零, 只保留Debug寄存器中加密密鑰以備下一次使用。

圖3 動(dòng)態(tài)密鑰調(diào)度 Figure 3 Dynamic Scheduling of Keys

4 系統(tǒng)實(shí)現(xiàn)

4.1 加密接口

本文基于開源虛擬化平臺(tái)Xen 4.4.0實(shí)現(xiàn)HCoper原型系統(tǒng)。HCoper利用Intel AES-NI指令集在CPU內(nèi)實(shí)現(xiàn)加密計(jì)算, 利用x86架構(gòu)的調(diào)試寄存器(Debug Registers)存儲(chǔ)數(shù)據(jù)加密密鑰, 利用MSR寄存器存儲(chǔ)主密鑰。Intel AES-NI利用SSE[53]寄存器存儲(chǔ)加密密鑰、中間狀態(tài)和AES輪次密鑰, 從而確保不會(huì)將任何中間狀態(tài)或密鑰加載到RAM中。HCoper通過(guò)超級(jí)調(diào)用(hypercall)機(jī)制向客戶虛擬機(jī)的內(nèi)核提供加密計(jì)算服務(wù)?？蛻籼摂M機(jī)的用戶空間進(jìn)程通過(guò)ioctl接口調(diào)用加密計(jì)算服務(wù)。本文已將ioctl接口集成到openssl-1.1.0g[54]和polarssl-2.6.0[55]中, 作為通用API為其他第三方應(yīng)用程序提供開發(fā)接口。

超級(jí)調(diào)用(hypercall)是從虛擬機(jī)到Hypervisor的軟件級(jí)陷入(software trap)操作。虛擬機(jī)通過(guò)超級(jí)調(diào)用請(qǐng)求特權(quán)操作(例如, 更新頁(yè)表等)。類似地, HCoper為虛擬機(jī)內(nèi)核提供了兩個(gè)超級(jí)調(diào)用, 用于調(diào)用加密和解密服務(wù)。在Xen的實(shí)現(xiàn)中每個(gè)超級(jí)調(diào)用都有全局唯一的超級(jí)調(diào)用號(hào)與之對(duì)應(yīng)。相應(yīng)的, 在HCoper的實(shí)現(xiàn)中, 在Xen內(nèi)核中擴(kuò)展了兩個(gè)超級(jí)調(diào)用, 其超級(jí)調(diào)用號(hào)分別為41、42。此外, HCoper還定義了用來(lái)封裝加解密請(qǐng)求的結(jié)構(gòu)體, 如下圖所示:

圖4 加密請(qǐng)求結(jié)構(gòu)體 Figure 4 Structure of Encryption Request

用戶層應(yīng)用程序需要將加密請(qǐng)求封裝為該結(jié)構(gòu)體, 再提交到HCoper內(nèi)部。其中src表示待加密(或解密)的數(shù)據(jù), dst用于存儲(chǔ)加密(或解密)的結(jié)果, msglen指示待加密(或解密)的數(shù)據(jù)大小, key-id指明本次加密計(jì)算所使用的加密密鑰。

4.2 密鑰保護(hù)

HCoper作為Hypervisor的一個(gè)內(nèi)核模塊運(yùn)行, 因此, 位于上層的客戶虛擬機(jī)訪問(wèn)MSR寄存器或Debug寄存器的行為均能被HCoper捕獲并攔截, 以保證主密鑰和加密密鑰不會(huì)被客戶虛擬機(jī)竊取。Intel虛擬化機(jī)制(Intel VT)允許在Hypervisor層定義敏感操作, 當(dāng)上層客戶虛擬機(jī)執(zhí)行敏感操作時(shí)會(huì)陷入(trap)到Hypervisor內(nèi)核中, 即執(zhí)行權(quán)限被轉(zhuǎn)交給Hypervisor。例如, 客戶虛擬機(jī)讀寫CR3寄存器以更新頁(yè)表為典型的敏感操作。在虛擬化場(chǎng)景下客戶虛擬機(jī)也需要Hypervisor的輔助才能訪問(wèn)物理內(nèi)存。因此, 更新CR3須陷入到Hypervisor中進(jìn)行處理。具體地, Intel VT虛擬化技術(shù)提供虛擬機(jī)執(zhí)行控制域字段[56](VM execution control filed)來(lái)定義敏感操作。HCoper通過(guò)該字段將MSR寄存器和Debug寄存器的訪問(wèn)操作定義為敏感操作, 當(dāng)客戶虛擬機(jī)訪問(wèn)這兩組寄存器時(shí)被HCoper截獲。具體過(guò)程如下:

(a)對(duì)于Debug寄存器, 將VM execution control 字段上MOV-DR標(biāo)志位設(shè)置為1, 使得虛擬機(jī)執(zhí)行mov指令讀寫Debug寄存器時(shí), 觸發(fā)VM-exit事件陷入到Hypervisor內(nèi)核, HCoper處理該事件并阻止訪問(wèn)Debug寄存器。

(b)類似的, 在VM execution control字段上將RDMSR和WRMSR標(biāo)志位設(shè)置為1, 截獲上層虛擬機(jī)訪問(wèn)MSR的行為。

(c)針對(duì)半虛擬化場(chǎng)景, 不能使用上述步驟中的方法。本文修改(patch)了Hypervisor(即Xen)中原本用于訪問(wèn)MSR寄存器和Debug寄存器的超級(jí)調(diào)用, 將對(duì)MSR寄存器和Debug寄存器的讀寫操作重定向到一塊固定內(nèi)存區(qū)域, 使得半虛擬化虛擬機(jī)不能讀寫真實(shí)的硬件寄存器, 從而保證密鑰的機(jī)密性。

5 實(shí)驗(yàn)評(píng)估

本節(jié)首先進(jìn)行有效性驗(yàn)證實(shí)驗(yàn), 以證明惡意的云運(yùn)維人員(Cloud operator)在HCoper執(zhí)行加密計(jì)算期間無(wú)法從內(nèi)存快照文件中恢復(fù)出加密密鑰和主密鑰。然后, 本節(jié)通過(guò)比較OpenSSL-1.1.0g中的原始加密函數(shù)與HCoper實(shí)現(xiàn)的加密函數(shù)之間的性能差異來(lái)評(píng)估HCoper的實(shí)用性。本次實(shí)驗(yàn)環(huán)境部署在Intel Core i7 4790 CPU(8核)的工作站上, 其運(yùn)行的Hypervisor為Xen 4.4.0版本。

5.1 安全功能驗(yàn)證

HCoper的加密接口被集成到三個(gè)常見(jiàn)的加密庫(kù)中: GnuPG 1.4.22[57]、OpenSSL-1.1.0g[54]和polarssl-2.6.0[58]。安全功能驗(yàn)證實(shí)驗(yàn)主要分為3個(gè)步驟: (1)首先, 在實(shí)驗(yàn)虛擬機(jī)內(nèi)部執(zhí)行這三個(gè)加密工具中的AES加密函數(shù)對(duì)測(cè)試文件進(jìn)行加密(解密)操作, 在執(zhí)行加密函數(shù)的過(guò)程中, 在特權(quán)虛擬機(jī)(Dom0)中執(zhí)行“xl save”命令獲取實(shí)驗(yàn)虛擬機(jī)的內(nèi)存快照; (2)使用文獻(xiàn)[27]中的aeskeyfind工具從內(nèi)存快照中提取AES加密密鑰; (3)在實(shí)驗(yàn)虛擬機(jī)內(nèi)執(zhí)行HCoper加密計(jì)算進(jìn)程, 同時(shí)在此期間獲取虛擬機(jī)快照, 再次使用aeskeyfind工具從內(nèi)存快照中嘗試提取AES加密密鑰。

此外, 本節(jié)中還模擬了外部攻擊者獲取客戶虛擬機(jī)內(nèi)存快照并從內(nèi)存快照中恢復(fù)出AES加密密鑰。本次模擬外部攻擊者實(shí)驗(yàn)中, 在虛擬機(jī)中運(yùn)行加密計(jì)算進(jìn)程時(shí), 通過(guò)虛擬機(jī)內(nèi)部的/dev/mem設(shè)備接口來(lái)獲取虛擬機(jī)的內(nèi)存鏡像, 再使用同樣的工具嘗試從內(nèi)存快照中提取AES加密密鑰。兩個(gè)實(shí)驗(yàn)的結(jié)果均一致表明攻擊者(內(nèi)部或外部攻擊者)無(wú)法從內(nèi)存快照中獲取HCoper使用的主密鑰和加密密鑰, 而運(yùn)行常規(guī)加密庫(kù)中的原始加密函數(shù)時(shí)能成功從內(nèi)存快照中恢復(fù)出加密密鑰, 實(shí)驗(yàn)結(jié)果如表2所示。另外,

表2 密鑰恢復(fù)結(jié)果對(duì)比 Table 2 Comparison of Recovering Keys

由于HCoper使用的密鑰不會(huì)存在于內(nèi)存中, 也不會(huì)出現(xiàn)在虛擬機(jī)鏡像文件和普通的文件中, 進(jìn)一步表明了HCoper不受冷啟動(dòng)攻擊(Cold-boot)、VM克隆攻擊(VM Cloning)和DaaS文件復(fù)制攻擊(DaaS File Copying)的威脅。

5.2 性能評(píng)估

圖5 總時(shí)間開銷 Figure 5 Real Time Overhead

系統(tǒng)時(shí)間開銷(sys time)是指某個(gè)進(jìn)程在內(nèi)核態(tài)(內(nèi)核模式)中執(zhí)行的時(shí)間。如圖6所示, openssl-xen- aes-ni的內(nèi)核態(tài)執(zhí)行時(shí)間開銷明顯高于openssl-ecb- aes。當(dāng)加密同一個(gè)文件(例如900MB)時(shí), openssl-ecb- aes(2.1248s)在內(nèi)核模式下的平均開銷僅為openssl- xen-aes-ni(6.9544s)的30.6%(2.1248/ 6.9544)。這可以歸因于HCoper大部分加密計(jì)算操作是在Hypervisor的內(nèi)核中執(zhí)行的。僅有少部分的操作是在用戶模式下完成, 比如用戶層應(yīng)用程序簡(jiǎn)單地構(gòu)造加密請(qǐng)求, 然后將加密請(qǐng)求提交給客戶操作系統(tǒng)內(nèi)核。此外, 從圖6中還可以看到, 隨著文件大小的持續(xù)增長(zhǎng), openssl-xen-aes-ni的系統(tǒng)時(shí)間開銷相比于openssl- ecb-aes增長(zhǎng)速度要較快些。

圖6 系統(tǒng)時(shí)間開銷 Figure 6 Sys Time Overhead

相應(yīng)地, 實(shí)驗(yàn)結(jié)果還表明 openssl-xen-aes-ni的用戶態(tài)時(shí)間開銷(即在用戶模式下的開銷)比openssl-ecb-aes低很多, 并且openssl-xen-aes-ni的用戶態(tài)時(shí)間開銷幾乎不隨文件大小的增加而增長(zhǎng), 如圖7所示。對(duì)于相同大小的文件(例如, 100MB), openssl-xen-aes-ni(0.042s)在用戶模式下的平均開銷 僅為openssl-ecb-aes(0.6588s)的6.4%(0.042/0.6588)。這與我們所期望的一致, 內(nèi)核模式時(shí)間開銷越高, 用戶態(tài)時(shí)間開銷越低, 兩者的總和即是總時(shí)間開銷(real time)?？傊? 盡管openssl xen-aes-ni(或HCoper)的平均內(nèi)核模式時(shí)間開銷要高于openssl-ecb-aes, 但openssl-xen-aes-ni的整體加密運(yùn)算性能甚至比openssl-ecb-aes要快一點(diǎn)。換言之, HCoper的加密運(yùn)算效率與OpenSSL庫(kù)中的加密實(shí)現(xiàn)方案一樣具備實(shí)用性。

圖7 用戶態(tài)時(shí)間開銷 Figure 7 User Time Overhead

5.2.2 并發(fā)性能影響評(píng)估

由于HCoper在執(zhí)行塊加密計(jì)算期間, HCoper會(huì)短暫地禁用CPU搶占, 因此被分配到同一CPU核上運(yùn)行的其他任務(wù)的性能可能會(huì)受到影響。本次實(shí)驗(yàn)使用SysBench[60]工具來(lái)衡量HCoper短時(shí)間獨(dú)占CPU核對(duì)其他并發(fā)型應(yīng)用程序造成的影響, Sys-Bench是一個(gè)通用的系統(tǒng)性能(如內(nèi)存訪問(wèn)速度, CPU運(yùn)算性能)度量工具。本節(jié)實(shí)驗(yàn)部署時(shí)先將HCoper集成到Apache Web服務(wù)器中, 具體地, 在PHP文件中調(diào)用HCoper執(zhí)行加密運(yùn)算。在客戶機(jī)端, 本次實(shí)驗(yàn)啟動(dòng)了多個(gè)客戶線程來(lái)并發(fā)地提交加密8KB數(shù)據(jù)的請(qǐng)求。在服務(wù)器端(HCoper和SysBench都運(yùn)行在服務(wù)器端, 即同一臺(tái)機(jī)器上), 使用SysBench啟動(dòng)4個(gè)線程向本地CPU核發(fā)出10K個(gè)請(qǐng)求, 每個(gè)請(qǐng)求都涉及高達(dá)40K的素?cái)?shù)計(jì)算, 即求出40K個(gè)素?cái)?shù)。我們收集了當(dāng)客戶端線程以不同的速率(requests/second)發(fā)出加密請(qǐng)求時(shí)(即此時(shí)HCoper需要響應(yīng)客戶的加密請(qǐng)求), 記錄SysBench(在服務(wù)器端運(yùn)行)所發(fā)起的每個(gè)素?cái)?shù)計(jì)算任務(wù)的平均運(yùn)行時(shí)間。

如圖8所示, 基準(zhǔn)值(baseline)是在沒(méi)有執(zhí)行任何加密進(jìn)程的干凈環(huán)境中測(cè)量的。對(duì)于相同的加密速率(requests/sec), 相對(duì)于openssl-xen-aes-ni而言, 原來(lái)的openssl-ecb-aes對(duì)Sysbench啟動(dòng)的素?cái)?shù)計(jì)算進(jìn)程性能的影響較低一些, 但實(shí)驗(yàn)結(jié)果表明, HCoper對(duì)其他并發(fā)型應(yīng)用程序性能造成的影響是可以接受的。例如, 當(dāng)加密速率為 400(requsets/sec)時(shí), openssl-xen-aes-ni導(dǎo)致執(zhí)行素?cái)?shù)計(jì)算任務(wù)的并發(fā)進(jìn)程的性能下降了1.8%, 而openss-ecb-aes導(dǎo)致素?cái)?shù)計(jì)算性能下降了1.3%。相比之下, openssl-xen-aes-ni帶來(lái)的并發(fā)性能影響和openssl-ecb-aes造成的并發(fā)性能影響還處于同一個(gè)數(shù)量級(jí)(僅高了0.5%)。這主要是因?yàn)楫?dāng)HCoper執(zhí)行塊加密運(yùn)算時(shí), 它將暫時(shí)地禁止CPU搶占, 使得CPU密集型的運(yùn)算任務(wù)的性能會(huì)受到影響。然而實(shí)驗(yàn)結(jié)果表明, 與openssl-ecb-aes相比, HCoper引起附加開銷是可以接受的, 即不影響實(shí)用性。

圖8 對(duì)并發(fā)型程序的性能影響 Figure 8 Impact on Concurrent Processes

6 潛在安全威脅分析

如第5節(jié)所示, 實(shí)驗(yàn)結(jié)果已驗(yàn)證了HCoper的功能正確并且在執(zhí)行加密運(yùn)算時(shí)不會(huì)將加密密鑰泄漏到RAM中。在本節(jié)中, 本節(jié)將分析HCoper針對(duì)Hypervisor級(jí)攻擊的防御能力。然后討論HCoper可能會(huì)面臨的來(lái)自硬件層面的攻擊方式以及相關(guān)防御措施。

6.1 Hypervisor層攻擊

HCoper的安全性基于Hypervisor安全可靠的假設(shè)之上。然而在真實(shí)的云環(huán)境中, Hypervisor不可能沒(méi)有任何安全缺陷。不可避免地, 攻擊者可能會(huì)利用Hypervisor的漏洞竊取密鑰。例如, 在虛擬機(jī)逃逸攻擊[61]中, 攻擊者可以使用虛擬機(jī)逃逸漏洞向Hypervisor的內(nèi)核中注入惡意代碼, 然后設(shè)計(jì)精妙的攻擊手段(如ROP)來(lái)執(zhí)行惡意代碼。由于惡意代碼與Hypervisor內(nèi)核的執(zhí)行權(quán)限級(jí)別相同, 因此攻擊者可以輕松讀取或?qū)懭爰拇嫫?即Debug或MSR)以獲取密鑰。類似的, 利用XSA-148[62]漏洞利用也能實(shí)現(xiàn)任意讀取和寫入Xen的物理內(nèi)存。此外, 惡意的半虛擬化客戶虛擬機(jī)中可以通過(guò)此漏洞篡改(Hook)Xen內(nèi)核中的超級(jí)調(diào)用表(hypercall table), 進(jìn)而實(shí)現(xiàn)在Hypervisor內(nèi)核級(jí)別執(zhí)行任意代碼[63]。本文使用最新的安全補(bǔ)丁來(lái)提高HCoper對(duì)抗Hypervisor內(nèi)核級(jí)別攻擊的能力。如何增Hypervisor內(nèi)核的安全性以及發(fā)現(xiàn)Hypervisor的漏洞超出了本文的研究范圍。

6.2 硬件層攻擊

云服務(wù)提供商內(nèi)部的惡意運(yùn)維人員(Cloud operator)可能會(huì)有機(jī)會(huì)物理接觸到部署云計(jì)算平臺(tái)的物理機(jī)器。考慮一個(gè)簡(jiǎn)單的場(chǎng)景: 惡意運(yùn)維人員有可能使用惡意啟動(dòng)設(shè)備(例如, 外部USB啟動(dòng)設(shè)備)重新啟動(dòng)計(jì)算機(jī), 以讀取CPU內(nèi)部寄存器(例如, DR和MSR)中殘存的數(shù)據(jù)內(nèi)容。幸運(yùn)的是, 這種攻擊是無(wú)效的, 因?yàn)樵谥匦聠?dòng)物理機(jī)器時(shí), CPU內(nèi)部的所有寄存器都將被重置為零[35]。

基于CPU緩存(Cache)的側(cè)信道(side-channel)攻擊[64-65]對(duì)很多加密系統(tǒng)而言的是一大安全威脅。但是這種攻擊對(duì)HCoper中是無(wú)效的, 因?yàn)镮ntel AES- NI提供的硬件加密指令集對(duì)timing-attacks[24]免疫。即Intel AES-NI指令執(zhí)行加密運(yùn)算時(shí)沒(méi)有表現(xiàn)出規(guī)律性的時(shí)間差異, 攻擊者不能根據(jù)執(zhí)行時(shí)間差異性逆推出加密運(yùn)算執(zhí)行的細(xì)節(jié)。另外, HCoper的執(zhí)行控制流中沒(méi)有輸入依賴性(input dependent)的執(zhí)行分支(branch), 使得攻擊者不能使用側(cè)信道攻擊的手段(通過(guò)監(jiān)控、窺探目標(biāo)代碼內(nèi)跳轉(zhuǎn)分支的執(zhí)行情況, 逆推出執(zhí)行分支代碼時(shí)的輸入值)來(lái)推測(cè)加密密鑰以及加密計(jì)算得中間狀態(tài)值等。因此HCoper能防御側(cè)信道攻擊。

攻擊者還可能會(huì)發(fā)起基于DMA的高級(jí)攻擊[43], 將惡意代碼注入Hypervisor內(nèi)核, 然后訪問(wèn)調(diào)Debug存器和MSR寄存器中的密鑰。幸運(yùn)的是, 我們可以通過(guò)配置IOMMU[45]或使用BARM[44]來(lái)監(jiān)視系統(tǒng)總線活動(dòng)以檢測(cè)、揭露從外圍設(shè)備(peripherals)訪問(wèn)內(nèi)存的惡意行為, 從而抵御這種攻擊。最后, 通過(guò)物理訪問(wèn)(接觸)云平臺(tái)中的真實(shí)機(jī)器, 惡意的內(nèi)部人員(例如高級(jí)電氣工程師)可能會(huì)通過(guò)使用示波器等專業(yè)設(shè)備測(cè)量CPU周圍的電磁信號(hào)來(lái)變向讀取正在運(yùn)行的CPU的寄存器。但是這種攻擊實(shí)施條件異常嚴(yán)苛并且實(shí)施過(guò)程高度復(fù)雜, 據(jù)本文所知, 目前暫時(shí)還沒(méi)公開過(guò)這種高難度攻擊手段成功的案例。如何防御此種攻擊已不在HCoper研究的范圍。

7 結(jié)論

本文提出了一種在CPU內(nèi)執(zhí)行加密運(yùn)算(CPU- bound)的解決方案HCoper, 目的在于保護(hù)云租戶的密鑰免受惡意運(yùn)維人員發(fā)起的內(nèi)存快照攻擊。HCoper適用于真實(shí)云計(jì)算平臺(tái)。同時(shí), 所有的密碼計(jì)算都在CPU寄存器內(nèi)完成, 因此HCoper也不受冷啟動(dòng)攻擊(Cold-boot)、VM克隆攻擊(VM Cloning)和DaaS文件復(fù)制攻擊(DaaS File Copying)的威脅。通過(guò)執(zhí)行動(dòng)態(tài)密鑰調(diào)度, HCoper支持多個(gè)應(yīng)用程序使用多個(gè)密鑰。此外, HCoper已經(jīng)集成到其他第三方密碼庫(kù)中(如OpenSSL-1.1.0g、polarssl-2.6.0、GnuPG 1.4.22), 使得開發(fā)新應(yīng)用程序變得容易。HCoper原型系統(tǒng)作為Xen4.4.0的核心模塊實(shí)現(xiàn), 體現(xiàn)其具備實(shí)際部署價(jià)值。安全功能驗(yàn)證實(shí)驗(yàn)表明, 惡意運(yùn)維人員無(wú)法從客戶虛擬機(jī)的內(nèi)存快照文件中提取數(shù)據(jù)加密密鑰或主密鑰。此外, 性能評(píng)估表明, HCoper的效率與傳統(tǒng)的加密計(jì)算實(shí)現(xiàn)方案相當(dāng), 對(duì)其他并發(fā)型應(yīng)用程序性能的影響在可接受范圍(即HCoper帶來(lái)的性能損失不足以影響其實(shí)用性)。

目前HCoper只針對(duì)Intel CPU實(shí)現(xiàn)了對(duì)稱加密算法(AES)。理論上, HCoper的架構(gòu)思想可以部署在其他類型處理器上, 只要這些處理器也提供指令集支持實(shí)現(xiàn)加密算法(如AES、RSA)的加密操作。將來(lái), HCoper可以擴(kuò)展到非對(duì)稱加密計(jì)算(如RSA)。然而, 完全在CPU內(nèi)實(shí)現(xiàn)非對(duì)稱加密計(jì)算極具挑戰(zhàn)性, 因?yàn)镽SA計(jì)算需要更大的存儲(chǔ)空間, 而寄存器(如SSE)暫時(shí)不支持RSA所需要的存儲(chǔ)空間。HCoper方案比較適用于加密計(jì)算的中間變量或參數(shù)占用空間較小的算法(如AES算法等)。而其他算法(如RSA)計(jì)算過(guò)程中使用到的參數(shù)占用空間較大遠(yuǎn)超過(guò)SSE寄存器的空間, 針對(duì)此類算法, 可將一部分加密過(guò)程交給HCoper來(lái)完成或者使用HCoper來(lái)加密此類算法運(yùn)行過(guò)程中重要參數(shù)達(dá)到加密密鑰保護(hù)的目標(biāo), 這將是HCoper未來(lái)的優(yōu)化工作。另外, HCoper基于這樣一個(gè)假設(shè): Hypervisor是安全的, 沒(méi)有任何安全缺陷。另一個(gè)未來(lái)的工作可在硬件支持的可行執(zhí)行環(huán)境(如Intel SGX提供的Enclave)中實(shí)現(xiàn)加密計(jì)算, SGX對(duì)不受信任或遭受攻擊的Hypervisor發(fā)動(dòng)的攻擊免疫。然而, Intel SGX只為Enclave保留128M物理內(nèi)存, 如何使用有限的RAM加密大文件是一個(gè)挑戰(zhàn)。