劉 峰，趙俊峰

內(nèi)蒙古大學計算機學院，內(nèi)蒙古呼和浩特010021

在海量數(shù)據(jù)存儲的需求下，云存儲服務逐漸興起，云存儲技術(shù)也就成了數(shù)據(jù)存儲領域的一個研究熱點[1]。云存儲服務是云計算提供的重要服務之一，它通過網(wǎng)絡將大量不同類型的存儲設備整合為一個有海量存儲能力的數(shù)據(jù)池。與傳統(tǒng)的存儲技術(shù)相比存在以下優(yōu)勢：1）存儲更加靈活，可以根據(jù)實際需求請求存儲空間，并支付對應的服務費用。2）便于管理，無需對存儲設備進行維護管理；3）存儲空間無限擴展，從理論上講，云存儲服務能提供的存儲空間沒有限制。正是憑借上述優(yōu)點，云存儲已成為個人和中小型企業(yè)存儲數(shù)據(jù)的首選方案。雖然云存儲服務帶來了諸多好處和便利，但其安全問題[2-4]依然值得關(guān)注。

不可信云服務商的數(shù)據(jù)完整性問題是云存儲安全的重要問題之一。2017年某公司技術(shù)人員因為不規(guī)范操作刪除了80 萬用戶數(shù)據(jù)，2018年管理員因操作失誤造成前沿數(shù)控在云中存儲的數(shù)據(jù)丟失，這些數(shù)據(jù)安全事件引發(fā)了大眾對數(shù)據(jù)云存儲服務的思考。

云提供商或者因為經(jīng)濟利益沒有遵循服務等級協(xié)議，在沒有取得用戶許可的情況下刪除一些用戶不常訪問的數(shù)據(jù)[5]，或者因為節(jié)省成本關(guān)閉數(shù)據(jù)備份機制而只存儲了原數(shù)據(jù)。由于用戶數(shù)據(jù)的完整性無法得到有效保障，云存儲安全問題成了制約云存儲發(fā)展的瓶頸。

數(shù)據(jù)完整性驗證機制能夠識別云存儲中損壞數(shù)據(jù)的行為[6]，該機制根據(jù)是否采用容錯預處理分為數(shù)據(jù)持有性證明（provable data possession,PDP）機制和數(shù)據(jù)可恢復證明（proofs of retrievability,PoR）機制[7]。PDP 機制[8-9]能夠快速識別云存儲中的數(shù)據(jù)是否損壞。PoR 機制[10]不僅能識別數(shù)據(jù)是否損壞，同時也能恢復損壞的數(shù)據(jù)。早期PDP 機制的審計工作都是由用戶自身完成的，增加了用戶的計算量和通信開銷。引入第3 方審計者代替用戶對數(shù)據(jù)進行審計，減輕了用戶的計算負擔和通信開銷[5]。上述方法雖然有效地解決了云存儲中數(shù)據(jù)完整性驗證的問題，但依然存在以下幾點問題。1）存在第3 方審計者與云提供商合謀攻擊和第3 方審計者泄露數(shù)據(jù)的風險[11]。2）當數(shù)據(jù)完整性遭到破壞時，既不能提供有效證明來說明數(shù)據(jù)損壞的程度，又不能對損壞程度進行定量判斷，還無法提供有效證明進行索賠。3）當數(shù)據(jù)發(fā)生損壞時，無法提供有效的證據(jù)判斷是云提供商損壞了數(shù)據(jù)，還是惡意用戶為向云提供商索賠而故意損壞數(shù)據(jù)。

比特幣[12]的誕生將區(qū)塊鏈技術(shù)引入人們的視野，而區(qū)塊鏈[13]具有的防篡改和去中心化特性為解決數(shù)據(jù)完整性問題提供了新的思路。區(qū)塊鏈中的防篡改特性可以提供可問責的證明，區(qū)塊鏈的去中心化特性可以擺脫對第3 方審計機構(gòu)的依賴。文獻[14] 基于私鏈提出一種名為Zeppar 的保護模型，將文件的修改記錄以及文件的Hash 值同步上傳至區(qū)塊鏈中存儲，通過對比Hash 值來判斷數(shù)據(jù)是否完整。這種模型使用私有鏈，其安全性遠低于公鏈和聯(lián)盟鏈。文獻[15-16] 使用去中心化程度和安全性更高的公鏈并提出了基于區(qū)塊鏈的云數(shù)據(jù)完整性檢測方案，但依然存在以下3 個問題：1）雖然利用區(qū)塊鏈防篡改特性存儲了數(shù)據(jù)的Hash 值，但只能通過Hash 值檢測數(shù)據(jù)是否有損壞，卻無法評估數(shù)據(jù)的損壞程度。2）只是將不可信的云存儲提供商當作假想敵，而針對惡意用戶的非法挑戰(zhàn)沒有有效的防范措施。3）對于云提供商為節(jié)省成本而選擇不存儲數(shù)據(jù)副本的問題還沒有得到的有效解決。針對上述問題，本文提出了基于區(qū)塊鏈的云存儲數(shù)據(jù)完整性驗證方案。

1 基于區(qū)塊鏈的云存儲數(shù)據(jù)完整性驗證方案

本文針對數(shù)據(jù)的完整性問題，基于區(qū)塊鏈技術(shù)提出了如圖1所示的基于區(qū)塊鏈的云存儲數(shù)據(jù)完整性驗證方案。首次引入第3 方仲裁機構(gòu)（third party arbitration institution,TPAI）對用戶和云存儲提供商（cloud storage provider,CSP）的請求進行數(shù)據(jù)完整性仲裁。方案除了TPAI 外，還包括用戶、CSP 和區(qū)塊鏈網(wǎng)絡（blockchain network,BCN）。用戶就是使用云存儲服務的用戶，可以是個人用戶也可以是中小型企業(yè)。CSP 提供云存儲服務，為用戶提供高可靠、安全、低成本和易擴展的數(shù)據(jù)存儲服務。BCN 提供存儲和驗證服務，將用戶的數(shù)據(jù)完整性證明和輔助驗證信息存儲到區(qū)塊中，并依據(jù)區(qū)塊鏈防篡改的特性為數(shù)據(jù)提供具有法律效力的完整性證明。BCN 中的智能合約向CSP 轉(zhuǎn)發(fā)用戶發(fā)起的完整性挑戰(zhàn)，并對CSP 的應答進行驗證。TPAI 作為可信任的具有法律效力的仲裁機構(gòu)，可以對用戶和CSP 發(fā)起的仲裁進行數(shù)據(jù)完整性仲裁。

圖1 基于區(qū)塊鏈的云存儲多副本數(shù)據(jù)完整性驗證Figure 1 Blockchain-based integrity verification of cloud-stored multi-replica data

整個方案可以分為三部分：

1）數(shù)據(jù)上傳

User 在上傳數(shù)據(jù)前對數(shù)據(jù)進行加密，并生成數(shù)據(jù)完整性證明樹（data integrity proof tree,DIPT）和輔助驗證信息樹（auxiliary validation information tree,AVIT），隨后將DIPT 和AVIT 上傳到區(qū)塊鏈網(wǎng)絡中。

2）挑戰(zhàn)- 應答

User 發(fā)起完整性驗證挑戰(zhàn)，BCN 中的智能合約向CSP 轉(zhuǎn)發(fā)User 的挑戰(zhàn)，CSP 接收并應答挑戰(zhàn)，再將應答結(jié)果發(fā)送給智能合約。智能合約依據(jù)區(qū)塊中存儲的AVIT 對應答進行驗證，并將驗證結(jié)果發(fā)送給User。

3）數(shù)據(jù)完整性仲裁

User 接收到智能合約發(fā)送的挑戰(zhàn)成功的結(jié)果后向TPAI 發(fā)起數(shù)據(jù)完整性仲裁。TPAI 利用區(qū)塊中存儲的DIPT 對CSP 上的數(shù)據(jù)進行完整性驗證，并將仲裁結(jié)果返回給User。同時CSP 針對用戶的非法挑戰(zhàn)也可向TPAI 發(fā)起仲裁。

1.1 數(shù)據(jù)上傳

User 將數(shù)據(jù)上傳到云存儲服務器之前需要對數(shù)據(jù)進行一系列處理，處理流程分為四部分。首先進行數(shù)據(jù)加密生成兩個不同的加密文件，然后利用兩個加密文件生成DIPT 和AVIT，接著將DIPT 和AVIT 上傳到區(qū)塊鏈網(wǎng)絡，最后將數(shù)據(jù)及其副本上傳到云存儲服務器。

步驟1數(shù)據(jù)加密

數(shù)據(jù)加密分為原始數(shù)據(jù)加密和副本數(shù)據(jù)加密。針對數(shù)據(jù)D，可以使用不同的加密算法，或者使用相同的加密算法但必須使用不同的密鑰進行加密，生成不同的密文E1和E2。規(guī)定將E1稱為原始數(shù)據(jù)密文，而將E2稱為副本數(shù)據(jù)密文。副本數(shù)據(jù)密文可以有多個，但強制要求CSP 遵循最低保存一個副本的原則，故在方案中只生成一個副本數(shù)據(jù)密文。

步驟2生成DIPT 和AVIT

DIPT 的生成過程如圖2所示，首先將E1和E2分別拆分成數(shù)量相同的數(shù)據(jù)塊集合，構(gòu)成兩個數(shù)據(jù)塊集合E′1={e0,e1,e2,e3,e4,···,en}和E′2={e′0,e′1,e′2,e′3,e′4,···,e′n}，然后將數(shù)據(jù)塊集合E′1和E′2分別構(gòu)建成Merkle 樹。由E1生成的Merkle 樹稱為原始數(shù)據(jù)完整性證明樹（original data integrity proof tree,ODIPT），由E2生成的Merkle 樹稱為副本數(shù)據(jù)完整性證明樹（ectypal data integrity proof tree,EDIPT）。ODIPT 和EDIPT 可作為數(shù)據(jù)完整性證明存儲在區(qū)塊中。如果要求CSP 存儲多個副本，那么可以在DIPT 生成的過程中加入多個副本的DIPT。

圖2 完整性證明生成過程Figure 2 Process of integrity proof generation

AVIT 的生成過程如圖3所示，首先生成數(shù)量與E′1和E′2相同的隨機字符串集合S={s0,s1,s2,s3,s4,···,sn}，然后使用S、E′1、E′2計算出隨機哈希集合H′={H′1,H′2,H′3,H′4,···,H′n}，其中計算公式為

式中，Hash(x,y) 表示對x和y進行Hash 計算。對H′再次進行Hash 計算，得到哈希集合H。最后利用集合H構(gòu)建Merkle 樹，得到AVIT。如果要求CSP 存儲多個副本，那么可以在隨機哈希集合的生成過程中加入多個副本。

圖3 輔助驗證信息樹生成過程Figure 3 Process of auxiliary validation information tree generation

步驟3上傳區(qū)塊鏈網(wǎng)絡

將步驟1 和2 生成的ODIPT、EDIPT 和AVIT 上傳到區(qū)塊鏈網(wǎng)絡中，將隨機字符串集合S保存下來作為數(shù)據(jù)完整性挑戰(zhàn)信息，當這些信息被成功地記錄在區(qū)塊鏈時，表示上傳區(qū)塊鏈網(wǎng)絡過程完成。

步驟4上傳數(shù)據(jù)

在完整性證明ODIPT、EDIPT 和AVIT 被成功記錄到區(qū)塊后，用戶開始上傳原始加密數(shù)據(jù)E1和副本加密數(shù)據(jù)E2到云存儲服務器，云存儲服務器從區(qū)塊中獲取ODIPT 和EDIPT后對用戶上傳的數(shù)據(jù)進行完整性驗證，確認數(shù)據(jù)的完整性正確后將E1保存到存儲服務器中，并依據(jù)數(shù)據(jù)備份策略存儲E2。

1.2 挑戰(zhàn)-應答

挑戰(zhàn)-應答過程是針對數(shù)據(jù)完整性的驗證過程。由用戶發(fā)起數(shù)據(jù)完整性挑戰(zhàn)，中間經(jīng)過智能合約將挑戰(zhàn)轉(zhuǎn)發(fā)到CSP，CSP 對挑戰(zhàn)進行應答并將應答結(jié)果發(fā)送給智能合約，由智能合約對應答結(jié)果進行驗證，最后將驗證結(jié)果發(fā)送給用戶。具體步驟如下：

步驟1User 發(fā)起完整性挑戰(zhàn)，在S中隨機選擇出sm，隨后附帶信息sm向BCN 發(fā)起完整性挑戰(zhàn)T(sm)。

步驟2BCN 一旦接收到用戶發(fā)起的挑戰(zhàn)T(sm) 即可啟動智能合約，智能合約向CSP轉(zhuǎn)發(fā)起完整性驗證挑戰(zhàn)T(sm)。

步驟3CSP 接收到挑戰(zhàn)T(sm)，立即根據(jù)式(1) 計算哈希摘要H′m，并將計算出的H′m反饋給智能合約。

步驟4智能合約根據(jù)存儲在區(qū)塊中的AVIT 和H′m計算Verify(AVIT,H′m)，并將計算結(jié)果與存儲在AVIT 的Merkle Root 進行對比。如果相同，則向User 發(fā)送挑戰(zhàn)失敗的消息；反之向用戶返回挑戰(zhàn)成功的消息。

步驟5智能合約若在規(guī)定時間內(nèi)未收到CSP 的應答結(jié)果，則向User 發(fā)送應答超時的結(jié)果。

1.3 數(shù)據(jù)完整性仲裁

當用戶收到挑戰(zhàn)成功的消息后，立即向第3 方仲裁機構(gòu)發(fā)起數(shù)據(jù)完整性仲裁。如果有惡意用戶為了向云提供商索賠而發(fā)起非法挑戰(zhàn)，那么CSP 同樣也可以向第3 方仲裁機構(gòu)發(fā)起數(shù)據(jù)完整性仲裁。具體步驟如下：

步驟1User 或CSP 向TPAI 發(fā)起數(shù)據(jù)完整性仲裁請求。

步驟2TPAI 收到數(shù)據(jù)完整性仲裁請求后，立即對CSP 發(fā)起數(shù)據(jù)完整性驗證，并下載E1和E2。

步驟3TPAI 根據(jù)區(qū)塊中存儲的ODIPT 和EDIPT 對E1和E2進行驗證，評估出數(shù)據(jù)完整性遭破壞的程度，評估出有多少數(shù)據(jù)塊是完好的，有多少數(shù)據(jù)是已經(jīng)被篡改或損壞的。

步驟4TPAI 根據(jù)驗證結(jié)果生成仲裁結(jié)果(arbitral result,AR)，并將AR 發(fā)送給User或CSP。

步驟5User 與CSP 可以依據(jù)AR 進行協(xié)商處理，或依據(jù)AR 發(fā)起訴訟進行索賠。

2 方案分析

2.1 功能性分析

本方案針對云存儲中的數(shù)據(jù)及其副本數(shù)據(jù)同時進行完整性驗證，并且強制要求CSP 至少存儲一份副本數(shù)據(jù)。如果用戶在云存儲服務器中的數(shù)據(jù)及其副本發(fā)生篡改或損壞，就無法規(guī)避方案的檢驗。本方案經(jīng)實驗測試可以滿足對云存儲數(shù)據(jù)進行完整性驗證的要求，能夠達到設計目標。

2.2 安全性分析

2.2.1 云存儲服務安全問題

惡意攻擊者會攻擊云存儲服務器，對云存儲服務器的數(shù)據(jù)進行查看和篡改。因為云存儲中的數(shù)據(jù)是加密后的數(shù)據(jù)，所以攻擊者在無法獲取密鑰的情況下是無法獲取到數(shù)據(jù)內(nèi)容的。用戶對云存儲服務只有使用權(quán)而沒有控制權(quán)，也就無法有效遏止這種攻擊，但CSP 有能力防范這種攻擊。本方案中區(qū)塊鏈的引入可提供可問責的數(shù)據(jù)完整性證據(jù)，同時有第3 方仲裁機構(gòu)對數(shù)據(jù)完整性進行仲裁。一旦數(shù)據(jù)發(fā)生篡改或損壞，用戶就可以向CSP 索賠，從而促使CSP 為了企業(yè)利益而提高服務器存儲數(shù)據(jù)的安全性。

2.2.2 完整性證明篡改問題

惡意攻擊者會攻擊區(qū)塊鏈，篡改區(qū)塊中的完整性證明，但這種攻擊的成功概率趨近于0。以比特幣、超級賬本和以太坊為例，想要攻擊區(qū)塊鏈來篡改區(qū)塊中的數(shù)據(jù)幾乎是不可能實現(xiàn)的。

2.2.3 拒絕應答問題

CSP 拒絕對用戶發(fā)起的完整性挑戰(zhàn)進行應答。智能合約在轉(zhuǎn)發(fā)用戶的完整性挑戰(zhàn)后，如果在一定時間內(nèi)沒有收到應答結(jié)果，則再次發(fā)送；如果再次應答超時，就向用法發(fā)送應答超時的結(jié)果。用戶可以向第3 方仲裁機構(gòu)發(fā)起仲裁，拒絕支付存儲服務費用或進行追責賠償。CSP為其利益不受損失會避免這個攻擊方式。

2.2.4 非法挑戰(zhàn)問題

為了拒絕支付存儲服務費用或惡意進行索賠，惡意用戶向CSP 發(fā)起非法完整性挑戰(zhàn)。用戶向CSP 發(fā)送非法的挑戰(zhàn)信息sm，致使CSP 無法提供合法的應答，可能出現(xiàn)用戶挑戰(zhàn)成功的情況。因為本方案中的區(qū)塊鏈存儲著數(shù)據(jù)的完整性證明，CSP 可以向第3 方仲裁機構(gòu)發(fā)起數(shù)據(jù)完整性仲裁，證明云存儲中的數(shù)據(jù)具備正確的完整性，所以本方案中的惡意用戶無法通過這種攻擊方式獲取利益，可見這種攻擊方式不成立。

2.2.5 DDos 攻擊問題

存在惡意用戶不斷發(fā)起挑戰(zhàn)而造成網(wǎng)絡堵塞的情況。當用戶加入?yún)^(qū)塊鏈網(wǎng)絡時，本方案采取聯(lián)盟鏈對其身份進行審核；同時在區(qū)塊鏈網(wǎng)絡中加入對惡意用戶DDos 攻擊的識別，如果該用戶被識別為惡意用戶，那么會拒絕該用戶發(fā)起的挑戰(zhàn)。

3 實驗結(jié)果與分析

本節(jié)將通過實驗測試本文方案的性能，主要針對ODIPT 生成過程、AVIT 生成過程、應答過程和驗證過程的時間開銷進行了測試。對于測試平臺，本文采用了Intel?CoreTMi5-8265U@1.60 GHz 處理器、8 GB 內(nèi)存、526 G 固態(tài)硬盤、Windows10 64 位操作系統(tǒng)。算法由IntelliJIDEA2020.1.1 x64 編譯實現(xiàn)。測試中的哈希算法采用SHA-256，可以滿足安全性要求。首先分別對100 MB、200 MB 和400 MB 的數(shù)據(jù)按照8 kB、16 kB、32 kB、64 kB、128 kB和256 kB 大小進行數(shù)據(jù)塊切分，然后對這18 種情況分別進行完整性證明生成過程、AVIT 生成過程、應答過程和驗證過程時間開銷測試。對于每種情況測試3 次，取其平均值。

3.1 測試完整性證明和AVIT 生成的時間開銷

由于EDIPT 的生成過程與ODIPT 相同，在此只對ODIPT 進行測試和分析。圖4為數(shù)據(jù)塊大小與ODIPT 生成時間關(guān)系折線圖，圖5為數(shù)據(jù)塊大小與AVIT 生成時間關(guān)系折線圖。ODIPT 和AVIT 生成時間開銷主要受到兩個因素的影響：一個因素是數(shù)據(jù)哈希過程，時間開銷隨著數(shù)據(jù)塊的增大而增大；另一個因素是樹結(jié)構(gòu)構(gòu)建過程，時間開銷隨著數(shù)據(jù)塊數(shù)量的增加而增大。如圖4和5 所示，ODIPT 和AVIT 生成時間開銷隨著數(shù)據(jù)塊的增大而減少，即隨著數(shù)據(jù)塊數(shù)量的減少而減少。對于整體時間開銷的影響而言，數(shù)據(jù)塊大小的影響小于數(shù)據(jù)塊數(shù)量的影響，可見數(shù)據(jù)塊數(shù)量是主要影響因素。圖4和5 中被標記的點都是數(shù)據(jù)量塊數(shù)量為12 800，可以看出整體時間開銷隨著數(shù)據(jù)塊大小的增大而增加，故數(shù)據(jù)塊大小是次要影響因素。雖然ODIPT 和AVIT 的生成過程是相似的，但由圖4和5 可知ODIPT 和AVIT 生成時間相差較大，主要是因為ODIPT 的生成包含了數(shù)據(jù)切分的過程，而AVIT 是使用已經(jīng)切好的數(shù)據(jù)塊。

圖4 數(shù)據(jù)塊大小與ODIPT 生成時間關(guān)系折線圖Figure 4 Line graph of data block size and ODIPT generation time

圖5 數(shù)據(jù)塊大小與AVIT 生成時間關(guān)系折線圖Figure 5 Line graph of data block size and AVIT generation time

3.2 測試應答和驗證過程的時間開銷

圖6為數(shù)據(jù)塊大小與應答過程運行時間關(guān)系折線圖，圖7為數(shù)據(jù)塊大小與驗證過程運行時間關(guān)系折線圖。因為應答過程主要是進行哈希計算，所以時間開銷與數(shù)據(jù)塊大小成正比。如圖6所示，測試結(jié)果與分析一致，說明越小的數(shù)據(jù)塊切分對CSP 的計算開銷要求越小。圖6中數(shù)據(jù)塊為256 kB 的時間開銷為4 ms，數(shù)據(jù)塊切分通常比256 kB 小，且云服務器的計算能力遠遠高于本次測試平臺，所以應答過程的時間開銷對CSP 來說是可接受的。驗證過程主要是對AVIT 中固定長度的字符串進行AVIT 的高度次的哈希計算，時間開銷受AVIT 的高度影響。因為樹的高度增加緩慢，故驗證過程的時間開銷趨于穩(wěn)定，如圖7所示驗證過程的時間開銷在0.4 ms 左右波動。驗證過程的計算開銷對智能合約來說是可接受的。

圖6 數(shù)據(jù)塊大小與應答運行時間關(guān)系折線圖Figure 6 Line graph of data block size and replying time

圖7 數(shù)據(jù)塊大小與驗證運行時間關(guān)系折線圖Figure 7 Line graph of data block size and verification time

4 結(jié) 語

本文設計了一個基于區(qū)塊鏈的云存儲數(shù)據(jù)完整性驗證方案。引入?yún)^(qū)塊鏈去中心化和防篡改的特性，以智能合約替代傳統(tǒng)方案中第3 方審計機構(gòu)來驗證CSP 的應答是否合法，將數(shù)據(jù)完整性證明存儲到區(qū)塊中建立可問責的完整性驗證。同時引入第3 方仲裁機構(gòu)對來自惡意用戶或CSP 的惡意攻擊進行仲裁，利用Merkle 樹對數(shù)據(jù)進行完整性評估，生成數(shù)據(jù)損壞程度的仲裁結(jié)果。在驗證階段加入了對副本數(shù)據(jù)的完整性驗證，強制要求CSP 存儲至少一份的數(shù)據(jù)副本。本方案經(jīng)分析表明滿足安全性要求，經(jīng)實驗結(jié)果表明是可行而有效的。