面向云計算平臺的虛擬機(jī)同駐方法

劉維杰，王麗娜，王丹磊，尹正光，付楠

?

面向云計算平臺的虛擬機(jī)同駐方法

劉維杰1,2，王麗娜1,2，王丹磊1,2，尹正光3，付楠1,2

（1. 空天信息安全與可信計算教育部重點(diǎn)實(shí)驗(yàn)室，湖北 武漢 430079；2. 武漢大學(xué)國家網(wǎng)絡(luò)安全學(xué)院，湖北 武漢 430079；3. 阿里云計算有限公司，浙江 杭州 311121）

若攻擊者想攻擊云平臺上某一目標(biāo)虛擬機(jī)，則其必須與目標(biāo)虛擬機(jī)同駐?；诖?，提出一種虛擬機(jī)同駐方法，通過構(gòu)建云環(huán)境中自適應(yīng)的隱蔽信道，結(jié)合基于隱蔽信道的虛擬機(jī)同駐檢測方法和自動化虛擬機(jī)洪泛策略，并在國內(nèi)某知名商業(yè)云平臺上進(jìn)行同駐驗(yàn)證。實(shí)驗(yàn)表明，所構(gòu)建的自適應(yīng)隱蔽信道傳輸正確率可高達(dá)95%以上；所提出的同駐檢測方法置信度高，誤檢率不超過5‰。同駐方法不會破壞云平臺本身隔離性且具有一定的通用性，但潛在威脅極大，亟需重視與防范。

云計算平臺；虛擬機(jī)同駐；隱蔽信道；虛擬機(jī)洪泛

1 引言

云計算的概念從提出到廣泛應(yīng)用，在短短幾年的時間里經(jīng)歷了巨大的變革。目前，國內(nèi)外的商用云計算業(yè)務(wù)都已進(jìn)入蓬勃發(fā)展的重要時期，云計算也越來越多地被視為存儲數(shù)據(jù)和部署服務(wù)的下一代IT基礎(chǔ)設(shè)施。然而，多租戶動態(tài)聚合、邊界泛化的特點(diǎn)使云計算平臺難以抵抗虛擬機(jī)之間共享計算資源所帶來的安全威脅。其中，最主要的是虛擬機(jī)同駐威脅，即將屬于攻擊者的虛擬機(jī)實(shí)例運(yùn)行在目標(biāo)虛擬機(jī)所在的物理主機(jī)上。由于云環(huán)境“虛擬隔離、物理共存”的特點(diǎn)，云平臺允許同駐的虛擬機(jī)共享物理主機(jī)的大部分資源，因此同駐威脅難以避免，其主要包括資源干擾、拒絕服務(wù)、隱蔽/側(cè)信道、虛擬機(jī)跳躍、虛擬機(jī)逃逸和遷移間隙等[1-9]。惡意的虛擬機(jī)同駐會破壞云平臺中數(shù)據(jù)的機(jī)密性和資源的可用性，導(dǎo)致嚴(yán)重的安全問題，對大規(guī)模企業(yè)用戶和普通云租戶都會造成極大危害。

如果攻擊者意圖實(shí)施針對云計算平臺的攻擊，則必須先實(shí)現(xiàn)其惡意虛擬機(jī)與目標(biāo)虛擬機(jī)的同駐。早在2009年，Ristenpart等[10]首次提出了Amazon EC2（elastic compute cloud）平臺上的虛擬機(jī)同駐方案，但是其檢測同駐的方法是基于兩臺虛擬機(jī)之間的網(wǎng)絡(luò)分組往返時延（RTT, round trip time）會隨同駐與否而發(fā)生變化的原理，該原理過于簡單，且未能考慮到云平臺中復(fù)雜的網(wǎng)絡(luò)環(huán)境所造成網(wǎng)絡(luò)分組時延測量不準(zhǔn)確的問題。

在判斷虛擬機(jī)是否同駐方面，Bates等[11]提出利用“同駐水印”來進(jìn)行同駐檢測。其原理為利用檢測虛擬機(jī)向外部周期性地發(fā)送網(wǎng)絡(luò)分組，同時通過外部代理向目標(biāo)虛擬機(jī)發(fā)送網(wǎng)絡(luò)分組，通過測量網(wǎng)絡(luò)分組通信是否有足夠的時延來判斷虛擬機(jī)是否同駐。然而，此方法與Ristenpart等[10]提出的同駐檢測方法都依賴云平臺允許虛擬機(jī)自由地和外部進(jìn)行網(wǎng)絡(luò)通信，很容易由于云平臺因安全考慮將ICMP（internet control message protocol）禁止而失效[12]，且云平臺一旦對不同的私有專用網(wǎng)進(jìn)行隔離[13]，基于網(wǎng)絡(luò)信息的同駐方案將會變得毫無用武之地。

Zhang等[14]提出了一種虛擬機(jī)同駐探測方案，其讓租戶將一些暫不使用的處理器緩存行留為警報行，若探測到警報行被使用或其負(fù)載與之前不同，則表明其他虛擬機(jī)使用了該處理器緩存（下文簡稱cache）區(qū)域，同駐檢測器進(jìn)程就會發(fā)出報警。同時，余思等[15]將虛擬機(jī)同駐檢測問題具體化為cache負(fù)載的差異性度量，基于cache負(fù)載特征匹配來推斷目標(biāo)虛擬機(jī)與攻擊者虛擬機(jī)是否同駐。這兩種方案都根據(jù)cache的負(fù)載差異進(jìn)行同駐判斷，但是云平臺為了降低能耗，提高資源利用率，引入了各種基于硬件特性的資源優(yōu)化機(jī)制和資源隔離機(jī)制[16]，使cache的負(fù)載測量并不準(zhǔn)確，并且計算cache負(fù)載特征方法復(fù)雜，很難保證同駐檢測的實(shí)時性。

基于隱蔽信道的同駐檢測方案效果好，但難以在此基礎(chǔ)上實(shí)現(xiàn)虛擬機(jī)同駐[17]。針對這一問題，本文以“先假設(shè)，后驗(yàn)證”的思路，提出了一種面向云計算平臺的虛擬機(jī)同駐方案，如圖1所示。攻擊者在實(shí)施同駐的過程中，需要對同駐情況進(jìn)行判定，因此需要準(zhǔn)確率高的虛擬機(jī)同駐檢測手段來確定同駐情況。在攻擊者有目的性地進(jìn)行虛擬機(jī)洪泛后，還需借助合謀方案對目標(biāo)虛擬機(jī)進(jìn)行精確定位。

本文方案充分考慮具體的云計算環(huán)境，力求同駐檢測正確率高且易于部署。該方案改進(jìn)了現(xiàn)有的兩種隱蔽信道，并將其運(yùn)用到虛擬機(jī)的同駐檢測方案中，打破了基于隱蔽信道的檢測方案在現(xiàn)實(shí)環(huán)境難以實(shí)現(xiàn)同駐的壁壘；提出了一種基于后驗(yàn)概率的自動化虛擬機(jī)洪泛方法，有針對性地確定目標(biāo)虛擬機(jī)與洪泛虛擬機(jī)的同駐。利用本方案在國內(nèi)某知名商用云平臺上進(jìn)行實(shí)際驗(yàn)證，對增強(qiáng)現(xiàn)有商用云平臺的安全性有重要意義。

2 云計算環(huán)境下同駐威脅模型

在公有云環(huán)境中，攻擊者理論上可以通過合法渠道獲得部分資源，即攻擊者能夠創(chuàng)建任意的虛擬機(jī)并對其進(jìn)行管理。本文基于該事實(shí)提出如下假設(shè)。

假設(shè)1 云平臺系統(tǒng)有良好的隔離性，云平臺管理系統(tǒng)和其上的客戶操作系統(tǒng)均是干凈且安全的（及時更新，補(bǔ)丁完備），同時云管理員的操作均是善意且合規(guī)的，不存在內(nèi)部威脅[18]。如此，本文中的攻擊者僅通過側(cè)信道的方式實(shí)現(xiàn)與目標(biāo)虛擬機(jī)同駐。

假設(shè)2 云平臺的各個租戶之間是互不信任的，且不具有任何特殊權(quán)限。攻擊者只能期望利用側(cè)信道攻擊來獲取其他用戶的隱私信息[19]。攻擊者的目標(biāo)為使用云平臺的正常租戶，他們利用虛擬機(jī)運(yùn)行某些機(jī)密性的相關(guān)應(yīng)用。

假設(shè)3 攻擊者有足夠的資金保證其能夠開啟足夠多的虛擬機(jī)，同時還能夠通過社會工程的方式獲取目標(biāo)開啟虛擬機(jī)的準(zhǔn)確時間[11]。

上述假設(shè)均符合實(shí)際應(yīng)用場景，假設(shè)2中針對攻擊者背景知識的假設(shè)也具有相當(dāng)?shù)钠者m意義。為了方便描述，下面將攻擊者創(chuàng)建并擁有的虛擬機(jī)稱為攻擊虛擬機(jī)，將目標(biāo)用戶創(chuàng)建并擁有的虛擬機(jī)稱為目標(biāo)虛擬機(jī)。

3 基于隱蔽信道的虛擬機(jī)同駐檢測

如果攻擊者意圖實(shí)現(xiàn)與目標(biāo)虛擬機(jī)同駐，則必須擁有檢測攻擊虛擬機(jī)是否與目標(biāo)虛擬機(jī)同駐的能力。于是，在描述同駐方案前，本節(jié)提出其實(shí)現(xiàn)的基礎(chǔ)——基于隱蔽信道的同駐檢測方案。

現(xiàn)有研究中，基于網(wǎng)絡(luò)信息的同駐檢測方法實(shí)現(xiàn)簡單，檢測效率較高，但是檢測準(zhǔn)確率低，只能作為其他同駐檢測方法的輔助手段使用；基于資源干擾的同駐檢測方法雖然實(shí)現(xiàn)復(fù)雜，但檢測準(zhǔn)確率較高，適用范圍廣。但是，隨著虛擬機(jī)資源管理機(jī)制的優(yōu)化以及硬件技術(shù)的不斷發(fā)展，同駐虛擬機(jī)之間的相互干擾越來越難被發(fā)現(xiàn)[17]。基于硬件的隱蔽信道作為云平臺中不可避免地存在，可被充分地應(yīng)用于同駐檢測中[21]。

因此，本文以準(zhǔn)確性、高效性和實(shí)用性為目標(biāo)，提出基于隱蔽信道的同駐檢測方案，并以基于內(nèi)存總線沖突的隱蔽信道和基于最高級緩存（LLC, last level cache）的隱蔽信道為例，實(shí)現(xiàn)了這兩種同駐檢測方案。由于該方案以云平臺中的共享硬件資源為渠道構(gòu)建，因此具備極強(qiáng)的通用性[17]。

3.1 云環(huán)境下隱蔽信道機(jī)理與構(gòu)建

基于微處理器架構(gòu)的隱蔽信道是多用戶計算機(jī)系統(tǒng)中最常見的隱蔽信道類型，其主要存在于具有共享資源的系統(tǒng)中，如云計算環(huán)境中。不過在嘈雜的公有云環(huán)境中，微處理器架構(gòu)隱蔽信道會面臨更多的問題。虛擬機(jī)遷移、vCPU調(diào)度以及Hypervisor的活動增加了許多噪聲，這些都給隱蔽信道精確同步帶來了挑戰(zhàn)。

圖2 內(nèi)存與新型LLC的映射索引

3.1.1 基于LLC的隱蔽信道

與其他隱蔽信道介質(zhì)相比，cache對于攻擊者更具吸引力。因?yàn)閏ache的高操作速度可產(chǎn)生高帶寬，并且不受軟件系統(tǒng)限制，可以繞過許多高級隔離機(jī)制，所以近年來基于cache的隱蔽信道備受重視[20-21]。其中，最常用的交替通信技術(shù)是Prime + Probe方法[22]和Flush + Reload[23]方法。

文獻(xiàn)[24-25]提出了如何對該散列函數(shù)進(jìn)行逆向，但這種逆向工程需要進(jìn)行大量的實(shí)驗(yàn)，消耗大量時間。于是，文獻(xiàn)[7]提出了一種通過構(gòu)建沖突集的方法來尋找能夠映射到相同cache set而虛擬地址不同的內(nèi)存塊。本文對這種方法進(jìn)行了改進(jìn)，提出了一種快速構(gòu)建沖突內(nèi)存塊的方法，能夠進(jìn)一步地縮短尋找時間。改進(jìn)的方法描述如算法1所示。其中，函數(shù)()為所定義的Probe訪存原語。

算法1 基于LLC的隱蔽信道沖突集構(gòu)建算法

輸入 候選內(nèi)存行l(wèi)ines

輸出 驅(qū)逐集，每個分片一個驅(qū)逐集

(；)

讀??；

for eachin set do

讀??；

end for

end function

構(gòu)建

隨機(jī)化；

for each∈do

if not(_；)

將放入；

end for

構(gòu)建

for eachindo

if(，)

for eachindo

if not(_；)

將放入；

end for

if∪≠?

=e∪

輸出；

；

end for

通過將具有同樣元素的驅(qū)逐集合并，使本文構(gòu)建驅(qū)逐集的方案更加圓滿，能夠在每個slice對應(yīng)的驅(qū)逐集中找到超過組相聯(lián)路數(shù)的可供驅(qū)逐的內(nèi)存行。這樣，在隱蔽信道構(gòu)建時，就可以更加靈活地選用任意的slice ID和set ID作為LLC沖突集的ID。

3.1.2 基于內(nèi)存總線的隱蔽信道

內(nèi)存總線負(fù)責(zé)處理器與主存之間的數(shù)據(jù)傳輸，是現(xiàn)代計算機(jī)系統(tǒng)中不可或缺的組成部分。處理器內(nèi)的CPU核心都共用該內(nèi)存總線。因此，內(nèi)存總線上的沖突將會導(dǎo)致系統(tǒng)范圍可觀測的內(nèi)存訪問時延。因此，利用某些特定的程序行為所觸發(fā)的內(nèi)存總線沖突就可以構(gòu)建出一種隱蔽信道[26]。x86架構(gòu)中，處理器利用總線鎖（memory bus lock）實(shí)現(xiàn)內(nèi)存原子指令。對于未對齊的內(nèi)存區(qū)域，執(zhí)行內(nèi)存原子指令會觸發(fā)內(nèi)存總線鎖。利用這種機(jī)制，可以構(gòu)建一種高速、可靠、跨虛擬機(jī)的隱蔽信道，如圖3所示。

圖3 基于內(nèi)存總線的隱蔽信道

同樣地，對現(xiàn)有的基于內(nèi)存總線的隱蔽信道進(jìn)行了改進(jìn)：當(dāng)發(fā)送方使用特定的原子操作時，接收方使用SSE (streaming SIMD extension)指令集的某些訪存指令操作，避免訪問cache，使正常訪問內(nèi)存總線時的訪存時間不會因cache命中而產(chǎn)生影響，從而保證每次正常訪存（總線不沖突）時的時間基本一致，進(jìn)而保證了信道傳輸?shù)臏?zhǔn)確性。具體如算法2所示。

算法2基于內(nèi)存總線的隱蔽信道構(gòu)建算法

：異常操作數(shù)原子指令

[]，[]：發(fā)送和接收數(shù)據(jù)

發(fā)送方：

for=1 to1 do

if[]=1

for=0 to1 do

M內(nèi)存訪問；

end for

else

for=0 to1 do

SIMD內(nèi)存訪問；

end for

end for

接收方：

for=1 to1 do

for=0 to1 do

SIMD內(nèi)存訪問；

end for

if 平均訪問時間

[]=1；

else

[]=0；

end for

3.2 面向碼元識別的自適應(yīng)信道優(yōu)化

為了解決信道在嘈雜的公有云環(huán)境中傳輸正確率會受到影響的問題，本文引入了自適應(yīng)的碼元識別技術(shù)，以此來提升傳輸正確率。

本文通過使用數(shù)據(jù)幀（frame）來加強(qiáng)通信協(xié)議對時鐘漂移和調(diào)度中斷的彈性。傳輸?shù)臄?shù)據(jù)被分成固定長度，發(fā)送方使用偽隨機(jī)數(shù)生成算法來產(chǎn)生每一個數(shù)據(jù)幀的載荷[27]，并用起始模式和停止模式將每個數(shù)據(jù)段構(gòu)造成數(shù)據(jù)幀。這種方式具備兩個優(yōu)點(diǎn)：①當(dāng)發(fā)送方檢測到傳輸中斷時，不需要重傳全部數(shù)據(jù)，僅需重發(fā)相關(guān)數(shù)據(jù)幀；②在傳輸期間總是不可避免地會丟失部分?jǐn)?shù)據(jù)，利用數(shù)據(jù)幀，接收方能更加容易地定位錯誤，進(jìn)行糾錯處理。

3.2.1 信號的平滑與連續(xù)識別

由于嘈雜的云環(huán)境帶來的噪聲，信道若未經(jīng)過去噪便進(jìn)行碼元識別操作，將會引入相當(dāng)大的傳輸錯誤。平滑濾波技術(shù)能夠過濾低頻信號中的噪聲，它不經(jīng)由傅里葉轉(zhuǎn)換，在圖像處理領(lǐng)域被廣泛應(yīng)用。本文利用平滑濾波來實(shí)現(xiàn)信號的初篩。

經(jīng)過去噪操作后，所接收的“0”和“1”的區(qū)別已經(jīng)較為明顯（在基于內(nèi)存總線的信道中，發(fā)送“0”僅消耗約100個CPU時鐘周期，發(fā)送“1”需消耗幾千個CPU時鐘周期；在基于LLC的信道中，發(fā)送“0”消耗約30個CPU時鐘周期，而發(fā)送“1”需要消耗約100個時鐘周期）。因此，采取聚類的方式來區(qū)分接收的信息即可。在此情況中，僅需要將數(shù)據(jù)分為兩類，即僅需要求出聚類中心，之后再進(jìn)行簡單判斷。由于不用考慮時間序列，需要聚類的數(shù)據(jù)僅為一維數(shù)據(jù)。在此本文采用最為簡單有效的均值聚類法來實(shí)現(xiàn)該功能。

3.2.2 信道自適應(yīng)同步與校準(zhǔn)

由于發(fā)送方和接收方分屬不同的虛擬機(jī)，它們之間的調(diào)度差異將導(dǎo)致數(shù)據(jù)傳輸和檢測過程不同步，進(jìn)而對信道的調(diào)制造成很大的問題。本文通過自時鐘編碼克服時鐘失步，并使用差分曼徹斯特編碼傳輸數(shù)據(jù)位。更重要的是，當(dāng)通信雙方傳輸起始時間不同時，有很大的概率導(dǎo)致傳輸?shù)臄?shù)據(jù)極不連續(xù)。同時，為了減少重發(fā)次數(shù)，節(jié)省時間開銷，必須確保發(fā)送方和接收方的時隙是對齊的。如果沒有對齊，兩者將在重疊的時間內(nèi)爭用該信道并引入位翻轉(zhuǎn)錯誤。這種不受限制的爭用會導(dǎo)致“0”和“1”的值的可分離分布較少，加劇發(fā)送方和接收方的競爭，明顯降低信道的容量與可用性。針對這個問題，本文提出時鐘同步與接收確認(rèn)機(jī)制來提高信道可靠性，如算法3所示。其中，()與()分別表示發(fā)送幀與接收幀的函數(shù)方法，()表示搜索并微調(diào)當(dāng)前幀延時的函數(shù)方法。

算法3 自適應(yīng)的信道同步算法

[]，[]：發(fā)送和接收數(shù)據(jù)

()：信道傳輸正確率計算函數(shù)

發(fā)送方：

for<1 to 20 do

([])；

=+1；/* 微調(diào)1 μs */

end for

確定；

接收方：

for<1 to 20 do

([])；

end for

=([])；

本文提出的同步協(xié)議能夠?qū)崿F(xiàn)在幾百μs的時鐘差異內(nèi)，實(shí)現(xiàn)高精度的對齊傳輸。通過在隱蔽通道上傳送一個已知的比特序列來進(jìn)行多輪處理。在每次通信之后，發(fā)送方將其時鐘移動1 μs，稍微改變兩個進(jìn)程的執(zhí)行起始時間。隨著時鐘變得更加同步，兩個進(jìn)程的爭用變得更加一致。一旦達(dá)到最高正確率后，發(fā)送方的每次移位都會降低信道的傳輸正確率。此時，接收方通過測量最高正確率便可能定位到最佳的移位大小。同步過程的耗時取決于用于測試的分組大小，基本上每個虛擬機(jī)只需要執(zhí)行一次即可完成同步。

4 面向云平臺的虛擬機(jī)同駐方案

由于虛擬機(jī)同駐造成的危害越來越大，研究人員在云平臺的虛擬機(jī)投放策略上提出了抵御同駐危害的方法。已有研究[28-29]提出虛擬機(jī)動態(tài)部署算法，基于云提供商協(xié)助的VM遷移服務(wù)，通過不斷地重新部署VM，使任意兩臺VM間不存在足夠長的同駐時間，從而限制由側(cè)信道引發(fā)的信息泄露。上述方法雖然能夠在一定程度上抵御同駐威脅，但其防御窗口過長，仍無法從本質(zhì)上防止虛擬機(jī)實(shí)例洪泛造成的同駐。

虛擬機(jī)實(shí)例洪泛，即攻擊者在同一時間、同一個云平臺可用區(qū)，開啟大量的虛擬機(jī)實(shí)例。這些實(shí)例可能是攻擊者利用自身賬號投放，也可能是通過其控制的虛擬機(jī)僵尸網(wǎng)絡(luò)投放。虛擬機(jī)實(shí)例洪泛本質(zhì)上是對云平臺虛擬機(jī)分布策略的濫用，但其并不違反云平臺的商業(yè)策略和服務(wù)等級協(xié)議。

當(dāng)攻擊者實(shí)例開啟時間接近受害者虛擬機(jī)實(shí)例開啟時間時，攻擊者可以有效地利用云平臺平行放置的部署算法來實(shí)現(xiàn)一定概率的攻擊者實(shí)例與受害者實(shí)例同駐。由于云計算的動態(tài)特性，服務(wù)器通常在實(shí)例上運(yùn)行，不需要時終止，稍后再運(yùn)行。例如，攻擊者可以監(jiān)視服務(wù)器的狀態(tài)（如通過網(wǎng)絡(luò)探測）直到該實(shí)例消失，然后在發(fā)現(xiàn)一個新實(shí)例（該服務(wù)）重新開啟時進(jìn)行實(shí)例洪泛。攻擊者甚至可以利用該特點(diǎn)主動觸發(fā)新的目標(biāo)虛擬機(jī)實(shí)例。

4.1 基于后驗(yàn)概率的虛擬機(jī)洪泛覆蓋

本節(jié)提出了一種基于后驗(yàn)概率的自動化虛擬機(jī)方案。通過該方案可以得出：①被攻擊的虛擬機(jī)分布在各臺物理主機(jī)的概率；②本次投放VM flooding虛擬機(jī)時，每一臺攻擊虛擬機(jī)與被攻擊的目標(biāo)虛擬機(jī)同駐的概率。該方案的總體思路為先大量投放虛擬機(jī)，再對所投放的虛擬機(jī)進(jìn)行同駐檢測，將確定為同駐的虛擬機(jī)歸類，最后對所投放的虛擬機(jī)進(jìn)行約減。具體步驟如下。

在實(shí)驗(yàn)結(jié)果上有

記

顯然式(4)為凸函數(shù)，在式(6)中引入拉格朗日乘子，代入式(4)得

當(dāng)式(7)取得最大值時，自變量偏導(dǎo)數(shù)為0，即

將式(4)、式(6)代入式(8)，有

由式(2)、式(9)可得

上述概率可以告知攻擊者如何進(jìn)行下一步的攻擊實(shí)驗(yàn)，并給予攻擊者理論上的指導(dǎo)。例如，優(yōu)先從同駐發(fā)生率較高的物理主機(jī)開始進(jìn)行同駐檢測，從而加快發(fā)現(xiàn)與目標(biāo)同駐的速度。

4.2 基于合謀的同駐虛擬機(jī)遠(yuǎn)程定位

當(dāng)洪泛虛擬機(jī)數(shù)量達(dá)到一定程度時，可實(shí)現(xiàn)云平臺可用區(qū)物理主機(jī)的全部覆蓋。盡管如此，攻擊虛擬機(jī)如何定位目標(biāo)虛擬機(jī)依舊困難。

文獻(xiàn)[4]提出，在云計算環(huán)境下，攻擊虛擬機(jī)可借助前面所述的內(nèi)存總線沖突來實(shí)現(xiàn)云環(huán)境的拒絕服務(wù)（DoS, denial of service）攻擊，具體操作方式為不斷觸發(fā)內(nèi)存總線沖突，正如構(gòu)建隱蔽信道一般[30]，造成大量內(nèi)存訪問時延，從而達(dá)到平臺上其他虛擬機(jī)無法正常使用內(nèi)存的目的。除了該內(nèi)存總線占用漏洞外，利用內(nèi)存行錘擊漏洞也可造成虛擬化平臺的服務(wù)等級下降甚至停止。攻擊虛擬機(jī)可通過不斷錘擊具有關(guān)鍵數(shù)據(jù)的內(nèi)存行（如Hypervisor所維護(hù)的EPT/NPT頁表），使整個虛擬化平臺暫停服務(wù)[2-3]。本文基于上述DDoS攻擊，結(jié)合合謀攻擊的思路，提出一種能夠快速定位目標(biāo)虛擬機(jī)的方法。

5 同駐實(shí)驗(yàn)與行業(yè)驗(yàn)證

在對本文提出的同駐方案驗(yàn)證之前，首先對所提的基于隱蔽信道的同駐檢測方案進(jìn)行了實(shí)驗(yàn)驗(yàn)證，以確保該同駐檢測（判定）方案在之后的方案驗(yàn)證中得到最大程度的效用。

5.1 虛擬機(jī)同駐判定

5.1.1 同駐閾值計算

為了確定傳輸正確率與虛擬機(jī)是否同駐之間的關(guān)系，選取分布在兩臺物理主機(jī)上的共10臺虛擬機(jī)之間進(jìn)行隱蔽信道通信實(shí)驗(yàn)。以基于內(nèi)存總線的隱蔽信道為例，其傳輸正確率與同駐狀態(tài)如圖4所示。

圖4 傳輸正確率的多次采樣

其中，實(shí)際同駐的虛擬機(jī)共20對，非同駐的虛擬機(jī)共25對。實(shí)驗(yàn)中，同駐虛擬機(jī)傳輸正確率最小值為90.7%，非同駐虛擬機(jī)傳輸正確率最大值為57.9%。兩類樣本間有明顯間隔，因此，可以通過設(shè)定傳輸準(zhǔn)確率閾值判定虛擬機(jī)是否同駐。

實(shí)際上，當(dāng)隱蔽信道的參數(shù)一定時，同駐虛擬機(jī)傳輸正確率與非同駐虛擬機(jī)傳輸正確率均為客觀上的定值。由于實(shí)驗(yàn)數(shù)據(jù)的局限性和某些可能出現(xiàn)的噪聲的影響，傳輸正確率符合正態(tài)分布。為了確定虛擬機(jī)是否同駐的判定閾值，需要先由樣本估計出正態(tài)分布的參數(shù)，然后經(jīng)過計算得到最優(yōu)的判定閾值。

不同駐時傳輸正確率分布函數(shù)為

最優(yōu)判定閾值應(yīng)滿足

5.1.2 檢測效果評估

通過上述計算得到判定閾值后，重新對3臺同樣的物理主機(jī)上的共15臺確定編號的虛擬機(jī)進(jìn)行隱蔽信道通信實(shí)驗(yàn)。為了盡可能地模擬實(shí)際云平臺環(huán)境，所有虛擬機(jī)每15 min進(jìn)行一次隨機(jī)遷移(目標(biāo)主機(jī)不確定)。

以基于內(nèi)存總線的隱蔽信道實(shí)現(xiàn)為測試工具，同樣每15 min對105對虛擬機(jī)進(jìn)行同駐檢測，每次檢測持續(xù)8 s，持續(xù)測量1 h，實(shí)驗(yàn)結(jié)果如表1所示。

表1 同駐檢測效果評估

通過表1可以看出，本文提出的同駐檢測方法具有極低的誤檢率和漏檢率。這一方面是由于對兩種隱蔽信道的實(shí)現(xiàn)做出了改進(jìn)，且充分考慮到云環(huán)境中的噪聲和其他不良影響，對信道的通信進(jìn)行了針對性的優(yōu)化；另一方面是由于所設(shè)的判定閾值具有較好的置信度。隨后，本文提出的同駐檢測方法在實(shí)驗(yàn)室環(huán)境中檢測成功的前提下，將此方法應(yīng)用于商用云平臺的同駐檢測中，通過虛擬機(jī)洪泛碰撞的方式使兩臺云實(shí)例同駐。

5.2 同駐方案行業(yè)應(yīng)用驗(yàn)證

現(xiàn)階段，國內(nèi)公有云服務(wù)競爭激烈。其中，某云平臺（下文中簡稱α云）作為行業(yè)標(biāo)桿，其他公有云服務(wù)平臺架構(gòu)與其極為類似。因此，為了使實(shí)驗(yàn)結(jié)果具有標(biāo)準(zhǔn)性和普適性，本文選取α云作為目標(biāo)，對其商業(yè)策略和服務(wù)等級協(xié)議進(jìn)行研究，并在α云上有針對性地利用前面提出的VM flooding攻擊方案進(jìn)行了一系列實(shí)驗(yàn)。

目前，在物理基礎(chǔ)設(shè)施方面，α云提供了5個配置自由度，分別是：①地域；②可用區(qū)，可用區(qū)是指在同一地域內(nèi)，電力和網(wǎng)絡(luò)互相獨(dú)立的物理區(qū)域，通常為一個機(jī)房；③~⑤實(shí)例系列，實(shí)例系列代表著不同的硬件系列，分別為系列Ⅰ、系列Ⅱ、系列Ⅲ。其中，不同系列采用不同的CPU類型，且其內(nèi)存也不盡相同。在上述5個自由度中，前兩個（地域和可用區(qū)）屬于對地理位置的配置，而后3個屬于對實(shí)例類型的配置。本文選擇華南1-可用區(qū)A進(jìn)行投放實(shí)驗(yàn)，后續(xù)如無特殊說明，虛擬機(jī)實(shí)例都在該可用區(qū)創(chuàng)建。

5.2.1 自動化同駐檢測

為了能夠?qū)γ總€虛擬機(jī)實(shí)例進(jìn)行同駐檢測，每個虛擬機(jī)實(shí)例上都必須安裝隱蔽信道通信程序。因此，首先創(chuàng)建了一個含有隱蔽信道發(fā)送和接收程序的鏡像Image-covert-channel，其用戶操作系統(tǒng)為64 bit Ubuntu14.04。后續(xù)的虛擬機(jī)實(shí)例均以此鏡像為模板創(chuàng)建。

為了更進(jìn)一步實(shí)現(xiàn)同駐檢測的自動化，本文基于Ansible開發(fā)了配置管理與自動化運(yùn)行工具，通過SSH（secure shell）連接服務(wù)器并運(yùn)行配置任務(wù)。它非常適合將bash腳本轉(zhuǎn)換成Ansible任務(wù)，并且由于其基于SSH，因此更易于檢查運(yùn)行結(jié)果。Ansible同樣支持在α云或其他大型商用云（如Amazon EC2）中采用組（group）的形式管理虛擬機(jī)并遍歷組內(nèi)的所有主機(jī)。由此，使用add_host模塊動態(tài)創(chuàng)建一個由這些新實(shí)例組成的group，便于在后續(xù)任務(wù)中立即在主機(jī)上執(zhí)行所需操作。

圖5 ACD工作流程

5.2.2 同駐實(shí)驗(yàn)案例研究

由于考慮到CPU核數(shù)和內(nèi)存大的虛擬機(jī)可能被分配到更具特殊性的物理機(jī)中，首先用賬號甲同時創(chuàng)建了n1.small和n1.medium虛擬機(jī)實(shí)例各50臺，基于第3節(jié)提出的同駐檢測方法，對其進(jìn)行兩兩檢測。檢測結(jié)果顯示，任意兩臺虛擬機(jī)都不同駐。再考慮到獨(dú)享型的虛擬機(jī)可能被分配到更具特殊性的物理機(jī)。繼續(xù)用賬號甲同時創(chuàng)建了n2.small和n2.medium虛擬機(jī)實(shí)例各50臺，對其進(jìn)行兩兩檢測。檢測結(jié)果顯示，任意兩臺虛擬機(jī)都不同駐。結(jié)果如表2所示。

表2 單一賬號同時創(chuàng)建多臺虛擬機(jī)

基于上述推測可知，單一賬號的同駐情況并不理想。于是，本文調(diào)整最初的洪泛策略，使用多個賬號進(jìn)行實(shí)驗(yàn)。

首先，改用兩個賬號分別同時創(chuàng)建了5臺sn1.medium虛擬機(jī)實(shí)例，對其進(jìn)行同駐檢測，檢測到一對虛擬機(jī)同駐，其實(shí)例ID分別為i-wz91n5w6 koukiloem6lj和i-wz952qiz9n49r2vj5yyg。

以i-wz91n5w6koukiloem6lj作為發(fā)送方，i-wz952qiz9n49r2vj5yyg作為接收方，采用經(jīng)過調(diào)試的最優(yōu)參數(shù)：=6 700、=300、=7，測量隱蔽信道傳輸正確率高達(dá)95.3%，其傳輸效果如圖6所示。其中，發(fā)送信息被封裝到一個frame中，“+”“?”分別代表所發(fā)送的“1”和“0”。后續(xù)如無特殊說明，所有同駐實(shí)驗(yàn)均采用上述參數(shù)作為輸入。

(a) 發(fā)送方

(b) 接收方

圖6 隱蔽信道在α云上的檢測效果

之后，用甲、乙、丙這3個賬號分別同時各創(chuàng)建了5臺sn1.medium型實(shí)例，共15臺實(shí)例。為了進(jìn)一步具體測量同駐產(chǎn)生率，本文分別使用兩個賬號同時創(chuàng)建5臺sn1.medium虛擬機(jī)及3個賬號同時創(chuàng)建5臺sn1.medium虛擬機(jī)，并進(jìn)行50次重復(fù)實(shí)驗(yàn)。其中，當(dāng)兩個不同賬號同時創(chuàng)建medium型實(shí)例各5臺時，有48%的概率實(shí)現(xiàn)一對虛擬機(jī)同駐；當(dāng)3個不同賬號同時創(chuàng)建實(shí)例各5臺時，有90%的概率出現(xiàn)至少一對虛擬機(jī)同駐，有82%的概率出現(xiàn)至少兩對虛擬機(jī)同駐，有52%的概率出現(xiàn)3對虛擬機(jī)同駐。另外，觀察到同駐的這兩臺虛擬機(jī)分別處于兩個不同的內(nèi)網(wǎng)網(wǎng)段，因此判斷α云有極大可能使用了類似VPE[13]或VxLan的網(wǎng)絡(luò)隔離措施來構(gòu)建安全組或私有云的網(wǎng)絡(luò)邊界。

采用更多的賬號進(jìn)行了相同的實(shí)驗(yàn)。當(dāng)使用4個賬號甲、乙、丙、丁同時創(chuàng)建sn1.medium虛擬機(jī)實(shí)例時，共出現(xiàn)了35對同駐。其中，有兩臺物理機(jī)上同駐了4臺虛擬機(jī)，3臺物理機(jī)上同駐了3臺虛擬機(jī)，14臺物理機(jī)上同駐了兩臺虛擬機(jī)，另外，75臺物理機(jī)上只分配到一臺虛擬機(jī)，總計120臺虛擬機(jī)被部署到了94臺物理機(jī)上。同時，5個賬號與6個賬號同時創(chuàng)建共120臺虛擬機(jī)的同駐結(jié)果如表3所示。由表3可知，當(dāng)賬號越多時，同駐情況越好，實(shí)證了5.2.1節(jié)所提出的假設(shè)。

接著，為了探究虛擬機(jī)同駐概率與實(shí)例類型之間的關(guān)系，本文對n1.tiny、sn1.medium、sn2.medium這3種類型的實(shí)例進(jìn)行了實(shí)驗(yàn)。此次實(shí)驗(yàn)使用了12個賬號同時各創(chuàng)建一臺虛擬機(jī)，重復(fù)實(shí)驗(yàn)50次，同駐結(jié)果如表4所示?？梢钥闯?，sn1.medium型實(shí)例的平均同駐對數(shù)略高于其他兩種類型。

表3 多賬號同時創(chuàng)建多臺虛擬機(jī)

表4 多賬號同時創(chuàng)建不同類型實(shí)例

由上述分析可知：當(dāng)賬號越多時，同駐比例越大；當(dāng)實(shí)例類型為sn1.medium時，同駐比例最大。因此，為了進(jìn)一步對本文所提的洪泛策略進(jìn)行改進(jìn)與實(shí)驗(yàn)驗(yàn)證，在36 d時間內(nèi)α云使用高峰時間段（晚8時—晚9時），使用12個賬號同時開啟共360臺、480臺和600臺sn1.medium型實(shí)例各10次。具體情況如圖7所示。

圖7 大規(guī)模虛擬機(jī)實(shí)例洪泛

由圖7(c)可知，110臺物理主機(jī)中，載有5個和6個同駐虛擬機(jī)的數(shù)量最多，分別有32臺和31臺。所有的物理主機(jī)均有3個及以上同駐虛擬機(jī)，單臺物理主機(jī)上最大的同駐虛擬機(jī)數(shù)為9。由第4節(jié)結(jié)論可知：在同一時間再開啟10~15個虛擬機(jī)，有約15%~21%的概率使攻擊虛擬機(jī)與這9個目標(biāo)虛擬機(jī)同駐。另外，在所有的12個賬號中，每50個實(shí)例均被投放到了40~43臺物理主機(jī)上，其中，載有兩個虛擬機(jī)的物理主機(jī)均不少于6臺。

圖8顯示了采用上述基于后驗(yàn)概率洪泛策略進(jìn)行有針對性的虛擬機(jī)投放時，僅使用2、5、10個賬號迭代開啟虛擬機(jī)時同駐的覆蓋率。從圖8可以看到，當(dāng)投放數(shù)量超過100時，同駐覆蓋率有大幅提升；當(dāng)使用5個不同賬號投放72次（360臺虛擬機(jī)實(shí)例）時，同駐覆蓋率就已經(jīng)接近90%；當(dāng)使用10個不同賬號投放25次時，覆蓋率超過95%；當(dāng)投放實(shí)例數(shù)超過500時，無論使用多少數(shù)量的賬號，都可基本實(shí)現(xiàn)全部覆蓋。

圖8 同駐覆蓋比

5.2.3 實(shí)驗(yàn)結(jié)果分析

通過歷時多個月的同駐實(shí)驗(yàn)，可以發(fā)現(xiàn)與驗(yàn)證如下規(guī)律。

1) 現(xiàn)階段α云對于同駐威脅做出了基本的防護(hù)，采取了一些簡單的應(yīng)對措施。首先，ICMP分組被禁止使用于網(wǎng)絡(luò)探測，不同用戶的虛擬機(jī)之間的網(wǎng)絡(luò)與其所處的物理主機(jī)無關(guān)。其次，同一賬號的虛擬機(jī)在正常情況下無法被分配到同一物理機(jī)。

2) 不同賬號同時創(chuàng)建相同可用區(qū)、相同實(shí)例類型的虛擬機(jī)時，產(chǎn)生同駐的可能性極大，且采用的賬號越多，攻擊成功率越高。實(shí)例類型對于同駐率的影響不大。

3) 當(dāng)啟動大量的虛擬機(jī)來進(jìn)行VM flooding實(shí)驗(yàn)時，由于物理主機(jī)的數(shù)量遠(yuǎn)小于開啟的實(shí)例數(shù)，同一賬號的虛擬機(jī)無法被分配到同一物理機(jī)的規(guī)律被打破。在同一時間大量虛擬機(jī)被分布在百余臺物理主機(jī)上，基本覆蓋了該可用區(qū)子網(wǎng)的物理主機(jī)，充分說明了該洪泛策略的可行性。

6 結(jié)束語

本文對適用于商用云平臺的虛擬機(jī)同駐方案進(jìn)行了研究。以“先假設(shè)，后驗(yàn)證”的方式來完成攻擊虛擬機(jī)與目標(biāo)虛擬機(jī)的同駐，且在強(qiáng)安全條件下依舊有效。該方案能夠使攻擊者快速實(shí)現(xiàn)惡意虛擬機(jī)與目標(biāo)虛擬機(jī)的同駐，盡可能地減少不必要的開銷。

[1] DESNOS A, FILIOL E, LEFOU I, et al. Detecting (and creating!) a HVM rootkit (aka BluePill-like)[J]. Journal in Computer Virology, 2011, 7(1): 23-49.

[2] RAZAVI K, GRAS B, BOSMAN E, et al. Flip feng shui: hammering a needle in the software stack[C]//Usenix Security Symposium. 2016: 1-18.

[3] XIAO Y, ZHANG X, ZHANG Y, et al. One bit flips, one cloud flops: cross-VM row hammer attacks and privilege escalation[C]//Usenix Security Symposium. 2016: 19-35.

[4] ZHANG T, ZHANG Y, LEE R. DoS attacks on your memory in the cloud[C]//ACM Symposium on Information, Computer and Communications Security. 2017: 253-265.

[5] IRAZOQUI G, INCI M S, EISENBARTH T, et al. Fine grain cross-VM attacks on Xen and VMware[C]//ACM Conference on Cloud Computing. 2014: 737-744.

[6] IRAZOQUI G, INCI M S, EISENBARTH T, et al. Wait a minute! a fast, cross-VM attack on AES[C]//International Symposium on Recent Advances in Intrusion Detection. 2014: 299-319.

[7] LIU F, YAROM Y, GE Q, et al. Last-level cache side-channel attacks are practical[C]//IEEE Symposium on Security and Privacy. 2015: 605-622.

[8] IRAZOQUI G, EISENBARTH T, SUNAR B, et al. Cross processor cache attacks[C]//ACM Conference on Computer and Communications Security. 2016: 353-364.

[9] YAROM Y, GENKIN D, HENINGER N, et al. CacheBleed: a timing attack on OpenSSL constant time RSA[C]//International Workshop on Cryptographic Hardware and Embedded Systems. 2016: 346-367.

[10] RISTENPART T, TROMER E, SHACHAM H, et al. Hey, you, get off of my cloud: exploring information leakage in third-party compute clouds[C]//ACM Conference on Computer and Communications Security. 2009: 199-212.

[11] BATES A, MOOD B, PLETCHER J, et al. Detecting co-residency with active traffic analysis techniques[C]//ACM Conference on Cloud Computing. 2012: 1-12.

[12] XU Z, WANG H, WU Z, et al. A measurement study on co-residence threat inside the cloud[C]//Usenix Security Symposium. 2015: 929-944.

[13] 王麗娜, 張浩, 余榮威, 等. 基于VPE的可信虛擬域構(gòu)建機(jī)制[J]. 通信學(xué)報, 2013, 34(12): 167-177.

WANG L N, ZHANG H, YU R W, et al. Building mechanism of trusted virtual domain via the VPE[J]. Journal on Communications, 2013, 34(12): 167-177.

[14] ZHANG Y, JUELS A, OPREA A, et al. HomeAlone: co-residency detection in the cloud via side-channel analysis[C]//IEEE Symposium on Security and Privacy. 2011: 313-328.

[15] 余思, 桂小林, 張學(xué)軍, 等. 云環(huán)境中基于cache共享的虛擬機(jī)同駐檢測方法[J]. 計算機(jī)研究與發(fā)展, 2013, 50(12): 2651-2660.

YU S, GUI X L, ZHANG X J, et al. Co-residency detection scheme based on shared cache in the cloud[J]. Journal of Computer Research and Development, 2013, 50(12): 2651-2660.

[16] LIU F, GE Q, YAROM Y, et al. CATalyst: defeating last-level cache side channel attacks in cloud computing[C]//IEEE International Symposium on High Performance Computer Architecture. 2016: 406-418.

[17] 梁鑫, 桂小林, 戴慧珺, 等. 云環(huán)境中跨虛擬機(jī)的cache側(cè)信道攻擊技術(shù)研究[J]. 計算機(jī)學(xué)報, 2017, 40(2): 317-336.

LIANG X, GUI X L, DAI H J, et al. Cross-VM cache side channel attacks in cloud: a survey[J]. Chinese Journal of Computers, 2017, 40(2): 317-336.

[18] 王國峰, 劉川意, 潘鶴中, 等. 云計算模式內(nèi)部威脅綜述[J]. 計算機(jī)學(xué)報, 2017, 40(2): 296–316.

WANG G F, LIU C Y, PAN H Z, et al. Survey on insider threats to cloud computing[J]. Chinese Journal of Computers, 2017, 40(2): 296-316.

[19] WANG L, LIU W, KUMAR N, et al. A novel covert channel detection method in cloud based on XSRM and improved event association algorithm[J]. Security and Communication Networks, 2016, 9(16): 3543-3557.

[20] IRAZOQUI G, EISENBARTH T, SUNAR B, et al. S$A: a shared cache attack that works across cores and defies VM sandboxing-and its application to AES[C]//IEEE Symposium on Security and Privacy. 2015: 591-604.

[21] 沈晴霓, 李卿. 云計算環(huán)境中的虛擬機(jī)同駐安全問題綜述[J]. 集成技術(shù), 2015, 4(5): 5-17.

SHEN Q N, LI Q. Review on co-residency security issues of virtual machines in cloud computing[J]. Journal of Integration Technology, 2015, 4(5): 5-17.

[22] OSVIK D A, SHAMIR A, TROMER E. Cache attacks and countermeasures: the case of AES[C]//Cryptographers’ Track at the RSA Conference. 2006: 1-20.

[23] YAROM Y, FALKNER K. FLUSH+RELOAD: a high resolution, low noise, L3 cache side-channel attack[C]//Usenix Security Symposium. 2014: 719-732.

[24] MAURICE C, SCOUARNEC N L, NEUMANN C, et al. Reverse engineering intel last-level cache complex addressing using performance counters[C]//International Symposium on Recent Advances in Intrusion Detection. 2015: 48-65.

[25] IRAZOQUI G, EISENBARTH T, SUNAR B, et al. Systematic reverse engineering of cache slice selection in intel processors[C]//Euromicro Conference on Digital Systems Design. 2015: 629-636.

[26] WU Z, XU Z, WANG H, et al. Whispers in the hyper-space: high-bandwidth and reliable covert channel attacks inside the cloud[J]. IEEE/ACM Transactions on Networking, 2015, 23(2): 603-615.

[27] PAAR C, PELZL J. Understanding cryptography: a textbook for students and practitioners[M]. Springer Science & Business Media, 2009.

[28] LI P, GAO D, REITER M K, et al. Replica placement for availability in the worst case[C]//International Conference on Distributed Computing Systems. 2015: 599-608.

[29] MOON S, SEKAR V, REITER M K, et al. Nomad: mitigating arbitrary cloud side channels via provider-assisted migration[C]//ACM Conference on Computer and Communications Security. 2015: 1595-1606.

[30] LIU W, GAO D, REITER M K. On-demand time blurring to support side-channel defense[C]//European Symposium on Research in Computer Security. 2017:210-228.

[31] NEEDLEMAN S B, WUNSCH C D. A general method applicable to the search for similarities in the amino acid sequence of two proteins[J]. Journal of Molecular Biology, 1970, 48(3): 443-453.

[32] VARADARAJAN V, ZHANG Y, RISTENPART T, et al. A placement vulnerability study in multi-tenant public clouds[C]//Usenix Security Symposium. 2015:913-928.

Virtual machine co-residency method on cloud computing platform

LIU Weijie1,2, WANG Li’na1,2, WANG Danlei1,2, YIN Zhengguang3, FU Nan1,2

1. Key Laboratory of Aerospace Information Security and Trusted Computing, Ministry of Education, Wuhan 430079, China 2. School of Cyber Science and Engineering, Wuhan University, Wuhan 430079, China 3. Alibaba Cloud Computing Co., Ltd., Hangzhou 311121, China

If the attacker wants to compromise a target virtual machine on a cloud platform, the malicious virtual machine must be co-resident with the target. Based on this, a virtual machine co-residency method was proposed. The method combined a co-residency detection scheme based on covert channel construction and an automatic virtual machine flooding strategy, and was evaluated on a well-known domestic cloud platform. Experiment shows that the adaptive covert channel can achieve accuracies of 95%, the proposed detection scheme has strong robustness whose false positive rate is less than 5 ‰, the proposed method is versatile and keeps the virtualization isolation barrier intact, which has great potential threat and should be paid great attention and precaution.

cloud computing platform, virtual machine co-residency, covert channel, virtual machine flooding

TP309

A

10.11959/j.issn.1000?436x.2018241

劉維杰（1991–），男，湖北武漢人，武漢大學(xué)博士生，主要研究方向?yàn)樘摂M化安全、圖像處理等。

王麗娜（1964–），女，遼寧營口人，博士，武漢大學(xué)教授、博士生導(dǎo)師，主要研究方向?yàn)槎嗝襟w安全、云計算安全、可信計算等。

王丹磊（1992–），男，湖北武漢人，武漢大學(xué)碩士生，主要研究方向?yàn)闄C(jī)器學(xué)習(xí)、信息內(nèi)容安全等。

尹正光（1989–），男，江西吉安人，碩士，阿里云計算有限公司高級開發(fā)工程師，主要研究方向?yàn)閏loud native和IaaS架構(gòu)等。

付楠（1993–），女，江西九江人，武漢大學(xué)碩士生，主要研究方向?yàn)榫W(wǎng)絡(luò)安全、云計算安全等。

2018?04?03；

2018?06?29

王麗娜，lnwang@whu.edu.cn

國家自然科學(xué)基金資助項(xiàng)目（No.U1536204）；中央高?；究蒲袠I(yè)務(wù)費(fèi)專項(xiàng)基金資助項(xiàng)目（No.2042018kf1028）

The National Natural Science Foundation of China (No.U1536204), The Central University Basic Business Expenses Special Funding for Scientific Research Project (No.2042018kf1028)