動態數據安全審計云存儲系統研究

劉璐玲

摘 要： 提出支持數據去重的數據持有性證明方案，該方案改進了原有數據去重中利用MD5值冒領原數據使用權的安全問題，并且引入可信第三方對不同文件的驗證密鑰進行管理，避免了文件標簽的重復計算，同時利用額外的本地存儲減少了時間消耗和通信代價。針對文件級云存儲，設計了基于索引的動態數據持有性證明方案，并且針對之前方案中存在文件I/O對驗證時間的影響，采用B+樹多級索引對文件做查詢優化。實驗結果表明，該方案與傳統方案相比，針對數據去重場景大幅度地減少了存儲開銷，降低了文件級的更新操作時間復雜度。

關鍵詞： 數據持有性證明； 數據去重； 云存儲； 索引

中圖分類號： TN915.08?34； TP311.17 文獻標識碼： A 文章編號： 1004?373X（2017）09?0096?03

Abstract： A provable data possession scheme supporting data deduplication is proposed. The scheme has improved the security issue that the MD5 value in the original data deduplication is used to falsely claim the use right of the original data. A trusted third party is introduced into the scheme to manage the verification secret key of different documents to avoid the repeated calculation of the file label. The additional local storage is adopted to reduce the time consumption and communication cost. For the file?level cloud storage， a dynamic provable data possession scheme based on index was designed. According to the influence of the file I/O existing in the previous schemes on verification time， the B+ tree multi?level index is used to perform the query optimization for the file. The experimental results show that， in comparison with the traditional schemes， the proposed scheme has reduced the storage cost for data deduplication greatly， and lowered the time complexity of the file?level update operation.

Keywords： provable data possession； data deduplication； cloud storage； index

0 引 言

隨著信息技術的發展，越來越多的企業或者用戶選擇在云存儲服務提供商的服務器中存儲數據，但是被存儲數據的安全性和完整性在一定程度上不能得到很好的保障。雖然云存儲服務提供商會有相應的技術來備份和恢復用戶鎖存的數據，但是一部分用戶的數據依然會因為一些惡意篡改或者物理損壞等因素而造成變更甚至丟失。雖然數據能夠帶來的價值均會被大型企業關注，但政府卻沒有出臺管轄數據安全問題的相關法律法規，所以，用戶和服務商遇到最大的問題之一就是用戶的數據出現問題[1]。提供云存儲服務的供應商在提供云存儲服務的過程中，需要為用戶提供隨時查驗數據完整性服務，一旦檢測到數據方面的錯誤時，能夠在第一時間對數據進行恢復和保存，只有實現了這一功能，用戶才能將云存儲服務使用的更加安心[2]。

1 可支持數據去重數據持有性證明方案

1.1 初始化模塊

如果用戶是首次登錄數據客戶端，那么首先需要注冊賬號，賬號里包含了惟一的用戶名、ID以及口令，與此同時，這個賬號中所有的信息也將同時被云服務商以及可信第三方擁有。

此時，驗證文件所用的密鑰將在本地客戶端通過計算生成，具體步驟為：尋找大素數當且同時滿足這一條件，生成元需要在正整數循環子群的范疇里尋找，再尋找出大于安全參數的大素數以及大素數使得大素數和大素數滿足之后一個位的二進制數將由系統隨機生成。其中，使得私鑰sk用來體現，公鑰pk用來體現。上述步驟與傳統PDP方案相同。

在生成了公鑰與私鑰之后，需要輸入pw這個新口令，用AES對私鑰加密之后再進行存儲，之后將公鑰公開存儲在數據庫中[3]。Android平臺上的sqlite是實現上述步驟時所采用的數據庫。

1.2 數據去重模塊

針對需求，本文設計了以下方案：

（1） 用戶需要上傳文件客戶端首先計算該文件的MD5值[4]計算完成后將結果向云服務端發送，云服務端對接收到的的驗證過程如下：

if （searchHash（HashTable，m） == true）：

sendClient（randomKey， FID）；

else requestFileTag（）；

在服務器查找哈希表的過程中，如果能驗證的存在，系統在返回客戶端之后會生成一個隨機的randomKey密鑰，密鑰生成完成系統將繼續運行步驟（2）；但是如果不能驗證到的存在，則系統會請求客戶端上傳文件標簽和相應文件。

（2） 當服務端在運行過程中發現了的存在，則系統返回客戶端之后生成一個文件序號FID和隨機的密鑰，客戶端通過對該文件值以及FID的計算，將結果向云服務端發送，云服務端對接收到的二次驗證過程如下：

F=getFile（FID）；

temp = MAC（F， randomKey）；

if （m′== temp）：

addFileUser（FID，user）；

sendThirdParty（FID）；

else requestFileTag（）；

在云服務端進行二次驗證時，若MAC值和第一次計算的結果一致，服務端把FID發送給可信第三方，可信第三方在接收到FID之后把驗證密鑰發送給客戶端。如果MAC值在兩次計算中結果不同，則系統發送請求給客戶端，命令客戶端將文件標簽以及相應文件繼續上傳。

1.3 數據上傳模塊

文件預處理模塊原理如圖1所示。

在完成數據去重之后，需要從兩方面考慮問題：第一種情況，若驗證到文件在云服務端已經存在，則可信第三方會向用戶提供影響文件的驗證密鑰；第二種情況，若在云客戶端驗證不到該文件的存在，則云客戶端會將即將上傳的文件的FID發送回客戶端，客戶端再根據FID計算標簽TF。

1.4 完整性驗證模塊

用戶需要通過對文件發送挑戰、計算證明、驗證證明三個步驟來驗證單文件的數據。

（1） 發送挑戰

在進行驗證之前，提前與服務端尋找出偽隨機文件，問卷之后對置換函數進行定義：之后再尋找出偽隨機函數進行定義[5]：首先，兩個位隨機二進制數被系統隨機生成；其次，隨機數被系統生成；最后，將數據塊總數以及的計算結果發送給服務端。

（2） 計算證明

在將的二進制串轉換為用所表示的另一個二進制串的過程中，可以根據情況運用偽隨機置換函數結果用表示。用表示通過偽隨機函數生成的系數。

然后生成證明和與都擁有1 024位數，在實際操作過程中，偽隨機置換函數用AES表示，偽隨機函數用HMAC進行表示，函數用SHA1進行表示，同時，需要將云服務器端和客戶端函數的一致性進行約定。

（3） 驗證證明

驗證證明的過程同計算證明基本相同，在的每一個數字中，二進制串將運用偽隨機置換函數來計算，系數運用偽隨機函數來計算。與此同時，計算并且使如果則說明該單文件完整性驗證成功；若不相等，則失敗。

2 基于索引的動態數據持有性證明系統模型

2.1 初始化模塊

通過RSA的密鑰生成來設計初始化模塊，之后再在本地數據庫中通過用戶的口令加密存儲。在設計本模塊的過程中，要盡量滿足簡便操作的原則，還要盡可能使方案的安全性有所保障。

2.2 數據上傳模塊

在客戶端計算文件標簽的過程中，數據上傳模塊可參考完整性驗證方案，在將文件以及相關數據上傳服務端之后，服務端需要根據文件的標簽構建B+的樹索引。在驗證源碼PDP之前，發現當文件逐漸增大時，服務端生成證明所消耗的時間一方面運用在了指數運算上，而更大一部分則運用在了文件塊I/O上[6]。

2.3 完整性挑戰模塊

驗證模式分為全盤驗證和單文件驗證兩種，驗證模式不同，則系統發送的挑戰也各不相同[7]。如果是全盤性的驗證模式，那么需要挑選隨機文件，在文件中選取數據塊，整個過程一共需要工作460次。但是在單文件驗證模式中，則將密鑰挑戰中隨機的文件塊進行發送。同臺驗證標簽仍然是本方案的驗證依據。

3 系統設計與實現

3.1 系統架構

（1） 系統客戶端

系統的客戶端中包含了用戶與文件管理、可視化驗證與完整性驗證等，其結構設計見圖2。客戶端中用戶管理業務通過用戶管理模塊進行實現，主要包含用戶登錄邏輯以及用戶注冊兩項業務。文件管理模塊實現了與云存儲中文件存儲相關的所有業務邏輯。客戶端界面的可視化通過可視化模塊進行實現，同時，該模塊支持用戶對文件的讀寫和管理操作在客戶端進行，能夠給予用戶更好的實用體現。利用客戶端驗證文件完整性，能夠提升業務邏輯條理性，進而有效完成驗證模塊。

（2） 系統服務端

服務端的系統主要包含用戶管理、存儲管理、索引以及完整性驗證模塊，安全云存儲服務端平臺結構圖如圖3所示。

3.2 測試與結果分析

3.2.1 測試方案

系統詳細功能測試包括文件上傳測試、文件更新測試、文件刪除測試三方面的內容。在文件上傳到服務期之后，用戶可以發出文件指令，云服務器能夠將文件上傳至云存儲器，url?tag地址表項在標簽哈希表中進行補充新增[8]，這一操作實現了在對文件完整性驗證的過程中查找文件中tag鏈表，提升查找的準確性，提升文件的驗證有效性。對于云存儲中需要刪除的部分文件，需要重視文件的刪除測試，利用文件刪除測試實現具體的功能測試。

系統運行效率測試包括文件上傳效率測試、更新效率、刪除效率等測試。

3.2.2 測試結果分析

（1） 數據更新時間

假設文件塊大小均為4 Kb，且通信的代價相同，本文方案和DPDP中的搜索添加刪除三項操作時間的結果對比如表1所示。

（2） 證明效率測試

當存儲文件所占內存為10 GB時，DPDP，Flex?DPDP的驗證速度均比UT?DPDP慢了2.5倍。在驗證過程中發現Flex?DPDP與DPDP驗證速度和文件線性大小之間具有非常密切的關聯，UT?DPDP的驗證速度是固定的，隨著文件占用內存率不斷增加而愈發明顯。

（3） 文件上傳、更改、刪除操作效率測試

本文方案在文件塊數量很大這一情況下，在文件上傳、更新、刪除等方面的優越性表現顯著，因此，針對理論時間復雜度來說，這三項操作都是但是變量是DPDP理論時間復雜度。

4 結 語

本文提出可支持數據去重的數據持有性證明方案和基于索引支持動態數據持有性證明的文件級云存儲模型。可支持的數據去重數據持有性方案在一定程度上更新了數據自身去重環境下能夠進行壓縮，但是無法壓縮完整性驗證所需要的文件標簽這一問題；基于索引支持動態數據持有性證明的文件級云存儲模型設計并實現了一種新型的數據持有性證明技術，主要解決了動態驗證中數據更新操作時間復雜度高且更新量龐大的問題。和同類其他方案相比，本文所提出的方案針對理論時間復雜度這一指標來說，三項操作都是滿足了用戶實際需求。

參考文獻

[1] 劉雪瓊，武剛，鄧厚平.Web信息整合中的數據去重方法[J].計算機應用，2013，33（9）：2493?2496.

[2] 張曉，秦志光，羅亞東，等.一種低代價的云計算存儲權限管理機制[J].西南師范大學學報（自然科學版），2015（7）：33?40.

[3] WU J， PING L， GE X， et al. Cloud storage as the infrastructure of cloud computing [C]// Proceedings of 2010 IEEE International Conference on Intelligent Computing and Cognitive Informatics. [S.l.]： IEEE， 2010： 380?383.

[4] HE Q， LI Z， ZHANG X. Data deduplication techniques [C]// Proceedings of 2010 IEEE International Conference on Future Information Technology and Management Engineering. [S.l.]： IEEE， 2010： 430?433.

[5] 馮泓淵，趙逢禹.云存儲服務中支持動態數據完整性檢測研究[J].小型微型計算機系統，2014，35（2）：239?243.

[6] CHEN B， CURTMOLA R. Robust dynamic provable data possession [C]// Proceedings of 2012 the 32nd IEEE International Conference on Distributed Computing Systems Workshops. Macau， China： IEEE， 2012： 515?525.

[7] 周相兵，馬洪江，苗放.云計算環境下的一種基于Hbase的ORM設計實現[J].西南師范大學學報（自然科學版），2013，38（8）：130?135.

[8] ZHU Y， AHN G J， HU H， et al. Dynamic audit services for outsourced storages in clouds [J]. IEEE transactions on services computing， 2013， 6（2）： 227?238.