區塊鏈下的EMRs聚合密鑰可搜索加密方案

汪祖民，鄭 雅，高 兵+，秦 靜

(1.大連大學 信息工程學院，遼寧 大連 116622；2.大連大學 軟件學院，遼寧 大連 116622)

0 引 言

傳統的電子病歷(electronic medical records，EMRs)包括文本文檔和醫學數字成像與通信(digital imaging and communications in medicine，DICOM)，大都存儲在醫院本地服務器或云服務器，由于內部管理機制和安全性等問題人們對云服務器存儲隱私數據的信任有所動搖。為了解決上述問題，國內外學者通過在云服務器中引入各種加密機制或者與區塊鏈結合來保證數據的隱私。文獻[1-3]中提出在區塊鏈上將可搜索加密和代理重加密相結合的安全共享方案，保證EMRs的可靠共享。但是上述文獻的方案針對單關鍵字文檔的加密使得效率較低，而且在區塊鏈上存儲大量數據存在壓力過大的問題，因此在后來的研究中采取了多關鍵字加密。文獻[4-9]為提高加密效率，提出聚合密鑰加密方案，對多個關鍵字進行聚合加密，但是仍存在一些問題，例如存儲加密大都以醫院為中心，無法避免非法利用，未經授權訪問等。因此，為解決區塊鏈存儲壓力過大和共享過程安全性問題，文獻[10]提出一個基于區塊鏈的電子健康記錄數據安全存儲共享方案。將去中心化的星際文件系統(inter planetary file system，IPFS)和區塊鏈結合來存儲密文和哈希地址，結合無證書內容簽名算法來安全共享。但是無證書內容簽名算法容易隱藏敏感內容致使EMRs共享結果不準確。因此，針對現有方案中的安全性和共享效率方面的不足，提出一種區塊鏈下的EMRs聚合密鑰可搜索加密方案。

1 基礎知識

1.1 雙線性映射

(2)非退化性(Non-degenerate)：存在R，S∈G1， 使得e(x，y)≠1；

(3)可計算性(Computable)：對于任意的R，S∈G1， 存在有效算法計算e(x，y)。

1.2 相關困難性假設

定義2 決策雙線性Diffie-Hellman問題[12]

AdvDBDH(A)=Pr[A(g，ga，gb，gc，eg，gabc)=1]-
Pr[A(g，ga，gb，gc，Q)=1]≥ε

(1)

如果概率多項式時間(probabilistic polynomial time，PPT)算法沒有至少ε的優勢，則DBDH假設在G1中成立。

1.3 可搜索加密

可搜索加密中，用戶首先使用可搜索加密(searchable encryption，SE)機制對數據進行加密[13]，并將密文存儲在遠程服務器，當用戶需要搜索某個關鍵字時，可以將該關鍵字的搜索憑證發給遠程服務器，服務器將接收到的搜索憑證對每個文檔進行試探匹配，如果匹配成功，則說明該文檔中包含該關鍵字，最后遠程服務器將所有匹配成功的文檔發回給用戶。

1.4 區塊鏈

區塊鏈是分布式數據存儲、點對點傳輸、共識機制、加密算法等計算機技術的新型應用模式，由數據層、網絡層、共識層、激勵層、合約層和應用層組成。區塊鏈本質上是一個去中心化的數據庫，上鏈數據不可篡改且永久存儲。數據區塊結構如圖1所示，區塊頭通常包含前一區塊哈希地址、時間戳、隨機數以及Merkle樹等參數，區塊體包含交易數據等信息[14]。

圖1 區塊結構

1.5 IPFS

IPFS是一個點對點分布式文檔存儲模型，它定義了文檔該如何存儲、索引和傳輸，永久性去中心化存儲和共享文件[10]。IPFS可以將所有計算機設備連接到同一文檔系統，并確保文檔不被篡改。IPFS上傳的文件存放在各個分布式節點中，下載時從多個節點同時下載，最后拼接成一個完成文件，有快速、安全的特性。當患者的DICOM文檔上傳到IPFS時，返回當前文檔的唯一哈希地址，數據請求方申請時使用哈希地址就可以訪問資源，節約了區塊鏈的存儲資源。

1.6 智能合約

智能合約是在區塊鏈上自動觸發，執行合約條款的預設指令，由尼克·薩博提出。區塊鏈將智能合約的代碼和狀態作為交易保存到區塊中，實時監測已部署的智能合約動態。患者在區塊鏈中設置智能合約，一旦數據請求方正確觸發預設指令，合約自動執行，否則返回驗證失敗當其滿足執行規則時。通過一份智能合約的執行規則來對該數據進行每一次訪問[15]。智能合約原理如圖2所示。

圖2 智能合約原理

2 系統模型

本文提出的電子病歷系統中包含6個實體：醫生、患者、數據請求方、IPFS、云服務器和區塊鏈。為實現電子病歷由醫院控制向患者控制的轉變，在醫生診療完成后將EMRs反饋給患者。患者的EMRs因看病在不同醫院不同科室等因素分為多個文檔，將文檔分為DICOM和診療記錄分別存儲，針對患者診療記錄多文檔多關鍵字的情況進行加密存儲和共享。

醫生：醫生對患者的病癥進行診療并創建其個人的病歷，完成EMRs給患者。

患者：得到EMRs后，先按DICOM和診療記錄分類，再對多個診療記錄分別提取生成一系列關鍵字，生成一級聚合密鑰，然后將一級聚合密鑰提取，生成二級聚合密鑰；對診療記錄進行加密；對IPFS返回的哈希地址加密；設置智能合約來進行判斷請求者的身份，是否符合授權。

IPFS：存儲DICOM后生成唯一哈希地址輸出，一定程度上節約了存儲空間，并保證了存儲于IPFS上文檔的安全性。

云服務器：生成的密文存儲于云服務器，進行陷門匹配。

區塊鏈：將診療記錄的聚合密鑰和相對應DICOM的哈希地址加密以及密文索引構成交易單存儲于區塊鏈；在區塊鏈設置智能合約，當數據請求方正確觸發合約時，合約自動執行，否則返回驗證失敗。

數據請求方：先向區塊鏈發送一個數據請求，區塊鏈收到請求后，進行智能合約的驗證。通過驗證之后進行陷門匹配。兩次匹配成功后，獲得哈希地址和診療記錄的密文，解密獲得哈希地址，查詢IPFS中的對應的DICOM。系統模型中各實體間的作用如圖3所示。

圖3 EMRs存儲共享系統模型

其中，數據請求方先通過二級聚合密鑰生成關鍵字陷門，檢索所需文檔是否在文檔集中，再根據查驗是否與文檔中的關鍵字匹配。對于多文檔多關鍵字中的陷門匹配過程如圖4所示。

圖4 密文存儲和關鍵字陷門匹配流程

3 方案的詳細設計與驗證

(3)文檔加密算法Encrypt(gp，M)→(Cm，Cw)： 輸入文檔集M和公共參數gp。

1)關鍵字提取階段

患者先輸入文件索引Im={1，2，…，y}， 對文檔集M={m1，m2，…，my} 分類提取多個關鍵字，得到關鍵字集W={Wm1，Wm2，…，Wmz}。 其中，mi為不同醫院的病歷記錄，先對不同醫院的病歷m按科室分類，作為一層關鍵字Wmi={w1，w2，…，wy}， 再對不同科室的診療記錄提取關鍵字得到W。 將DICOM存儲于IPFS，患者將返回的哈希地址進行加密和Im構成交易單。

2)加密階段

Cmi=(C1，C2，C3)=
〈gt，e(v，gz+1-i)，mi·e(g1，gz)t〉

(2)

(3)

(4)聚合密鑰提取算法Extract(msk，W)→(Kaggm，Kagg)： 當數據請求者向患者請求相關EMRs時，患者輸入主密鑰msk和文檔關鍵字集合W， 兩級聚合密鑰的模式如圖5所示。

圖5 兩級聚合密鑰的模式

1)由msk={γ1，γ2，…，γz} 對每個文檔通過聚合密鑰生成算法生成一級聚合密鑰Kaggm1，Kaggm2，…，Kaggmz。

其中，一級聚合密鑰生成如式(4)所示

(4)

2)患者對所有文檔的聚合密鑰Kaggm進行聚合，生成二級聚合密鑰Kagg如式(5)所示。最終，輸出Kagg和Kaggm和交易單存儲于區塊鏈

(5)

3)在區塊鏈上設置智能合約，對數據請求方進行身份驗證，如果請求方無法正確觸發合約，則返回驗證失敗；如果請求方驗證通過，則獲得聚合密鑰進行陷門匹配。數據請求方將機構的唯一標識user_ID廣播到區塊鏈中，區塊鏈的每個節點都記錄生成Users_ID，節點記錄中的ID不可重復且不可篡改。當請求方申請數據時，輸入自己機構的user_ID，如果在所有節點的Users_ID記錄中查到，則身份合法，輸出“true”，否則身份不明，輸出“false”。

算法1：驗證階段智能合約算法

輸入：user_ID

輸出：true or false

(1)constract user{

(2)address user_ID;}

(3)function User() public{

(4)user_ID = msg.sender;}

(5)function TestUser(){

(6)if (user_ID = Users_ID)

(7)return true;

(8)else

(9)return false; }

T′w1=(T0，T1)=(Kaggm·(gw′i)b，gb)

(6)

(7)

(6)匹配算法Test(T′w1，T′w2，Cm，Kagg，Kaggm)→(Ii)： 數據申請方輸入陷門T′w1和T′w2， 文檔密文Cm， 聚合密鑰Kagg和Kaggm。

(8)

正確性證明

2)若wi=w′i， 則等式(8)成立，即二級關鍵字匹配成功，得到患者在不同醫院的診療記錄。通過下列等式(9)判斷關鍵字是否匹配

(9)

正確性證明

若wi=w′i， 則等式(8)和等式(9)都成立，說明陷門的關鍵字和聚合密鑰Kagg和Kaggm中的關鍵字相匹配。驗證算法正確時獲得交易單，區塊鏈上節點向數據請求方返回關鍵字索引Ii和DICOM哈希地址。若wi≠w′i， 則兩個等式都不成立，驗證算法輸出“false”，檢索失敗。

(10)

正確性證明

4 安全性分析與證明

4.1 聚合密鑰安全性分析

數據請求方的檢索安全準確，擁有聚合密鑰的數據請求方只能檢索到所需的文檔mi， 無法得到文檔集M中除mi以外的其它文檔，也無法通過二級聚合密鑰Kagg來獲得一級聚合密鑰Kaggm， 不存在獲得授權范圍之外的搜索權限。

4.1.1 擁有Kagg和Kaggm的數據請求方能進行關鍵字檢索

數據請求方獲得一級聚合密鑰Kagg和二級聚合密鑰Kaggm。 先用Kagg生成一個聚合陷門T′w2， 執行搜索驗證算法進行第一次關鍵字檢索。若檢索失敗，則輸出“false”；若檢索成功，則成功檢索所需文檔的類別，用Kaggm生成聚合陷門T′w1， 進行第二次關鍵字檢索。若檢索失敗，則輸出“false”；若檢索成功，則獲得所需文檔的密文。由等式(8)和等式(9)中的正確性證明可以看到檢索算法的正確性。因此，數據請求方得到兩級聚合密鑰后能進行關鍵字檢索，檢索是否成功取決于所需關鍵字是否和文檔關鍵字一致。

4.1.2 擁有聚合密鑰的數據請求方只能獲得所需文檔，無法獲得其它文檔

首先，本方案對患者的病歷按照醫院和科室劃分為兩級，二級聚合密鑰中涉及的文檔是一級聚合密鑰中所有文檔的分類。數據請求方進行關鍵字檢索時，首先根據二級聚合密鑰進行文檔分類的檢索，檢索成功說明患者存在某一類別的病歷記錄，檢索失敗說明患者不存在這一類別的病歷記錄。然后，通過第一次檢索的數據請求方可以進行第二次檢索。最后，兩次關鍵字檢索成功后，僅獲得和關鍵字相關的密文，無法獲得更多文檔。

4.2 密文的安全性證明

定理1 如果敵手A在一個概率多項式時間內能以不可忽略的優勢ε贏得游戲，挑戰者C以不可忽略的優勢AdvA(gp) 解決DBDH困難問題，則可證明本文方案在DBDH假設下是IND-CPA安全的。

證明：假設存在敵手A能打破方案中提出的IND-CPA安全。構造一個挑戰者C，讓C和敵手交互解決DBDH困難問題。C的最終目的是判斷對于給定的元組g，ga，gb，gc∈G1， 通過計算v的值來判斷Q=e(g，g)abc能否成立，如式(11)所示

(11)

模擬挑戰者C和敵手A之間的交互過程如下：

(2)詢問階段：

(3)挑戰階段：

敵手A決定結束詢問階段1)，會輸出挑戰的關鍵字 (w0，w1)， 并將其發送給挑戰者C。C設置可搜索加密密鑰ki=t=bc/a1+z-1。 而且，C隨機選擇u∈{0，1}， 計算Cmu=(C1，C2，C3) 如式(12)所示

(12)

(4)猜測階段：

敵手A輸出猜想u′， 如果u′=u， 則說明A挑戰成功，輸出v′=1， 意味著Q=e(g，g)abc。 如果u′≠u， 挑戰失敗，輸出v′=0， 意味著Q≠e(g，g)abc。 A獲勝的概率為Pr[u′=u|v=0]=1/2， 當u′≠u時，挑戰者C輸出猜想v′=0獲勝的概率為Pr[v′=v|v=0]=1/2。 當v=1時，敵手A挑戰成功的優勢為ε=Pr[u′=u|v=1]-1/2。 當u′=u時，挑戰者C猜想v′=1挑戰者獲勝的概率為Pr[u′=u|v=1]=ε+1/2。 挑戰者能解決DBDH困難問題的優勢如式(13)所示

(13)

5 性能分析

本節首先將本文方案與相關的EMRs共享方案在性能和計算效率方面進行詳細的比較，包括理論分析和數值分析。

5.1 理論分析

5.1.1 功能性對比

此部分從理論上對存儲、區塊鏈和多關鍵字等功能特性展開對本文方案與其它共享方案的對比分析。見表1，其中“√”表示實現此功能，“×”表示未實現此功能。

表1 不同方案的功能特性對比

文獻[3，4，6-9]僅僅使用了云服務器進行存儲。云服務器是半可信且具有好奇心的，并不總是誠實地計算并返回檢索結果的情況，所以僅用云服務器進行存儲時，由于數據中心化嚴重，分布集中且管理不當容易導致數據被泄露甚至被非法利用。IPFS具有去中心化的特點，且文檔由多個節點存儲，安全性更有保障。因此，本文方案將DICOM數據存儲于IPFS。文獻[10]中采用IPFS存儲，但隱私保護采用的方法是內容截取簽名，此方法會隱藏部分敏感信息，容易導致數據請求方搜索結果不準確。本文方案采用IPFS和云服務器聯合存儲，云服務器存儲密文，智能合約實現訪問控制，并采取兩級聚合密鑰來實現關鍵字的檢索匹配，保證了數據請求方得到所需文檔的準確性和完整性。

5.1.2 計算量分析

此部分對不同文獻中的方案的計算量進行對比。TH代表一般哈希函數運算時間，執行時間為12.573 ms，Tp代表雙線性對映射時間，執行時間為5.021 ms，Te代表指數函數運算時間，執行時間為4.888 ms。顯然，基本運算的執行時間先后排序為TH>Tp>Te。 一般哈希運算的時間遠大于另外兩個函數的運算時間，根據執行時間對不同方案的運行時間進行計算，得出的計算量見表2。

表2 不同方案的計算量對比

由表2可知，本文方案雖生成了兩級關鍵字密文和聚合密鑰，用戶需要生成兩個陷門，在檢索階段需要進行兩次陷門匹配，但是在加解密階段以及陷門生成階段的計算時間較快。在檢索階段需要經過兩次關鍵字檢索驗證，所以此階段的計算量稍高。從可搜索加密的總過程的計算量來看，本文方案在計算效率方面與文獻[6]相比具有一定的優勢，而且與文獻[7]相比，存儲共享的安全性更高。

因此，本文方案相較于其它可搜索加密方案的性能和計算效率更占優勢。

5.2 實驗分析

本節通過對文獻[6]、文獻[7]的方案和本文方案進行數值模擬實驗來分析方案的實際性能。數據模擬實驗硬件環境是Intel(R)Core i5-6700CPU；軟件環境是在Linux系統上使用PBC(pairing-based cryptography)庫，基于C語言實現文獻[6]、文獻[7]的方案和本文方案，效果如圖6～圖8所示。

圖6 文檔加密算法的時間開銷

如圖6所示，文獻[6]和文獻[7]的方案和本文方案都是多關鍵字的加密，方案中文檔的加密時間與文檔的數量都是正相關。但本文方案中文檔加密階段僅用患者的公鑰對文檔、關鍵字和哈希地址進行加密，而且沒有進行哈希運算，因此文檔加密的時間開銷遠小于文獻[6]的方案，略低于文獻[7]的方案。

圖7中由于文獻[6]的方案中陷門生成階段對關鍵字進行哈希運算，用時與關鍵字的數量正相關，而文獻[7]和本文方案中對多個文檔的關鍵字進行聚合加密，因此本文方案中陷門生成的時間開銷遠小于文獻[6]的方案。圖8中文獻[7]中的方案解密階段對區塊鏈上包含密文哈希地址和文件地址的交易進行數據驗證運算，因此本文方案文檔解密的時間開銷遠小于文獻[7]的方案。

圖7 陷門生成算法的時間開銷

圖8 密文解密算法的時間開銷

綜上所述，雖然本文方案在陷門生成算法和解密算法分別與文獻[7]和文獻[6]持平，但是本文方案在加密階段和陷門生成階段的計算效率方面與文獻[6]相比有一定的優勢，在解密方面與文獻[7]相比有一定的優勢。因此，本文所提出的多文檔多關鍵字的聚合密鑰可搜索加密方案的性能和更高的計算效率。

6 結束語

本文方案對多文檔多關鍵字的EMRs采取兩級聚合密鑰和兩級陷門實現更精確的檢索，將IPFS和云服務器結合實現安全存儲，加入智能合約實現對數據請求方的訪問控制。分析結果表明方案中的聚合密鑰具有較高的安全性，可搜索加密方案能抵抗適應性選擇攻擊，具有密文安全性，在性能和效率方面都有提高，適用于數據龐大的醫院EMRs的存儲共享。在未來的研究中，將聚合密鑰過程和密鑰管理過程更加細化，并進一步加強區塊鏈在共享過程中的作用。