王崛贛，柳毅

（廣東工業(yè)大學(xué)計算機學(xué)院，廣州510006）

0 引言

云存儲服務(wù)以其存儲方便、價格低廉的特點，吸引了大量的用戶，而眾多云存儲用戶上傳的海量數(shù)據(jù)中存在許多重復(fù)數(shù)據(jù)。為了節(jié)約存儲成本、減少網(wǎng)絡(luò)帶寬消耗，云存儲服務(wù)提供商（CSP）會采用數(shù)據(jù)去重技術(shù)?；驹矸浅：唵危慨?dāng)上載文件時，存儲服務(wù)器都會檢查該文件是否是先前存儲的內(nèi)容的副本，如果存在，新副本將定向到相同副本的位置，不存在，則上傳內(nèi)容。而實際中，存在大量的內(nèi)容相似度高而細(xì)節(jié)不盡相同的文件，所以文件級重復(fù)數(shù)據(jù)刪除方案往往效率不高。實際中常應(yīng)用數(shù)據(jù)塊級去重，每個文件切分為若干數(shù)據(jù)塊，將冗余的數(shù)據(jù)塊從系統(tǒng)中刪除。

在數(shù)據(jù)上傳過程中，重復(fù)數(shù)據(jù)刪除技術(shù)的應(yīng)用還存在減少網(wǎng)絡(luò)帶寬消耗的可能?？蛻舳巳ブ胤桨钢?，用戶只需要上傳數(shù)據(jù)的哈希值，云服務(wù)器對數(shù)據(jù)的哈希值進(jìn)行查驗，如果存在重復(fù)性，則無需上傳數(shù)據(jù)，減少了數(shù)據(jù)上傳的網(wǎng)絡(luò)帶寬消耗。

盡管在客戶端實現(xiàn)跨用戶去重的方案有諸多優(yōu)點，但是也存在著不足。在去重過程中，它為側(cè)通道攻擊的出現(xiàn)提供了可能性，攻擊者通過數(shù)據(jù)的去重是否發(fā)生就可以推斷出數(shù)據(jù)存在與否，進(jìn)而侵犯他人數(shù)據(jù)隱私。這存在一個去重悖論：一方面，必須暴露數(shù)據(jù)部分信息，用于做去重的依據(jù)；另一方面，用戶不希望存儲在云中的數(shù)據(jù)信息暴露，被攻擊者獲取隱私信息。

本文提出了一種隱私保護(hù)的客戶端去重方案，在不借助可信第三方服務(wù)器、存儲網(wǎng)關(guān)等網(wǎng)絡(luò)設(shè)備的前提下，通過略微增加通信開銷，實現(xiàn)了更強的數(shù)據(jù)隱私保護(hù)。本文方案貢獻(xiàn)總結(jié)如下：

（1）重復(fù)性查詢時，同時對兩個數(shù)據(jù)塊的重復(fù)度進(jìn)行查驗，設(shè)計獨特的反饋信號。使攻擊者無法判斷數(shù)據(jù)塊的存在性。

（2）不需要額外的第三方網(wǎng)絡(luò)設(shè)備，降低了系統(tǒng)成本，也降低了第三方設(shè)備被攻擊者劫持造成數(shù)據(jù)泄露的風(fēng)險。

（3）對驗證為可能是重復(fù)數(shù)據(jù)的數(shù)據(jù)塊進(jìn)行所有權(quán)證明驗證，有效防止攻擊者僅憑借數(shù)據(jù)標(biāo)簽就可以取得用戶數(shù)據(jù)的情況發(fā)生。

（4）對數(shù)據(jù)進(jìn)行流行度劃分，流行度高的數(shù)據(jù)含有的隱私信息較少，可以直接向客戶端反饋這些數(shù)據(jù)的存儲狀況，無需上傳流行數(shù)據(jù)達(dá)到減少網(wǎng)絡(luò)帶寬消耗的目的。

1 相關(guān)工作

關(guān)于云存儲去重已經(jīng)進(jìn)行了大量的研究。早期因為數(shù)據(jù)加密方式的不同，導(dǎo)致數(shù)據(jù)去重和語義安全的加密不兼容，加密方式及密鑰等差異，即使同樣的明文數(shù)據(jù)得到不同的密文，不可能識別出數(shù)據(jù)是否重復(fù)。對此，文獻(xiàn)[1]提出收斂加密（Convergent Encryp?tion，CE）算法，CE為基于內(nèi)容的加密算法，由數(shù)據(jù)內(nèi)容計算得到加密密鑰，并用此密鑰加密原始數(shù)據(jù)得到密文。確保了相同的數(shù)據(jù)加密之后得到相同的密文，為云存儲去重提供了技術(shù)支持。出于降低存儲成本、網(wǎng)絡(luò)帶寬消耗的目的，云存儲服務(wù)供應(yīng)商往往會采用跨用戶客戶端重復(fù)數(shù)據(jù)刪除[2]。但是這種去重方案過程中可能會發(fā)生側(cè)信道攻擊造成用戶數(shù)據(jù)隱私泄露。

為了抵抗側(cè)信道攻擊，Harnik等人[3]提出了減輕惡意用戶利用側(cè)信道的方法，他們對每一個上傳文件設(shè)置一個隨機閾值tF。只有當(dāng)文件上傳次數(shù)超過閾值，才會啟用客戶端去重。因為閾值隨機，所以當(dāng)服務(wù)器要求上傳文件時，攻擊者無法判斷該數(shù)據(jù)是否原來就存在；但是當(dāng)服務(wù)器發(fā)出不需要上傳文件信號時，攻擊者可以得出上傳文件一定存在的結(jié)論。Lee等人[4]對Harnik的方案進(jìn)行了改進(jìn)，引入一個隨機數(shù)r（r∈{0,1,2}），文件去重閾值定義為tF-r，增加了文件去重的隨機性，降低了數(shù)據(jù)隱私泄露的可能性，提高了安全性。Wang等人[5]提出了用博弈論對去重中遇到的安全問題進(jìn)行建模，通過實驗仿真證明該方案能夠有效地抵御側(cè)信道攻擊。Armknecht等人[6]對去重策略和其優(yōu)劣勢進(jìn)行建模分析，證明去重過程中必須權(quán)衡效率和安全。

以上方案歸根到底都屬于設(shè)置文件去重隨機閾值，所以都存在浪費網(wǎng)絡(luò)帶寬的缺點。抵御側(cè)信道攻擊的另一種手段是使用額外的網(wǎng)絡(luò)設(shè)備來混淆上傳網(wǎng)絡(luò)流量。例如Heen等人[7]提出一種基于網(wǎng)關(guān)的去重模型，由網(wǎng)關(guān)對上傳數(shù)據(jù)進(jìn)行混淆操作，使得攻擊者無法依據(jù)數(shù)據(jù)包的上傳情況得出有效的信息。Shin等人[8]在Heen的基礎(chǔ)上引入差分隱私機制，通過上傳虛擬數(shù)據(jù)混淆上傳數(shù)據(jù)，減少了數(shù)據(jù)信息泄露的風(fēng)險。

上述存儲網(wǎng)絡(luò)方案往往造價高昂，不適合大規(guī)模部署。Yu等人[9]提出ZEUS方案，要求每次上傳兩個數(shù)據(jù)塊，設(shè)計特定的刪除響應(yīng)表、數(shù)據(jù)對的異或值上傳等手段，使得攻擊者無法確認(rèn)數(shù)據(jù)塊的存在性，但是造成了一定的網(wǎng)絡(luò)帶寬消耗。Pooranian等人[10]在此基礎(chǔ)上結(jié)合隨機化方法提出RARE方案，提高了安全性，但造成了更多的網(wǎng)絡(luò)帶寬消耗。

基于上述方案存在的問題，本文對ZEUS方案進(jìn)行改進(jìn)，進(jìn)一步提高安全性能、降低網(wǎng)絡(luò)帶寬消耗。

2 預(yù)備知識

2.1 客戶端重復(fù)數(shù)據(jù)刪除

重復(fù)數(shù)據(jù)刪除技術(shù)在云存儲中應(yīng)用廣泛，理想狀況下，云存儲服務(wù)器接收到相同的文件，就可以創(chuàng)建對原文件副本的引用鏈接，而無需上傳冗余數(shù)據(jù)。而根據(jù)重復(fù)數(shù)據(jù)刪除執(zhí)行的位置可分為客戶端去重和服務(wù)器去重，客戶端去重中需要用戶和服務(wù)器進(jìn)行信息交互，來判斷是否需要執(zhí)行去重。如圖1所示。

圖1 客戶端去重響應(yīng)模型

由用戶在客戶端發(fā)出數(shù)據(jù)刪除請求（dc請求），dc請求包含需要上傳數(shù)據(jù)F的哈希值，用來檢測數(shù)據(jù)是否重復(fù)；服務(wù)器接收到請求后進(jìn)行檢測并將結(jié)果反饋給客戶端，確認(rèn)是否需要上傳數(shù)據(jù)。

2.2 側(cè)信道攻擊

去重方案中存在以下幾種側(cè)信道攻擊的可能：

（1）文件確認(rèn)：攻擊者通過執(zhí)行重復(fù)檢查來驗證某些文件，以重復(fù)數(shù)據(jù)刪除是否執(zhí)行判斷文件的存在性；

（2）學(xué)習(xí)剩余信息：攻擊者盡可能生成所有可能的數(shù)據(jù)進(jìn)行重復(fù)性檢查，通過數(shù)據(jù)刪除響應(yīng)確認(rèn)數(shù)據(jù)塊的存在，反復(fù)調(diào)用已確認(rèn)存在的數(shù)據(jù)塊來學(xué)習(xí)數(shù)據(jù)擁有者的敏感信息。

（3）相關(guān)塊攻擊：攻擊者根據(jù)特定文件拆分后數(shù)據(jù)塊之間的依賴性，給予某個文件的一定比例數(shù)據(jù)塊就可以確認(rèn)文件的存在性。

側(cè)信道攻擊主要利用去重方案中對重復(fù)數(shù)據(jù)刪除執(zhí)行的反饋信號確認(rèn)，數(shù)據(jù)塊的存在性，進(jìn)行流量混淆，隱藏數(shù)據(jù)塊的存在性是抵御上述側(cè)信道攻擊的有力手段。

2.3 所有權(quán)證明

所有權(quán)證明（Proof of Ownership，PoW）[11]能夠有效提高客戶端的去重的數(shù)據(jù)安全性能。云去重通過上傳數(shù)據(jù)的哈希值來檢測數(shù)據(jù)的存在與否，而攻擊者可能擁有某些數(shù)據(jù)的哈希值而并未擁有真實數(shù)據(jù)，這可能出現(xiàn)嚴(yán)重的數(shù)據(jù)安全問題。Halevi提出的PoW方法[11]，要求客戶端和服務(wù)器根據(jù)上傳數(shù)據(jù)的內(nèi)容建立默克爾哈希樹（Merkle Hash Tree，MHT），并以挑戰(zhàn)問答的形式由服務(wù)器發(fā)起驗證挑戰(zhàn)。具體方式為：服務(wù)器根據(jù)已經(jīng)存在的數(shù)據(jù)D，計算其短消息值φ(D)，同時客戶端計算φ'并運行算法。當(dāng)φ'=φ(D)時，則證明用戶確實擁有該數(shù)據(jù)。

2.4 數(shù)據(jù)流行度

數(shù)據(jù)內(nèi)容鮮為人知，數(shù)據(jù)的流行度[12]定義為非流行數(shù)據(jù)，存在隱私信息的可能性高；數(shù)據(jù)被大量用戶擁有，這種數(shù)據(jù)定義為流行數(shù)據(jù)，隱私信息存在的可能性低。不同的數(shù)據(jù)類型對隱私保護(hù)的需求是不一樣，可以根據(jù)數(shù)據(jù)流行度的高低對數(shù)據(jù)進(jìn)行不同程度的保護(hù)。數(shù)據(jù)流行度高即含隱私信息少，流行度低則意味著數(shù)據(jù)隱私信息多需要更高強度的保護(hù)。數(shù)據(jù)隱私度的劃分依據(jù)為該數(shù)據(jù)上傳用戶數(shù)量，將數(shù)據(jù)的合法上傳者數(shù)量設(shè)定為數(shù)據(jù)流行度的衡量依據(jù)，設(shè)立一個數(shù)據(jù)流行度閾值（合法上傳者數(shù)量），當(dāng)某個數(shù)據(jù)塊合法上傳的用戶數(shù)超過閾值，數(shù)據(jù)類型標(biāo)識轉(zhuǎn)變?yōu)榱餍袛?shù)據(jù)。

3 方案概述

3.1 系統(tǒng)模型

本方案模型由云服務(wù)提供商（CSP）和用戶（User）兩個實體組成。方案是基于數(shù)據(jù)塊級去重的，當(dāng)用戶上傳文件時，先由客戶端將文件進(jìn)行分割，數(shù)據(jù)塊大小固定，且需要保證文件分割后得到的數(shù)據(jù)塊數(shù)目為偶數(shù)，當(dāng)文件自然分割后不滿足大小固定或數(shù)據(jù)為偶數(shù)時，客戶端需要選擇隨機數(shù)進(jìn)行填充。去重交互過程中，每次同時上傳兩個數(shù)據(jù)塊的哈希值，向服務(wù)器發(fā)起刪除問詢（dc請求），服務(wù)器接收到dc請求處理后向客戶端發(fā)出刪除響應(yīng)（dc響應(yīng)），并據(jù)此決定是否上傳數(shù)據(jù)。單輪dc響應(yīng)及處理概述如圖2所示。

圖2 系統(tǒng)響應(yīng)模型

3.2 方案概述

（1）客戶端將文件分割為若干數(shù)據(jù)塊，保證每個數(shù)據(jù)塊大小一致，保證最后分割出的數(shù)據(jù)塊數(shù)為偶數(shù)。

（2）上傳一對數(shù)據(jù)塊的哈希值進(jìn)行重復(fù)度查詢，如果數(shù)據(jù)塊存在，則發(fā)起PoW驗證，驗證通過則更改數(shù)據(jù)塊的流行度計數(shù)值。

（3）服務(wù)器根據(jù)上傳兩個數(shù)據(jù)塊存儲狀態(tài)，參照設(shè)定的dc響應(yīng)表（表1）向客戶端做出dc響應(yīng)。

（4）客戶端根據(jù)dc響應(yīng)，確認(rèn)數(shù)據(jù)塊是否需要上傳至服務(wù)器。

3.3 dc響應(yīng)設(shè)計

為了隱藏數(shù)據(jù)塊的存儲狀態(tài)，文獻(xiàn)[9]提出了同時上傳兩個數(shù)據(jù)塊，設(shè)計特定的dc響應(yīng)的方案。本文在其基礎(chǔ)上進(jìn)行效率改進(jìn)，設(shè)計出新的dc響應(yīng)規(guī)則，如表1所示。

表1 dc響應(yīng)表

根據(jù)響應(yīng)設(shè)計存在三種處理方式：

（1）當(dāng)兩個數(shù)據(jù)塊（記作c1、c2）都不存在云服務(wù)器中時，服務(wù)器將發(fā)送dc響應(yīng)值2給客戶端，此時客戶端需要將c1和c2上傳服務(wù)器，服務(wù)器根據(jù)上傳的c1、c2計算數(shù)據(jù)標(biāo)簽（h(c1)、h(c2)）確保數(shù)據(jù)真實標(biāo)簽與重復(fù)性檢查時的標(biāo)簽一致，標(biāo)簽相同服務(wù)器存儲這兩個數(shù)據(jù)塊，用戶對數(shù)據(jù)簽名；兩次數(shù)據(jù)標(biāo)簽不同，終斷本次文件上傳。

（2）當(dāng)c1和c2中有且僅有一個數(shù)據(jù)塊存儲時，服務(wù)器將發(fā)送dc響應(yīng)值1給客戶端，此時客戶端需要將c1和c2的異或值上傳服務(wù)器，服務(wù)器通過計算數(shù)據(jù)塊的異或值推斷出另一個數(shù)據(jù)塊。例如，服務(wù)器中c1存在，服務(wù)器通過計算（c1⊕c2）⊕c1就可以得到c2。對新數(shù)據(jù)塊進(jìn)行標(biāo)簽驗證（同A中所述），驗證通過服務(wù)器存儲該數(shù)據(jù)塊，并要求用戶給該數(shù)據(jù)塊簽名。驗證不通過，中斷本次文件上傳。

（3）當(dāng)c1和c2都已存在時，需要查驗兩個數(shù)據(jù)塊的流行度，處理分兩種情況：①如果兩個數(shù)據(jù)塊都屬于流行數(shù)據(jù)，服務(wù)器將發(fā)送dc響應(yīng)值0給客戶端，告訴客戶端無需上傳數(shù)據(jù)；②存在非流行數(shù)據(jù)塊時，服務(wù)器將發(fā)送dc響應(yīng)值1給客戶端，再要求用戶對非流行數(shù)據(jù)塊進(jìn)行簽名。

3.4 PoW驗證

在上述dc響應(yīng)過程中，是依據(jù)數(shù)據(jù)標(biāo)簽（數(shù)據(jù)的哈希值）來判斷數(shù)據(jù)塊是否存在存儲系統(tǒng)中的，攻擊者可能擁有某些數(shù)據(jù)塊的哈希值而并未擁有該數(shù)據(jù)，這里如果依舊簡單的執(zhí)行去重操作，這會導(dǎo)致?lián)碛性摂?shù)據(jù)用戶隱私泄露。所以當(dāng)憑借數(shù)據(jù)標(biāo)簽得出數(shù)據(jù)塊存在時，服務(wù)器需要發(fā)起PoW驗證挑戰(zhàn)，客戶端響應(yīng)PoW挑戰(zhàn)，通過驗證證明用戶真實擁有該數(shù)據(jù)；驗證失敗則中斷本次文件上傳操作。

3.5 數(shù)據(jù)流行度標(biāo)識設(shè)計

不同的數(shù)據(jù)類型對隱私保護(hù)的要求是不一樣的，如：收藏的電影視頻文件含有個人隱私的可能性低，基本上不會暴露用戶的隱私信息；而個人薪資單、病例表等文件往往含有的大量的用戶隱私，需要更嚴(yán)苛的隱私保護(hù)。為了減少去重復(fù)數(shù)據(jù)刪除過程中的網(wǎng)絡(luò)消耗，本文依照數(shù)據(jù)流行度的劃分對數(shù)據(jù)進(jìn)行差異性處理。在存儲系統(tǒng)中設(shè)置了一個流行度閾值t（非流行數(shù)據(jù)用戶上限數(shù)），系統(tǒng)維護(hù)一個文件列表（表2），數(shù)據(jù)標(biāo)簽用來做初步的數(shù)據(jù)存在性檢查，密文數(shù)據(jù)用來發(fā)起PoW驗證挑戰(zhàn)，當(dāng)PoW驗證通過則要求數(shù)據(jù)上傳用戶給數(shù)據(jù)簽名，當(dāng)給數(shù)據(jù)簽名的用戶數(shù)超過流行度閾值t時，流行度狀態(tài)轉(zhuǎn)為1，標(biāo)識著該數(shù)據(jù)為流行數(shù)據(jù)，其含有用戶隱私的可能性低。

表2 文件列表

3.6 算法描述

本方案的偽代碼描述如下，當(dāng)用戶需要將文件f上傳到云存儲系統(tǒng)中時。文件首先被分割（第一行代碼）。由于方案設(shè)定為一對數(shù)據(jù)塊同時上傳，所以需要保證文件被分割為偶數(shù)個數(shù)據(jù)塊（第6-9行）。一個文件被分割為n個數(shù)據(jù)塊，所以一次文件上傳需要執(zhí)行n/2輪數(shù)據(jù)問詢（第10行）。當(dāng)服務(wù)器接到重復(fù)查詢信號時，會先確認(rèn)數(shù)據(jù)塊的存儲狀態(tài)，根據(jù)數(shù)據(jù)塊的存儲狀況區(qū)分不能的處理方式，并進(jìn)行所有權(quán)驗證、數(shù)據(jù)流行度查詢和數(shù)字簽名等手段確保數(shù)據(jù)的安全性（第12-23行）。

算法客戶端去重

輸入：上傳文件f，數(shù)據(jù)塊大小ф

01.user partitionsfinto chunkc1,c2…cn//分割文件

02.user setsn=sizeo（ff）/ф

03.if size o（fcn）≠ф

04.dummy bytes are padded tocn//補齊數(shù)據(jù)塊

05.end if;

06.ifnis odd//數(shù)據(jù)塊數(shù)量為奇數(shù)

07.padded random chunkcn+1//填充一個數(shù)據(jù)塊

08.sets n=n+1//n+1保證數(shù)據(jù)塊數(shù)量為偶數(shù)

09.end if;

10.for i∈{1,3…n-1}

11.performs duplicate check on//上傳數(shù)據(jù)塊對進(jìn)行重復(fù)檢查

12.ifci=0 andci+1=0//兩數(shù)據(jù)塊存儲狀況為零

13.uploadsciandci+1//上傳數(shù)據(jù)

14.else ifci=1 andci+1=1//數(shù)據(jù)塊都存在

15.if POW test pass//數(shù)據(jù)所有權(quán)驗證

16.ifci=1 andci+1is popularity data//兩個數(shù)據(jù)塊均為流行數(shù)據(jù)

17.replies dc response 0//發(fā)送dc響應(yīng)0，告訴客戶端無需上傳數(shù)據(jù)

18.else

19.ci.sign(U),ci+1.sign(U)//數(shù)據(jù)擁有者對非流行數(shù)據(jù)

簽名

20.replies dc response 1//發(fā)送dc響應(yīng)1，要求上傳數(shù)據(jù)

21.end if;

22.else

23.exit；//所有權(quán)驗證不通過中斷去重

24.else//僅有一個數(shù)據(jù)塊存儲在云中

25.replies dc response 1//發(fā)送dc響應(yīng)1，要求上傳數(shù)據(jù)

26.ifci⊕(ci⊕ci+1)//確認(rèn)存在的數(shù)據(jù)塊

27.storageci//存儲數(shù)據(jù)塊

28.ci+1sign(U) //數(shù)據(jù)擁有者簽名

29.else

30.storageci+1//存儲數(shù)據(jù)塊

31.ci.sign(U)//數(shù)據(jù)擁有者簽名

32.end if；

33.end if；

4 安全分析

4.1 數(shù)據(jù)隱私

客戶端重復(fù)數(shù)據(jù)刪除方案是基于服務(wù)器和客戶端進(jìn)行信息交互，通過信息反饋來確認(rèn)數(shù)據(jù)是否需要上傳的。攻擊者根據(jù)此原理發(fā)動側(cè)信道攻擊，獲取用戶數(shù)據(jù)隱私。為了隱藏數(shù)據(jù)塊的存在性，本文通過改進(jìn)ZUES方案設(shè)計了一個新的dc響應(yīng)表（表1）。響應(yīng)狀態(tài)為0、1、2這3種，當(dāng)dc響應(yīng)為2時，c1、c2兩個數(shù)據(jù)塊均不存在于存儲系統(tǒng)中，攻擊者無法獲取用戶的隱私；當(dāng)dc響應(yīng)為0時，意味著c1、c2兩個數(shù)據(jù)塊均存在于存儲系統(tǒng)中，且c1、c2都為流行度高的數(shù)據(jù)塊，其含有隱私數(shù)據(jù)的可能性低，攻擊者通過流行數(shù)據(jù)獲取數(shù)據(jù)擁有用戶的隱私可能性低；當(dāng)dc響應(yīng)為1時，意味著c1、c2至少有一個數(shù)據(jù)塊存在，此時服務(wù)器可以根據(jù)數(shù)據(jù)塊c1、c2的數(shù)據(jù)標(biāo)簽確認(rèn)數(shù)據(jù)塊的存在性，但是服務(wù)器并未將這些信息反饋給客戶端，所以攻擊者是無法判斷具體的數(shù)據(jù)塊的存在性；綜上dc響應(yīng)的設(shè)計能夠隱藏數(shù)據(jù)的存在性，保護(hù)數(shù)據(jù)隱私不被泄露。

在本方案中，當(dāng)系統(tǒng)確認(rèn)某個數(shù)據(jù)塊在云存儲系統(tǒng)中存在時，會先進(jìn)行PoW驗證確保數(shù)據(jù)上傳者真實擁有該數(shù)據(jù)，防止攻擊者僅憑借數(shù)據(jù)標(biāo)簽就可以獲取到原數(shù)據(jù)的鏈接，進(jìn)而侵犯數(shù)據(jù)真實擁有者的隱私。重復(fù)上傳數(shù)據(jù)會要求上傳者對數(shù)據(jù)進(jìn)行數(shù)字簽名，能夠防止惡意用戶重復(fù)上傳某些數(shù)據(jù)導(dǎo)致數(shù)據(jù)流行度遭受惡意修改，更好保護(hù)用戶數(shù)據(jù)的隱私不被泄露。

4.2 抗污染攻擊

在云存儲系統(tǒng)去重方案中，會有一種惡意用戶上傳與文件標(biāo)簽不一致的密文數(shù)據(jù)，造成數(shù)據(jù)被污染。例如，惡意用戶是文件F1的上傳者，F(xiàn)1對應(yīng)的數(shù)據(jù)標(biāo)簽為T1，在服務(wù)器要求上傳F1的密文C1時，惡意用戶上傳的是F2的密文C2。當(dāng)后續(xù)上傳者需要下載此文件時，下載解密之后得到的文件便不是F1而是惡意用戶上傳到的F2，造成數(shù)據(jù)污染。

在本文方案中，會要求在初傳者上傳數(shù)據(jù)時將數(shù)據(jù)標(biāo)簽與服務(wù)器根據(jù)真實上傳數(shù)據(jù)計算的數(shù)據(jù)標(biāo)簽作對比，如果對比通過則存儲數(shù)據(jù)；不通過就認(rèn)定本次上傳為惡意上傳終止文件上傳。這樣可以有效避免數(shù)據(jù)被污染，保障用戶上傳數(shù)據(jù)的完整性。

5 性能分析與實驗評估

5.1 通信開銷

本文方案在文獻(xiàn)[9]提出的ZEUS方案上做出改進(jìn)，以犧牲網(wǎng)絡(luò)帶寬的方式提高數(shù)據(jù)隱私保護(hù)，所以以通信開銷來評估方案性能。與文獻(xiàn)[9]的ZEUS和文獻(xiàn)[10]的RARE方案作對比。假定任意數(shù)據(jù)塊存儲在服務(wù)器的概率為p，數(shù)據(jù)塊大小為ф。

上傳兩個數(shù)據(jù)塊的通信開銷計算為：

文獻(xiàn)[9]中ZEUS方案在上傳數(shù)據(jù)時，除原始數(shù)據(jù)塊之外還需要上傳數(shù)據(jù)對的異或值c1⊕c2（大小為ф），通信開銷計算為：

同樣的，文獻(xiàn)[10]的RARE方案通信開銷計算為：

在本文方案中，當(dāng)上傳的兩個數(shù)據(jù)塊均不在服務(wù)器中時通信開銷應(yīng)為公式（1）所示；當(dāng)服務(wù)器中存在數(shù)據(jù)塊時，客戶端需要上傳c1、c2的異或值c1⊕c2，此時本文方案的通信消耗應(yīng)為公式（2）所示；本文方案中設(shè)計了數(shù)據(jù)流行度的查驗，當(dāng)數(shù)據(jù)流行度高時，直接告知客戶端無需上傳數(shù)據(jù)，此時通信開銷為零。

綜上分析，很容易得出3個方案的通信開銷結(jié)果，對比如下：

5.2 實驗仿真

本方案是在AMD銳龍5的CPU、主頻2.1 GHz、內(nèi)存16 GB、系統(tǒng)為Windows 10的PC上實現(xiàn)的。使用編程語言為C++，借助OpenSSL庫實現(xiàn)哈希函數(shù)SHA-256，實驗過程中忽略數(shù)據(jù)標(biāo)簽（數(shù)據(jù)哈希值）上傳造成的通信開銷。在實驗中以上傳同一個文件的用戶數(shù)作為上傳數(shù)據(jù)的流行度衡量，實驗中選擇一個大小為1 MB文件進(jìn)行上傳，切分?jǐn)?shù)據(jù)大小設(shè)定為64 KB，將數(shù)據(jù)流行度閾值設(shè)置為{20,30}，通過創(chuàng)建不同用戶賬號進(jìn)行數(shù)據(jù)上傳，統(tǒng)計多次上傳的通信開銷。將本文方案與Original方案以及文獻(xiàn)[9]中的ZEUS方案的實驗結(jié)果作對比，結(jié)果如圖3所示。

圖3 各方案在不同流行度下的通信開銷

由實驗結(jié)果可以看出：Original方案只有在第一次上傳數(shù)據(jù)才有通信開銷，因為在實驗中我們是通過許多不同的用戶賬戶對同一份文件進(jìn)行上傳以達(dá)到改變數(shù)據(jù)流行的目的，所以除第一次之外，其余上傳時Original方案認(rèn)定上傳數(shù)據(jù)為重復(fù)數(shù)據(jù)就不再將數(shù)據(jù)進(jìn)行上傳，所以在不考慮數(shù)據(jù)隱私的前提下Original的通信開銷是最低的。對比本文方案與ZEUS方案，可以看出當(dāng)數(shù)據(jù)類型為非流行數(shù)據(jù)時，其通信開銷和ZEUS方案一致，當(dāng)數(shù)據(jù)存在于云存儲中但是其為非流行數(shù)據(jù)可能包含用戶的隱私，此時需要上傳數(shù)據(jù)用以混淆數(shù)據(jù)的存在性，保障用戶數(shù)據(jù)安全；當(dāng)數(shù)據(jù)類型轉(zhuǎn)變?yōu)榱餍袛?shù)據(jù)時，本文方案的通信開銷不再增加，因為流行數(shù)據(jù)所以含有用戶隱私的可能性低，系統(tǒng)直接執(zhí)行客戶端去重，不再要求上傳數(shù)據(jù)，用以隱藏數(shù)據(jù)的存在性。實驗結(jié)果證明本文方案在保障用戶數(shù)據(jù)隱私不泄露的同時降低了通信開銷。

6 結(jié)語

針對當(dāng)前面向數(shù)據(jù)塊級別的客戶端重復(fù)數(shù)據(jù)刪除方案中存在的缺陷，在ZEUS方案的基礎(chǔ)上，改進(jìn)其dc響應(yīng)的設(shè)計，引入數(shù)據(jù)流行度的概念，根據(jù)流行度對數(shù)據(jù)進(jìn)行不同的處理，在保證數(shù)據(jù)隱私不被泄露的前提下，降低去重過程中網(wǎng)絡(luò)帶寬的消耗；對數(shù)據(jù)進(jìn)行所有權(quán)證明驗證確保數(shù)據(jù)上傳者真實擁有該數(shù)據(jù)，進(jìn)一步提高了數(shù)據(jù)安全性，保障用戶隱私。仿真實驗證明本文方案是高效可行的，同時必須承認(rèn)在去重過程中，為了保證數(shù)據(jù)安全幾乎每一輪的重復(fù)度查詢之后都會執(zhí)行一次PoW驗證，所以整個文件上傳過程會造成更多的時間消耗。如何在保障數(shù)據(jù)安全的前提下減少去重過程中的時間成本，是下一步研究的重點。