基于联盟链的安全和支持高效模糊查询的电子病历共享系统*

闫冠辰, 姜顺荣, 李胜利,2, 张启亮, 周 勇

1. 中国矿业大学 计算机科学与技术学院, 徐州 221116

2. 徐州医科大学附属医院 病案统计科, 徐州 221006

3. 徐工汉云技术股份有限公司, 徐州 221001

1 引言

电子医疗病历(electronic health record, EHR) 是一种利用数字化手段存储、管理和使用患者资料的医疗系统, 该系统可以记录患者完整的就诊医疗信息. 对于某些疾病的患者, 医生在后续的就诊过程中, 可以通过对EHR 的查询, 对病情有更加全面的了解, 从而能够进行更加高效而全面的治疗[1].

近年来, EHR 系统在全球范围内快速发展, 预计2022 年将产生超过397 亿美元的价值[2]. 在我国, EHR 系统同样发展迅速. 以江苏省为例, 截至2019 年, 75.6% 的基层医疗机构已经建立EHR 系统,78.5% 的医疗机构的信息系统已实现公共卫生服务功能[3]. 然而, Xing[3]指出, EHR 普及的背后, 依然存在着“信息孤岛” 现象, 具体原因有: (1) 数据标准不统一; (2) 没有开通数据互通的接口; (3) 缺少信息安全的保障[4]. “信息孤岛” 的存在消耗了大量存储资源, 同时也存在着数据共享上的困难[5]. 这对于患者转诊、转院极为不利, 患者新就诊的医院可能由于无法获得患者之前完整的诊疗数据而耽误治疗时机.

针对“信息孤岛” 带来的EHR 数据共享问题, 区块链提供了一种可行的解决思路. 区块链伴随着“比特币[6]” 诞生, 其作为数字货币的底层技术, 可以看作是一个去中心化的数据库, 适用于需要全局性、历史性地记录数据的场景[7], 此特点与医疗领域中共享病历的需求不谋而合. 区块链采用密码技术和共识机制, 将数据存储在一个个区块中, 再按照时间顺序将区块链接起来, 具有可追溯、难篡改等特点[8]. 通过区块链, 可以保证存储在链上的不被篡改, 即使区块链上的一小部分节点被破坏, 整个区块链系统仍可以正常运行[9].

然而, 区块链上的数据公开透明[10], 这无疑存在着数据安全的风险. 为了实现链上数据的安全共享,Niu 等人[5]结合代理重加密和可搜索加密技术,实现了关键字的安全搜索以及数据的安全共享. Zhang 等人[11]设计了基于实用拜占庭(PBFT) 算法的联盟区块链系统, 降低了算力消耗, 防止了数据泄露. Wang等人[12]基于环签名技术构建了存储数据协议, 并使用了智能合约进行访问控制. Jiang 等人[13]构建了隐匿授权方案以实现患者对数据的控制权, 并根据类型打包交易以实现数据的高效删除. Xu 等人[14]使用同态加密技术对数据进行隐私保护, 并使用智能合约对密文进行操作, 实现了自动理赔功能, 避免了隐私数据的泄露. Ren 等人[15]提出了一种指定验证者序列聚合签名方案(DVSSA), 以实现访问控制与隐私保护. 现有方案对比如表1 所示.

表1 现有方案对比Table 1 Comparison of existing schemes

上述方案解决了数据安全分享的难点, 但是模糊查询的需求没有完全实现. 关于模糊查询的必要性,Zhang 等人[16]指出, 一种疾病可能由另一种疾病引起或与之相关, 在这种情况下, 诊断的准确性受到医生获得的病人其他健康信息的数量和准确性的影响. 通过询问病人, 医生可以得到有关疾病的一些信息.然而, 这种方法不足以有效地辅助诊断, 原因有下: (1) 若两次就诊间隔过久, 病人可能会忘记一些细节,例如所服用的药物或医疗检查, 这将影响医生的诊断或治疗的精确性; (2) 由于病人的医学知识有限, 不能专业地描述诊断或治疗, 这也会影响医生的判断. 因此, 高效的模糊查询算法在诊疗中是必要的, 其可以快速调取出患者既往的诊疗记录, 帮助医生更全面了解患者的身体状况. 但目前有关这方面的工作较少, 为此需要设计合理的方案, 以实现医疗数据安全分享与高效模糊查询的双目标.

1.1 本文贡献

(1) 设计、采用统一的EHR 格式生成医疗数据, 并采用Fabric 联盟链平台存储数据, 方便数据共享;

(2) 基于SHVE 算法的特性实现高效的模糊查询, 医生可以通过此算法跨科室查询患者的诊疗信息;

(3) 改进SHVE 算法, 使之与基于密文策略属性加密(cipertext policy attribute-based encrypption,CP-ABE) 算法相结合, 并在智能合约上部署CP-ABE 算法, 实现了细粒度的访问控制;

(4) 在Fabric 联盟链平台进行了模拟测试, 实验结果表明了本方案具有可行性.

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 算法支持在加密数据上操作, 符合医疗场景中对数据安全、隐私的需求, 故本文选取此算法用于数据的加解密与查询.

2.2 区块链

区块链是一个分布式的共享账本和数据库, 具有去中心化、不可篡改、全程留痕、可以追溯、集体维护、公开透明等特点. 其结构如图1 所示.

图1 区块链结构Figure 1 Structure of blockchain

区块链可划分为公有链、私有链和联盟链[18], 其中联盟链由多个机构共同参与管理, 其中每个机构运行着一个或多个节点. 节点间的权限完全对等, 它们不需要完全互信(有一定的信任基础) 就可以直接进行交互, 并由对等节点共同记录交互信息. Hyperledger Fabric 是目前比较成熟的联盟链, 它是一个开源的企业级许可分布式账本技术(distributed ledger technology, DLT) 平台. Fabric 是私密且权限化的, 相对于允许未知身份参与网络的开放式权限系统, 它可以提供更好的数据安全性与隐私性. 由于医疗行业的数据属于敏感数据, 包含着患者的隐私, 在处理、存储过程中存在着隐私泄露的风险, 因而对平台环境的信任度需求较高. 相较于无需审核的公有链, 需要授权才可加入或退出的联盟链更加契合医疗行业, “授权”这一操作缓解了信任缺失的情况, 奠定了信任基础. 因此, 本文的方案便基于Fabric 联盟链设计.

2.3 双线性配对

一个双线性配对(bilinear pairing) 定义为e: G×G→GT, 其表示将阶为p的乘法循环群G 中的两个元素映射到同阶的乘法循环群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 基于密文策略属性加密

基于属性加密是为了解决外部存储环境中, 数据的粒度访问控制问题以及大规模用户的动态扩展问题[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 系统模型

3.1 系统设计目标

(1) 数据安全. 病历信息、就诊记录等医疗数据属于隐私信息, 此信息的泄露会对患者的正常生活造成严重且不必要的影响[22]. 同时, 医疗信息的篡改会误导后续医生的诊断, 耽误患者的病情. 因此, 本系统需要将密码学与区块链技术相结合, 在保护患者隐私信息安全的同时, 保证信息的不可篡改性.

(2) 高效的模糊查询. 对于医生来说, 患者的病史是诊疗过程中的一大利器, 医生可以通过查阅诊疗记录对患者的身体状况有更加全面的了解, 以便于快速定位病因[23]. 因此, 本系统需要设计一种支持高效模糊查询的算法, 通过此算法可以快速查询到患者在不同科室的诊疗记录.

(3) 细粒度的访问控制. 需要在隐私数据流转的关键流程处设置密码学保护, 确保数据的正确流向,实现细粒度的访问控制.

3.2 系统模型

本文提出了一种基于区块链的EHR 共享方案. 医生会基于患者的密钥对其相关的诊疗数据进行SHVE 算法的加密操作, 并采用CP-ABE 算法设置访问控制, 随后上传密文至医院数据中心, 同时上传存储凭证与访问控制信息至Fabric 联盟链网络. 在需要查阅病历的时候, 医生会向Fabric 联盟链网络发送访问控制申请, 待CP-ABE 的算法验证成功后便会生成并发送查询令牌至医院数据中心, 数据中心负责完成密文的查询匹配, 最终返回相应的结果. 系统架构如图2—3 所示, 图2 展示的是患者在同一家医院转诊的架构图, 图3 展示的是患者进行跨院转诊的架构图, 时序如图4 所示. 系统中包含5 种主要角色, 分别为:

图2 院内Figure 2 In-hospital

图3 跨院Figure 3 Cross-hospital

图4 系统时序图Figure 4 System timing diagram

(1) 患者: 负责提供加密、解密过程中的密钥.

(2) 密钥管理中心(key management center, KMC): 负责全局参数的生成, 负责流程中全部密钥的生成与分发.

(3) 医生: 负责诊疗数据的生成、加解密, 负责查询令牌的生成, 负责CP-ABE 的加密操作.

(4) 区块链: 负责诊疗数据摘要的存储, 负责CP-ABE 的验证与解密.

(5) 医院数据中心: 负责诊疗数据密文的存储与查询匹配.

3.3 攻击模型

在本文的框架中, 患者被认为是完全诚实的, 其行为均不会对整个系统产生危害. 区块链上的信息是经共识节点验证的, 因此也完全可信. 医生被认为是半诚实的, 这意味着他们在对患者的诊疗过程期间会严格保持诚实, 而在诊疗结束后, 其可能会对患者的诊疗数据感兴趣, 并利用自己的属性生成属性密钥以通过CP-ABE 的验证, 获得区块链上的存储凭证, 以及存储在医院数据中心的完整诊疗记录密文, 对于密文诊疗记录, 其可能会采用暴力破解等方式破译密码. 医院数据中心与公共网络环境被认为是完全不诚实的, 医院数据中心有可能擅自对加密的诊疗信息进行修改. 此外, 由于本方案涉及到跨院的流程, 此流程中查询令牌、诊疗数据等信息需要经过公网进行院际传输, 而公网环境对于数据传输有着较高的泄露风险.

4 系统详细设计

?

4.1 系统初始化

(3) 访问控制初始化. KMC 使用给定的安全参数β通过ABE.Setup(β) 生成主密钥A_msk 与公开参数A_PK. 对于每一个医生Di, KMC 根据其发来的属性Att_Di(见表2), 通过ABE.keyGen(A_msk,Att_Di) 方法生成属性私钥在我国医疗体系中, 医生职称分为住院医师、主治医师、副主任医师以及主任医师, 医院等级分为一、二、三级, 每级又分为甲、乙、丙三等, 其中三级医院增设特等. 本方案对这两个属性均按照由低至高的顺序(医生为住院医师至主任医师, 医院为一级丙等至三级特等) 分别编号为1 至4 和5 至14.

表2 属性定义Table 2 Definition of attribution

4.2 患者就诊

4.2.1 患者注册、就诊

患者Pi首次在医院H1就诊,H1会要求Pi办理就诊卡, 卡内包含Pi的密钥对(Pk1i ,Pk2i ,Pki)、身份证号ID_Pi等数据. 随后Pi挂号至相应科室医生D1处就诊,D1通过刷就诊卡就会得知Pi的相关信息.

诊疗结束后,D1生成诊疗记录Msgi, 其内容如表3 所示. 依照北京协和医院(三级甲等医院) 官网,可供患者挂号就诊的共计有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 医生端随机生成空间为{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 中采用双重对称加密的目的在于提高安全性, 这样即使在后续的查询操作中匹配成功, 没有密钥信息, 也无法查看明文数据.

4.2.4 访问权限设置

从冰箱取出一支保存的黑曲霉试管斜面，在超净工作台中加入无菌水，使无菌水刚好没过斜面上的全部黑曲霉，然后用接种环把黑曲霉从斜面上轻轻刮下来，制成黑曲霉孢子悬液。

就诊结束后, 系统会采用CP-ABE 算法设置访问控制, 本方案的访问策略Pi_Policy 为:

(1) 对于D_Title, 若新就诊医院的H_Title 较原医院的高, 则允许低一级编号的医生查看之前存储的信息, 例如13 级医院(三级甲等) 3 级的医生(副主任医师) 可查看12 级医院(三级乙等) 4 级的医生(主任医师) 存储的信息. 其余情况下, 高编号等级可以查看低编号等级医生存储的信息,反之不可;

(2) 对于H_Title, 就诊信息只可同等级或更高等级的医院才可查看.

系统对算法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)存入到区块链中用作凭证.

4.3 转诊/再就诊

假设患者Pi重新到医生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发送至数据中心, 数据中心接收后进行查询匹配操作.

算法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隶属于不同的医院, 上述4.3.3 与4.3.4 节的流程则需要在两个医院之间跨院进行. 针对此情形, 本文提出的方案是在数据跨院发送前, 使用接收方的公钥对数据进行加密, 同时使用发送方的私钥进行签名, 接收方在收到数据时可使用发送方的公钥进行签名验证, 验签无误后便可使用自己的私钥进行解密.

4.3.6 数据解密

算法3 返回二重对称加密数据的第一层解密结果, 即AES.enc(EK_Pi,Msgi), 随后便可使用患者的密钥Pk2i以及4.3.1 节流程中得到的随机数Msgi_r生成EK_Pi=H0(Pk2i||Msgi_r), 并进行第二重解密, 恢复之前的诊疗记录明文Msgi. 得到明文后计算H0(Msgi), 并与区块链上存储的H0(Msgi) 进行比对, 若成功, 则表明数据无误, 即可开始本次的诊疗.

5 安全性与隐私性分析

本系统在SHVE 算法与CP-ABE 算法的基础上, 结合区块链技术实现了电子病历的模糊查询、访问控制以及共享功能, SHVE 算法与CP-ABE 算法的安全性已分别在文献[16] 与文献[21] 中加以证明.

诊疗数据在上传前会经过SHVE 算法的加密处理(4.2.3 节流程), SHVE 对数据的加密算法本质上为二重AES 对称加密算法, 内外层的密钥不相关, 无法相互推导, 其中内层的密钥与患者的私钥、随机生成数相关联, 只有同时拥有这两种数据才能还原诊疗数据的明文. 随机生成数会被CP-ABE 算法加密(4.2.4 节流程), 只有当数据访问者的属性符合系统设置的属性时, 才能解密得到随机数, 但是只有随机数,没有患者的密钥, 也无法解密内层密文. 此外AES 算法多达上百位的密钥也极大降低了密文被暴力破解的可能性. 上述举措降低了数据泄露的风险, 提高了数据的安全性.

存储数据时(4.2.5 节流程), 诊疗数据的密文会被存至医院数据中心, 然而数据中心存在着被攻击的风险, 因此存入的密文数据不包含患者的隐私信息, 攻击者无法从这些数据中挖掘、分析出患者的敏感信息, 数据的隐私性得到了保证. 诊疗数据的哈希摘要被上传存储在区块链中, 区块链自身的数据结构保证了数据无法被篡改的同时, 也保证了其不可抵赖性. 当攻击者攻击存储服务器, 企图修改数据时, 任何微小的改动都会改变诊疗数据的哈希摘要, 这将会导致数据解密(4.3.6 节流程) 中的比对失败. 如果攻击者企图修改区块链中的数据, 就必须获得全网半数以上的算力(称为“51% 攻击”[24]), 此举代价极大, 且目前实现较难. 此外, Fabric 联盟链的通道技术、隐私数据技术也提供了较好的隐私保护, 攻击者无法通过区块链中的数据反推出患者的真实身份.

在查询匹配数据时(4.3.2—4.3.4 节流程), 本系统会使用SHVE 算法加密查询索引, 生成查询令牌, 并进行查询匹配. 在此过程中, 患者本人的敏感数据不会暴露, 查询成功后返回的均为加密数据, 数据的安全、隐私得到了保障.

综上, 本系统在每个可能出现数据泄露、数据隐私暴露的环节均进行了相应的防范, 并做出了对应的保护措施, 因此本系统是兼具安全性与隐私性的.

6 实验分析

本节对本文提出的方案进行数值模拟实验. 实验采用Visual Studio Code (1.57.1) 作为开发平台, 使用Golang (1.15.5) 和Java (11.0.9) 进行开发, 在个人主机中基于Hyperledger Fabric 2.0 搭建联盟链.实验运行于虚拟机中, 实验平台信息如表4 所示. 依据某二线城市三甲医院的真实数据, 该院日均就诊患者1 万人次, 日均生成诊疗数据量14 GB, 可得人均生成诊疗数据量1.4 MB. 考虑到城市以及医院等级的差异, 本实验测试4000—16 000 人次患者的相关数据, 测试源数据大小为1.4 MB.

表4 实验平台信息Table 4 Information of experimental platform

6.1 模糊查询

本节对方案内SHVE 算法的模糊查询性能进行测试. 图5 展示了不同的科室数对诊疗记录命中耗时的影响, 图中n表示诊疗记录的总个数. 可以看出, 在诊疗记录数固定的情况下, 随着所选科室数的增加,查询命中的耗时虽然一直在5—10 毫秒内小范围波动, 但其变化的趋势呈现水平状, 无明显上升趋势, 表明了模糊查询的耗时与所选择的科室数无关联; 而在所选科室数固定的情况下, 随着诊疗记录数的增加, 查询命中的耗时线性增加, 且增长幅度较缓, 在诊疗记录数分别为4000、6000、14 000 和16 000 份时, 查询的平均耗时为52.3 ms、78.6 ms、174.7 ms 和218 ms, 因此可知增速大概为130 ms/万份诊疗记录数, 此耗时增速处于较低的水平, 对于医疗行业而言是可以接受的.

图6 展示了文献[5] 所提方案与本方案在搜索阶段的耗时对比结果, 图中结果是在诊疗记录数固定为10 000 份的前提下得出的. 从图中可以看出, 在查询科室数较少的时候, 两者的耗时接近, 但随着查询科室数的增多, 对比方案的耗时呈现大幅度线性增长, 在查询科室数达到最大值37 的时候, 对比方案的耗时上探到4.7 s 左右, 远超同等状态下本文方案的耗时. 究其原因, 类似的方案因为不支持模糊匹配查询, 所以需要发送多个查询请求, 每个查询请求又需要完成一次完整查询流程, 因此耗时较高, 而本文方案支持模糊查询, 只需要发送一次查询请求就可以获得多个数据, 从而降低了查询阶段的整体耗时.

图6 模糊查询耗时对比Figure 6 Comparison of fuzzy query time consumption

综上所述, 本文方案中的模糊查询算法有着较好的性能.

6.2 链下部分

本小节对方案内的链下部分进行测试, 主要包括病历的加、解密流程. 由于本文方案的加、解密流程主要基于AES 对称加密算法设计, 常见的AES 算法包括AES-128、AES-192 与AES-256, 为了确定哪一种算法更加适合本文方案, 本部分测试分别使用这3 种方案进行本文中的加、解密操作, 测试数据大小为1.4 MB, 结果如图7 和图8 所示. 图7 展示了3 种不同的方案在本文中的20 次加、解密实验结果, 从图中可以看出, 3 种方案的加密耗时均远高于解密耗时. 在加密流程中, 3 种方案的耗时接近, 均在40—50 ms 的区间内; 在解密流程中, 3 种方案的耗时同样相近, 均未超过10 ms. 图8 展示的是20 次取样实验的平均值比对结果, 可以看出, 在分别进行加、解密操作时, 3 种方案的平均耗时几乎没有差距, 3 者的平均加密耗时为45 ms, 平均解密耗时为3.8 ms, 平均耗时误差在1 ms 以内. 通过上述实验可以看出, 3 种不同的AES 方案在本文中的时间开销相近, 因此, 为了更好的系统安全性, 本文选取密钥长度更长、加密轮数更多的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 是某真实医院的日诊疗数据量平均到每个患者的数据量, 是理想化的, 而在真实情况中, 由于患者的病症不同以及诊疗数据类型的多样性, 患者个人产生的诊疗数据量是不固定的. 若是诊疗的过程中出现了非结构化的检验结果, 例如CT 片、X 光片等, 那么此患者就会产生十几兆甚至几十兆的数据量. 本部分测试的目的就在于研究较大的数据量对本系统产生的影响. 测试从1.4 MB 的数据量开始, 逐渐增长数据量至35 MB, 每次增长后进行20 次的取样测试, 最终的结果为20 次测试的平均值, 实验结果如图9 所示. 从结果图中可以看出, 随着数据量的不断增加, 加、解密的操作耗时也以线性的方式增加, 在数据量为1.4 MB 时, 系统加密的平均耗时为45 ms, 解密的平均耗时为3.8 ms, 在数据量为35 MB 时, 系统加密的平均耗时为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 链上部分

本小节对方案内的链上部分进行测试, 包括数据上链、链上查询等流程. 本文在单机中基于Hyperledger Fabric 2.0 搭建联盟链, 链中有10 个组织(医院) 参与, 每个组织包含了1 个peer 节点, 另外还有1 个排序节点, 共计11 个节点.

首先测试数据上链与链上查询的性能. 为了保证链上数据的真实性与可信性, 对链上数据的操作需要经过区块链节点的共识操作, 这是保证区块链系统在分布式架构下数据正确可信的重要步骤. 通常情况下,共识需要区块链网络中半数以上的节点完成, 因此, 此部分测试不同的共识节点数对于系统效率的影响.

测试从6 个共识节点开始, 依次增加共识节点数至10, 假定在极限情况下, 10 个组织(医院) 的37个科室均有5 名医生向区块链发送交易, 即共有1850 条交易, 使用TAPE 测试工具[27]将这1850 条交易发送至Fabric 联盟链网络, 并循环测试20 次数据上链与链上查询的TPS (transactions per second,每秒处理的事务数), 最终的结果为20 次测试的平均值. 实验结果如图11 所示, 由于测试中每个节点均以Docker 容器的形式启动, 受制于实验机器的硬件资源, 单机同时启动全部节点消耗了大量资源, 导致虚拟机的性能下降, 故测试结果中的TPS 数值偏低, 甚至在全共识节点时TPS 骤降至28, 因此将共识节点数为6—9 的实验结果放大至图12. 从结果可以看出, 数据上链与链上查询的TPS 是非常接近的, 从数值可知其两者误差不超过1. 在共识节点增加的情况下, 交易的TPS 也在以线性的方式下降, 当6 个节点进行共识时, 两者TPS 均为64, 而在9 个节点进行共识的情况下, 两者的TPS 均降至49, 降速大概为5/共识节点. 经过分析, 推测下降的原因可能为: 节点的共识验证运算量会随着共识节点的增加而增加, 因此系统的效率也就随之下降, 不过相信若使用更高性能的机器, 或采用多机形式部署区块链网络, 其系统效率的下降速率会远低于本次实验.

图11 TPS 测试结果Figure 11 Results of TPS tests

图12 TPS 测试结果部分放大图Figure 12 Partial enlargement of TPS tests

最后测试链上CP-ABE 访问控制的部分, 通过上面的TPS 测试可以发现, 在超过半数的情况下, 共识节点数与系统效率成反比, 因此, 此部分测试选取6 个节点用作共识. 测试方法依旧为20 次的取样测试, 最终的结果为20 次测试的平均值. 经过测试, CP-ABE 的平均加密耗时为44.19 ms, 平均解密耗时为17.33 ms.

7 功能评估

本节采用对照分析的方法来评估本文提出的方案, 通过与表1 中的现有方案进行对比, 分析本文方案的特点, 评估结果如表5 所示, 表中“✓” 表示支持, “×” 表示不支持. 表中从3 个维度将本文方案与现有研究成果进行了对比, 可以看出本文方案在整体上具有一定的优势, 但是同样有许多弱点与需要改进的地方, 例如访问控制未支持属性撤销等, 这将是本文方案后续研究的方向.

表5 本文方案与现有方案对比Table 5 Comparison of our solution with existing solutions

8 总结

针对电子病历的数据安全以及共享问题, 本文设计了一个基于区块链技术的电子病历共享系统. 在数据存储方面, 链上链下双存储的方案减轻了区块链的存储压力, 并且所存数据均经过密码学技术处理, 安全性得到了保障. 在数据查询方面, 首先智能合约会进行访问权限的筛选, 控制数据的流向; 其次基于查询算法的特性, 实现了较为高效的模糊查询功能. 在数据共享方面, 统一的数据格式以及区块链技术的采用方便了电子病历在医院之间的流通. 综合对原型系统的测试与分析, 本系统具备可行性与实用性.