技术领域
[0001] 本
发明属于计算机领域，涉及一种基于条件隐私保护的健康记录系统的安全认证方法。
背景技术
[0002] 当然个人信息的隐私保护涉及到许多方面，本方法主要针对一类应用场景来提出相对应的解决方案。在
电子健康记录记录系统中通常出现以下情况，当病人在医院看病后，医院会针对病人的病情开出病例，并对病例进行签名。之后病人需要将病例传递给医保局已达到报销生病开销的目的。因为病人需要将医院签名的病例给医保局，因此这种情况下，实际医保局也掌握了病人的生病信息，但是这种信息病人是不希望暴露的。
[0003] 首先，我们需要解决的问题是病人信息的隐私保护认证问题。此问题需要病人既可以向医保局证明自己的信息是准确的，又需要病人的信息不能泄露出来。既医保局无法向别人证明病人的病例信息，因为在传统的场景中。医保局会获得有医院签字的病例，因此医保局是具有证明病人病例信息的能
力的。
[0004] 其次，我们需要解决的问题是病人信息的打开证明问题。因为在实际场景中，当医保局后期发现病人的报销信息有误时，需要向法院证明病人所给的病例是由哪家医院所出示的。但是由于我们为了保护病人隐私导致医保局无法向法院直接证明。因此就需要有一个打开中心在这种情况下将病人的信息进行打开，已起到司法公正的作用。
发明内容
[0005] 有鉴于此，本发明的目的在于提供一种基于条件隐私保护的健康记录系统的安全认证方法，解决在电子健康记录系统中的病人信息的隐私保护认证问题、以及在此
基础上的满足病人信息的可打开证明问题。
[0006] 为达到上述目的，本发明提供如下技术方案：
[0007] 一种基于条件隐私保护的健康记录系统的安全认证方法，该方法包括以下步骤：
[0008] S1：系统初始化：系统根据安全参数生成系统公共参数；
[0009] S2：打开中心OC和医院HP初始化：打开中心和医院根据公共参数生成自己的公/私钥，打开中心的公钥用于病人对自己的签名进行转换的作用，私钥用于在出现问题时用于打开，医院的私钥用于对病人的病例进行签名；打开中心和医院添加参数(u,v,h)和w到公共参数中；
[0010] S3：医院普通签名σ生成及验证：医院通过使用自己的私钥对消息m进行签名并将此签名传递给该病例的病人，病人把签名给自己认可的验证者，验证者通过医院公钥w对签名进行验证；
[0011] S4：病人P和医保局HIB交互：病人拥有签名σ，在与医保局交互时，病人先通过打开中心公钥对签名转换，之后通过和医保局通过交互进行验证以此来证明自己拥有签名；
[0012] S5：打开中心OC打开签名：当医保局发觉自己的交互之后所确认的签名本身有问题时，通过将交互信息传递给打开中心，打开中心确认确实存在问题之后由打开中心进行打开，来知道这个签名到底是谁签署的从而找到负责人。
[0013] 可选的，所述步骤S1包括如下步骤：
[0014] S11：系统
服务器随机选择一个素数p，G和GT是两个阶为素数q的乘法循环群，g是G的生成元，双线性映射e:G×G→GT；
[0015] S12：服务器定义并生成两个哈希函数：H: 之后服务器公开公共参数params＝{G,GT,p,g,e,H}。
[0016] 可选的，所述步骤S2包括如下步骤：
[0017] S21：打开中心OC生成中心私钥/中心公钥，包括：
[0018] S211：打开中心根据所接收的公共参数随机选择一个 和并设置u,v∈G使其满足等式
[0019] S212：打开中心将msk＝(ξ1,ξ2)作为私钥保存下来，将mpk＝(u,v,h)作为公钥添加到公共参数params中；
[0020] S22：医院HP生成医院私钥/医院公钥，包括：
[0021] S221：医院根据所接收的公共参数随机选择一个 并计算w＝gr；
[0022] S222：医院将hpsk＝r作为私钥保存下来，将hppk＝w作为公钥添加到公共参数params中。
[0023] 可选的，所述步骤S3包括如下步骤：
[0024] S31：医院普通签名生成及传递，包括：
[0025] S311：医院根据私钥r和消息m计算签名
[0026] S312：医院将签名σ给自己认可的病人或普通验证者；
[0027] S32：医院HP的普通签名验证，包括：
[0028] S321：验证方V根据收到的签名σ和医院公钥w进行验证，如果通过验证则认为签名有效，否则认为无效；验证等式如下；
[0029] e(σ,wgH(m))＝e(g,g)。
[0030] 可选的，所述步骤S4包括如下步骤：
[0031] S41：病人对签名进行转换，包括：
[0032] S411：病人选取 作为转换所需要的参数；
[0033] S412：病人计算T1＝uα,T2＝vβ,T3＝σhα+β，之后再计算δ1＝H(m)α,δ2＝H(m)β；
[0034] S42：病人和医保局交互，包括：
[0035] S421：病人选取 作为交互所需要的参数；
[0036] S422：病人通过这些参数计算
[0037]
[0038]
[0039]
[0040] S423：病人将R1,R2,R3,R4,R5传递给医保局，医保局接收之后选取一个挑战值c返回给病人；
[0041] S424：病人分别计算：
[0042] sα＝rα+cα,sβ＝rβ+cβ
[0043] sH(m)＝rH(m)+cH(m)
[0044]
[0045]
[0046] 并将其发送给医保局；
[0047] S43：医保局验证过程，包括：
[0048] S431：医保局验证交互是否可以通过，如果验证通过则认为病人确实具有医院开具的病历签名，否则就不认可病人病历；验证等式如下：
[0049]
[0050]
[0051]
[0052]
[0053]
[0054] 可选的，所述步骤S5包括如下步骤：
[0055] S51：打开中心获取转换信息并进行打开，包括：
[0056] S511：当医保局发觉之前确认的签名信息本身有误时，则将T1,T2,T3发送给打开中心；
[0057] S512：打开中心获取T1,T2,T3，根据自己的私钥ξ1,ξ2对其打开，计算过程如下：
[0058]
[0059] S513：打开中心根据签名来得知此签名到底由谁签署，找到责任人。
[0060] 本发明的有益效果在于：
[0061] 在本发明中，实现了一种具有可打开能力的隐私保护认证方案，在方案中病人可以在不暴露自己病例信息的情况下，向医保局证明自己的病例是真实的是由医院所签署的。医保局得到确认后可以向病人发放医保，并且医保局并没有获取到可以向其他人证明病人信息的能力。但是当医保局发现病人的信息有误时，可以通过向打开中心
申请。在打开中心认为必要时，通过打开中心的私钥打开病人医疗信息，已达到寻找病历签署者的作用。
[0062] 本发明的其他优点、目标和特征在某种程度上将在随后的
说明书中进行阐述，并且在某种程度上，基于对下文的考察研究对本领域技术人员而言将是显而易见的，或者可以从本发明的实践中得到教导。本发明的目标和其他优点可以通过下面的说明书来实现和获得。
附图说明
[0063] 为了使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作优选的详细描述，其中：
[0064] 图1为系统模型；
[0066] 图3为系统初始化流程框图；
[0067] 图4为打开中心与医院初始化流程框图；
[0068] 图5为医院普通签名生成及验证流程框图；
[0069] 图6为病人与医保局交互流程框图；
具体实施方式
[0071] 以下通过特定的具体实例说明本发明的实施方式，本领域技术人员可由本说明书所揭露的内容轻易地了解本发明的其他优点与功效。本发明还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本发明的精神下进行各种修饰或改变。需要说明的是，以下
实施例中所提供的图示仅以示意方式说明本发明的基本构想，在不冲突的情况下，以下实施例及实施例中的特征可以相互组合。
[0072] 其中，附图仅用于示例性说明，表示的仅是示意图，而非实物图，不能理解为对本发明的限制；为了更好地说明本发明的实施例，附图某些部件会有省略、放大或缩小，并不代表实际产品的尺寸；对本领域技术人员来说，附图中某些公知结构及其说明可能省略是可以理解的。
[0073] 本发明实施例的附图中相同或相似的标号对应相同或相似的部件；在本发明的描述中，需要理解的是，若有术语“上”、“下”、“左”、“右”、“前”、“后”等指示的方位或
位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此附图中描述位置关系的用语仅用于示例性说明，不能理解为对本发明的限制，对于本领域的普通技术人员而言，可以根据具体情况理解上述术语的具体含义。
[0074] 本发明的系统模型如图1所示，该模型由三个主要部分组成，第一部分为系统服务器，系统服务器主要负责生成系统公共参数。第二部分为打开中心，打开中心主要作用是提供公钥用于病人对签名进行转换，其次是在认证发生争议时，起到一个打开原签名来寻找签名方的用途。第三部分为医院、病人、医保局，其中医院负责对病人的病情开出病历并对其进行签名，之后医院将签名交付给病人，病人可以把此签名直接交付给可信任的人进行验证。当病人希望保证自己隐私时，可以通过本方案中隐私保护认证方法与医保局进行交互，以起到病历信息的隐私保护。并且同样可以向医保局证明自己确实具有医院开出的病历签名。
[0075] 本发明提供的一种针对电子健康记录系统的具有条件隐私保护的安全认证方法流程参见图2，包括以下步骤：
[0076] S1：系统初始化：系统根据安全参数生成系统公共参数；
[0077] 进一步参见图3，所述步骤S1包括如下步骤：
[0078] S11：系统服务器随机选择一个素数p，G和GT是两个阶为素数q的乘法循环群，g是G的生成元，双线性映射e:G×G→GT；
[0079] S12：服务器定义并生成两个哈希函数：H: 之后服务器公开公共参数params＝{G,GT,p,g,e,H}；
[0080] S2：打开中心OC和医院HP初始化：打开中心和医院根据公共参数生成自己的公/私钥，打开中心的公钥用于病人对自己的签名进行转换的作用，私钥用于在出现问题时用于打开，医院的私钥用于对病人的病例进行签名。打开中心和医院添加参数(u,v,h)和w到公共参数中；
[0081] 进一步参见图4，所述步骤S2包括如下步骤：
[0082] S21：打开中心OC生成中心私钥/中心公钥，包括：
[0083] S211：打开中心根据所接收的公共参数随机选择一个 和并设置u,v∈G使其满足等式
[0084] S212：打开中心将msk＝(ξ1,ξ2)作为私钥保存下来，将mpk＝(u,v,h)作为公钥添加到公共参数params中；
[0085] S22：医院HP生成医院私钥/医院公钥，包括：
[0086] S221：医院根据所接收的公共参数随机选择一个 并计算w＝gr；
[0087] S222：医院将hpsk＝(r)作为私钥保存下来，将hppk＝(w)作为公钥添加到公共参数params中；
[0088] S3：医院普通签名σ生成及验证：医院通过使用自己的私钥对消息m进行签名并将此签名传递给该病例的病人，病人可以把签名给自己认可的验证者，验证者可以通过医院公钥w对签名进行验证；
[0089] 进一步参见图5，所述步骤S3包括如下步骤：
[0090] S31：医院普通签名生成及传递，包括：
[0091] S311：医院根据私钥r和消息m计算签名
[0092] S312：医院将签名σ给自己认可的病人或普通验证者；
[0093] S32：医院HP的普通签名验证，包括：
[0094] S321：验证方V根据收到的签名σ和医院公钥w进行验证，如果通过验证则认为签名有效，否则认为无效。验证等式如下；
[0095] e(σ,wgH(m))＝e(g,g)
[0096] S4：病人P和医保局HIB交互：病人拥有签名σ，在与医保局交互时，病人希望不暴露自己的病例信息，因此病人先通过打开中心公钥对签名转换，之后通过和医保局通过交互进行验证以此来证明自己拥有签名；
[0097] 进一步参见图6，所述步骤S4包括如下步骤：
[0098] S41：病人对签名进行转换，包括：
[0099] S411：病人选取 作为转换所需要的参数；
[0100] S412：病人计算T1＝uα,T2＝vβ,T3＝σhα+β，之后再计算δ1＝H(m)α,δ2＝H(m)β；
[0101] S42：病人和医保局交互，包括：
[0102] S421：病人选取 作为交互所需要的参数；
[0103] S422：病人通过这些参数计算
[0104]
[0105]
[0106]
[0107] S423：病人将R1,R2,R3,R4,R5传递给医保局，医保局接收之后选取一个挑战值c返回给病人；
[0108] S424：病人分别计算：
[0109] sα＝rα+cα,sβ＝rβ+cβ
[0110] sH(m)＝rH(m)+cH(m)
[0111]
[0112]
[0113] 并将其发送给医保局；
[0114] S43：医保局验证过程，包括：
[0115] S431：医保局验证交互是否可以通过，如果验证通过则认为病人确实具有医院开具的病历签名，否则就不认可病人病历。验证等式如下：
[0116]
[0117]
[0118]
[0119]
[0120]
[0121] S5：打开中心OC打开签名：当医保局发觉自己的交互之后所确认的签名本身有问题的地方时，可以通过将交互信息传递给打开中心，打开中心确认确实存在问题之后由打开中心进行打开，来知道这个签名到底是谁签署的从而找到负责人；
[0122] 进一步参见图7，所述步骤S5包括如下步骤：
[0123] S51：打开中心获取转换信息并进行打开，包括：
[0124] S511：当医保局发觉之前确认的签名信息本身有误时，则将T1,T2,T3发送给打开中心；
[0125] S512：打开中心获取T1,T2,T3，根据自己的私钥ξ1,ξ2对其打开，计算过程如下：
[0126]
[0127] S513：打开中心可以根据签名来得知此签名到底由谁签署，找到责任人；
[0128] 最后说明的是，以上实施例仅用以说明本发明的技术方案而非限制，尽管参照较佳实施例对本发明进行了详细说明，本领域的普通技术人员应当理解，可以对本发明的技术方案进行
修改或者等同替换，而不脱离本技术方案的宗旨和范围，其均应涵盖在本发明的
权利要求范围当中。
