一種基于Fabric區(qū)塊鏈的云端數(shù)據(jù)動態(tài)訪問控制方案

胡睿，張功萱，寇小勇

1.南京理工大學(xué)，網(wǎng)絡(luò)空間安全學(xué)院，江蘇 南京 210094

2.南京理工大學(xué)，計算機(jī)科學(xué)與工程學(xué)院，江蘇 南京 210094

引 言

伴隨著數(shù)字化時代的浪潮，云計算、云存儲等概念被廣泛的應(yīng)用到社會生產(chǎn)、人們的日常生活以及政府部門的管理中。面對海量的多源異構(gòu)的數(shù)據(jù)，用戶對存儲系統(tǒng)的性能需求越來越高，對于傳統(tǒng)的數(shù)據(jù)存儲系統(tǒng)，用戶需要使用的數(shù)據(jù)常常保存在本地的存儲設(shè)備中，這顯然不能滿足如今各類應(yīng)用數(shù)據(jù)爆發(fā)式增長的需求，面對現(xiàn)實挑戰(zhàn)，云存儲應(yīng)運(yùn)而生。

云存儲是從云計算概念擴(kuò)展發(fā)展起來的新概念[1]。云存儲系統(tǒng)中，用戶可以將自己需要存儲的數(shù)據(jù)上傳至云端以減少本地主機(jī)或移動設(shè)備等的存儲空間消耗[2]，并在任意需要使用數(shù)據(jù)的時候通過可聯(lián)網(wǎng)的設(shè)備連接至云端訪問數(shù)據(jù)。對于云存儲的用戶而言，云端數(shù)據(jù)的安全性至關(guān)重要，用戶需要云存儲服務(wù)的提供方能夠保證其在云端存儲的數(shù)據(jù)不會丟失、數(shù)據(jù)內(nèi)容不被篡改、數(shù)據(jù)不被泄露等[3]。近年來，云端數(shù)據(jù)的泄露頻繁出現(xiàn)，云服務(wù)提供商在云存儲系統(tǒng)中并不一定是誠實守信的[4]，他們可能會違規(guī)刪除云端用戶長時間未訪問的數(shù)據(jù)、惡意販賣用戶的隱私數(shù)據(jù)，并且中心化的云存儲系統(tǒng)存在存儲設(shè)備故障導(dǎo)致數(shù)據(jù)永久性丟失、系統(tǒng)被攻破導(dǎo)致數(shù)據(jù)泄露等問題。

區(qū)塊鏈作為分布式存儲的賬本[5]，經(jīng)過研究人員的不斷探索，它去中心化、難以篡改的特性在信息安全領(lǐng)域發(fā)揮著重要的作用。而區(qū)塊鏈的這些性質(zhì)，通過數(shù)據(jù)上鏈的方式可以很好的解決用戶對云服務(wù)提供商的信任問題。

用戶存儲在云端的數(shù)據(jù)在物理上不受到用戶的控制，對于數(shù)據(jù)擁有者與數(shù)據(jù)請求者實現(xiàn)數(shù)據(jù)共享的應(yīng)用場景下，密文策略的屬性基加密（Ciphertext-policy Attribute-based Encryption,CP-ABE）[6]被提出且被廣泛的采用，即數(shù)據(jù)在云端以密文的形式保存而只有擁有相應(yīng)屬性的用戶才能解密云端的數(shù)據(jù)。

基于原有的密文策略屬性基加密方案，Waters 為解決訪問控制策略更新的問題[7]，提出了動態(tài)證書和密文授權(quán)的方案，但是其新策略比舊策略要求更嚴(yán)格[8]。傳統(tǒng)的CP-ABE方案存在加解密計算消耗大、對數(shù)據(jù)擁有者與請求者所使用平臺的性能要求高、屬性授權(quán)中心存在安全風(fēng)險和單點(diǎn)故障問題、難以實現(xiàn)對用戶屬性的撤銷與訪問控制策略的動態(tài)更新等問題[9]。為了解決這些問題，Lai 等[10]人提出了具有用戶屬性撤銷與訪問策略更新功能的CP-ABE 方案，Maesa 等[11]人提出了具有加解密計算外包功能的外包型CP-ABE 方案研究，Chase 等[12]人提出了具有多個屬性授權(quán)中心(Central Authority,CA)的多機(jī)構(gòu)CP-ABE 方案。然而在上述方案中，加解密計算外包型的方案雖然降低了用戶系統(tǒng)的性能要求，但是數(shù)據(jù)在服務(wù)器與用戶間傳輸可能存在泄露的風(fēng)險[13]。對于多屬性授權(quán)中心的方案，需要存在完全可信CA，而且CA并不支持對用戶屬性的撤銷或增加[14]，當(dāng)用戶屬性發(fā)生變更時，攻擊者可以使用它變更前的屬性私鑰解密當(dāng)前不允許其訪問的數(shù)據(jù)。通過結(jié)合區(qū)塊鏈難以篡改的特性，利用超級賬本平臺上的Fabric-CA 模塊，邱云翔等[15]人提出了一種屬性私鑰安全分發(fā)的方法。但是該方案并沒有實現(xiàn)數(shù)據(jù)訪問控制策略與用戶屬性的變更，并且方案的加解密算法為原生的CP-ABE算法，存在計算負(fù)擔(dān)大的問題。

為了解決上述加解密計算負(fù)擔(dān)大、屬性授權(quán)可撤銷、訪問控制策略可更改等問題，本文提出了一種基于Fabric 區(qū)塊鏈的云端數(shù)據(jù)動態(tài)訪問控制方案，主要貢獻(xiàn)如下：

1）基于CP-ABE算法，提出了一種云端數(shù)據(jù)動態(tài)訪問控制方案，實現(xiàn)對數(shù)據(jù)擁有者數(shù)據(jù)的安全共享，降低了加解密算法對計算資源的消耗。

2）基于Fabric 區(qū)塊鏈，在用戶屬性可變更、訪問控制策略可動態(tài)變化的云環(huán)境下實現(xiàn)了屬性私鑰的安全分配。

3）對本文方案的安全性進(jìn)行了分析，對方案的加解密性能與屬性私鑰申請性能進(jìn)行了仿真測試，并與現(xiàn)有方案進(jìn)行了比較。

1 背景技術(shù)

1.1 Fabric區(qū)塊鏈與Fabric-CA

在2008 年發(fā)布的比特幣白皮書中，中本聰?shù)谝淮翁岢隽恕皡^(qū)塊”與“鏈”的概念[16]。聯(lián)盟鏈又稱為許可鏈，定義為介于公有鏈與私有鏈之間的一種區(qū)塊鏈，Hyperledger Fabric是其代表性的技術(shù)平臺之一，它支持可拔插的共識協(xié)議，架構(gòu)高度模塊化，在擁有較好性能的同時實現(xiàn)了交易信息的隱私保護(hù)。

Fabric 網(wǎng)絡(luò)的結(jié)構(gòu)如圖1 所示，不同的節(jié)點(diǎn)通過通道實現(xiàn)區(qū)塊鏈網(wǎng)絡(luò)中業(yè)務(wù)的隔離，同一組織可以擁有多個節(jié)點(diǎn)，F(xiàn)abric區(qū)塊鏈網(wǎng)絡(luò)的每一個參與者，都需要申請數(shù)字證書以確定它的數(shù)字身份從而確定它對資源的確切權(quán)限以及對參與者在區(qū)塊鏈網(wǎng)絡(luò)中擁有信息的訪問權(quán)限[17]。Fabric-CA是Fabric提供的內(nèi)置的CA組件，它提供了身份注冊、證書申請、撤銷證書或身份等功能，身份的注冊證書可以包含一個或多個屬性。

圖1 Fabric網(wǎng)絡(luò)模型Fig.1 Fabric network model

1.2 屬性基加密

屬性基加密（Attribute-based Encryption,ABE）[18]是一種將用戶屬性與數(shù)據(jù)訪問控制策略嵌入密鑰或密文中的技術(shù)，根據(jù)嵌入對象的不同，又可以分為以下兩種類型，即基于密鑰策略的屬性基加密（Key-policy Attribute-based Encryption,KP-ABE）、基于密文策略的屬性基加密CP-ABE。前者將數(shù)據(jù)訪問控制策略嵌入密鑰中，用戶屬性嵌入密文中。后者將數(shù)據(jù)訪問控制策略嵌入密文當(dāng)中，用戶屬性嵌入密鑰當(dāng)中，只有當(dāng)用戶屬性滿足訪問控制策略，其密鑰才能夠解密密文。

1.3 IPFS星際文件系統(tǒng)

星際文件系統(tǒng)（Inter-Planetary File System，IPFS）[19]是一種點(diǎn)對點(diǎn)的分布式文件系統(tǒng)，它結(jié)合分布式哈希表，提供一種高吞吐量的內(nèi)容尋址存儲模型。IPFS網(wǎng)絡(luò)中的文件會被賦予一個哈希值即IPFS hash作為用戶訪問文件的索引。

1.4 預(yù)備知識

1.4.1 雙線性映射

設(shè)G與GT為階數(shù)為p的乘法循環(huán)群，G的生成元為g，對于一個雙線性映射e:G×G→GT應(yīng)當(dāng)滿足以下的性質(zhì)：

（1）雙線性：?a,b∈Zp，?R,S∈G，有e(Ra,Sb)=e(R,S)ab；

（2）非退化性：?g∈G，使得e(g,g)≠1，且e(g,g)是GT的成員；

（3）可計算性：存在有效的算法對于?R,S∈GT，計算e(R,S)的值。

1.4.2 Shamir秘密共享方案

秘密共享技術(shù)是一種將秘密分散到每一個參與方，每個單獨(dú)分散的秘密都是無用的，只有當(dāng)滿足條件的部分分散的秘密共享在一起時，才能夠恢復(fù)原始的秘密。

Shamir秘密共享方案構(gòu)建了t-1 次多項式函數(shù)，多項式的常數(shù)項即為需要保護(hù)的秘密，當(dāng)擁有該函數(shù)的t個點(diǎn)時，即可通過拉格朗日插值差法完整的恢復(fù)該多項式，從而恢復(fù)秘密。

方案的具體流程如下：

（1）根據(jù)設(shè)定的秘密共享規(guī)則定義門限結(jié)構(gòu)，如至少需要k個參與方才能恢復(fù)秘密，并構(gòu)造多項式函數(shù)；

（2）拆分秘密s，n個參與方每人得到一個秘密分片；

（3）當(dāng)大于k個參與方一起恢復(fù)秘密時，秘密即可順利恢復(fù)。

2 系統(tǒng)模型

2.1 系統(tǒng)架構(gòu)

本文的的系統(tǒng)架構(gòu)如圖2所示，主要包括以下5類實體：

圖2 系統(tǒng)架構(gòu)圖Fig.2 System architecture diagram

（1）數(shù)據(jù)擁有者（Data Owner,DO）負(fù)責(zé)數(shù)據(jù)訪問控制策略的制定、數(shù)據(jù)的加密與上傳；

（2）數(shù)據(jù)使用者（Data User,DU），當(dāng)需要訪問數(shù)據(jù)時將調(diào)用區(qū)塊鏈上的智能合約申請屬性私鑰，并發(fā)起數(shù)據(jù)請求；

（3）區(qū)塊鏈（Block Chain,BC）通過智能合約實現(xiàn)屬性基加密公共參數(shù)的初始化、云端數(shù)據(jù)的上傳與獲取；

（4）去中心化云（Decentralized Cloud,DC），使用IPFS負(fù)責(zé)接收并存儲密文數(shù)據(jù)；

（5）Fabric-CA：負(fù)責(zé)用戶證書的管理、驗證用戶的屬性并為其頒發(fā)屬性證書。

2.2 系統(tǒng)流程

系統(tǒng)的流程可分為以下5個階段：

（1）系統(tǒng)初始化：DO 制定訪問控制策略并調(diào)用系統(tǒng)初始化智能合約，智能合約將初始化CP-ABE公共參數(shù)GP，生成訪問控制樹ACT，之后DO在本地生成對稱密鑰SKP。

（2）數(shù)據(jù)加密與上傳：DO 在本地對明文M進(jìn)行對稱加密得到對稱加密密文CT，并利用所述屬性基加密公共參數(shù)GP、系統(tǒng)公鑰對SKP 進(jìn)行屬性基加密得到對稱密鑰密文SKC，之后將CT 與SKC 以文件的形式組合并一起存儲在去中心化云IPFS，并將文件的hash 返回至Fabric區(qū)塊鏈中存儲。

（3）屬性私鑰申請與數(shù)據(jù)解密：DU 向Fabric-CA申請屬性證書，之后啟動應(yīng)用程序連接至Fabric 區(qū)塊鏈上的peer 節(jié)點(diǎn)，并調(diào)用智能合約，分別申請屬性私鑰與密文，收到申請請求后智能合約計算用戶屬性私鑰并將其與密文文件一起返回給DU；之后，DU在本地解密對稱密鑰密文得到對稱密鑰，進(jìn)一步解密對稱加密密文，得到明文M。

（4）用戶屬性變更：DO申請對DU進(jìn)行屬性變更，包括申請撤銷DU 的屬性和申請增加DU的屬性，執(zhí)行屬性撤銷時，DO 調(diào)用屬性撤銷合約選擇撤銷DU的一個或多個屬性，執(zhí)行屬性增加時，DO 與Fabric-CA 交互，撤銷DU 的屬性證書，并為DU申請新的屬性證書。

（5）訪問控制策略更新：DO 申請訪問控制策略更新，調(diào)用Fabric區(qū)塊鏈上的策略更新智能合約，重新構(gòu)建ACT，更換當(dāng)前DO 的對稱密鑰SKP，重新加密明文、對稱密鑰得到對稱加密密文CT與對稱密鑰密文SKC，并重新上傳至IPFS。

3 方案詳細(xì)設(shè)計

3.1 具體流程

3.1.1 系統(tǒng)初始化

DO調(diào)用Setup智能合約初始化屬性基加密公共參數(shù)GP，并構(gòu)造雙線性映射e:G1×G1→GT，其中G1、GT均為階為p的乘法循環(huán)群，g為G1的生成元，Zp為有限域。選取隨機(jī)數(shù)α∈Zp，并計算Y=e(g,g)α，選取隨機(jī)數(shù)β∈Zp，并計算gβ。計算系統(tǒng)主密鑰MK=gα，系統(tǒng)公鑰

在本地生成長度為128bit 的AES 對稱密鑰SKP；制定訪問控制策略，并根據(jù)相應(yīng)的訪問控制結(jié)構(gòu)構(gòu)建訪問控制樹ACT；ACT的Node節(jié)點(diǎn)的數(shù)據(jù)結(jié)構(gòu)如表1所示。

表1 訪問控制樹數(shù)據(jù)結(jié)構(gòu)Table 1 ACT data structure

將上述生成的屬性基加密公共參數(shù)GP 與訪問控制樹ACT 存儲至Fabric 節(jié)點(diǎn)私有數(shù)據(jù)集，并返回給數(shù)據(jù)擁有者DO。

3.1.2 數(shù)據(jù)加密與上傳

DO 使用上一步生成的對稱密鑰SKP 對明文M進(jìn)行AES加密得到對稱加密密文CT；

針對對稱密鑰SKP，選取隨機(jī)數(shù)s∈Zp，計算C=SKP×e(g,g)αs，C0=gs；將s作為秘密，運(yùn)行秘密共享算法將s沿著訪問控制樹ACT進(jìn)行拆分，使得對葉子節(jié)點(diǎn)的屬性i對應(yīng)的秘密分片為γi。

對于每個葉子節(jié)點(diǎn)屬性i，對i進(jìn)行哈希運(yùn)算得到H(i)以將屬性映射到乘法循環(huán)群G1上，隨機(jī)選取pi∈Zp并計算Ci1=gβγiH(i)-pi，Ci2=gpi，最終得到對稱密鑰密文LeafNode為葉子節(jié)點(diǎn)屬性集合。

DO 調(diào)用文件上傳智能合約將對稱密鑰密文SKC、對稱加密密文CT、數(shù)據(jù)擁有者標(biāo)識DOid 以三元組的形式上鏈，并建立與去中心化云DC 的連接，將三元組組織成文件的形式存儲至IPFS，同時將文件的hash、文件名Fid 保存并公開在Fabric區(qū)塊鏈的世界狀態(tài)數(shù)據(jù)庫中。

3.1.3 屬性私鑰申請與數(shù)據(jù)解密

為保證屬性私鑰在Fabric 與DU 之間傳遞的安全，傳遞將采用非對稱加密的方案。其中PU為DU的公鑰，SU為為DU的私鑰。

（1）屬性私鑰申請：DU 向Fabric-CA 申請屬性證書Ucert，若DU 未申請過屬性私鑰，則在本地生成隨機(jī)數(shù)t,并以Ucert、t為參數(shù)調(diào)用屬性私鑰申請合約，若申請過，則將t置為-1。

該合約將提取屬性證書中的屬性列表，并當(dāng)接收到t不為-1 時，計算D=gαgβt，D0=gt，之后對于DU 屬性列表中的每一個屬性i，計算Di=H(i)t。若t=-1，則只計算{Di}i∈attList，并將其與存在的部分屬性私鑰結(jié)構(gòu)D,D0進(jìn)行組合，用戶屬性私鑰SK=D,D0,{Di}i∈attList，SK被以PU 為公鑰進(jìn)行非對稱加密得到屬性密鑰密文DSK，并發(fā)送給DU。

（2）數(shù)據(jù)解密：DU申請訪問密文數(shù)據(jù)，輸入密文文件名Fid 及與之相對應(yīng)的數(shù)據(jù)擁有者標(biāo)識DOid，智能合約與IPFS交互后返回對稱加密密文CT、對稱密鑰密文SKC 給DU；DU 在本地使用SU 解密DSK 得到SK，之后利用屬性私鑰運(yùn)行解密算法解密對稱密鑰密文SKC，通過秘密恢復(fù)函數(shù)恢復(fù)秘密值即對稱密鑰SKP。最后，運(yùn)行AES 解密算法解密CT 得到數(shù)據(jù)明文M。

3.1.4 用戶屬性變更

DO 申請對數(shù)據(jù)請求者DU 進(jìn)行屬性變更，包括申請撤銷DU 的屬性和申請增加DU 的屬性。

執(zhí)行屬性撤銷時，DO 調(diào)用屬性撤銷合約選擇撤銷DU 的任意一個或多個屬性，屬性撤銷需要與系統(tǒng)中其余的DO 達(dá)成共識，DO 通過調(diào)用屬性撤銷合約向Fabric-CA 申請撤銷DU 的屬性證書，并更換所有DO 的對稱密鑰SKP，重新加密明文M、對稱密鑰SKP 得到對稱加密密文CT 與對稱密鑰密文SKC，最后調(diào)用文件上傳合約將密文數(shù)據(jù)上傳至IPFS。當(dāng)DO 需要訪問數(shù)據(jù)時，可以重新向Fabric-CA 申請屬性證書。

執(zhí)行屬性增加時，需要與系統(tǒng)中的其余DO達(dá)成共識，DO 與Fabric-CA 交互，撤銷DU 的屬性證書，并為DU申請新的屬性證書。

3.1.5 訪問控制策略更新

DO申請訪問控制策略更新，重新制定訪問控制策略，依據(jù)表1 中的Node 節(jié)點(diǎn)結(jié)構(gòu)重新構(gòu)建訪問控制樹ACT。

DO 在本地重新生成128bit 的AES 對稱加密密鑰SKP，對明文M、對稱密鑰SKP重新加密得到新的對稱加密密文CT 與對稱密鑰密文SKC，最后調(diào)用文件上傳合約將密文數(shù)據(jù)上傳至IPFS。

3.2 智能合約與相關(guān)算法

3.2.1 秘密共享算法

算法使用了Shamir 秘密分發(fā)方案，訪問控制結(jié)構(gòu)采用了訪問控制樹，以下為算法的形式化描述（算法1）：

算法1 秘密共享算法Alg.1 Secret sharing algorithm

3.2.2 秘密恢復(fù)算法

算法使用了Shamir 秘密恢復(fù)方案，采用拉格朗日插值以恢復(fù)秘密（算法2）。

算法2 秘密恢復(fù)算法Alg.2 Secret recovery algorithm

3.2.3 文件上傳智能合約

DO 調(diào)用智能合約使密文上鏈并存儲在IPFS。文件上傳智能合約具體流程如算法3所示。

算法3 文件上傳智能合約Alg.3 File upload smart contract

3.2.4 屬性私鑰申請智能合約

DU向Fabric-CA申請屬性證書，通過解析屬性證書可以得到其屬性集合。DU調(diào)用屬性私鑰申請合約獲取屬性私鑰，具體流程如算法4所示。

算法4 屬性私鑰申請智能合約Alg.4 Attribute private key application smart contract

3.2.5 屬性撤銷、策略更新智能合約

當(dāng)DO希望撤銷DU的某一或者多個屬性并達(dá)成共識時，將會調(diào)用屬性撤銷智能合約，合約流程如算法5所示。

算法5 屬性撤銷智能合約Alg.5 Property revocation smart contract

當(dāng)DO 希望更新數(shù)據(jù)訪問策略時需要執(zhí)行策略更新合約，合約需要重新構(gòu)建ACT、重新加密并上傳密文，流程與屬性撤銷合約相似，本文不再贅述。

4 方案分析

4.1 安全性分析

本節(jié)將從CA 安全性、云端數(shù)據(jù)安全性、屬性證書申請與分發(fā)的安全性、訪問控制機(jī)制變更的安全性4個方面分析本文方案的安全性。

（1）CA 安全性：CA 負(fù)責(zé)屬性證書的頒發(fā)與管理，CA 的安全性直接決定了方案的安全性，F(xiàn)abric-CA 是Fabric 區(qū)塊鏈的內(nèi)置組件，本文方案采用Fabric-CA 實現(xiàn)屬性的授權(quán)與認(rèn)證，利用區(qū)塊鏈去中心化、難以篡改的特性解決了CA的可信問題、單點(diǎn)故障問題，保障了其高可用性。

（2）云端數(shù)據(jù)安全性：數(shù)據(jù)存儲在云端，數(shù)據(jù)的完整性與不可篡改性應(yīng)該被保證，本文方案采用IPFS 去中心化存儲數(shù)據(jù)，保證了數(shù)據(jù)的高可用。而數(shù)據(jù)文件的hash作為IPFS內(nèi)容尋址的索引被保存在區(qū)塊鏈上，改變云端數(shù)據(jù)的內(nèi)容，其hash值就會改變，這保證了云端數(shù)據(jù)的完整與不可篡改性。

（3）屬性私鑰申請與分發(fā)的安全性：屬性私鑰在方案中是DU擁有相關(guān)屬性的描述，屬性證書是用戶屬性的合法性證明。本文方案中屬性的認(rèn)證與屬性證書的生成與分發(fā)由Fabric-CA完成，屬性私鑰通過DU 輸入屬性證書，調(diào)用屬性私鑰申請合約獲取，屬性私鑰用DU的公鑰加密，在區(qū)塊鏈與DU 之間以密文形式傳遞，保證了屬性私鑰分發(fā)的安全性。

本文方案在屬性私鑰的申請中，提出了利用Fabric 私有數(shù)據(jù)緩存DU 的屬性私鑰結(jié)構(gòu)D,D0，在本地生成隨機(jī)數(shù)t通過判斷DU是否申請過屬性私鑰決定是否給t重新賦值，以下將討論緩存方法的安全性：

隨機(jī)數(shù)t存儲在用戶的私有數(shù)據(jù)中，不存在泄露的問題，由用戶在本地隨機(jī)選取，并以參數(shù)的形式傳遞給屬性私鑰申請智能合約，之后不論用戶的屬性如何變更，屬性私鑰中的D,D0對于單個用戶都不會改變，只需要計算{Di}i∈attList，最后拼接得到完整的屬性私鑰。對于不同的DU，隨機(jī)數(shù)t完全隨機(jī)生成、彼此無關(guān)且不會泄露，保證了屬性私鑰申請的安全性。

（4）訪問控制機(jī)制變更的安全性：在本文方案中實現(xiàn)了用戶屬性的變更、訪問控制策略的更新。用戶屬性變更：執(zhí)行屬性增加時，增加前能解密的密文之后仍然能夠解密，只需要重新為DU 頒發(fā)屬性證書；執(zhí)行屬性撤銷時，撤銷前能解密的密文之后不一定能夠解密，為保證前向安全性，方案將重新選取對稱加解密密鑰，重新對明文加密并上傳至云端。訪問控制策略更新：當(dāng)DO 希望重新制定數(shù)據(jù)的訪問控制策略時，方案將重新構(gòu)建訪問控制樹重新加密并上傳數(shù)據(jù)以保證只有具有滿足當(dāng)前策略屬性的用戶才能解密相應(yīng)的密文，保護(hù)云端數(shù)據(jù)的安全。

4.2 安全性證明

本文方案的安全性由CP-ABE 方案的安全性與Fabric-CA 的安全性保證，下面基于挑戰(zhàn)者與攻擊者之間的博弈過程對方案在選擇明文攻擊CPA(chosen plaintext attack)下的安全性進(jìn)行證明。

定義1.如果在多項式時間內(nèi)，沒有攻擊者可以以不可忽略的優(yōu)勢贏得游戲，則本文方案是安全的。

證明：定義挑戰(zhàn)者與攻擊者的博弈過程，挑戰(zhàn)者依照定義回答攻擊者的查詢。

（1）系統(tǒng)初始化：攻擊者A選擇一種訪問控制策略A*發(fā)送給挑戰(zhàn)者B，B運(yùn)行Setup初始化算法將生成的公鑰PK發(fā)送給A并保留系統(tǒng)主密鑰MK。

（2）密鑰查詢階段1：攻擊者A選擇一系列不滿足訪問控制策略A*的屬性集合T1,T2,…,Tq并向挑戰(zhàn)者B查詢屬性私鑰，B計算后返回對應(yīng)的屬性私鑰。

（3）挑戰(zhàn)階段：攻擊者A向B提交兩個等長的消息ME0,ME1，挑戰(zhàn)者B隨機(jī)選擇β∈{0 ,1}，并加密MEβ得到挑戰(zhàn)密文并發(fā)送給A。

（4）密鑰查詢階段2：與密鑰查詢階段1 相似，攻擊者再次選擇不滿足訪問控制策略A*的屬性集合Tq+1,Tq+2,…,Tr并向挑戰(zhàn)者B查詢屬性私鑰，B計算后返回對應(yīng)的屬性私鑰。

（5）猜測階段：攻擊者A輸出對β的猜測β*，β*?{0 ,1}，若β*=β則A贏得游戲，攻擊者在游戲中的優(yōu)勢可被定義為

其概率由隨機(jī)比特決定。

證畢。

4.3 實驗評估

4.3.1 實驗環(huán)境

本文方案的實現(xiàn)基于Java 語言與Go 語言，開發(fā)使用Fabric 區(qū)塊鏈的開發(fā)工具包Fabric-Java-SDK實現(xiàn)。

本文實驗基于PBC 庫的Java 封裝版本JPBC，使用512bit 的橢圓曲線y2=x3+x構(gòu)造160bit 的橢圓曲線群。實驗采用一臺主機(jī)(Windows10 64位操作系統(tǒng)、內(nèi)存為16GB、CPU為Intel(R) Core(TM) i7-8550U)，F(xiàn)abric 版本為2.4.1，區(qū)塊鏈的搭建基于Windows10 的linux 子系統(tǒng)wsl2，子系統(tǒng)版本為Ubuntu20.04.6LTS。

4.3.2 性能分析

實驗采用10MB的明文進(jìn)行加解密，所有實驗結(jié)果均為10次獨(dú)立重復(fù)實驗取平均值。本文實驗對比了本文方案與文獻(xiàn)[13]的方案的加解密性能、屬性私鑰計算性能，大部分基于密文的屬性基加密方案均由傳統(tǒng)的CP-ABE 方案改進(jìn)而來，作為參考，本文方案也與傳統(tǒng)的CP-ABE方案進(jìn)行了對比。

（1）加解密性能

對于本文方案中的加解密算法，需要考慮的屬性數(shù)量對算法的復(fù)雜度起到了決定性的因素，實驗由8 至40 個分別選取不同的屬性數(shù)量對方案的加解密性能進(jìn)行測試。

如圖3、圖4所示，本文方案的加解密時間消耗隨屬性數(shù)量的增加接近線性增加，方案的加解密性能與文獻(xiàn)[13]相近，并且方案的性能較傳統(tǒng)的CP-ABE方案有較大的提升。

圖3 方案加密性能對比Fig.3 Scheme encryption performance comparison

圖4 方案解密性能對比Fig.4 Scheme decryption performance comparison

（2）屬性私鑰計算性能

在本文方案中，DU 需要申請屬性私鑰SK并在本地解密密文才能獲取到明文，屬性私鑰申請與計算的性能與方案的加解密流程的總耗時相關(guān)，屬性私鑰的計算性能越強(qiáng)，方案流程的總耗時越短。

實驗結(jié)果如圖5所示，傳統(tǒng)的CP-ABE 方案與文獻(xiàn)[13]方案的性能相近，本文方案因為緩存了屬性私鑰的部分結(jié)構(gòu)相較于文獻(xiàn)[13]與傳統(tǒng)的CP-ABE方案屬性私鑰的申請時間減少，屬性私鑰的計算性能得到了提升。

圖5 屬性私鑰申請時間對比Fig.5 Attribute private key application time comparison

4.3.3 功能分析

本文方案與相關(guān)文獻(xiàn)方案的功能對比如表2 所示，功能對比從以下角度出發(fā)，分別為方案是否存在單點(diǎn)故障、是否需要第三方可信CA、是否支持屬性撤銷、是否支持策略更新、是否采用去中心化云存儲，表中"√" 代表方案具備該功能，"×" 則代表方案不具備該功能。

表2 不同方案功能對比Table 2 Function comparison of different schemes

文獻(xiàn)[4]、文獻(xiàn)[13]方案的加解密過程中引入了智能合約，利用智能合約自動執(zhí)行的特性實現(xiàn)了用戶屬性私鑰自動分發(fā)、加解密流程的自動執(zhí)行。文獻(xiàn)[4]、文獻(xiàn)[13]引入了IPFS 存儲數(shù)據(jù)，解決了中心化云服務(wù)器的單點(diǎn)故障問題、“云“是否可信的問題。但文獻(xiàn)[13]需要可信的第三方CA提供支持，方案中為用戶屬性提供證明的CA 存在單點(diǎn)故障的問題，文獻(xiàn)[15]引入了Fabric-CA實現(xiàn)用戶屬性的授權(quán)使得方案不再需要額外的可信的第三方CA。

本文方案采用Fabric-CA 實現(xiàn)用戶屬性證書的頒發(fā)，使用智能合約實現(xiàn)屬性私鑰的獲取，方案無需第三方可信CA的支持，解決了私鑰申請的單點(diǎn)故障問題。方案支持屬性撤銷、策略更新并以密文的形式在去中心化云中存儲數(shù)據(jù)，保證了云端數(shù)據(jù)存儲的完整性與不可篡改性。

5 總結(jié)與展望

為解決云存儲用戶數(shù)據(jù)共享場景的一系列問題，本文提出了一種基于Fabric區(qū)塊鏈的云環(huán)境下的數(shù)據(jù)動態(tài)訪問控制方法。方案利用了區(qū)塊鏈難以篡改的特性，系統(tǒng)中數(shù)據(jù)擁有者DO、數(shù)據(jù)使用者DU以及去中心化云DC之間不需要相互信任，方案以執(zhí)行智能合約的形式實現(xiàn)了屬性私鑰分發(fā)的全自動執(zhí)行，同時結(jié)合Fabric私有數(shù)據(jù)模型，提出了一種屬性私鑰的緩存模型，提升了私鑰分發(fā)的性能，減少了屬性私鑰申請過程中時間的消耗。此外，方案實現(xiàn)了數(shù)據(jù)擁有者對云上數(shù)據(jù)動態(tài)的訪問控制，達(dá)成共識后，數(shù)據(jù)擁有者可以隨時執(zhí)行對數(shù)據(jù)使用者的屬性變更并且數(shù)據(jù)擁有者也可以隨時更新其數(shù)據(jù)的訪問控制策略。

通過實驗驗證與理論分析，本文方案具有一定的應(yīng)用前景，使用本文方案為用戶提供云端數(shù)據(jù)共享服務(wù)，可以增加云服務(wù)的可靠性，可以解決云服務(wù)器的單點(diǎn)故障問題，本文方案在加解密階段與屬性私鑰獲取階段的性能較傳統(tǒng)方案均有一定的提升。但本文方案在每次實現(xiàn)屬性撤銷、策略更新時都需要對數(shù)據(jù)重新加密，在未來的研究中應(yīng)當(dāng)進(jìn)一步改進(jìn)屬性基加解密算法，探索更高效的屬性撤銷、策略更新方法。

利益沖突聲明

所有作者聲明不存在利益沖突關(guān)系。