一種側重數據隱私保護的客戶端去重方法

王崛贛，柳毅

（廣東工業大學計算機學院，廣州510006）

0 引言

云存儲服務以其存儲方便、價格低廉的特點，吸引了大量的用戶，而眾多云存儲用戶上傳的海量數據中存在許多重復數據。為了節約存儲成本、減少網絡帶寬消耗，云存儲服務提供商（CSP）會采用數據去重技術。基本原理非常簡單，每當上載文件時，存儲服務器都會檢查該文件是否是先前存儲的內容的副本，如果存在，新副本將定向到相同副本的位置，不存在，則上傳內容。而實際中，存在大量的內容相似度高而細節不盡相同的文件，所以文件級重復數據刪除方案往往效率不高。實際中常應用數據塊級去重，每個文件切分為若干數據塊，將冗余的數據塊從系統中刪除。

在數據上傳過程中，重復數據刪除技術的應用還存在減少網絡帶寬消耗的可能。客戶端去重方案中，用戶只需要上傳數據的哈希值，云服務器對數據的哈希值進行查驗，如果存在重復性，則無需上傳數據，減少了數據上傳的網絡帶寬消耗。

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

本文提出了一種隱私保護的客戶端去重方案，在不借助可信第三方服務器、存儲網關等網絡設備的前提下，通過略微增加通信開銷，實現了更強的數據隱私保護。本文方案貢獻總結如下：

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

（2）不需要額外的第三方網絡設備，降低了系統成本，也降低了第三方設備被攻擊者劫持造成數據泄露的風險。

（3）對驗證為可能是重復數據的數據塊進行所有權證明驗證，有效防止攻擊者僅憑借數據標簽就可以取得用戶數據的情況發生。

（4）對數據進行流行度劃分，流行度高的數據含有的隱私信息較少，可以直接向客戶端反饋這些數據的存儲狀況，無需上傳流行數據達到減少網絡帶寬消耗的目的。

1 相關工作

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

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

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

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

基于上述方案存在的問題，本文對ZEUS方案進行改進，進一步提高安全性能、降低網絡帶寬消耗。

2 預備知識

2.1 客戶端重復數據刪除

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

圖1 客戶端去重響應模型

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

2.2 側信道攻擊

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

（1）文件確認：攻擊者通過執行重復檢查來驗證某些文件，以重復數據刪除是否執行判斷文件的存在性；

（2）學習剩余信息：攻擊者盡可能生成所有可能的數據進行重復性檢查，通過數據刪除響應確認數據塊的存在，反復調用已確認存在的數據塊來學習數據擁有者的敏感信息。

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

側信道攻擊主要利用去重方案中對重復數據刪除執行的反饋信號確認，數據塊的存在性，進行流量混淆，隱藏數據塊的存在性是抵御上述側信道攻擊的有力手段。

2.3 所有權證明

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

2.4 數據流行度

數據內容鮮為人知，數據的流行度[12]定義為非流行數據，存在隱私信息的可能性高；數據被大量用戶擁有，這種數據定義為流行數據，隱私信息存在的可能性低。不同的數據類型對隱私保護的需求是不一樣，可以根據數據流行度的高低對數據進行不同程度的保護。數據流行度高即含隱私信息少，流行度低則意味著數據隱私信息多需要更高強度的保護。數據隱私度的劃分依據為該數據上傳用戶數量，將數據的合法上傳者數量設定為數據流行度的衡量依據，設立一個數據流行度閾值（合法上傳者數量），當某個數據塊合法上傳的用戶數超過閾值，數據類型標識轉變為流行數據。

3 方案概述

3.1 系統模型

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

圖2 系統響應模型

3.2 方案概述

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

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

（3）服務器根據上傳兩個數據塊存儲狀態，參照設定的dc響應表（表1）向客戶端做出dc響應。

（4）客戶端根據dc響應，確認數據塊是否需要上傳至服務器。

3.3 dc響應設計

為了隱藏數據塊的存儲狀態，文獻[9]提出了同時上傳兩個數據塊，設計特定的dc響應的方案。本文在其基礎上進行效率改進，設計出新的dc響應規則，如表1所示。

表1 dc響應表

根據響應設計存在三種處理方式：

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

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

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

3.4 PoW驗證

在上述dc響應過程中，是依據數據標簽（數據的哈希值）來判斷數據塊是否存在存儲系統中的，攻擊者可能擁有某些數據塊的哈希值而并未擁有該數據，這里如果依舊簡單的執行去重操作，這會導致擁有該數據用戶隱私泄露。所以當憑借數據標簽得出數據塊存在時，服務器需要發起PoW驗證挑戰，客戶端響應PoW挑戰，通過驗證證明用戶真實擁有該數據；驗證失敗則中斷本次文件上傳操作。

3.5 數據流行度標識設計

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

表2 文件列表

3.6 算法描述

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

算法客戶端去重

輸入：上傳文件f，數據塊大小ф

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

02.user setsn=sizeo（ff）/ф

03.if size o（fcn）≠ф

04.dummy bytes are padded tocn//補齊數據塊

05.end if;

06.ifnis odd//數據塊數量為奇數

07.padded random chunkcn+1//填充一個數據塊

08.sets n=n+1//n+1保證數據塊數量為偶數

09.end if;

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

11.performs duplicate check on//上傳數據塊對進行重復檢查

12.ifci=0 andci+1=0//兩數據塊存儲狀況為零

13.uploadsciandci+1//上傳數據

14.else ifci=1 andci+1=1//數據塊都存在

15.if POW test pass//數據所有權驗證

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

17.replies dc response 0//發送dc響應0，告訴客戶端無需上傳數據

18.else

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

簽名

20.replies dc response 1//發送dc響應1，要求上傳數據

21.end if;

22.else

23.exit；//所有權驗證不通過中斷去重

24.else//僅有一個數據塊存儲在云中

25.replies dc response 1//發送dc響應1，要求上傳數據

26.ifci⊕(ci⊕ci+1)//確認存在的數據塊

27.storageci//存儲數據塊

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

29.else

30.storageci+1//存儲數據塊

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

32.end if；

33.end if；

4 安全分析

4.1 數據隱私

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

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

4.2 抗污染攻擊

在云存儲系統去重方案中，會有一種惡意用戶上傳與文件標簽不一致的密文數據，造成數據被污染。例如，惡意用戶是文件F1的上傳者，F1對應的數據標簽為T1，在服務器要求上傳F1的密文C1時，惡意用戶上傳的是F2的密文C2。當后續上傳者需要下載此文件時，下載解密之后得到的文件便不是F1而是惡意用戶上傳到的F2，造成數據污染。

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

5 性能分析與實驗評估

5.1 通信開銷

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

上傳兩個數據塊的通信開銷計算為：

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

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

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

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

5.2 實驗仿真

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

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

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

6 結語

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