基于聯(lián)盟鏈的安全和支持高效模糊查詢的電子病歷共享系統(tǒng)*

閆冠辰, 姜順榮, 李勝利,2, 張啟亮, 周 勇

1. 中國礦業(yè)大學 計算機科學與技術學院, 徐州 221116

2. 徐州醫(yī)科大學附屬醫(yī)院 病案統(tǒng)計科, 徐州 221006

3. 徐工漢云技術股份有限公司, 徐州 221001

1 引言

電子醫(yī)療病歷(electronic health record, EHR) 是一種利用數字化手段存儲、管理和使用患者資料的醫(yī)療系統(tǒng), 該系統(tǒng)可以記錄患者完整的就診醫(yī)療信息. 對于某些疾病的患者, 醫(yī)生在后續(xù)的就診過程中, 可以通過對EHR 的查詢, 對病情有更加全面的了解, 從而能夠進行更加高效而全面的治療[1].

近年來, EHR 系統(tǒng)在全球范圍內快速發(fā)展, 預計2022 年將產生超過397 億美元的價值[2]. 在我國, EHR 系統(tǒng)同樣發(fā)展迅速. 以江蘇省為例, 截至2019 年, 75.6% 的基層醫(yī)療機構已經建立EHR 系統(tǒng),78.5% 的醫(yī)療機構的信息系統(tǒng)已實現公共衛(wèi)生服務功能[3]. 然而, Xing[3]指出, EHR 普及的背后, 依然存在著“信息孤島” 現象, 具體原因有: (1) 數據標準不統(tǒng)一; (2) 沒有開通數據互通的接口; (3) 缺少信息安全的保障[4]. “信息孤島” 的存在消耗了大量存儲資源, 同時也存在著數據共享上的困難[5]. 這對于患者轉診、轉院極為不利, 患者新就診的醫(yī)院可能由于無法獲得患者之前完整的診療數據而耽誤治療時機.

針對“信息孤島” 帶來的EHR 數據共享問題, 區(qū)塊鏈提供了一種可行的解決思路. 區(qū)塊鏈伴隨著“比特幣[6]” 誕生, 其作為數字貨幣的底層技術, 可以看作是一個去中心化的數據庫, 適用于需要全局性、歷史性地記錄數據的場景[7], 此特點與醫(yī)療領域中共享病歷的需求不謀而合. 區(qū)塊鏈采用密碼技術和共識機制, 將數據存儲在一個個區(qū)塊中, 再按照時間順序將區(qū)塊鏈接起來, 具有可追溯、難篡改等特點[8]. 通過區(qū)塊鏈, 可以保證存儲在鏈上的不被篡改, 即使區(qū)塊鏈上的一小部分節(jié)點被破壞, 整個區(qū)塊鏈系統(tǒng)仍可以正常運行[9].

然而, 區(qū)塊鏈上的數據公開透明[10], 這無疑存在著數據安全的風險. 為了實現鏈上數據的安全共享,Niu 等人[5]結合代理重加密和可搜索加密技術,實現了關鍵字的安全搜索以及數據的安全共享. Zhang 等人[11]設計了基于實用拜占庭(PBFT) 算法的聯(lián)盟區(qū)塊鏈系統(tǒng), 降低了算力消耗, 防止了數據泄露. Wang等人[12]基于環(huán)簽名技術構建了存儲數據協(xié)議, 并使用了智能合約進行訪問控制. Jiang 等人[13]構建了隱匿授權方案以實現患者對數據的控制權, 并根據類型打包交易以實現數據的高效刪除. Xu 等人[14]使用同態(tài)加密技術對數據進行隱私保護, 并使用智能合約對密文進行操作, 實現了自動理賠功能, 避免了隱私數據的泄露. Ren 等人[15]提出了一種指定驗證者序列聚合簽名方案(DVSSA), 以實現訪問控制與隱私保護. 現有方案對比如表1 所示.

表1 現有方案對比Table 1 Comparison of existing schemes

上述方案解決了數據安全分享的難點, 但是模糊查詢的需求沒有完全實現. 關于模糊查詢的必要性,Zhang 等人[16]指出, 一種疾病可能由另一種疾病引起或與之相關, 在這種情況下, 診斷的準確性受到醫(yī)生獲得的病人其他健康信息的數量和準確性的影響. 通過詢問病人, 醫(yī)生可以得到有關疾病的一些信息.然而, 這種方法不足以有效地輔助診斷, 原因有下: (1) 若兩次就診間隔過久, 病人可能會忘記一些細節(jié),例如所服用的藥物或醫(yī)療檢查, 這將影響醫(yī)生的診斷或治療的精確性; (2) 由于病人的醫(yī)學知識有限, 不能專業(yè)地描述診斷或治療, 這也會影響醫(yī)生的判斷. 因此, 高效的模糊查詢算法在診療中是必要的, 其可以快速調取出患者既往的診療記錄, 幫助醫(yī)生更全面了解患者的身體狀況. 但目前有關這方面的工作較少, 為此需要設計合理的方案, 以實現醫(yī)療數據安全分享與高效模糊查詢的雙目標.

1.1 本文貢獻

(1) 設計、采用統(tǒng)一的EHR 格式生成醫(yī)療數據, 并采用Fabric 聯(lián)盟鏈平臺存儲數據, 方便數據共享;

(2) 基于SHVE 算法的特性實現高效的模糊查詢, 醫(yī)生可以通過此算法跨科室查詢患者的診療信息;

(3) 改進SHVE 算法, 使之與基于密文策略屬性加密(cipertext policy attribute-based encrypption,CP-ABE) 算法相結合, 并在智能合約上部署CP-ABE 算法, 實現了細粒度的訪問控制;

(4) 在Fabric 聯(lián)盟鏈平臺進行了模擬測試, 實驗結果表明了本方案具有可行性.

2 背景知識

2.1 SHVE

對稱密鑰隱藏矢量加密(SHVE)[17]是一種謂詞加密方案,并且支持在加密數據上進行查詢匹配操作.假設Γ∈{0,1}是一個有限的屬性集,* 為通配符, Γ*∈{0,1,*}, 則SHVE 包含下列算法:

SHVE.Setup(λ)→(msk,M): 輸入安全參數λ, 返回主密鑰msk, 并生成信息空間M;

SHVE.keyGen(msk,ν ∈Γ*)→sk: 輸入主密鑰msk 和包含通配符*的謂詞向量ν, 返回查詢令牌sk;

SHVE.enc(msk,μ ∈M,x ∈Γ)→c: 輸入主密鑰msk, 待加密信息μ和屬性向量x, 返回密文c;

SHVE.evaluate(sk,c)→message/⊥: 輸入查詢令牌sk 和密文c, 此算法查詢向量ν是否在密文c中. 若PSHVEν(x)=1, 則返回信息message, 否則返回⊥. 其中,PSHVEν(x) 的計算方法為:

鑒于SHVE 算法的特性, 若給定謂詞向量{1,*,0,*}, 則可以查詢到包含屬性向量為{1, 0, 0, 0}, {1,0, 0, 1}, {1, 1, 0, 0}, {1, 1, 0, 1} 的密文. 因此, 只要合理設置謂詞向量中的通配符, 就可以快速、全面地篩選出需要的數據, 達到模糊選擇的目標. 又因為SHVE 算法支持在加密數據上操作, 符合醫(yī)療場景中對數據安全、隱私的需求, 故本文選取此算法用于數據的加解密與查詢.

2.2 區(qū)塊鏈

區(qū)塊鏈是一個分布式的共享賬本和數據庫, 具有去中心化、不可篡改、全程留痕、可以追溯、集體維護、公開透明等特點. 其結構如圖1 所示.

圖1 區(qū)塊鏈結構Figure 1 Structure of blockchain

區(qū)塊鏈可劃分為公有鏈、私有鏈和聯(lián)盟鏈[18], 其中聯(lián)盟鏈由多個機構共同參與管理, 其中每個機構運行著一個或多個節(jié)點. 節(jié)點間的權限完全對等, 它們不需要完全互信(有一定的信任基礎) 就可以直接進行交互, 并由對等節(jié)點共同記錄交互信息. Hyperledger Fabric 是目前比較成熟的聯(lián)盟鏈, 它是一個開源的企業(yè)級許可分布式賬本技術(distributed ledger technology, DLT) 平臺. Fabric 是私密且權限化的, 相對于允許未知身份參與網絡的開放式權限系統(tǒng), 它可以提供更好的數據安全性與隱私性. 由于醫(yī)療行業(yè)的數據屬于敏感數據, 包含著患者的隱私, 在處理、存儲過程中存在著隱私泄露的風險, 因而對平臺環(huán)境的信任度需求較高. 相較于無需審核的公有鏈, 需要授權才可加入或退出的聯(lián)盟鏈更加契合醫(yī)療行業(yè), “授權”這一操作緩解了信任缺失的情況, 奠定了信任基礎. 因此, 本文的方案便基于Fabric 聯(lián)盟鏈設計.

2.3 雙線性配對

一個雙線性配對(bilinear pairing) 定義為e: G×G→GT, 其表示將階為p的乘法循環(huán)群G 中的兩個元素映射到同階的乘法循環(huán)群GT中. 定義g為群G 的生成元, 此配對e具有如下性質:

(1) 雙線性: 對于任意a,b ∈G 和隨機數m,n ∈Z*q,e(am,bn)=e(a,b)mn始終成立;

(2) 非退化性: 存在g1,g2∈G, 使得e(g1,g2)/=1 成立;

(3) 可計算性: 對于任意a,b ∈G,e(a,b) 是可以被計算出來的.

2.4 基于密文策略屬性加密

基于屬性加密是為了解決外部存儲環(huán)境中, 數據的粒度訪問控制問題以及大規(guī)模用戶的動態(tài)擴展問題[19], 可分為基于密鑰策略屬性加密(key policy attribute-based encryption, KP-ABE)[20]和基于密文策略屬性加密(CP-ABE)[21].

在CP-ABE 算法中, 用戶通過密鑰生成算法得到包含自己屬性的屬性密鑰, 而密文數據中包含著解密所需要的解密策略, 用戶只有在自己的屬性密鑰與密文中的解密策略完全匹配時, 才能成功解密該數據.因此, CP-ABE 算法可以用作訪問控制算法, 控制密文數據的訪問權限, 保護數據安全. CP-ABE 通常包含以下算法:

CP-ABE.Setup(λ)→(PK,MSK): 輸入安全參數λ, 該算法進行初始化, 并生成公開參數PK 和主密鑰MSK;

CP-ABE.keyGen(MSK, Att_S)→USK: 輸入主密鑰和屬性集Att_S, 返回用戶屬性密鑰USK;

CP-ABE.enc(PK, Msg,P)→c: 輸入公開參數、需要加密的數據Msg、解密策略P, 返回加密后的密文c;

CP-ABE.dec(PK,c,USK)→Msg: 輸入公開參數、密文、用戶屬性密鑰, 若是用戶屬性匹配c中的解密策略, 則可以成功解密, 返回明文Msg.

3 系統(tǒng)模型

3.1 系統(tǒng)設計目標

(1) 數據安全. 病歷信息、就診記錄等醫(yī)療數據屬于隱私信息, 此信息的泄露會對患者的正常生活造成嚴重且不必要的影響[22]. 同時, 醫(yī)療信息的篡改會誤導后續(xù)醫(yī)生的診斷, 耽誤患者的病情. 因此, 本系統(tǒng)需要將密碼學與區(qū)塊鏈技術相結合, 在保護患者隱私信息安全的同時, 保證信息的不可篡改性.

(2) 高效的模糊查詢. 對于醫(yī)生來說, 患者的病史是診療過程中的一大利器, 醫(yī)生可以通過查閱診療記錄對患者的身體狀況有更加全面的了解, 以便于快速定位病因[23]. 因此, 本系統(tǒng)需要設計一種支持高效模糊查詢的算法, 通過此算法可以快速查詢到患者在不同科室的診療記錄.

(3) 細粒度的訪問控制. 需要在隱私數據流轉的關鍵流程處設置密碼學保護, 確保數據的正確流向,實現細粒度的訪問控制.

3.2 系統(tǒng)模型

本文提出了一種基于區(qū)塊鏈的EHR 共享方案. 醫(yī)生會基于患者的密鑰對其相關的診療數據進行SHVE 算法的加密操作, 并采用CP-ABE 算法設置訪問控制, 隨后上傳密文至醫(yī)院數據中心, 同時上傳存儲憑證與訪問控制信息至Fabric 聯(lián)盟鏈網絡. 在需要查閱病歷的時候, 醫(yī)生會向Fabric 聯(lián)盟鏈網絡發(fā)送訪問控制申請, 待CP-ABE 的算法驗證成功后便會生成并發(fā)送查詢令牌至醫(yī)院數據中心, 數據中心負責完成密文的查詢匹配, 最終返回相應的結果. 系統(tǒng)架構如圖2—3 所示, 圖2 展示的是患者在同一家醫(yī)院轉診的架構圖, 圖3 展示的是患者進行跨院轉診的架構圖, 時序如圖4 所示. 系統(tǒng)中包含5 種主要角色, 分別為:

圖2 院內Figure 2 In-hospital

圖3 跨院Figure 3 Cross-hospital

圖4 系統(tǒng)時序圖Figure 4 System timing diagram

(1) 患者: 負責提供加密、解密過程中的密鑰.

(2) 密鑰管理中心(key management center, KMC): 負責全局參數的生成, 負責流程中全部密鑰的生成與分發(fā).

(3) 醫(yī)生: 負責診療數據的生成、加解密, 負責查詢令牌的生成, 負責CP-ABE 的加密操作.

(4) 區(qū)塊鏈: 負責診療數據摘要的存儲, 負責CP-ABE 的驗證與解密.

(5) 醫(yī)院數據中心: 負責診療數據密文的存儲與查詢匹配.

3.3 攻擊模型

在本文的框架中, 患者被認為是完全誠實的, 其行為均不會對整個系統(tǒng)產生危害. 區(qū)塊鏈上的信息是經共識節(jié)點驗證的, 因此也完全可信. 醫(yī)生被認為是半誠實的, 這意味著他們在對患者的診療過程期間會嚴格保持誠實, 而在診療結束后, 其可能會對患者的診療數據感興趣, 并利用自己的屬性生成屬性密鑰以通過CP-ABE 的驗證, 獲得區(qū)塊鏈上的存儲憑證, 以及存儲在醫(yī)院數據中心的完整診療記錄密文, 對于密文診療記錄, 其可能會采用暴力破解等方式破譯密碼. 醫(yī)院數據中心與公共網絡環(huán)境被認為是完全不誠實的, 醫(yī)院數據中心有可能擅自對加密的診療信息進行修改. 此外, 由于本方案涉及到跨院的流程, 此流程中查詢令牌、診療數據等信息需要經過公網進行院際傳輸, 而公網環(huán)境對于數據傳輸有著較高的泄露風險.

4 系統(tǒng)詳細設計

?

4.1 系統(tǒng)初始化

(3) 訪問控制初始化. KMC 使用給定的安全參數β通過ABE.Setup(β) 生成主密鑰A_msk 與公開參數A_PK. 對于每一個醫(yī)生Di, KMC 根據其發(fā)來的屬性Att_Di(見表2), 通過ABE.keyGen(A_msk,Att_Di) 方法生成屬性私鑰在我國醫(yī)療體系中, 醫(yī)生職稱分為住院醫(yī)師、主治醫(yī)師、副主任醫(yī)師以及主任醫(yī)師, 醫(yī)院等級分為一、二、三級, 每級又分為甲、乙、丙三等, 其中三級醫(yī)院增設特等. 本方案對這兩個屬性均按照由低至高的順序(醫(yī)生為住院醫(yī)師至主任醫(yī)師, 醫(yī)院為一級丙等至三級特等) 分別編號為1 至4 和5 至14.

表2 屬性定義Table 2 Definition of attribution

4.2 患者就診

4.2.1 患者注冊、就診

患者Pi首次在醫(yī)院H1就診,H1會要求Pi辦理就診卡, 卡內包含Pi的密鑰對(Pk1i ,Pk2i ,Pki)、身份證號ID_Pi等數據. 隨后Pi掛號至相應科室醫(yī)生D1處就診,D1通過刷就診卡就會得知Pi的相關信息.

診療結束后,D1生成診療記錄Msgi, 其內容如表3 所示. 依照北京協(xié)和醫(yī)院(三級甲等醫(yī)院) 官網,可供患者掛號就診的共計有37 個科室, 因此本方案將Tid設計為37 位的{0, 1} 序列, 每一位代表一個科室. 在某一科室就診時, 序列里對應的位置值就為1, 其余為0.

表3 Msgi 內容Table 3 Contents of Msgi

4.2.2 數據處理

(2) 對ID_Pi進行切分, 按照長度分為“6-8-4” 三個部分. 例如患者Pi的ID_Pi為“32030119 900101999X”, 可切分為“320301”, “19900101”, “999X” 三部分. 前兩個部分依照十進制轉換為二進制生成20+25 位共計45 位的{0, 1} 序列, 最后一部分按照十六進制(尾號X 視作A) 轉換為二進制生成16 位{0, 1} 序列. 因此, 患者Pi的身份證號可轉換為61 位{0, 1} 序列:

(3) 將Tid連接在上步生成的{0, 1} 序列后, 可得到最終的就診信息序列PIDi. 假設Pi此次在眼科就診, 而此科室的序列位置是第2 位, 所以Pi的PIDi為:

4.2.3 數據加密

算法1 加密算法Input: kHid, PIDi, Pk2 i , Msgi Output: SHVE 加密的密文CPi 1 醫(yī)生端隨機生成空間為{0,1}λ 的密鑰K, 并隨機生成98 個長度同于K 的串: K1 至K98, 使得K = K1 ⊕K2 ⊕···⊕K98;2 定義n ∈[1,98];3 計算c0n = F0(kHid,(PIDi)n||n)⊕Kn, c1n = F0(kHid,*||n)⊕Kn;4 選取隨機數Msgi_r ∈{0,1}λ, 計算EK_Pi = H0(Pk2 i ||Msgi_r), 以及c = AES.enc(K,AES.enc(EK_Pi,Msgi));5 得到密文CPi =({c0n,c1n},c).

算法1 中采用雙重對稱加密的目的在于提高安全性, 這樣即使在后續(xù)的查詢操作中匹配成功, 沒有密鑰信息, 也無法查看明文數據.

4.2.4 訪問權限設置

從冰箱取出一支保存的黑曲霉試管斜面，在超凈工作臺中加入無菌水，使無菌水剛好沒過斜面上的全部黑曲霉，然后用接種環(huán)把黑曲霉從斜面上輕輕刮下來，制成黑曲霉孢子懸液。

就診結束后, 系統(tǒng)會采用CP-ABE 算法設置訪問控制, 本方案的訪問策略Pi_Policy 為:

(1) 對于D_Title, 若新就診醫(yī)院的H_Title 較原醫(yī)院的高, 則允許低一級編號的醫(yī)生查看之前存儲的信息, 例如13 級醫(yī)院(三級甲等) 3 級的醫(yī)生(副主任醫(yī)師) 可查看12 級醫(yī)院(三級乙等) 4 級的醫(yī)生(主任醫(yī)師) 存儲的信息. 其余情況下, 高編號等級可以查看低編號等級醫(yī)生存儲的信息,反之不可;

(2) 對于H_Title, 就診信息只可同等級或更高等級的醫(yī)院才可查看.

系統(tǒng)對算法1 中的隨機數Msgi_r在策略Pi_Policy 下, 使用CP-ABE 的公開參數A_PK 進行加密, 得到訪問控制密文AC_Cipher←ABE.enc(A_PK,Msgi_r,Pi_Policy).

4.2.5 信息存儲、上鏈

(1) 將經過SHVE 加密后的密文CPi存入數據中心中;

(2) 計算出H0(Hid||K) 以及H0(Msgi), 并將(Pk1i ,H0(Hid||K),H0(Msgi),AC_Cipher)存入到區(qū)塊鏈中用作憑證.

4.3 轉診/再就診

假設患者Pi重新到醫(yī)生D2處就診,D2為了獲取Pi之前的診療記錄, 會通過刷Pi的就診卡獲得相關數據, 并進行如下操作.

4.3.1 訪問權限申請

(3)D2選擇想要查看的Pi之前就診過的科室, 不選擇的話默認本科室, 并在科室序列中將對應的位置設為“*”, 最后將科室序列連接在上述步驟(2) 的身份序列后. 假設D2想要查看眼科和內科的就診記錄, 而這兩個科室的序列位置為第2 位和第5 位, 因此最后得到的查詢序列sPIDi如下. 使用此方法可以選擇多個科室進行查詢, 從而實現了支持多選的模糊查詢功能.

4.3.3 查詢令牌生成

算法2 令牌生成算法Input: k′Hid, sPIDi Output: SHVE 生成的查詢令牌TKHid 1 定義n ∈[1,98];2 計算dn = F0(k′)Hid,(sPIDi)n||n;3 計算bn =■■ ■1, (sPIDi)n = *0, otherwise ;4 得到查詢令牌TKHid = ((d1,b1),··· ,(d98,b98)).

4.3.4 查詢匹配

D2將算法2 生成的查詢令牌TKHid發(fā)送至數據中心, 數據中心接收后進行查詢匹配操作.

算法3 查詢匹配算法Input: CPi, TKHid Output: AES.enc(EK_Pi,Msgi)/⊥1 計算K* = (cb11 ⊕d1)⊕(cb22 ⊕d2)⊕···⊕(cb9898 ⊕d98);2 計算H0(Hid||K*), 并檢查H0(Hid||K*) = H0(Hid||K) 是否成立, 成立則進行下一步, 否則返回⊥;3 使用K* 解密CPi 中c 的首層加密, 并返回AES.enc(EK_Pi,Msgi).

4.3.5 安全傳輸(跨院轉診附加流程)

假設D2與D1隸屬于不同的醫(yī)院, 上述4.3.3 與4.3.4 節(jié)的流程則需要在兩個醫(yī)院之間跨院進行. 針對此情形, 本文提出的方案是在數據跨院發(fā)送前, 使用接收方的公鑰對數據進行加密, 同時使用發(fā)送方的私鑰進行簽名, 接收方在收到數據時可使用發(fā)送方的公鑰進行簽名驗證, 驗簽無誤后便可使用自己的私鑰進行解密.

4.3.6 數據解密

算法3 返回二重對稱加密數據的第一層解密結果, 即AES.enc(EK_Pi,Msgi), 隨后便可使用患者的密鑰Pk2i以及4.3.1 節(jié)流程中得到的隨機數Msgi_r生成EK_Pi=H0(Pk2i||Msgi_r), 并進行第二重解密, 恢復之前的診療記錄明文Msgi. 得到明文后計算H0(Msgi), 并與區(qū)塊鏈上存儲的H0(Msgi) 進行比對, 若成功, 則表明數據無誤, 即可開始本次的診療.

5 安全性與隱私性分析

本系統(tǒng)在SHVE 算法與CP-ABE 算法的基礎上, 結合區(qū)塊鏈技術實現了電子病歷的模糊查詢、訪問控制以及共享功能, SHVE 算法與CP-ABE 算法的安全性已分別在文獻[16] 與文獻[21] 中加以證明.

診療數據在上傳前會經過SHVE 算法的加密處理(4.2.3 節(jié)流程), SHVE 對數據的加密算法本質上為二重AES 對稱加密算法, 內外層的密鑰不相關, 無法相互推導, 其中內層的密鑰與患者的私鑰、隨機生成數相關聯(lián), 只有同時擁有這兩種數據才能還原診療數據的明文. 隨機生成數會被CP-ABE 算法加密(4.2.4 節(jié)流程), 只有當數據訪問者的屬性符合系統(tǒng)設置的屬性時, 才能解密得到隨機數, 但是只有隨機數,沒有患者的密鑰, 也無法解密內層密文. 此外AES 算法多達上百位的密鑰也極大降低了密文被暴力破解的可能性. 上述舉措降低了數據泄露的風險, 提高了數據的安全性.

存儲數據時(4.2.5 節(jié)流程), 診療數據的密文會被存至醫(yī)院數據中心, 然而數據中心存在著被攻擊的風險, 因此存入的密文數據不包含患者的隱私信息, 攻擊者無法從這些數據中挖掘、分析出患者的敏感信息, 數據的隱私性得到了保證. 診療數據的哈希摘要被上傳存儲在區(qū)塊鏈中, 區(qū)塊鏈自身的數據結構保證了數據無法被篡改的同時, 也保證了其不可抵賴性. 當攻擊者攻擊存儲服務器, 企圖修改數據時, 任何微小的改動都會改變診療數據的哈希摘要, 這將會導致數據解密(4.3.6 節(jié)流程) 中的比對失敗. 如果攻擊者企圖修改區(qū)塊鏈中的數據, 就必須獲得全網半數以上的算力(稱為“51% 攻擊”[24]), 此舉代價極大, 且目前實現較難. 此外, Fabric 聯(lián)盟鏈的通道技術、隱私數據技術也提供了較好的隱私保護, 攻擊者無法通過區(qū)塊鏈中的數據反推出患者的真實身份.

在查詢匹配數據時(4.3.2—4.3.4 節(jié)流程), 本系統(tǒng)會使用SHVE 算法加密查詢索引, 生成查詢令牌, 并進行查詢匹配. 在此過程中, 患者本人的敏感數據不會暴露, 查詢成功后返回的均為加密數據, 數據的安全、隱私得到了保障.

綜上, 本系統(tǒng)在每個可能出現數據泄露、數據隱私暴露的環(huán)節(jié)均進行了相應的防范, 并做出了對應的保護措施, 因此本系統(tǒng)是兼具安全性與隱私性的.

6 實驗分析

本節(jié)對本文提出的方案進行數值模擬實驗. 實驗采用Visual Studio Code (1.57.1) 作為開發(fā)平臺, 使用Golang (1.15.5) 和Java (11.0.9) 進行開發(fā), 在個人主機中基于Hyperledger Fabric 2.0 搭建聯(lián)盟鏈.實驗運行于虛擬機中, 實驗平臺信息如表4 所示. 依據某二線城市三甲醫(yī)院的真實數據, 該院日均就診患者1 萬人次, 日均生成診療數據量14 GB, 可得人均生成診療數據量1.4 MB. 考慮到城市以及醫(yī)院等級的差異, 本實驗測試4000—16 000 人次患者的相關數據, 測試源數據大小為1.4 MB.

表4 實驗平臺信息Table 4 Information of experimental platform

6.1 模糊查詢

本節(jié)對方案內SHVE 算法的模糊查詢性能進行測試. 圖5 展示了不同的科室數對診療記錄命中耗時的影響, 圖中n表示診療記錄的總個數. 可以看出, 在診療記錄數固定的情況下, 隨著所選科室數的增加,查詢命中的耗時雖然一直在5—10 毫秒內小范圍波動, 但其變化的趨勢呈現水平狀, 無明顯上升趨勢, 表明了模糊查詢的耗時與所選擇的科室數無關聯(lián); 而在所選科室數固定的情況下, 隨著診療記錄數的增加, 查詢命中的耗時線性增加, 且增長幅度較緩, 在診療記錄數分別為4000、6000、14 000 和16 000 份時, 查詢的平均耗時為52.3 ms、78.6 ms、174.7 ms 和218 ms, 因此可知增速大概為130 ms/萬份診療記錄數, 此耗時增速處于較低的水平, 對于醫(yī)療行業(yè)而言是可以接受的.

圖6 展示了文獻[5] 所提方案與本方案在搜索階段的耗時對比結果, 圖中結果是在診療記錄數固定為10 000 份的前提下得出的. 從圖中可以看出, 在查詢科室數較少的時候, 兩者的耗時接近, 但隨著查詢科室數的增多, 對比方案的耗時呈現大幅度線性增長, 在查詢科室數達到最大值37 的時候, 對比方案的耗時上探到4.7 s 左右, 遠超同等狀態(tài)下本文方案的耗時. 究其原因, 類似的方案因為不支持模糊匹配查詢, 所以需要發(fā)送多個查詢請求, 每個查詢請求又需要完成一次完整查詢流程, 因此耗時較高, 而本文方案支持模糊查詢, 只需要發(fā)送一次查詢請求就可以獲得多個數據, 從而降低了查詢階段的整體耗時.

圖6 模糊查詢耗時對比Figure 6 Comparison of fuzzy query time consumption

綜上所述, 本文方案中的模糊查詢算法有著較好的性能.

6.2 鏈下部分

本小節(jié)對方案內的鏈下部分進行測試, 主要包括病歷的加、解密流程. 由于本文方案的加、解密流程主要基于AES 對稱加密算法設計, 常見的AES 算法包括AES-128、AES-192 與AES-256, 為了確定哪一種算法更加適合本文方案, 本部分測試分別使用這3 種方案進行本文中的加、解密操作, 測試數據大小為1.4 MB, 結果如圖7 和圖8 所示. 圖7 展示了3 種不同的方案在本文中的20 次加、解密實驗結果, 從圖中可以看出, 3 種方案的加密耗時均遠高于解密耗時. 在加密流程中, 3 種方案的耗時接近, 均在40—50 ms 的區(qū)間內; 在解密流程中, 3 種方案的耗時同樣相近, 均未超過10 ms. 圖8 展示的是20 次取樣實驗的平均值比對結果, 可以看出, 在分別進行加、解密操作時, 3 種方案的平均耗時幾乎沒有差距, 3 者的平均加密耗時為45 ms, 平均解密耗時為3.8 ms, 平均耗時誤差在1 ms 以內. 通過上述實驗可以看出, 3 種不同的AES 方案在本文中的時間開銷相近, 因此, 為了更好的系統(tǒng)安全性, 本文選取密鑰長度更長、加密輪數更多的AES-256 用于本文的加、解密流程.

圖7 20 次AES 取樣測試Figure 7 20 times sampling test of AES

圖8 AES 取樣測試平均值Figure 8 Average of AES sampling tests

接著對本文方案的魯棒性進行測驗, 上述實驗的測試數據大小1.4 MB 是某真實醫(yī)院的日診療數據量平均到每個患者的數據量, 是理想化的, 而在真實情況中, 由于患者的病癥不同以及診療數據類型的多樣性, 患者個人產生的診療數據量是不固定的. 若是診療的過程中出現了非結構化的檢驗結果, 例如CT 片、X 光片等, 那么此患者就會產生十幾兆甚至幾十兆的數據量. 本部分測試的目的就在于研究較大的數據量對本系統(tǒng)產生的影響. 測試從1.4 MB 的數據量開始, 逐漸增長數據量至35 MB, 每次增長后進行20 次的取樣測試, 最終的結果為20 次測試的平均值, 實驗結果如圖9 所示. 從結果圖中可以看出, 隨著數據量的不斷增加, 加、解密的操作耗時也以線性的方式增加, 在數據量為1.4 MB 時, 系統(tǒng)加密的平均耗時為45 ms, 解密的平均耗時為3.8 ms, 在數據量為35 MB 時, 系統(tǒng)加密的平均耗時為129 ms, 解密的平均耗時為83.6 ms, 由此可得, 加、解密的增速大概為2.5 ms/MB. 因此, 本方案在數據量不固定的情況下有較好的魯棒性.

圖9 魯棒性測試Figure 9 Test of robustness

最后進行對比測試, 選取文獻[5]、文獻[25] 中的方案作為對比. 與上述的測試流程相同, 進行20 次取樣測試, 最終的結果為20 次測試的平均值, 相關的實驗結果如圖10 所示. 從圖中可以看出, 無論是加密還是解密, 本文方案的耗時均略低于文獻[5] 的方案, 且遠低于文獻[25] 的方案. 在加密階段, 本文方案的平均耗時為45 ms, 文獻[5] 的方案平均耗時為51.97 ms, 而文獻[25] 的方案平均耗時上探至213.74 ms;在解密階段, 本文方案的平均耗時為3.8 ms, 文獻[5] 的方案平均耗時為7.83 ms, 而文獻[25] 的方案平均耗時大幅增長至50.06 ms. 經過分析, 由于文獻[25] 所提方案較其余方案使用了更多的雙線性配對操作, 根據本實驗使用的基于Java 配對的密碼學庫(JPBC) 的基準測試網頁[26], 雙線性配對操作耗時較其余操作耗時更高, 因此總體耗時數倍高于文獻[5] 所提方案與本方案.

圖10 方案對比測試Figure 10 Comparison of different solutions

綜上, 本文方案在鏈下部分有較好的性能.

6.3 鏈上部分

本小節(jié)對方案內的鏈上部分進行測試, 包括數據上鏈、鏈上查詢等流程. 本文在單機中基于Hyperledger Fabric 2.0 搭建聯(lián)盟鏈, 鏈中有10 個組織(醫(yī)院) 參與, 每個組織包含了1 個peer 節(jié)點, 另外還有1 個排序節(jié)點, 共計11 個節(jié)點.

首先測試數據上鏈與鏈上查詢的性能. 為了保證鏈上數據的真實性與可信性, 對鏈上數據的操作需要經過區(qū)塊鏈節(jié)點的共識操作, 這是保證區(qū)塊鏈系統(tǒng)在分布式架構下數據正確可信的重要步驟. 通常情況下,共識需要區(qū)塊鏈網絡中半數以上的節(jié)點完成, 因此, 此部分測試不同的共識節(jié)點數對于系統(tǒng)效率的影響.

測試從6 個共識節(jié)點開始, 依次增加共識節(jié)點數至10, 假定在極限情況下, 10 個組織(醫(yī)院) 的37個科室均有5 名醫(yī)生向區(qū)塊鏈發(fā)送交易, 即共有1850 條交易, 使用TAPE 測試工具[27]將這1850 條交易發(fā)送至Fabric 聯(lián)盟鏈網絡, 并循環(huán)測試20 次數據上鏈與鏈上查詢的TPS (transactions per second,每秒處理的事務數), 最終的結果為20 次測試的平均值. 實驗結果如圖11 所示, 由于測試中每個節(jié)點均以Docker 容器的形式啟動, 受制于實驗機器的硬件資源, 單機同時啟動全部節(jié)點消耗了大量資源, 導致虛擬機的性能下降, 故測試結果中的TPS 數值偏低, 甚至在全共識節(jié)點時TPS 驟降至28, 因此將共識節(jié)點數為6—9 的實驗結果放大至圖12. 從結果可以看出, 數據上鏈與鏈上查詢的TPS 是非常接近的, 從數值可知其兩者誤差不超過1. 在共識節(jié)點增加的情況下, 交易的TPS 也在以線性的方式下降, 當6 個節(jié)點進行共識時, 兩者TPS 均為64, 而在9 個節(jié)點進行共識的情況下, 兩者的TPS 均降至49, 降速大概為5/共識節(jié)點. 經過分析, 推測下降的原因可能為: 節(jié)點的共識驗證運算量會隨著共識節(jié)點的增加而增加, 因此系統(tǒng)的效率也就隨之下降, 不過相信若使用更高性能的機器, 或采用多機形式部署區(qū)塊鏈網絡, 其系統(tǒng)效率的下降速率會遠低于本次實驗.

圖11 TPS 測試結果Figure 11 Results of TPS tests

圖12 TPS 測試結果部分放大圖Figure 12 Partial enlargement of TPS tests

最后測試鏈上CP-ABE 訪問控制的部分, 通過上面的TPS 測試可以發(fā)現, 在超過半數的情況下, 共識節(jié)點數與系統(tǒng)效率成反比, 因此, 此部分測試選取6 個節(jié)點用作共識. 測試方法依舊為20 次的取樣測試, 最終的結果為20 次測試的平均值. 經過測試, CP-ABE 的平均加密耗時為44.19 ms, 平均解密耗時為17.33 ms.

7 功能評估

本節(jié)采用對照分析的方法來評估本文提出的方案, 通過與表1 中的現有方案進行對比, 分析本文方案的特點, 評估結果如表5 所示, 表中“?” 表示支持, “×” 表示不支持. 表中從3 個維度將本文方案與現有研究成果進行了對比, 可以看出本文方案在整體上具有一定的優(yōu)勢, 但是同樣有許多弱點與需要改進的地方, 例如訪問控制未支持屬性撤銷等, 這將是本文方案后續(xù)研究的方向.

表5 本文方案與現有方案對比Table 5 Comparison of our solution with existing solutions

8 總結

針對電子病歷的數據安全以及共享問題, 本文設計了一個基于區(qū)塊鏈技術的電子病歷共享系統(tǒng). 在數據存儲方面, 鏈上鏈下雙存儲的方案減輕了區(qū)塊鏈的存儲壓力, 并且所存數據均經過密碼學技術處理, 安全性得到了保障. 在數據查詢方面, 首先智能合約會進行訪問權限的篩選, 控制數據的流向; 其次基于查詢算法的特性, 實現了較為高效的模糊查詢功能. 在數據共享方面, 統(tǒng)一的數據格式以及區(qū)塊鏈技術的采用方便了電子病歷在醫(yī)院之間的流通. 綜合對原型系統(tǒng)的測試與分析, 本系統(tǒng)具備可行性與實用性.