支持屬性和代理重加密的區塊鏈數據共享方案

李雪蓮，張夏川，高軍濤，向登梅

(1.西安電子科技大學 數學與統計學院，陜西 西安 710071；2.西安電子科技大學 通信工程學院，陜西 西安 710071)

基于云服務的電子智慧醫療體系，使醫療行業逐漸實現智能化和共享化[1]。2020年以來，醫療數據的互聯互通對新冠肺炎的及時治療和有效防控起了重要作用。然而醫療數據共享還存在一些問題和挑戰[2]：① 醫療數據呈指數規模增長；② 醫療數據中個人隱私保護和數據共享的矛盾突出；③ 醫療數據大多由各個醫院數據庫獨立存儲，容易形成“數據孤島”，導致共享性差，不能滿足當前相關行業的數據共享需求；④ 在數據共享過程中需要安全監管，防止舞弊現象和騙保等醫療違規情況發生[3]。

屬性加密(Attribute-Based Encryption，ABE)由于可實現一對多的訪問控制且可加密的特點為數據共享提供了技術支持。例如，文獻[4]提出了一種支持任意狀態的屬性加密方案，在云計算中實現數據共享。然而在大數據時代下，海量數據的產生會使得云存儲空間消耗巨大，并且中心化集中式的云存儲有著自身局限性，即中心服務器崩潰會導致整個系統宕機，造成存儲和共享過程中的數據泄露、丟失等問題[5-8]。區塊鏈由于其去中心和不可篡改等特性引起了人們的廣泛關注，它可以防止單點故障問題，并且可以解決“數據孤島”之間信任困難的問題。因此，區塊鏈與屬性加密技術相結合，可以更好地為海量數據實現安全的可信的大規模共享提供新思路。文獻[9]提出了基于區塊鏈的多屬性權威屬性基加密訪問控制系統，它們將授權中心和屬性權威都放到以太坊的智能合約中，進而實現一種去中心化的數據共享方案。文獻[10-11]將區塊鏈與屬性加密技術相結合實現了對數據的細粒度訪問控制，用戶所有操作上鏈后不可篡改且永久保留。WANG等[12]提出了基于區塊鏈的細粒度訪問控制的去中心化存儲系統和數據共享框架，但未考慮到用戶隱私的保護問題。XIA等[13]提出了基于許可鏈的數據共享框架，只有被邀請的用戶才可以訪問和共享敏感數據。楊顏博等[14]采用了區塊鏈和屬性加密相結合的方案來解決車聯網中的數據隱私、信任與訪問控制的問題。代理重加密(Proxy Re-Encryption，PRE)技術由于可轉化密文給指定對象的功能，為打破“數據孤島”提供了新的思路。文獻[15-16]基于代理重加密技術提出了去中心化的數據共享系統，能夠保證信息的可追溯性，也保證了訪問控制權限的不可篡改，但未考慮一對多的訪問控制和用戶隱私保護。POURNAGHI等[17]和SHAMSHAD等[18]分別提出了基于區塊鏈的支持隱私保護的電子醫療數據共享協議，使用雙鏈提高了遠程共享和治療效率。上述方案只考慮了數據訪問控制，未考慮數據本身和訪問策略也可能會泄露敏感信息[19]。文獻[20]提出了部分隱藏訪問策略和可追溯性的電子醫療數據共享方案，解決了訪問策略泄露敏感信息的問題。但和大多數隱藏訪問策略的方案一樣，文獻[20]是基于合數階群的，從而導致方案效率較低。隨后，HU等[21]和CUI等[22]基于素數階雙線性群分別提出了隱藏訪問策略的屬性加密方案，保護了用戶敏感信息。雖然屬性加密方案可以解決細粒度訪問控制問題，但仍存在效率低下，訪問策略失效等挑戰。

為了應對訪問策略失效問題，文獻[23]利用動態更新密鑰來應對訪問策略及密文更新的問題，文獻[24-26]提出屬性代理重加密方案，可以針對更改后的訪問策略進行重加密，能夠指定用戶解密重加密密文，但效率相對較低。DENG等[27]利用代理重加密技術將密文策略的屬性加密方案(Ciphertext Policy Attribute-Based Encryption，CP-ABE)的密文轉換為身份基加密(Identity-Based Encryption，IBE)的密文，提出一種允許修改訪問策略，還可以轉化為支持高效解密的方案。

筆者從保護敏感數據機密性、完整性角度出發，提出一種隱藏訪問策略的CP-ABE和代理重加密結合方案。與同類方案相比，筆者的主要貢獻如下：

(1) 將代理重加密技術與屬性加密技術相結合，在實現一對多數據共享的同時，克服了屬性加密訪問策略不可更改、無法動態共享和效率較低的缺點，可以實現數據的高效動態共享；

(2) 采用部分隱藏訪問策略的技術，隱藏訪問策略中的屬性值，解決敏感信息泄露問題；

(3) 安全性分析表明方案能夠抵抗惡意攻擊和共謀攻擊；效率、功能性分析表明方案效率較高，且與同類方案相比，具有保護敏感信息、動態共享等功能。

(4) 將筆者提出的方案與區塊鏈融合，設計了一個存儲共享鏈和監督鏈的雙鏈架構，可以動態靈活地有效保護醫療數據的存儲和共享。

1 預備知識

設p是一個大素數，設G1和GT是兩個階為素數p的乘法循環群，其中g是G1的生成元。

1.1 雙線性映射

映射e：G1×G1→GT，如果滿足以下三條性質，則稱e為一個雙線性映射：

(1) 雙線性：?g∈G1和x，y∈Z，有e(gx，gy)=e(g，g)xy；

(2) 非退化性：e(g，g)≠1；

(3) 可計算性：?g∈G1，e(g，g)能有效計算出來。

1.2 線性秘密共享方案

假設U表示屬性全集，包括n種屬性。在筆者提出的方案中，每一種屬性分別由兩部分構成：屬性名稱和屬性值。一種屬性可以對應多個屬性值。A是Zp上的一個l×n的矩陣，對應線性秘密共享方案中的生成矩陣A(l×n)，ρ是一個單射函數，可以把A矩陣的每一行分別映射到一個屬性名稱索引。那么如果滿足下述兩個條件，則稱為一個線性秘密共享方案：

(1) 共享秘密值：考慮向量v=(s，y2，…，yn)，其中s∈Zp是共享秘密值，y2，…，yn∈Zp是隨機數，用來隱藏s。然后令λi=Aiv，其中Ai表示A的第i行，λi代表共享秘密s的第i個份額，分別對應授權屬性名稱索引。

為了進行隱藏訪問策略來保護屬性隱私，文中方案訪問策略記為(A，ρ，T)，其中T=(attρ(1)，…，attρ(l))，(attρ(i)∈vUρ(i))是與訪問策略(A，ρ)屬性名稱索引對應的具體屬性值的集合。假設某用戶的屬性集為ATT=(IATT，LATT)，其中IATT表示此用戶的屬性名稱索引集合，LATT=(L1，L2，…，Ll)，(Li∈vUi)表示此用戶的屬性值集合。如果有(I={i|ρ(i)∈S}?IATT)∩(H(Lρ(i))=H(attρ(i)))成立，就稱用戶是滿足訪問策略的。

1.3 困難假設問題

q-type假設：設雙線性映射e：G1×G1→GT，隨機選取a，s，b1，…，bq←Zp，公開

如果不存在多項式時間算法使得以不可忽略的優勢區分Pq-type={(y，e(g，g)aq+1s)}和Rq-type={(y，R)}的分布，其中R是GT中的隨機元素，則q-type問題是困難的，即q-type假設是成立的。

1.4 屬性加密

屬性加密機制是將用戶的一系列屬性作為身份標識，制定與某屬性集合相匹配的訪問策略來實現一對多的數據共享，可實現密碼方案的細粒度訪問控制功能，只有滿足訪問策略結構的用戶才可以正確解密密文得到明文信息。屬性加密機制一般包含3個實體，分別是可信授權中心、數據擁有者和數據用戶。算法一般包括如下4個部分：

(1) 系統初始化算法Setup(λ)→(PK，MSK)：以安全參數λ為輸入，輸出公鑰PK和主密鑰MSK。

(2) 密鑰生成算法KeyGen(PK，MSK，S)→SK：以公鑰PK，主密鑰MSK及用戶的屬性集合S為輸入，輸出解密密鑰SK。

(3) 加密算法Encrypt(PK，(A，ρ)，M)→CT：以公鑰PK，明文信息M，以及訪問策略(A，ρ)為輸入，輸出密文CT。

(4) 解密算法Decrypt(PK，CT，SK)→Mor ⊥：以公鑰PK，密文CT和解密密鑰SK為輸入，若用戶屬性滿足訪問策略，則輸出明文消息M；否則，算法中止并輸出⊥。

1.5 代理重加密

代理重加密是密文間的一種密鑰轉換機制，具體指半可信的代理方通過轉換密鑰RK，將數據擁有者A加密的密文轉換為數據請求者B可以解密的密文，從而使B得到明文信息的過程。在此過程中代理方不能得到任何關于明文的信息，從而保證數據安全性和共享靈活性。代理重加密算法一般包括如下7個部分：

(1) 系統初始化算法Setup(λ)→(Par，MSK)：以安全參數λ為輸入，輸出系統公共參數Par。

(2) 密鑰生成算法KeyGen(Par)→(PK，SK)：以Par為輸入，輸出用戶的公私鑰對(PK，SK)。

(3) 轉換密鑰生成算法Re_KeyGen(Par，SKA，PKB)→RK：以公開參數Par，數據擁有者A的私鑰SKA和數據請求者B的公鑰PKB為輸入，輸出轉換密鑰RK。

(4) 加密算法Encrypt(Par，PKA，M)→CT：以公共參數Par，數據擁有者A的公鑰PKA及明文信息M為輸入，輸出密文CT。

(5) 重加密算法Re_Encrypt(CT，RK)→CT′：以公共參數Par，密文CT，轉換密鑰RK為輸入，輸出重加密密文CT′。

(6) 解密算法Decrypt1(CT，SKA)→Mor⊥：以數據擁有者A的私鑰SKA，密文CT為輸入，輸出明文消息M或者⊥。

(7) 重解密算法Decrypt2(CT′，SKB)→Mor⊥：以數據請求者B的私鑰SKB，密文CT′為輸入，輸出明文消息M或者⊥。

2 方案設計

2.1 系統模型與實體

如圖1所示，方案有5種角色：星際文件系統、數據擁有者、醫院信息系統、區塊鏈、數據請求者。

圖1 系統模型圖

2.1.1 星際文件系統

星際文件系統(Inter Planetary File System，IPFS)為海量數據共享提供分布式存儲的系統，可為區塊鏈系統減輕存儲壓力。IPFS不存在單點故障的問題，各個節點之間無需信任，可提高數據存儲的可靠性。其權利包括：(1) 存儲較大原始數據的密文，為其生成可快速索引的哈希指紋路徑；(2) IPFS根據路徑查找返回原始數據密文給數據請求者，以供最終解密和安全共享需求。

2.1.2 數據擁有者

數據擁有者(Data Owner，DO)即醫療數據的實際擁有者(患者)。其權利包括：(1) 有權制定訪問控制策略，決定欲共享數據的對象；(2) 加密原始文件上傳至IPFS；(3) 利用屬性加密技術將密鑰和路徑等關鍵密文進行加密并上傳至區塊鏈；(4) 生成代理重加密密鑰。

2.1.3 醫院信息系統

醫院信息系統(Hospital Information System，HIS)為生成醫療數據的醫療機構。合規的HIS集合組成區塊鏈的節點。其功能包括：(1) 驗證和保存DO上鏈的關鍵密文；(2) 使用DO生成的代理重加密密鑰，進行代理重加密。

2.1.4 區塊鏈

區塊鏈(Block Chain，BC)中的一條是存儲共享鏈，其功能包括：(1) 存儲屬性加密的關鍵密文，(2) 存儲重加密密文，(3) 通過智能合約向DR返回密文或者拒絕；另一條是監督鏈，其功能包括：(1) 存儲行政人員審核結果，(2) DO可通過智能合約進行查詢審核結果。

2.1.5 數據請求者

數據請求者(Data Requester，DR)即醫療數據的消費者，其權利包括：(1) 通過智能合約提出醫療數據訪問請求；(2) 滿足訪問策略或是經過患者同意共享的數據請求者可以對區塊鏈返回的密文或重密文進行解密操作，從而實現數據共享和有效監督審查；(3) 對IPFS返回的原始數據密文進行最終解密操作。

2.2 方案原理

在筆者設計的利用屬性加密和代理重加密技術且基于區塊鏈的醫療數據共享系統中，患者和醫療信息系統會產生大量敏感醫療數據，其中某些醫療數據過多過大(例如X光片及視頻等)導致無法在區塊鏈上存儲。為了減輕其存儲負擔并且解決各個醫療信息系統之間的數據共享性差的問題，可以將密文分為兩部分存儲和共享：(1)把對稱加密后的醫療數據分布式存儲在IPFS中，IPFS可快速返回一個指紋哈希路徑；(2)針對路徑和對稱密鑰等關鍵信息，DO進行屬性加密之后發布至區塊鏈上存儲和共享。有需求的DR可以通過區塊鏈和IPFS來訪問這些醫療數據。然而，屬性加密中的訪問策略一旦由DO制定好之后，就不可更改，只能由滿足此訪問策略的DR進行成功解密。但是在現實生活中，很有可能面臨更改訪問策略的需求。所以筆者將代理重加密技術與屬性加密技術相結合，可以在實現一對多數據共享的同時，生成重密鑰并進行重加密過程，然后克服屬性加密訪問策略不可更改、無法動態共享和效率較低的缺點，從而實現數據的高效動態共享。除此之外，由于醫療數據的敏感性，訪問策略在存儲和共享過程中一直是以明文形式存在的，這可能會泄露用戶隱私。為了保護訪問策略中的敏感隱私信息，還讓其實現了部分隱藏訪問策略的功能。進一步地，筆者設計了一個存儲共享鏈和監督鏈的雙鏈架構，利用上述的算法與區塊鏈結合以解決醫療數據的共享性差和“數據孤島”之間的信任問題。

2.3 具體方案過程

筆者所提出的方案主要分為5個階段，如圖2所示。

2.3.1 系統初始化階段

本階段分為系統設置和密鑰生成兩部分：

(1) Setup(λ)→(Params，MSK)：輸入安全參數λ，選擇生成元為g，階數為大素數p的雙線性循環群G1(雙線性映射e：G1×G1→GT)；然后隨機選取元素u，h，w，v，f∈G1和α，β1，β2，β3，β4∈Zp，計算g1=gβ1，g2=gβ2，g3=gβ3，g4=gβ4。再選取抗碰撞哈希函數H(用于將屬性值映射到Zp中的元素)，編碼函數F：GT→G1。最后輸出系統公開參數Params={u，h，w，v，f，g，g1，g2，g3，g4，H，F，e(g，g)α}和主密鑰MSK={α，β1，β2，β3，β4}，并把公開參數Params上傳至區塊鏈上用來參數共享，區塊鏈上的節點都可以調用公開參數Params。

圖2 方案流程圖

2.3.2 數據存儲階段

本階段分為兩部分：對稱加密后的醫療數據存儲在IPFS，利用屬性加密技術加密關鍵信息后，上傳至區塊鏈上存儲。筆者將CUI等[22]的具有隱藏訪問策略功能的CP-ABE算法與DENG等[27]的PRE方案的思想相結合，再融合對稱加密和區塊鏈技術，構造出基于區塊鏈的隱藏訪問策略的一種新的數據共享方案。

(1)Efile_key(file)→CF：原始數據file加密算法。首先使用對稱密鑰file_key對原始數據file進行加密，然后將密文CF存儲在IPFS中，最后IPFS返回哈希指紋路徑hashpath給數據擁有者。

利用粉晶X射線衍射儀ShimadzuXRD-6100進行實驗，實驗前先將煤樣研磨成粉末狀，在CuKa輻射、電壓20kV、電流30mA、掃描速度3°/mm、掃描范圍5°～80°的條件下進行物相分析。

(2) Encrypt(Params，(A，ρ，T)，M)→CT：對稱密鑰file_key和存儲路徑hashpath上鏈加密算法。

注：CUI等[22]的方案是普通的隱藏訪問策略的屬性加密算法，在加密部分是Ei=(uattρ(i)h)-zi，而在筆者提出的方案里，這一部分密文構造變為Ei=(uH(attρ(i))h)-zi。這樣做，可以更好地防止屬性隱私泄露。要滿足訪問策略正常解密，需要有H(φρ(i))=H(attρ(i))，在不暴露屬性的情況下，只需要計算哈希值進行對比即可。筆者提出的方案多了E=fs，是為訪問策略有所變化時進行代理重加密做準備，防止代理與用戶之間的惡意合謀攻擊。

2.3.3 代理階段

本階段根據更新后的新的訪問策略，生成重加密密鑰，進行代理重加密的操作，使原密文變為新的共享密文。不僅使得解密效率高于原本的屬性加密算法，還實現了動態共享和靈活監督的功能。

2.3.4 數據共享階段

然后得到關鍵信息M=C/Y。由于代理不知道用戶私鑰，從而保證了數據機密性，也提高了解密效率。

(3)Dfile_key(CF，hashpath)→file：最終解密算法。數據請求者按照已經得到的哈希指紋路徑hashpath去IPFS申請原始醫療數據的密文CF，然后經過驗證之后，可以用對稱密鑰file_key來解密此密文CF，最終得到原始醫療數據明文信息file。從而達到了數據共享的目的。

2.3.5 監督階段

當醫療糾紛發生時，需要監管人員來審核醫療數據。監管人員發生數據共享請求，通過階段2.3.1～階段2.3.4的代理重密鑰生成、代理重加密和解密重密文等操作，然后進行復核，將處理結果簽名后通過監督日志合約放到監督鏈上記錄，以供此案相關人員進行查看。實現監管精準化和精細化。

3 智能合約與混合共識

3.1 智能合約

智能合約主要由下面3部分組成：

(1) 解密密鑰生成合約。用戶創建一個智能合約，向區塊鏈CA發送解密密鑰生成請求。CA驗證是合法用戶后，將生成的解密密鑰，加上時間戳和密鑰哈希值，返回給用戶。用戶可以計算對比密鑰哈希，如果相等，則未被篡改，接受此解密密鑰。

(2) 代理合約。當監管人員想要訪問數據時創建一個智能合約，發送至區塊鏈代理節點。在驗證是合法用戶后，數據擁有者為其生成代理重密鑰補充智能合約，然后代理為其生成重加密密文，進行簽名。最后返回給監管人員。監管人員驗證數據完整后，用私鑰進行快速解密。

(3) 監督日志合約。當監管人員進行審核后，將處理結果進行簽名后放到監督鏈上記錄，以供此案相關人員進行查看。

具體的智能合約算法如算法1至算法3所示。

算法1解密密鑰生成DeKeyTx()

輸入：公共參數Params，主密鑰MSK，用戶屬性集S=(NATT，VATT)

輸出：解密密鑰SK

① 用戶設置限制時間T并設置合約條件：

② if當前使用時間T1

③ if 用戶是合法用戶 then

④ 1) CA產生解密密鑰SK并對SK作哈希運算；

⑤ 2) 進行簽名并提交簽名； /*供用戶接收時驗證*/

⑥ 3) 發送解密密鑰SK給用戶。

⑦ else Return⊥

⑧ end

⑨ elsethrow /*即拒絕該請求事件*/

⑩ end if

算法2代理合約ProxyTx()

輸入：數據請求者身份ID，公共參數Params，密文CT，代理密鑰RK

輸出：代理密文CT′

① 用戶設置限制時間T并設置合約條件：

② if當前使用時間T1

③ 驗證由數據擁有者生成的代理密鑰事件的簽名和用戶身份；

④ if用戶合法 && 簽名正確then

⑤ 1) 執行代理重加密算法；

⑥ 2) 給數據請求者發送重加密密文CT′。

⑦ else Return⊥

⑧ end

⑨ elsethrow /*即拒絕該請求事件*/

⑩ end if

算法3監督日志合約SupervisionLogTx()

輸入：數據請求者身份ID，事件標識Identification Index

輸出：相關信息

① 用戶設置限制時間T并設置合約條件：

② if當前使用時間T1

③ 1) 查找相關數據重密文和解密進行復核審查；

④ 2) 對結果簽名；

⑤ if 復核審查無誤then

⑥ Return ture；

⑦ else Return related data；

⑧ end

⑨ elsethrow /*即拒絕該請求事件*/

⑩ end if

3.2 混合共識

將委托權益證明(Delegated Proof of Stake，DPoS)和實用拜占庭容錯(Practical Byzantine Fault Tolerance，PBFT)相結合，提出一種改進的混合共識算法。筆者所提方案的區塊鏈節點主要分為兩大類，一類是代理節點，另一類是普通節點。由于各個醫院服務器的設備和網絡承載不同，節點的選取規則有所不同：根據全國所有醫院和醫療機構貢獻度排名，結合DPoS投票選舉前101個為代理節點，可以進行代理重加密和為用戶提供共享服務，剩下的為普通節點，可以進行排序和驗證區塊等工作。代理節點雖然不能得到有關明文的信息，但有可能是惡意的或是自身服務器存在故障從而導致數據請求者重解密失敗，此時PBFT共識可以保證整個系統不會因為個別節點故障而失效，可以容納最多1/3的作惡節點的存在。一旦發現惡意節點，利用DPoS共識可以投票來重新選取新的代理節點。每隔一段時間重新刷新貢獻排名，貢獻值排名倒數的會被撤銷代理作用從而轉變成普通節點，與此同時普通節點的前幾名可以替補轉變為代理節點。從而達到節點是動態的、可輪流當值的目的，提高系統的可靠性。具體共識過程如下：

(1) 請求階段：當數據請求者上傳請求共享數據的消息m至區塊鏈系統時，當前時間片的區塊礦工(按照以上的節點選取規則來進行DPoS投票結果輪流出塊)是此次驗證和廣播的當值代理節點。假設DPoS委托此節點進行出塊請求，并委任它為此輪共識的當值代理節點。

(2) 預準備階段：當值代理節點收到請求消息m時，則對交易進行編號i，得到預準備消息，其中H(·)是單向哈希函數，n是此輪出塊中的塊序號，s是簽名。隨后將預準備消息放入列表，準備廣播給其他節點進行驗證。

(3) 準備階段：其他節點收到當值代理節點的預準備消息后，首先驗證H(m)的合法性，然后得到準備消息，并將在整個區塊鏈網絡中進行廣播。

(4) 承諾階段：所有節點(包括當值代理節點和其他節點)收集準備消息，節點開始累加消息數量，當收到超過2f+1個不同節點的相同的準備消息后，節點將計算承諾消息并廣播。與此同時，所有節點也在收集整個網絡中的承諾消息，當所有節點收到超過2f+1個不同節點的承諾消息后，就認為該區塊已經基本達成一致，然后將塊中可以通過的交易打包成塊。

(5) 回復階段：向承諾階段執行的最后結果回復給用戶。不論哪種節點在收到某一個消息時，都會制定一個定時器；當定時到期后，如果還沒達成一致，本次共識中止丟棄。

4 安全分析

4.1 正確性驗證

Δ1=e(C0，K0)=e(gs，gαωβ1β2r+β3β4r′)=e(g，g)sαe(g，ω)s(β1β2r+β3β4r′)，

Δ2=∏i∈I{e(Ci，K1)e(Ci，1，Ki，1)e(Di，1，Ki，2)e(Ei，Ki，3)e(Ci，2，Ki，4)e(Di，2，Ki，5)}ωi=

所以有：當數據請求者滿足訪問策略時，

然后，可以解密得到關鍵信息：M=C/Y=[Me(g，g)αs]/e(g，g)αs=M。

(2) 重密文的解密正確性：

4.2 安全性證明與分析

4.2.1 安全性證明

定理 如果HCP-ABE[22]方案和IBE[27]方案是選擇明文安全的，則筆者所提方案也是選擇明文安全的。

證明：假設存在一個敵手A以不可忽略的優勢可以攻破筆者方案，那同樣也可以構造一個挑戰者B來攻破HCP-ABE方案[22]或者IBE方案[27]。

(1) 系統初始化階段

敵手A提供想挑戰的身份ID*和訪問策略A*。挑戰者B準備兩個表單列表分別用于存儲敵手A想要詢問關于重密鑰和IBE密鑰的有關信息，即L1=(Si，IDi，RK)和L2=(IDi，SKIDi)。

(2) 系統設置階段

挑戰者B給敵手A提供公開參數。首先挑戰者B向HCP-ABE方案進行公開參數查詢，獲得其公開參數pars={u，h，w，v，，g，g1，g2，g3，g4，H，e(g，g)α}，然后挑戰者B隨機選取元素γ∈Zp，并計算f=gγ。此外選取編碼函數F：GT→G。最后輸出公開參數Params={u，h，w，v，f，g，g1，g2，g3，g4，H，F，e(g，g)α}給敵手A。

(3) 密鑰查詢階段1

敵手A可以做以下3種詢問：

② 針對ABE方案。對于Si?A*，挑戰者B將查詢HCP-ABE方案的密鑰產生算法來得到有效的密鑰，最后返回給敵手A。

(4) 挑戰階段

(5) 密鑰查詢階段2

與密鑰查詢階段1類似。

(6) 猜測階段

敵手A輸出b′∈{0，1}作為對b的猜測。可以知道在Si∈A*的隨機生成重密鑰詢問階段，挑戰者B隨機選取的k0∈G，對于這樣的k0，一定會存在一個隨機元素t″∈Zp，使得k0=gαωβ1β2r+β3β4r′ft″，從而得到k6=F(e(g，g)αs′)gt″。由于其他部分都是相同的，敵手必須要區分清楚的是隨機生成的k6=F(e(g，g)αs′)gt′和按重密鑰生成算法完整格式部分k6=F(e(g，g)αs′)gt′，但對于gt′和gt″剛好為IBE方案[27]為加密的兩部分，因此敵手A要區分隨機的和按完整算法流程產生的密鑰和IBE方案具有完全相同的分布，即游戲優勢AdvA，IBE。

在整個游戲當中，挑戰者B為敵手A成功模擬筆者所提出的方案系統，概率不超過qAdvA，，IBE，其中q表示敵手A對重加密密鑰的詢問總數。因此，如果敵手A以AdvA，，BHCP-PRE的優勢成功攻破筆者所提方案的安全性，那么也就意味著挑戰者B以AdvA，，HCP-ABE=AdvA，，BHCP-PRE(1-qAdvA，，IBE)的優勢來成功攻破HCP-ABE方案的安全性。總之，如果HCP-ABE方案[22]和IBE[27]都是安全的，則筆者所提方案也是選擇明文安全的。

4.2.2 抗合謀攻擊分析

4.2.3 隱私保護

筆者提出的方案實現了以下3方面的隱私保護：

(1) 數據方面：對醫療數據進行加密后分別上傳到IPFS和區塊鏈中。代理不能得到醫療數據明文。假設存儲路徑被泄露，也只能泄露原始數據密文，不滿足訪問策略的用戶無法得到解密密鑰，此外方案也是抗合謀攻擊的，從而實現了數據隱私安全。

(2) 敏感屬性方面：屬性加密的訪問策略一般是以明文形式和數據密文一同發送，攻擊者針對于訪問策略中敏感詞匯進行猜測，就有可能會得到用戶的隱私。本方案采用部分策略隱藏的技術，將屬性分為兩部分，即屬性名索引和屬性值。隱藏了真正有關于隱私的屬性值，從而保護了用戶的敏感隱私。

(3) 身份隱私方面：是基于區塊鏈構造的方案，區塊鏈對于用戶都有唯一一對公私鑰來生成偽身份，降低了真實身份泄露的概率。此外混合共識機制可以保證整個區塊鏈系統不會因為個別惡意節點而失效，防止惡意代理訪問隱私數據的風險。

5 性能評估

5.1 功能對比

筆者提出的方案和其他數據共享方案的功能對比如表1所示。由表1可知，基于素數階群的方案大多未實現隱藏訪問策略的功能[16-17，25，27]，但訪問策略很有可能會泄露用戶隱私。文獻[22，26]可以實現一對多的數據共享，且通過隱藏訪問策略的技術實現了隱私保護。特別地，相比于合數階群方案[26]，文獻[22]不僅基于素數階群，而且基于大規模屬性集來實現，可以增強系統的靈活性與擴展性，即系統參數大小與屬性數量之間無需呈線性增長關系，屬性大小可以任意擴展。筆者提出的方案既具有與文獻[22，26]隱藏訪問策略的相同優勢，又有文獻[22]的基于素數階和大規模屬性集的優點。然而，在文獻[17，22]中，數據所有者制定的訪問策略一旦更改，整個加密方案就會面臨失效的風險。文獻[25-27]利用代理重加密技術可以解決訪問策略不可更改的問題，但文獻[27]沒有考慮到用戶的隱私保護。文中方案不僅與文獻[25-27]一樣，解決了文獻[22]中存在的以上問題，還利用隱藏部分訪問策略技術保護了數據和敏感隱私，彌補了文獻[27]的缺點。在效率方面，通過下面節5.3計算成本的分析，筆者提出的方案相比文獻[25-26]的效率較高。筆者提出的方案不僅可以克服屬性加密關于訪問策略改變導致方案會失效的現實缺點，在靈活代理共享的同時，用戶隱私也可以得到保護。

表1 功能對比

文獻[22，26-27]是基于一定理想化可信角色的方案，存在存儲中心化、共享過程中各方信任問題等挑戰。而文獻[16-17，25]都是拓展到基于區塊鏈的數據共享方案，從根本上可以解決中心化和存儲單點故障等問題，但區塊鏈由于吞吐量和擴展性較差，面對海量數據有較大的存儲壓力[17]，文獻[16，25]采用鏈下鏈上混合搭配或雙鏈存儲的設計方法，可以減緩區塊鏈存儲負擔。但文獻[25]未考慮敏感隱私的保護，文獻[16]不能實現一對多的數據共享。筆者利用屬性加密和代理重加密的技術構造算法，可以實現一對多細粒度的訪問控制、可應對訪問策略更改的動態場景、隱藏訪問策略來保護用戶敏感隱私等；面對海量數據的存儲，將算法與星際文件系統(IPFS)和區塊鏈結合，將較大的原始數據分布式存儲在IPFS里，然后將關鍵信息存儲在區塊鏈上進行下一步共享，可以有效地分配和利用存儲空間。并且設計了存儲共享鏈和監督鏈的雙鏈架構，不僅解決共享過程中的信任問題，還可以通過區塊鏈和智能合約實現有效監管的精準化和精細化，更符合動態靈活的現實共享應用場景。

5.2 存儲成本評估

由于文獻[25-26]是屬性加密和代理重加密相結合的數據共享方案，與筆者所提出的方案是最貼近的同類型共享方案。所以筆者選擇將文中方案與文獻[25-26]進行存儲成本分析對比，如表2所示。存儲成本評估主要是公開參數大小、解密密鑰長度、重密文長度方面的對比。由表2可知，文獻[25-26]的公開參數大小隨著屬性個數的增加而增加，而文中方案是基于大規模屬性集設計的，因此公開參數的大小是常量，與屬性數量多少無關，有利于系統的擴展性。此外，用戶解密密鑰長度隨屬性數目增加而增長。相比于文獻[25-26]的用戶解密密鑰長度來說，雖然文中方案密鑰長度較大，但是換來的是敏感數據隱私的保護，私鑰的抗攻擊能力更強。為換取隱私保護的安全，犧牲可接受的存儲成本是有意義的。從重密文長度來看，文中方案的重密文長度是固定的長度，相比文獻[25-26]的重密文存儲成本都要低。

表2 存儲成本比較

5.3 計算成本評估

仿真環境：使用C++編程語言在Ubuntu 18.04.1 LTS上進行仿真。計算機配置為Intel Core i7-3630QM CPU@ 2.40 GHz × 4，操作系統為Windows 7 Ultimate，64位6.1.7601，Service Pack 1。選擇調用開源密碼函數庫(Miracl庫)。在素數域Fp(p=3 mod 4)，構建橢圓曲線為Y2=X3+X，采用Type-1配對來進行密碼方案測試。由于文獻[25-26]是屬性加密和代理重加密相結合的數據共享方案，與筆者所提出的方案是最貼近的同類型共享方案。因此筆者選擇將文中方案與文獻[25-26]進行計算成本分析比較，如圖3所示。

圖3 計算成本比較

由圖3可知，在系統建立階段，文中方案的時間成本比文獻[25]少，和文獻[26]時間花費相近。但文中方案是基于大規模屬性集構建的，系統參數大小與屬性數量之間無線性增長關系，因此比文獻[25-26]系統的擴展性強。在用戶解密密鑰生成階段，文中方案所花費的時間相比文獻[25-26]較多，但是用戶密鑰是由系統CA生成頒發，無需用戶操作，而且為了實現隱藏訪問策略的功能，以部分時間為代價實現對敏感信息的保護，這是有價值的。加密階段和生成重密鑰階段是由數據所有者所執行的，對比文獻[25-26]，文中方案在這兩階段花費的時間是最少的，換句話說，文中方案減輕了用戶的加密計算成本，并且用戶只需要少量時間和簡單運算生成重密鑰，無需耗費時間和精力來進行重加密，用戶的體驗感較好。最后，相比文獻[25-26]的同類型數據共享方案，筆者所提出的方案所花費的解密時間是較少的。

(a) 重密鑰RK生成

(b) 重密文解密

從用戶角度來考慮，由圖4(a)可知，隨著屬性數目的遞增，文獻[25-26]的重密鑰生成時間逐漸增加。而文中方案的重密鑰生成時間是一個較小的固定常數值，和屬性數目無關。由圖4(b)可知，文獻[25]的重密文解密時間隨著屬性數目的遞增而線性增長，文獻[26]和文中方案的解密時間都是固定常數值，但文中方案相比文獻[26]來說重解密所需時間更少。總體來說，筆者所提方案在保證高效率的基礎上，同時又實現了更多功能。

5.4 智能合約開銷

仿真環境：筆者在64位的VMware15版虛擬機上安裝Linux系統——Ubuntu 18.04.1 LTS。由于FISCO BCOS是中國首個安全可控的開源區塊鏈技術平臺，在2017年正式對外開源。因此，利用BCOS提供的各種開發部署工具來搭建區塊鏈，來進行筆者所提方案中區塊鏈部分的實驗仿真。如圖5所示，進行了FISCO BCOS 區塊鏈平臺的安裝以及環境配置。隨后，利用Solidity語言和java語言編寫腳本對文中方案的節3.1中3個智能合約算法進行了具體編程、部署和調用，進行gas油耗開銷以及時間開銷成本的測試。

圖5 完成FISCO BCOS區塊鏈安裝——啟動并使用控制臺

5.4.1 智能合約gas消耗測試

筆者利用Solidity語言對節3.1中的智能合約內容進行編程，分別設置為解密密鑰合約(具體為設置密鑰與獲取密鑰兩部分)，代理合約(具體為生成重密鑰和進行重加密兩部分)，監督日志合約(上傳監督日志)。由于執行智能合約的每項操作都會消耗一定數量的gas，筆者隨后在測試網Remix平臺進行智能合約的部署和調用，進行gas消耗的測試。以消耗的gas為基準，一般正常范圍是幾千gas至兩萬多gas；經過測試，如表3所示，文中方案的智能合約gas油耗開銷較小，均在正常消耗范圍之內。(gas油耗指效易費用，可作為計算工作量的計數。)

表3 智能合約gas油耗開銷

5.4.2 智能合約時間開銷測試

由于測試網Remix平臺不能測試時間開銷，所以筆者使用java語言編寫腳本，在本地搭建的FISCO BCOS區塊鏈上進行對智能合約時間成本的測試，測試了智能合約100次調用的時間開銷，然后取其平均值。如圖6所示，文中方案所有智能合約的平均時間開銷較小，均不超過5 s。

圖6 智能合約的平均時間開銷測試

6 結束語

利用IPFS和關鍵信息上鏈的密文分離存儲的方法，筆者解決了集中式管理中的單點故障以及區塊鏈存儲負載過重的問題；利用隱藏訪問策略的屬性加密技術實現了保護敏感隱私的一對多靈活共享訪問控制；采用雙區塊鏈、智能合約和代理重加密結合，克服了屬性訪問策略失效問題，支持更靈活的數據監管。最后，安全性分析和性能分析表明，筆者提出的方案滿足選擇明文攻擊下的安全和抵抗合謀攻擊，在共享過程中實現了隱私保護和有效監督等功能的同時，效率高于現有的同類型數據共享方案，可應用于在有效監督下動態靈活的共享場景。