汪玉江, 曹成堂, 游 林

杭州電子科技大學(xué) 網(wǎng)絡(luò)空間安全學(xué)院, 杭州310018

1 引言

我們每天在生活中都會產(chǎn)生大量的數(shù)據(jù), 麥肯錫預(yù)測, 預(yù)計到2020 年, 全球的數(shù)據(jù)使用量將會達到40 ZB. 在大數(shù)據(jù)時代, 個人數(shù)據(jù)不斷地被收集和分析, 從而導(dǎo)致創(chuàng)新和經(jīng)濟增長. 公司和組織使用他們收集的數(shù)據(jù)來提供個性化服務(wù), 優(yōu)化公司決策過程, 預(yù)測未來趨勢等等. 盡管我們都從數(shù)據(jù)驅(qū)動的社會中受益, 但是公眾越來越關(guān)注個人數(shù)據(jù)隱私問題. 第三方機構(gòu)聚集了大量的個人的敏感信息, 個人幾乎無法控制他們所存儲的數(shù)據(jù)及其使用方式, 因此如何保護用戶個人隱私數(shù)據(jù)成為了研究熱點.

對用戶而言, 一方面要保護自己的數(shù)據(jù)隱私, 另一方面又需要使用第三方應(yīng)用來獲取便捷的服務(wù). 區(qū)塊鏈以數(shù)據(jù)難以被篡改、可追溯等特點成為了解決上述問題的關(guān)鍵技術(shù). 傳統(tǒng)的區(qū)塊鏈雖然解決了上述部分問題, 但是仍存在以下幾個不足: (1) 交易透明, 對任何用戶都可見; (2) 區(qū)塊容量小, 不適合在鏈上存儲大量數(shù)據(jù); (3) 使用傳統(tǒng)的對稱加密方式或非對稱加密方式, 只能支持一對一的安全傳輸, 不能滿足用戶需要多個第三方同時提供服務(wù)的需求. 針對上述不足, 學(xué)者們進行了積極的探索. 文獻[1] 提出了一種基于區(qū)塊鏈保護隱私數(shù)據(jù)的模型, 使用對稱加密的方式加密存儲數(shù)據(jù), 使用區(qū)塊鏈智能合約判定用戶權(quán)限是否滿足預(yù)先設(shè)置的訪問策略, 但是只能進行一對一的安全傳輸. 文獻[2] 將區(qū)塊鏈與分布式哈希表結(jié)合, 將數(shù)據(jù)存儲在分布式哈希表中, 鏈上只存儲與交易相關(guān)的必要數(shù)據(jù), 大大提高了系統(tǒng)查詢數(shù)據(jù)的效率. 此方案雖然解決了區(qū)塊鏈存儲數(shù)據(jù)能力不足的問題, 但是并沒有加密存儲數(shù)據(jù)且無法實現(xiàn)訪問控制.

利用屬性基加密(Attribute-Based Encryption, ABE) 可以實現(xiàn)數(shù)據(jù)的一對多的安全傳輸, 并且能實現(xiàn)復(fù)雜的訪問控制策略. 基本ABE 只能由授權(quán)機構(gòu)設(shè)置訪問策略, 而現(xiàn)實中需要由發(fā)送或接收方制定靈活的訪問控制策略. Ibraimi 等人[3]提出了一個基于一般樹結(jié)構(gòu)的、由發(fā)送方?jīng)Q定訪問控制策略的密文策略屬性基加密(Cipertext-Policy Attribute-Based Encryption, CP-ABE) 方案. 該方案將Shamir 的門限秘密共享技術(shù)與樹結(jié)構(gòu)相結(jié)合, 使發(fā)送方能夠制定復(fù)雜的訪問控制策略. 在不同時期, 隨著需求的變化, 用戶屬性可能會發(fā)生變化, 發(fā)生變化后的屬性可能不能滿足之前制定的屬性基加密方案的訪問控制策略, 因此屬性密鑰的撤銷成為研究重點. 為了實現(xiàn)屬性撤銷, 一些可撤銷的ABE 方案[4–6]被提出, 但這些方案都不能實現(xiàn)屬性的及時撤銷. 現(xiàn)有的實現(xiàn)屬性及時撤銷的ABE 方案的都是基于可信第三方的. Wu等[7]利用版本號和代理重加密技術(shù)實現(xiàn)屬性的及時撤銷, 當(dāng)撤銷操作發(fā)生后, 授權(quán)機構(gòu)將系統(tǒng)版本號加1, 可信第三方需要更新所有與版本號相關(guān)的密鑰和密文. 這些基于可信第三方的方案都不能防止用戶與第三方串謀攻擊. Sethia 等人[8]利用第三方代理實現(xiàn)了對屬性的及時撤銷, 且開銷相較于其它的方法有一個很大的提升. 該方案只能撤銷用戶的所有屬性, 不能針對用戶的某一個屬性撤銷.

利用可信第三方的屬性基加密雖然能夠很好的實現(xiàn)屬性的及時撤銷, 但是存在以下幾點風(fēng)險. 第一,當(dāng)?shù)谌匠霈F(xiàn)故障的時候, 整個系統(tǒng)都會停止運行; 第二, 如果第三方被攻擊者攻破, 則攻擊者可以在不被發(fā)現(xiàn)的情況下獲取數(shù)據(jù), 同時之前攻擊者被撤銷的屬性也可以被恢復(fù); 第三, 在某些極端情況下, 攻擊者與第三方合謀, 則攻擊者可以任意獲取數(shù)據(jù)而不被數(shù)據(jù)擁有者知曉. 區(qū)塊鏈底層網(wǎng)絡(luò)為分布式的, 在沒有51% 算力攻擊下, 賬本不可篡改, 很好地解決了以上風(fēng)險.

因此, 本文將區(qū)塊鏈技術(shù)與密文策略屬性基加密相結(jié)合, 提出了一種基于屬性基加密和區(qū)塊鏈的個人隱私數(shù)據(jù)保護方案.

2 相關(guān)研究

2.1 DHT

DHT (Distributed Hash Table) 是一種在點對點網(wǎng)絡(luò)中分散式的存儲方法. 它用來將一個關(guān)鍵值的集合分散到所有在分布式系統(tǒng)中的節(jié)點, 并且可以有效地將信息轉(zhuǎn)送到唯一一個擁有查詢者提供的關(guān)鍵值的節(jié)點. 這里的節(jié)點可以理解為散列表中的存儲位置. 在Chord[9]之前, 一致性哈希用于分布式系統(tǒng)中鍵值之間的映射, 應(yīng)用在實現(xiàn)預(yù)定的節(jié)點之間, 節(jié)點不能隨時加入或者退出系統(tǒng).

Chord[9]是DHT 的一種經(jīng)典實現(xiàn), 數(shù)據(jù)都存儲在虛擬的環(huán)形P2P 網(wǎng)絡(luò)中, NID為數(shù)據(jù)的哈希值,PID為節(jié)點IP 的哈希值. 用NID 作為鍵在虛擬的環(huán)形P2P 網(wǎng)絡(luò)中搜索時, 第一個PID ≥NID 的節(jié)點將會返回NID 對應(yīng)的數(shù)據(jù). 在一個由N 個節(jié)點組成的網(wǎng)絡(luò)中, 通過增加路由表, 可以使查詢的時間復(fù)雜度從O(N) 降到O(log N). 當(dāng)節(jié)點加入或者離開網(wǎng)絡(luò)的時候, 每個節(jié)點將會更新路由表. 為了容錯, 當(dāng)一個節(jié)點有N 個后繼節(jié)點時, 選擇此節(jié)點后續(xù)的k(k ≤N) 個節(jié)點, 復(fù)制此節(jié)點所有的數(shù)據(jù).

文獻[10] 基于DHT 提出了一種輕鏈結(jié)構(gòu), DHT 中的節(jié)點同時也是區(qū)塊鏈網(wǎng)絡(luò)中的節(jié)點, 每個區(qū)塊和交易都在DHT 節(jié)點中復(fù)制, 并按需檢索, 因此區(qū)塊鏈本身不需要保存所有的數(shù)據(jù). 此方案能夠有效的解決區(qū)塊鏈存儲數(shù)據(jù)能力不足的問題.

2.2 區(qū)塊鏈及相關(guān)技術(shù)

區(qū)塊鏈?zhǔn)亲鳛楸忍貛臶11]的底層技術(shù)首先提出來的, 是一種開放的分布式的公共賬本, 在沒有可信的第三方的情況下, 以安全可驗證的方式記錄了所有的交易, 每筆交易都可以追溯. 區(qū)塊鏈中的后一個區(qū)塊通過密碼學(xué)的哈希算法鏈接到前一個塊, 大多數(shù)節(jié)點通過共識后才能增加區(qū)塊, 保證了數(shù)據(jù)不能篡改或者刪除.

區(qū)塊鏈通常將所有的信息都集中存儲在一條鏈上, 分布式網(wǎng)絡(luò)中, 這樣會出現(xiàn)大量的冗余數(shù)據(jù)并且響應(yīng)遲緩. 文獻[12] 提出了雙鏈結(jié)構(gòu), 一條鏈僅存儲交易后的信息和賬戶信息; 另一條鏈僅存儲對交易有用的信息并且執(zhí)行相關(guān)交易. 這樣能在一定程度上提高區(qū)塊鏈的數(shù)據(jù)存儲能力和效率. 文獻[2] 是一種脫鏈存儲的方法, 鏈上只存數(shù)據(jù)哈希摘要和數(shù)據(jù)在DHT 上的地址. 這樣數(shù)據(jù)本身保存在DHT 上而不是區(qū)塊鏈上, 就能為區(qū)塊鏈節(jié)省很多空間, 提高上傳和查詢數(shù)據(jù)的效率.

智能合約概念在1995 年由Nick Szabo 首次提出, 是一種旨在以信息化傳播、驗證或執(zhí)行合同的計算機協(xié)議. 但是提出之后實際的應(yīng)用卻無法實現(xiàn), 直到區(qū)塊鏈技術(shù)的出現(xiàn). 區(qū)塊鏈去中心化、不可篡改、過程透明可追蹤的特點, 天然適合于智能合約. 智能合約是存儲在區(qū)塊鏈上的腳本, 一旦部署在區(qū)塊鏈上, 即可以按照預(yù)先設(shè)定的方式執(zhí)行.

Hyperledger 在2015 年的時候被Linux 基金會提出, Farbic 為Hyperledger 的一個區(qū)塊鏈子項目.Farbic 不同于公鏈任何節(jié)點都可以加入網(wǎng)絡(luò), 而是擁有準(zhǔn)入機制, 每個組織需要授權(quán)后才能加入網(wǎng)絡(luò). 因此, Fabric 屬于聯(lián)盟鏈. Fabric 網(wǎng)絡(luò)的關(guān)鍵組件如下所示.

? Membership service provider: 為網(wǎng)絡(luò)中的各個組成頒發(fā)證書授權(quán).

? Consensus: Fabric 在不同場景的需求下, 提供了solo, kafka, PBFT 共識.

? Channel: 通道中包含若干的授權(quán)成員, 每個成員可以屬于不同通道, 每個通道都是獨立運行的, 賬本狀態(tài)也是獨立的.

? Peers: Fabric 節(jié)點分為3 種. Endorser 節(jié)點: 完成交易提案的驗證, 模擬運行交易, 將結(jié)果附上簽名后返回給客戶端; Orderer 節(jié)點: 根據(jù)共識算法, 為交易打包排序生成區(qū)塊結(jié)構(gòu); Committer 節(jié)點: 從Orderer 節(jié)點獲取區(qū)塊結(jié)構(gòu), 驗證合法性區(qū)塊結(jié)構(gòu)的合法性, 生成區(qū)塊寫入賬本中.

3 可撤銷的屬性基加密

3.1 CP-ABE

文獻[3] 基于DBDH 假設(shè), 提出一種支持屬性的與、或和門限操作的CP-ABE 方案. 訪問結(jié)構(gòu)由與(∨)、或(∧) 和門限(of) 節(jié)點組成的k 叉樹設(shè)定, 選取隨機數(shù)作為用戶密鑰, 防止用戶串謀. 節(jié)點采用Shamir 的門限秘密共享技術(shù)分享秘密s. 具體算法流程如下:

(b) 第二層加密: 令樹τ 的根節(jié)點的值為s. 初始化標(biāo)記根節(jié)點, 其他節(jié)點不標(biāo)記. 遞歸地對每一個未標(biāo)記的非葉子節(jié)點執(zhí)行以下操作:

? 假如非葉子節(jié)點的標(biāo)志為of (門限操作), 且它的孩子節(jié)點未標(biāo)記, 用(t,n)-Shamir’s 門限分享方案分享秘密s. 這里t= n, n 為當(dāng)前節(jié)點孩子節(jié)點的個數(shù), t 為重構(gòu)秘密s 所需要的最小的孩子節(jié)點的數(shù)目. 對每一個孩子節(jié)點分配si=f(i), 并標(biāo)記這些節(jié)點為已分配狀態(tài).

? 假如非葉子節(jié)點的標(biāo)志為∧(且操作), 且它的孩子節(jié)點未標(biāo)記, 用(t,n)-Shamir’s 門限分享方案分享秘密s. 這里t = n, n, t 表示如上. 對每一個孩子節(jié)點分配si= f(i), 并標(biāo)記這些節(jié)點為已分配狀態(tài).

? 假如非葉子節(jié)點的標(biāo)志為∨(或操作), 且它的孩子節(jié)點未標(biāo)記, 用(t,n)-Shamir’s 門限分享方案分享秘密s. 這里t=1. 對每一個孩子節(jié)點分配si=f(i), 并標(biāo)記這些節(jié)點為已分配狀態(tài).

圖1 為權(quán)限控制樹τ 分享秘密s 生成密文的示例. 首先根節(jié)點(∨節(jié)點) 的值設(shè)置為s, 對第二層非葉子節(jié)點使用(1,2)-Shamir 秘密分享技術(shù)分配秘密s, 即∧節(jié)點和of 節(jié)點的值都為si; 對∧節(jié)點的孩子節(jié)點使用(2,2)-Shamir 秘密分享技術(shù)分配秘密si, 設(shè)其孩子節(jié)點的值為s1,s2; 對of節(jié)點使用(2,3)-Shamir 秘密分享技術(shù)分配秘密si, 設(shè)其孩子節(jié)點值為s3,s4,s5.

圖1 一個權(quán)限控制樹實例τ =(T1 ∧T2)∨2of(T3,T3,T5)Figure 1 Instance of access tree τ =(T1 ∧T2)∨2of(T3,T3,T5)

(4) Decrypt(cτ,skω):

(a) 選擇滿足最小的屬性集ω′?ω, 計算過程如下:

(b) 計算:

(c) 計算, 返回明文m:

3.2 RCP-ABE

本文在上述CP-ABE 方案的基礎(chǔ)上, 將算法改進為可撤銷的屬性基加密方案, 本文將新方案命名為Revocable CP-ABE, 簡稱RCP-ABE. RCP-ABE 的主要思想是區(qū)塊鏈維護一張數(shù)據(jù)請求者的屬性列表,系統(tǒng)為數(shù)據(jù)請求者生成密鑰時, 將密鑰分為兩部分, 一部分上傳到區(qū)塊鏈, 另一部分發(fā)送給數(shù)據(jù)請求者. 當(dāng)數(shù)據(jù)請求者請求數(shù)據(jù)的時候, 區(qū)塊鏈根據(jù)數(shù)據(jù)請求者的唯一標(biāo)識, 查詢數(shù)據(jù)請求者對應(yīng)的屬性列表. 如數(shù)據(jù)請求者的屬性滿足系統(tǒng)設(shè)定的數(shù)據(jù)訪問策略, 則將數(shù)據(jù)進行第一次解密, 并將解密的結(jié)果返回給數(shù)據(jù)請求者. 數(shù)據(jù)請求者收到結(jié)果后, 進行第二次解密, 得到明文數(shù)據(jù); 如不滿足, 則拒絕服務(wù). 該方案實現(xiàn)了屬性基加密的實時撤銷, 并且不需要可信的第三方為數(shù)據(jù)進行第一次解密, 所有操作均為智能合約自動執(zhí)行.

3.3 算法安全性分析

安全模型: 選擇屬性集(selective-attribute) 明文攻擊游戲(簡稱IND-sAttr-CPA) 在挑戰(zhàn)者和敵手A 之間進行, 挑戰(zhàn)者模擬協(xié)議執(zhí)行并回答來自A 的查詢. 游戲步驟如下:

(1) 初始化: 敵手A 選擇權(quán)限控制樹τ?發(fā)送給挑戰(zhàn)者.

(2) 設(shè)定: 挑戰(zhàn)者執(zhí)行Setup 算法生成(pk,mk), 將pk 發(fā)送給A.

(3) 階段一: A 對屬性ω = {aj| aj∈?, aj/∈τ?} 發(fā)起密鑰請求, 挑戰(zhàn)者執(zhí)行密鑰生成算法Keygen(ω,mk), 將執(zhí)行結(jié)果發(fā)送給A.

(4) 挑戰(zhàn): A 發(fā)送給挑戰(zhàn)者兩段等長信息m0,m1. 挑戰(zhàn)者隨機選擇b ∈{0,1}, 執(zhí)行加密算法cb=Encrypt(mb,τ?,pk), 將cb發(fā)送給A.

(5) 階段二: A 可以按照階段一的要求持續(xù)請求執(zhí)行Keygen 算法.

(6) 猜測: A 猜測b′∈{0,1}, 即cb是m0還是m1加密而來.

定義1 如果在任意多項式時間內(nèi), 敵手只能以可忽略的優(yōu)勢贏得上述游戲, 則稱該ABE 方案在此模型中是安全的.

判定雙線性Diffie-Hellman (DBDH) 假設(shè): 挑戰(zhàn)者隨機選擇a,b,c,θ ∈Zp, 選擇群G0的生成元g, 令A(yù) = ga,B = gb,C = gc, 公平拋擲硬幣μ, 假如μ = 0, 則輸出有效的五元組(g,A,B,C,Z =e(g,g)abc), 否則輸出隨機五元組(g,A,B,C,Z = e(g,g)θ), Z ∈G1. 敵手必須對μ 做出猜測, 以判斷等式Z =e(g,g)abc是否成立. 一個非確定性算法A 能以優(yōu)勢ε 解決DBDH 問題, 當(dāng)

定義2 如果不存在多項式時間算法攻擊者以至少ε 的優(yōu)勢解決DBDH 問題, 則DBDH 假設(shè)成立.

定理1 基于DBDH 假設(shè), 在RCP-ABE 方案中, 對于多項式時間敵手在IND-sAttr-CPA 游戲中滿足不可區(qū)分性.

證明: 證明過程類似文獻[3], 以下為簡要證明步驟. 假設(shè)敵手A 以不可忽略的優(yōu)勢ε 贏得INDsAttr-CPA 游戲, A 構(gòu)造模擬器B, B 將以ε/2 的優(yōu)勢解決DBDH 問題. 游戲開始前, 挑戰(zhàn)者初始化雙線性對: 選擇生成元為g 的群G0和群G1, 雙線性映射e, 隨機選擇a,b,c,θ ∈Z?p. 挑戰(zhàn)者拋硬幣μ, 如果μ=0, 令Zμ=e(g,g)abc; 否則令Zμ=e(g,g)θ. 挑戰(zhàn)者給定g,A=ga,B =gb,C =gc作為輸入, B判斷等式Zμ=e(g,g)abc是否成立.

初始化: A 選擇權(quán)限控制樹τ?發(fā)送給B.

初始設(shè)置: B 選擇隨機數(shù)x′∈Zp, 令e(g,g)α= e(g,g)ab·e(g,g)x′, 則α = ab+x′. 當(dāng)aj∈? 且aj/∈τ?時, 選擇隨機數(shù)kj∈Zp, 令Tj=B1/kj, 則tj=b/kj. B 將公共參數(shù)發(fā)送給A.

階段一: A 為屬性集ω = {aj|aj∈? ,aj/∈τ?} 發(fā)送密鑰請求. B 選擇隨機數(shù)r′∈Z?p, 令d0=gx′?r′b, 則r =ab+r′b. 計算過程如下:

則A 獲得密鑰skωj=(d0,?aj∈ωj:dj).

挑戰(zhàn): A 提交兩條等長信息m0,m1∈G1. B 拋擲硬幣, 返回mb的加密結(jié)果, mb加密過程如下:

(1) 第一層加密: c0=gc,

(2) 第二層加密: 令樹τ?的根節(jié)點的值為gc. 節(jié)點賦值操作同RCP-ABE 算法.

對于所有的葉子節(jié)點aj,i∈τ, 計算cj,i=gf(i)kj.

將密文cτ?=(τ?,c0,c1,?aj,i∈τ?:cj,i) 發(fā)送給A.階段二: A 可以一直按照階段一的步驟請求密鑰.猜測: A 輸出猜測b′∈{0,1}.

假如b′=b, B 將會猜測μ=0 和Zμ=e(g,g)abc. 假如b′=b, B 將會猜測μ=1 和Zμ=e(g,g)θ.當(dāng)μ=0 時, 敵手的優(yōu)勢為:

4 系統(tǒng)設(shè)計

4.1 系統(tǒng)整體功能說明

該系統(tǒng)中的用戶有數(shù)據(jù)擁有者, 用字母A 表示; 數(shù)據(jù)請求者, 用字母I 表示. 智能合約有屬性合約、上傳合約和查詢合約. 角色的作用分別如下:

? 屬性合約: 增加或刪除用戶屬性, 維持屬性列表.

? 上傳合約: 將數(shù)據(jù)上傳至DHT 中, 維護上傳列表.

? 查詢合約: 驗證請求者屬性集是否滿足訪問策略, 驗證通過后解密數(shù)據(jù).

? I: 提供身份信息, 申請密鑰; 查詢數(shù)據(jù).

? A: 初始化密鑰; 為數(shù)據(jù)請求者頒發(fā)屬性密鑰; 撤銷用戶權(quán)限; 上傳數(shù)據(jù); 設(shè)定訪問控制策略.

第三方應(yīng)用即數(shù)據(jù)的請求者通過調(diào)用SDK 與Fabric 網(wǎng)絡(luò)交互, Fabric 收到請求參數(shù)后, 自動執(zhí)行智能合約的業(yè)務(wù)邏輯, 并將執(zhí)行結(jié)果寫入到賬本中. 數(shù)據(jù)存儲層主要是利用DHT 脫鏈存儲用戶加密后的數(shù)據(jù). 系統(tǒng)架構(gòu)圖如圖2 所示.

4.2 系統(tǒng)詳細設(shè)計

整個系統(tǒng)分為五部分, 時序圖如圖3 所示.

圖3 個人數(shù)據(jù)保護時序圖Figure 3 Personal data protection timing diagram

4.2.1 初始化

Fabric 網(wǎng)絡(luò)初始化, 初始化Fabric 網(wǎng)絡(luò)節(jié)點, 編寫chaincode 即Fabric 上的智能合約, 打包智能合約, 將智能合約安裝部署到Fabric 網(wǎng)絡(luò)上, 實例化智能合約, 為系統(tǒng)中的用戶頒發(fā)證書; A 執(zhí)行Setup(k),生成公鑰pk, 主私鑰mk, 并生成A 對應(yīng)的身份標(biāo)識Auid.

4.2.2 身份注冊

(1) I 提供身份信息Iu和屬性集合ω.

(2) A 審查I 提供的身份和屬性信息, 審查通過后為I 生成唯一的身份標(biāo)識Iuid.

(3) A 執(zhí)行密鑰生成算法計算私鑰(skωIu,1,skωIu,2)=Keygen(mk,ω,Iu).

(4) A 通過安全信道將{Auid,Iuid,ω,skωIu,1} 發(fā)送給區(qū)塊鏈SDK, 將skωIu,2通過安全信道發(fā)送給I. 本文的安全信道通過安全傳輸協(xié)議TLS 實現(xiàn)的, 能夠保護信息的機密性和完整性.

(5) 客戶端通過調(diào)用SDK 發(fā)起區(qū)塊鏈網(wǎng)絡(luò)發(fā)送交易提案, Endorser 節(jié)點驗證交易提案的合法性, 若合法, 對交易提案背書, 模擬執(zhí)行智能合約, 將執(zhí)行后的生成的屬性列表和簽名發(fā)送給客戶端. 客戶端將背書節(jié)點返回的結(jié)果發(fā)送給Orderer 節(jié)點, 由Orderer 節(jié)點經(jīng)過共識后生成區(qū)塊結(jié)構(gòu).Committer 節(jié)點定期從Orderer 節(jié)點獲取區(qū)塊結(jié)構(gòu), 對所有區(qū)塊結(jié)構(gòu)進行合法檢查, 檢查通過后,生成區(qū)塊寫入賬本. 列表內(nèi)容如表1 所示.

表1 屬性列表Table 1 Attributes list

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

(1) A 首先對要上傳數(shù)據(jù)m 執(zhí)行加密操作, 計算密文cτ=Encrypt(m,τ,pk).

(2) A 將身份標(biāo)識Auid、權(quán)限控制樹τ、數(shù)據(jù)m 的關(guān)鍵詞mKey 和密文cτ發(fā)送給區(qū)塊鏈SDK.

(3) 區(qū)塊鏈將執(zhí)行交易流程, 上傳合約計算數(shù)據(jù)關(guān)鍵詞的哈希, 即計算ht = SHA ?256(mKey). ht作為DHT 中的key, cτ作為DHT 中的value, 將數(shù)據(jù)存入DHT 中, 生成上傳列表寫入到區(qū)塊鏈賬本中. 列表內(nèi)容如表2 所示.

表2 上傳列表Table 2 Upload list

4.2.4 訪問數(shù)據(jù)

(1) I 提供身份標(biāo)識Iuid, 數(shù)據(jù)m 的關(guān)鍵詞, 發(fā)送給區(qū)塊鏈的SDK.

(2) SDK 調(diào)用查詢合約, 根據(jù)Iuid查詢賬本中的屬性列表, 返回Iuid對應(yīng)的屬性集ω; 根據(jù)數(shù)據(jù)m的關(guān)鍵詞哈希查詢賬本中的上傳列表, 返回τ. 驗證ω 是否滿足τ, 如滿足, 則從DHT 中取出密文cτ, 對密文第一次解密, 即執(zhí)行算法

(3) I 得到區(qū)塊鏈返回的結(jié)果后執(zhí)行算法

得到明文m; 若沒有得到返回結(jié)果, 則重新提交請求.

4.2.5 撤銷用戶權(quán)限

A 因為需求變動, 需要撤銷I 的整個權(quán)限或者部分權(quán)限, 則向區(qū)塊鏈發(fā)起更改屬性的交易請求, 區(qū)塊鏈驗證用戶證書后, 將更新賬本中的屬性列表, 即將I 對應(yīng)的ω 修改為ω′, ω′為I 新的屬性集, 為空則說明這個用戶權(quán)限被撤銷.

4.3 系統(tǒng)仿真

本系統(tǒng)使用8 GB 內(nèi)存64 位的Ubuntu 16.04 操作系統(tǒng)實現(xiàn), 區(qū)塊鏈?zhǔn)褂玫氖荋yperledger-fabric 1.3 版本, DHT 由單機模擬實現(xiàn). 后端使用GOLANG 語言開發(fā), 前端用的語言是JavaScript. 后端使用Fabric 提供的GO-SDK 與區(qū)塊鏈交互. 密碼庫使用的斯坦福提供的pairing-based cryptography (PBC)0.5.14 版本. 仿真實驗選取的雙線性對基于橢圓曲線y2= x3+x, 橢圓曲線的階r 為160 位, 素數(shù)q 為512 位. 仿真界面用戶輸入的為白色底色, 系統(tǒng)生成的為灰色底色.

4.3.1 Fabric 網(wǎng)絡(luò)初始化

本文從github 官網(wǎng)上下載Fabric 1.3 的源碼, 運行官方first-network 示例網(wǎng)絡(luò). 運行過程如下:

(1) 利用cryptogen 工具生成用戶發(fā)起交易所需要的證書;

(2) 利用configten 工具生成一個orderer 節(jié)點和2 個組織, 每個組織包含兩個peer 節(jié)點;

(3) 生成創(chuàng)世區(qū)塊和channel 通道, 將創(chuàng)世區(qū)塊和每個節(jié)點都加入channel;

(4) 編寫智能合約, 替換示例中的智能合約, 部署智能合約, 利用docker-compose 啟動整個網(wǎng)絡(luò).智能合約如表3 所示.

表3 智能合約列表Table 3 Smart contract list

4.3.2 系統(tǒng)初始化

數(shù)據(jù)擁有者初始化界面: 用戶登錄系統(tǒng), 系統(tǒng)為用戶生成ID. 輸入屬性集{a,b,c,d}, 系統(tǒng)為用戶生成主私鑰主公鑰. 具體如圖4 所示.

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

數(shù)據(jù)上傳界面: 用戶輸入訪問策略(2of4 a b c d), 表示數(shù)據(jù)請求至少擁有4 個屬性中的2 個才能解密. 明文this is a test case, 并輸入明文的關(guān)鍵詞test, 關(guān)鍵詞用來給數(shù)據(jù)查詢者搜索明文. 系統(tǒng)讀取用戶的公鑰生成密文, 通過SDK 接口調(diào)用UploadC 智能合約, 智能合約發(fā)起交易, 交易驗證通過后, 生成上傳列表, 寫入?yún)^(qū)塊鏈賬本中, 并將密文上傳至DHT 中保存. 具體如圖5 所示.

圖5 數(shù)據(jù)上傳Figure 5 Upload data

4.3.4 身份注冊

身份注冊界面: 數(shù)據(jù)擁有者根據(jù)數(shù)據(jù)請求者的信息, 定義數(shù)據(jù)請求者的屬性(a,b), 生成密鑰sk1 和sk2, 將sk2 發(fā)送給數(shù)據(jù)請求者; sk1 發(fā)送給區(qū)塊鏈AttributesC 智能合約, 智能合約發(fā)起交易, 交易驗證通過后, 生成屬性列表, 寫入?yún)^(qū)塊鏈賬本中. 具體如圖6 所示.

圖6 身份注冊Figure 6 Identity registration

4.3.5 數(shù)據(jù)查詢

數(shù)據(jù)查詢: 用戶輸入明文的關(guān)鍵詞調(diào)用SDK 發(fā)送查詢數(shù)據(jù)請求, SDK 調(diào)用QueryC 智能合約, 智能合約根據(jù)用戶ID 找到用戶屬性(a,b), 判斷用戶屬性滿足權(quán)限控制樹, 智能合約從DHT 中取出密文, 對密文進行第一次解密. 用戶得到區(qū)塊鏈返回的結(jié)果, 用自己的私鑰進行第二次解密, 得到明文m. 具體如圖7 所示.

圖7 數(shù)據(jù)查詢Figure 7 Query data

5 對比分析

5.1 RCP-ABE 對比分析

本文方案與經(jīng)典的版本號撤銷方法和中國剩余定理進行對比, 分析各方案的存儲開銷和通信開銷, 由于存儲開銷與用戶的私鑰長度相關(guān), 通信開銷與密文長度相關(guān). 因此, 本文只對比各方案的密文長度和私鑰長度, 得到結(jié)果列表. 在進行性能評估時, Lx表示x 中元素的長度; Au表示用戶擁有的屬性個數(shù); Ac表示密文包含的屬性個數(shù).

文獻[7] 和文獻[13] 方案引入第三方使用版本號實現(xiàn)撤銷, 當(dāng)有屬性撤銷時, 第三方為該屬性選擇新的版本號. 文獻[14] 引入中國剩余定理實現(xiàn)屬性撤銷. 本文方案引入?yún)^(qū)塊鏈, 將用戶一部分密鑰存入到區(qū)塊鏈上, 極大的減輕了用戶的存儲負擔(dān), 同時實現(xiàn)了屬性的及時撤銷. 分析表4 可以看出, 本方案的存儲和通信開銷相對于其他方案都減少了1/2 左右.

表4 存儲開銷和通信開銷對比Table 4 Comparison of storage overhead and communication overhead

5.2 整體方案對比分析

表5 本方案與文獻[1] 方案的對比Table 5 Comparison of our proposed scheme with the scheme of Ref. [1]

6 結(jié)束語

針對用戶使用第三方應(yīng)用時產(chǎn)生的數(shù)據(jù)安全問題, 本文提出了一種基于區(qū)塊鏈和屬性基加密的個人隱私數(shù)據(jù)保護方案. 用區(qū)塊鏈智能合約代替了傳統(tǒng)的第三方, RCP-ABE 用來實現(xiàn)對用戶數(shù)據(jù)的細粒度訪問控制, 用戶還可以隨時撤銷第三方用戶的訪問權(quán)限, 幫助用戶在享受第三方應(yīng)用服務(wù)的時候保護自己的隱私數(shù)據(jù). 同時, 區(qū)塊鏈以可追蹤的特點防止第三方應(yīng)用濫用數(shù)據(jù).