CN113987443A

CN113987443A - Multi-cloud and multi-chain collaborative electronic medical data security sharing method

Info

Publication number: CN113987443A
Application number: CN202111287111.1A
Authority: CN
Inventors: 冯景瑜; 汪涛; 于婷婷; 张文波; 黄文华
Original assignee: Xian University of Posts and Telecommunications
Current assignee: Xian University of Posts and Telecommunications
Priority date: 2021-11-02
Filing date: 2021-11-02
Publication date: 2022-01-28

Abstract

A secure sharing method of multi-cloud and multi-chain collaborative electronic medical data comprises the following steps: step one, constructing a multi-cloud and multi-chain cooperative mode framework, wherein the framework is presented in a hierarchical mode and comprises a multi-cloud layer, a multi-chain layer, a user layer and a management layer; step two, a multi-anonymization medical data storage stage; step three, data projection stage on the chain; step four, a zero trust transfer access phase; when a alliance user requests to access electronic medical data, zero trust authentication is required, and then the requested medical data are obtained in a sharing pool in a confidentiality transfer mode; the method has the characteristics of anti-theft, anti-tampering, multi-anonymization of patient identity, cross-regional and cross-mechanism sharing.

Description

Multi-cloud and multi-chain collaborative electronic medical data security sharing method

Technical Field

The invention belongs to the technical field of electronic medical data sharing, and particularly relates to a multi-cloud and multi-chain collaborative electronic medical data security sharing method.

Background

The electronic medical data generally records all data of patient state change, examination report, treatment process and the like from hospitalization to treatment end. The continuous increase of digital hospitals causes electronic medical data to grow explosively and keep a higher growth speed all the time. However, the storage of the electronic medical data is mostly lack of intercommunication, and a seat information island is formed. When a patient changes from one hospital to another, all previous electronic medical data cannot be shared, which is a loss for both the patient and the hospital. The sharing of electronic medical data plays a crucial role in improving medical quality, controlling medical costs, improving the level of scientific research, and promoting the progress in the field of public health.

Electronic medical data has long been the primary target of being peered. The new outbreak of the crown epidemic situation can lead to the rapid increase of the network security risk of medical and public health departments while seriously creating global economic, political, medical and social systems, and become the main target of network attack. However, current systems of medical security defense are primarily directed to suppressing data theft from external threats. With the aging of APT attack, supply chain attack, Lesog and Trojan horse invasion means, an attacker can control a lost host in a hospital to steal and tamper electronic medical data. The existence of internal threats not only seriously affects the operation of a medical service system, but also brings a serious challenge to the safety guarantee of electronic medical data sharing.

Today, medical information systems have become the focus of national key information infrastructure protection and personal information protection. The medical data is guaranteed not to be leaked and prevented from being tampered, and effective isolated safe sharing is implemented, so that the medical data becomes a key factor for determining the success or failure of medical digitization. In view of this, a more reliable and efficient electronic medical data sharing mode is necessary to prevent the potential threat of the internal collapse host, and provide security guarantee and technical support for the digital medical industry developed vigorously in China.

With the construction of digital hospitals, Hospital information systems for realizing digital acquisition, storage, reading and retrieval of information such as characters, images, voice, data, diagrams and the like are relatively mature, and mainly include Hospital Information Systems (HIS), clinical management information systems (CIS), medical image archiving and communication systems (PACS), Laboratory Information Systems (LIS), Electronic Medical Records (EMR) and the like.

Generally, medical data generated by hospital information systems can be divided into two categories: structured and unstructured. Structured data is primarily numeric or textual data. The unstructured data refers to data such as pictures, audio, video and the like generated in the medical treatment process, such as images, B-ultrasonic, electrocardio, endoscope, operation, intensive care and the like. Currently, electronic medical data sharing mainly includes three modes, namely block chain, cloud storage and cloud chain cooperation.

The Blockchain (Blockchain) is a decentralized distributed book, does not need to cooperate with a third party organization or an administrator, all users in the chain can make decisions, and the Blockchain has a unique data trust protection mechanism and strong data tamper resistance. This provides a viable path for medical data sharing. A block chain-based shared medical data system (Xia Q I, Sifah E B, Asamoah K O, et al MeDShare: Trust-less media data sharing annular service provider via block chain [ J ]. IEEE Access,2017,5: 14757-. A Medical Data sharing Scheme (LIU J, LIANG T, SUN R, et al. APrivacy-monitoring Medical Data sharing Scheme Based on Consortium Consortium [ C ]. GLOBECOM 2020 and IEEE Global Communications conference. IEEE,2020:1-6.) with privacy protection function Based on alliance chain designs a conditional anonymity tracking mechanism to protect the privacy of users. The block chaining technique is used to protect the privacy of the patient's medical data (KUO T, OHNO-MACHADO L. Modelchain: Decentralized private-predictive healthcare predictive frame on private block networks [ J ]. arXiv predictive arXiv:1802.01746,2018), while enhancing interoperability of data among various institutions. The electronic medical records are used for sharing (the Zhai-Ping, Wang-Chi, Chenkeji, the application research of a blockchain technology in electronic medical record sharing, the institute of Western Ann electronic technology university, 2020), and a private chain and a alliance chain are constructed to respectively store the electronic medical records encrypted by users and security index records. The technical scheme includes that a searchable encryption electronic medical record data sharing scheme based on a block chain is provided for bovine gentlemen, Liuwenke, Chenlixia, Wangcolofen, Dou Xiao Ni, a searchable encryption electronic medical record data sharing scheme [ J ] communication bulletin, 2020,41(8):204 and 214) based on a union chain, a server is used for storing electronic medical records, a private chain is used for storing ciphertext hash values, and the union chain is used for storing keyword indexes, so that safe storage and sharing of the electronic medical records are finally achieved. To achieve faster block creation speed, the capacity of the blockchain is typically designed to be 1 MB. The electronic medical data includes large-sized data such as pictures, audio, and video in addition to text types, and is difficult to store in the blockchain.

By virtue of high-efficiency computing capacity and strong storage space, the cloud computing can effectively reduce storage pressure and processing pressure in the field of medical data. Patients, medical institutions and research institutions to large cooperating institutions all wish to store data they acquire in the cloud. A Medical Data Cloud platform (Sudheep K, Joseph S.View on secure Medical Big Data in Healthcare Cloud [ C ]/20195 th International Conference on Advanced Computing & Communication Systems (ICACCS). IEEE,2019:212-215) uploads the processed Medical Data set to the Cloud, thereby realizing efficient access and mobility. A cloud-based electronic medical record system (Liu Z, Weng J, Li J, et al. cloud-based electronic medical record system supporting fuzzy keyword search [ J ]. Soft Computing,2016,20(8):3243 and 3255) supports fuzzy keyword search to ensure safe sharing of data and effective utilization of electronic medical records. Zhang Kehong et al proposed a privacy protection patient medical information sharing scheme (Zhang Kehong, Wumenglong, Wangjing, etc. under the cloud environment, a secure verifiable multi-keyword search encryption scheme [ J ] in the communication bulletin, 2021,42(4):139-149.), and a dynamic searchable encryption technology was adopted to achieve high efficiency and strong privacy of shared data. A data storage and sharing method (Chen L, Zhang N, Sun H M, et al. secure search for encrypted personal health records from big data SQL databases in closed [ J ] Computing,2020,102(6): 1521-shell 1545) using a user as a center is designed based on a cloud Computing medical data sharing platform, thereby effectively protecting the safety and privacy of the medical data of the user. However, a single cloud storage still has many defects, for example, a cloud-based storage scheme still depends on a service provider greatly, and if an attack is made on the cloud service provider, data leakage is likely to be caused. A medical data storage platform with a multi-cloud framework (Cao R, Tang Z, Liu C, et al. A scalable storage architecture for closed-supported media Internet of Things [ J ]. IEEE Internet of Things Journal,2019,7(3):1641-1654.) solves the problem of resource management among a plurality of medical cloud platforms. He Xiuli et al proposed a hybrid cloud-based medical data sharing architecture (He Xiuli, Ningzhiyuan, Chenghua, etc.. cloud and fog network oriented to medical big data and its distributed computing scheme [ J ]. Sigan university of transportation proceedings, 2016,50(10):71-77.DOI:10.7652/xjtuxb201610011.) that enhances interoperability in the medical data sharing process. However, peer-to-peer networks and cloud environments do not completely avoid the risk of single point failures and potential attacks on centralized storage.

The block chain and the cloud are organically fused, so that the method has great potential in the aspects of performance enhancement, safety and privacy improvement. Some related researchers have begun to propose a combination of blockchains and cloud storage to enable secure sharing of medical data. A privacy protection scheme (HUANG H, ZHU P, XIAO F, et al. A block-based scheme for privacy-preserving and Security sharing of media data [ J ]. Computers & Security,2020,99:102010) based on a block chain stores medical data of a patient in a cloud to reduce storage pressure, and data indexes are stored in the block chain in a hash pointer mode, thereby realizing safe sharing of the medical data. A collaboration model (SHEN M, DUAN J, ZHU L, et al. Block-based in-resources for secure and collectible data sharing in multiple groups [ J ]. IEEE Journal on Selected Areas in Communications,2020,38(6):1229-1241) includes data owners, blockchain miners and third parties, stores data in respective private or public clouds, provides access rights to each participant by using federation chain authorization, and ensures the security of data privacy. A new framework of cloud-assisted medical data storage and sharing with privacy protection and data security based on a federation block chain (Wang Y, Zhang A, Zhang P, et al. cloud-assisted EHR sharing with security and privacy preservation view a social security block [ J ]. IEEE Access,2019,7: 136704-. A concept of continuous dynamic Health data sharing for personal (ZHENGN X, MUKKAMALA R, VATRAPU R, et al. blocchain-based personal Health data sharing system using closed storage [ C ].2018IEEE 20th International Conference on e-Health Networking, Applications and Services (Health). IEEE,2018:1-6.) with block chaining technique to assist cloud storage, shares Health related information in a safe and transparent way. After the cloud chain is coordinated, if the medical data is stored in the public cloud, the attack problem faced by the cloud service provider still exists. In addition, the block chain assists in cloud storage, privacy protection and access control are only well done, and although the safety of medical data is improved, effective implementation of sharing is still difficult to guarantee. Considering the blockchain assisted cloud storage query, cloud storage locations of medical data can be searched on the blockchain. However, if there is only one block chain in the network, the single-chain mixed type recording situation is easy to occur, which will cause the query efficiency to be low.

Currently, the alliance of medical institutions will face some technical problems when sharing medical data, such as:

1) public cloud storage security relies on cloud service providers, and if the cloud service providers are attacked, the risks of stealing and leaking medical data are caused.

2) The existing related work mainly focuses on a single cloud + single chain cooperative mode or a multi-cloud + single chain cooperative mode. The medical data is stored in the single cloud mode, so that the problem of single-point failure is easy to occur, and electronic medical data leakage is easy to occur due to attack.

3) At present, the block chain assisted cloud storage only performs privacy protection and access control, and although the security of medical data is improved, effective implementation of sharing is still difficult to guarantee.

4) If only one blockchain exists in the network, single-chain mixed type records are easy to appear, and the query efficiency is low.

Disclosure of Invention

In order to overcome the defects of the prior art, the invention aims to provide a secure sharing method of multi-cloud and multi-chain cooperative electronic medical data, which has the characteristics of anti-theft, anti-tampering, multi-anonymization of patient identity, cross-regional and cross-institution sharing.

In order to achieve the purpose, the invention adopts the technical scheme that: a secure sharing method of multi-cloud and multi-chain collaborative electronic medical data comprises the following steps:

step one, constructing a multi-cloud and multi-chain cooperative mode framework, wherein the framework is presented in a hierarchical mode and comprises a multi-cloud layer, a multi-chain layer, a user layer and a management layer;

multi-cloud layer: each hospital has a proprietary cloud that stores the various types of medical data it generates. Medical data in the private cloud can be directly accessed locally, Alliance Users (AUs) cannot be directly accessed, and only data encryption can be put into a sharing pool for obtaining;

multi-chain layer: the hospital provides medical departments for outpatient service, emergency treatment, hospitalization, operation and examination, and in the medical service process of the patients in the departments, the generated medical data can be respectively projected to an outpatient department block chain, an emergency treatment block chain, an accommodation department block chain, an operation block chain and an examination block chain, and a block chain for recording data access logs and user behaviors is added to form a multi-chain distinguishing and recording mode;

and (3) a user layer: the alliance users comprise hospitals, medical research institutes, law enforcement departments and insurance companies, the hospitals play the roles of contributors and visitors in medical data sharing, also play the roles of block generation and verification, have the functions of block chain miners, the medical research institutes can access data after desensitization processing of patient information, the data are used for scientific research, when doctor-patient disputes occur, the law enforcement departments can intervene to access the medical data, and when medical insurance compensation is confirmed, the insurance companies can partially access the medical data;

and (3) a management layer: the system consists of a digital certificate issuing mechanism, a secret key management mechanism, a management certificate revocation list, an anonymous server and a data sharing manager authentication system, and is deployed on a plurality of servers of a health administration mechanism, a management layer only executes authentication and authorization functions, does not store any medical data, and can effectively reduce the load pressure of the system; the digital certificate issuing authority is responsible for applying and issuing digital certificates of the alliance users; the key management mechanism is responsible for permanent keys and zero-time keys of the alliance users; the anonymous server is responsible for anonymizing the identity of the patient and protecting the identity privacy of the patient; when a alliance user requests to access medical data, a data sharing manager not only verifies a digital certificate of the alliance at a digital certificate authority, but also checks whether the digital certificate is invalid on a management certificate revocation list, so that the digital certificate can pass authentication and identity confirmation, and corresponding access rights are given;

step two, a multi-anonymization medical data storage stage

The method for storing the multiple anonymized medical data comprises the following three stages: patient identity de-anonymization, private cloud encrypted storage and on-chain data projection; introducing multi-anonymization storage, wherein each patient can obtain an anonymous identity when visiting a hospital in the medical institution alliance, and the anonymous identities obtained in different hospitals are not repeated;

step three, on-chain data projection stage

HBM_kWill EMD_jkExtracted as projection DS_jk＝{PID_jk,HBM_k,C_jk,sp_jk,E_PKj(access_jk),Sig_SKk(EMD_jk),Sig_SKj(EMD_jk),AD_jk,mdt_jkAnd packed into corresponding on-chain blocks, sp_jkIs EMD_jkStorage path of E_PKj(access_jk) Is EMD_jkThe federation user, with patient knowledge and permission, uses the private key to decrypt E_PKj(access_jk) Later, only has an opportunity to access the EMD_jk，Sig_SKk(EMD_jk),Sig_SKj(EMD_jk) Are HBM respectively_kAnd patient to EMD_jkSignature, AD_jkFor EMD_jkThe summary information description of (1);

step four, zero trust transfer access phase

When the alliance user requests to access the electronic medical data, the alliance user follows the zero trust thought of never trust and always authentication, a data sharing manager, a patient and a hospital where the data are located are linked to perform a series of authentication, encryption and decryption operations, the medical data requested to be accessed are transferred to a sharing pool, after the access is completed, the data in the sharing pool are automatically destroyed,

the core component of the zero trust authentication can be embedded into a data sharing manager of a management layer of a medical institution alliance, and mainly comprises a zero trust gateway, a zero trust authentication engine, a zero trust access control engine and a zero trust audit engine.

The patient identity multi-anonymization comprises the following steps:

step1, selecting a random data r by the patient_jkAs an anonymity parameter, an anonymity service request AR [ ID ] is issued to an anonymity server_j]＝E_PKAS(r_jk||ID_j||Sig_SKj(r_jk)||iat₁) Wherein PKAS is the public key of anonymous server, Sig_SKj(r_jk) Is a patient pair r_jkSKj is the private key of the patient, iat₁For the time stamp of the request message, the anonymity server holds an anonymity parameter List XI for the patient_jChecking r_jkWhether or not in xi_jIn the medical institution alliance, anonymous identity repetition of patients on the medical institution alliance is mainly avoided; if r is_jk∈Ξ_jThe anonymizing server asks the patient for reselectionA random number is selected and the anonymous service request is resent until it is not repeated, if so

Anonymous server computing identity anonymous PID_jk＝h_A(ID_j*r_jk) Wherein h is_A(.) is a hash function performing anonymous operation, having non-invertibility and collision resistance, and anonymous server sends anonymous service response SR [ AS ] to patient]＝E_PKj(PID_jk||Sig_SKAS(PID_jk)||iat₂) Wherein PKj is the public key of the patient, Sig_SKAS(PID_jk) For anonymous server pair PID_jkSKAS is the private key of the anonymous server iat₂A timestamp for the response message;

step2, patient decrypts ASR with SKj [ anonymous Server ]]To obtain an anonymous identity PID_jkH, a collection of hospitals over a federation of medical institutions { HBM₁,…,HBM_k,…,HBM_hThe anonymous server keeps a list of anonymous identities for the patient denoted as Γ_jAlgorithm 1 can be run at the anonymity server to achieve patient identity de-anonymization; having anonymous identity, the patient goes to HBM_kHospitalizing, only anonymous identity authentication is needed;

the algorithm 1 is as follows: entering H, xi_j,Γ_j,ID_jFirst, m is initialized to 0, Γ_jIs composed of

HBM when patient goes to certain hospital_kAt the time of hospitalization, the patient first selects a random number r_jkAs an anonymity parameter, if r_jkHaving existed in the anonymous parameter List xi_jIn (1), the patient must reselect a new r_jk(ii) a Otherwise will r_jkPut into xi_jAnd calculating the HBM of the patient_kAnonymous identity PID in_jk＝h_A(ID_j*r_jk) Finally, it is applied to HBM_kThe anonymous identity in (a) is added to an anonymous identity list Γ held by the patient_jFor the medical alliance machineEach hospital in the structure performs cyclic calculation, and finally outputs an anonymous identity list gamma of the patient_jWhich contains different anonymous identity information that the patient has in all hospitals.

The anonymous identity authentication specifically comprises the following steps:

step1, patient is administered to HBM_kSending anonymous identity docket AIB [ ID ]_j]＝E_PKk(PID_j||Sig_SKj(PID_j)||pvt₁) Wherein PKk is HBM_kOf public key, Sig_SKj(PID_jk) For patient to PID_jkSignature of, pvt₁A timestamp for the docket message;

step2, HBM_kSending AIV HBM to anonymous server for anonymous identity verification of patient_k]＝E_PKAS(PID_jk||||Sig_SKk(PID_jk)||pvt₂) Wherein, Sig_SKk(PID_jk) Is HBM_kTo PID_jkSignature of SK_kIs HBM_kPrivate key of (1), pvt₂A timestamp for the verification message;

step3, the anonymous server is arranged in the gamma_jUp-verification PID_jkIf PID exists_jk∈Γ_j

Verification result v

_jk1 if not, v_jk0, anonymous Server to HBM_kReturning anonymous identity confirmation AIC AS]＝E_PKk(v_jk||Sig_SKAS(v_jk)||pvt₃) Wherein, Sig_SKAS(v_jk) AS to v_jkSignature of, pvt₃A timestamp for the verification message;

step4, HBM_kAIC anonymous Server decrypted with SKk]After, if v_jkIf 1, then use PID_jkAnonymizing the patient to store medical data, if v_jk0, patients in HBM_kThe medical service application is difficult to pass;

the patient is in HBM_kAfter the medical treatment is finished, the generated medical data MD_jk＝{C_jk,Data_jk,mdt_jkHas to be stored encrypted to the PCloud_kWherein, C_jkThe value range Λ ═ 1,2,3,4,5 corresponds to { outpatient service, emergency treatment, hospitalization, operation, examination }, Data, respectively_jkAll electronic medical records, treatment records, diagnosis reports, C, generated during the patient's visit_jkMay take a subset or a full set of Λ, mdt_jkIs MD_jkThe generation time of (c);

for PCloud_kLocal access to medical data, HBM_kHas direct access rights and the patient is going to the HBM_kApplication to access, and thus, available PK_kEncrypted MD_jkIs denoted as EMD_jkIf the alliance user is not authorized, it is difficult to decrypt the EMD_jkAnd obtaining MD_jkTherefore, the privacy of the patient and the safety of medical data sharing are effectively guaranteed.

In the step, the zero trust transfer access comprises the following six stages:

and (3) boundary control strategy: zero trust gateway judgment AU_iTo access the data. If the trust is reasonable, forwarding the trust to a zero trust authentication engine;

and (3) authentication strategy: zero trust authentication Engine always to AU_iChecking the identity of the user, and sending an authentication result to a zero trust access control engine;

access arbitration policy: when the authentication result reaches the access control engine, performing access control arbitration according to a preset strategy set;

and (3) auditing strategy: and the zero trust audit engine performs abnormal audit according to the judgment result. If the security is ensured, the zero trust gateway is informed to give access authority;

and (3) authorization policy: zero trust gateway from AU_iOf the respective right ar granted in the set of access rights Σ_iThe access authority set Σ ═ 1,2,3,4, } corresponds to { high, medium, low }, respectively, high authority means that all electronic medical data of a patient can be accessed, high authority can access part of the data, medium authority can access desensitized medical data, low authority can access only limited medical data such as a diagnosis certificate, an electronic invoice, a charge detail, and the like, and meanwhile, the zero trust gateway relies on PID_jkAssociating out patient's post at ASMultiple anonymous identities exist, then, search is simultaneously expanded on multiple block chains according to the type of the requested data, and the inquired projection data is loaded to the search result sr_iIn, feed back to AU_i；

Transfer sharing strategy: AU (AU)_iAccording to the projection data in the search result, the requested electronic medical data is found to be positioned in the HBM_pAfter the processing, starting the confidentiality transfer access control protocol immediately, and according to the search result sr_iAlthough the federation user can know the storage path, abstract information, access password and the like of the requested data, the federation user cannot directly access the data, and the authorization ar is required_iAnd sr_iThe authentication is sent to a hospital where the electronic medical data is located, the authorization of the alliance user is confirmed to be correct from the zero trust gateway, and the hospital selects a random number as a temporary symmetric key and sends the temporary symmetric key to the alliance user; then, the hospital downloads the requested electronic medical data in the private cloud, decrypts the electronic medical data by using a private key of the hospital, encrypts the electronic medical data by using a temporary symmetric key and forwards the electronic medical data to the sharing pool; finally, the alliance user shows authorization, obtains the electronic medical data in the sharing pool and decrypts the electronic medical data by using the temporary symmetric key; once the access is completed, the data in the shared pool can be destroyed immediately; the access request sent by the alliance user is completed cooperatively by an authentication system deployed in a management layer.

The authentication process of the access request comprises the following steps:

Step1，AU_isending an access request AR [ AU ] to DSM_i]＝E_PKDSM(ara_i||CA_i||HBM_k||PID_jk||Sig_SKi(ara_i)||art₁) Wherein ara_iFor access request applications, CA_iIs AU_iThe digital certificate of (1). If AU_iIs simply HBM_kItself, then CA_i＝CA_k，PK_DSMPublic keys DSM, Sig for DSM_SKi(ara_i)AU_iTo ara_iSignature, art₁A timestamp for the request message;

step2, DSM verifies CA at CA_iAnd examining CA on CRL_iIf it is invalid, if true, then authentication is carried outBy, then, confirming CA_iWhether or not equal to CA_kIf CA_i＝CA_kDirectly jumping to Step5, otherwise, continuing to execute the next Step;

step3 DSM-to-HBM_kSending an authentication request VR DSM]＝E_PKk(ara_i||CA_i||PID_jk||Sig_SKDSM(ara_i)||art₂) Wherein SK_DSMBeing the private key, Sig, of DSM_SKDSM(ara_i) For DSM to ara_iSignature, art₂A timestamp for the request message;

Step4，HBM_kreturning an authentication acknowledgment VC HBM to DSM_k]＝E_PKDSM(sh_ik||CA_k||PID_jk||Sig_SKk(sh_ik)||art₃) If, HBM_kConfirmation of being AU_iDepends on the hospital, then sh_ikOn the contrary, sh_ik＝0。Sig_SKk(sh_ik) Is HBM_kTo sh_ikSignature, art₃A timestamp for the acknowledgment message;

step5, if CA_i＝CA_kOr sh_ik0, DSM to AU_iReturning an access request response ARR DSM]＝E_PKi(ar_i||sr_i||CA_i||Sig_SKDSM(ar_i)||Sig_SKDSM(sr_i)||art₄) Wherein, ar_iFor access rights, sr_iFor DSM according to ara_iDSM can rely on PID for search results queried on blockchain_jkAll multi-anonymous identities of John are correlated at the AS, then search is simultaneously expanded on a plurality of block chains according to the type of the requested data, and the inquired projection data are loaded to sr_iIn, Sig_SKDSM(ar_i)、Sig_SKDSM(sr_i) Respectively DSM pair ar_iAnd sr_iSignature, art₄A timestamp for the response message;

AU_iaccording to the projection data in the search result, the medical data requested by the search result is found to be positioned in the HBM_pAfter processing, the confidential transit access control is immediately startedAnd (4) protocol.

The implementation of the confidentiality transit access control protocol comprises the following steps:

Step1，AU_ito HBM_pSending AN Access requirement AN [ AU ]_i]＝E_PKp(ar_i||ara_i||PID_jp||Sig_SKi(ar_i)||Sig_SKi(ara_i)||crt₁) Wherein PKp is HBM_pPublic key, PID_jpFor John at HBM given in search results_pAnonymous identity of (Sig)_SKi(ar_i)、Sig_SKi(ara_i) Are respectively AU_iTo ar_iAnd ara_iSignature, crt₁A timestamp for the demand message;

Step2，HBM_psending authorization verification RV [ HBM ] to DSM_p]＝E_PKDSM(ar_i||HBM_p||PID_jp||Sig_SKp(ar_i)||crt₂) Wherein SKp is HBM_pPrivate key of (8), Sig_SKp(ar_i) Is HBM_pTo ar_iSignature, art₂A timestamp for the verification message;

step3 DSM-to-HBM_pReturn authorization confirmation RC DSM]＝E_PKp(rc_i||HBM_p||PID_jp||Sig_SKDSM(rc_i)||crt₃) If, DSM validates ar_iEffective, then rc _i1, otherwise, rc_i＝0，Sig_SKDSM(rc_i) As DSM vs rc_iSignature, crt₃A timestamp for the acknowledgment message;

step4 if rc_i＝1，HBM_pTo PCloud_pSending data call DT [ HBM ] about patient_p]＝E_PKcp(access_jp||ara_i||HBM_p||PID_jp||Sig_SKp(access_jp)||Sig_SKp(ara_i)||crt₄) Wherein access is_jpUsing the SKi-decrypted access password, Sig, for the patient_SKp(access_jp)、Sig_SKp(ara_i) Are HBM respectively_pFor access_jpAnd ara_iSignature, crt₄A timestamp for the invocation message;

Step5，PCloud_pverifying access_jpAfter being effective, to HBM_pSending an Access data download DP [ PCloud ]_p]＝E_PKp(PID_jp||EMD_jp||Sig_SKcp(EMD_jp)||crt₅) Wherein EMD_jpFor storage in the PCloud_pMedical data, crt, encrypted with PKp₅A timestamp for the download message;

Step6，HBM_pto AU_iSending a relay access response RAR [ HBM ]_p]＝E_PKi(s_ip||PID_jp||Sig_SKp(s_ip)||crt₆)，HBM_pSelecting a random number s_ipAs temporary transfer symmetric key for encrypting medical data MD of patient_jp，crt₆A timestamp for the response message;

Step7，HBM_pWAD [ HBM ] for forwarding data to be accessed to shared pool SP_p]＝E_PKSP(ar_i||PID_jp||HBM_p||TEMD_jp||||Sig_SKp(ar_i)||WAD[HBM_p]＝E_PKSP(ar_i||PID_jp||HBM_p||TEMD_jp||Sig_SKp(ar_i)||Sig_SKcp(TEMD_jp)||crt₇)，HBM_pUsing s_ipEncrypted MD_jpTo obtain TEMD_jp。Sig_SKp(ar_i)、Sig_SKcp(TEMD_jp) Are HBM respectively_pTo ar_iAnd TEMD_jpSignature, crt₇A timestamp for the forwarded data;

Step8，AU_isending transfer sharing application SA [ AU ] to SP_i]＝E_PKSP(ar_i||PID_jp||HBM_p||Sig_SKi(ar_i)||crt₈) Wherein, Sig_SKi(ar_i) Is AU_iTo ar_iSignature, crt₈A timestamp for the application message;

Step9，Sp authentication AU_iTransmitted ar_iHBM (hepatitis B M)_pTransmitted ar_iAfter the agreement, to AU_iReturning shared data SD SP]＝E_PKi(PID_jp||HBM_p||TEMD_jp||Sig_PKSP(TEMD_jp)||crt₉) Wherein, crt₉For the timestamp of the shared data, then SP deletes the temporarily stored TEMD_jpSaving space and protecting TEMD_jpSecurity of, AU_iUsing s_ipDecrypting TEMD_jpThen, the final MD is obtained_jp。

The invention has the beneficial effects that:

compared with the prior art, the invention has the following advantages:

1) the invention can encrypt and store the medical data of the patient in the private cloud of the hospital, and extract and pack the medical data to the corresponding block chain according to the medical service type of the patient. Compared with the traditional single-chain mixed recording method, the multi-chain differential recording method is more beneficial to improving the query efficiency and tracing.

2) The invention designs a multi-anonymization method, which can ensure that a patient can quickly obtain a plurality of anonymous identities when going to a medical institution alliance for hospitalization for the first time, and ensure the identity privacy data of the patient.

3) The invention designs an on-chain data projection strategy which is used for supporting the whole network data query, and meanwhile, the block structure is improved, so that the data query efficiency is improved.

4) The invention designs a zero-trust transfer access strategy which is used for guaranteeing the security of a coalition user when requesting to access data.

5) The invention designs an access request identity verification mechanism which specifies the authority range of the alliance user for accessing medical data.

6) The invention introduces a sharing pool for the alliance user to access the medical data; if the application is passed, the medical data needing to be accessed is sent to the shared pool, and the medical data is destroyed immediately after the access is finished.

7) The invention can solve the problem of identity privacy of the patient when the information island is broken.

8) In the invention, the patient can obtain a plurality of non-repeated anonymous identities when hospitalizing, and the security of medical electronic data sharing can be greatly improved.

9) The invention can prevent the medical electronic data in the medical institution alliance from being inferred due to the leakage of the identity of the patient in a certain hospital, thereby avoiding the continuous stealing of the data.

10) According to the invention, the encrypted medical data is stored in the private cloud, so that the privacy of the patient and the safety of the medical data can be effectively protected.

11) The invention changes the original structure of the block, and a certain block can only store the shadow data of one patient based on a single patient, thereby not only improving the generation efficiency of the block, but also improving the anti-tampering performance and the query efficiency.

12) The invention can give different access rights of the alliance user to the medical data, and can avoid stealing and leaking the privacy data of the patient.

13) The invention ensures the security of the data in the access sharing pool of the alliance users by implementing the confidentiality transfer access control protocol, and the data is destroyed immediately after the access is finished, thereby effectively saving the storage space and providing effective guarantee for the security of the data.

Drawings

Fig. 1 is a schematic view of a hierarchical architecture of a multi-cloud and multi-chain collaborative mode according to the present invention.

Fig. 2 is a schematic diagram of an overall framework of medical data security sharing in a multi-cloud and multi-chain collaborative mode.

Fig. 3 is a flow chart of the patient identity multi-anonymization medical data storage of the present invention.

Fig. 4 is a schematic diagram of the identity anonymization process of the present invention.

Fig. 5 is a schematic diagram of an anonymous identity verification process.

FIG. 6 is a block diagram of a packed projection.

Fig. 7 is a zero trust transit access policy framework diagram.

Fig. 8 is a schematic diagram of an access request authentication process.

Fig. 9 is a flowchart of the confidentiality transit access control protocol.

Detailed Description

The invention is described in further detail below with reference to the figures and specific examples.

The invention adopts a multi-cloud and multi-chain cooperative mode architecture to realize safe sharing of electronic medical data. As shown in fig. 1, the architecture is presented in a hierarchical fashion, including a multi-cloud tier, a multi-chain tier, a user tier, and a management tier.

Multi-cloud layer: each hospital has a Private cloud (pccloud) that stores the various types of medical data it generates. Medical data in the private cloud can be directly accessed locally, Alliance Users (AUs) cannot directly access the local cloud and only data can be encrypted and put into a shared pool to be acquired.

Multi-chain layer: hospitals typically provide patients with medical services such as outpatient service, emergency, hospitalization, surgery, examination, and the like. During the Medical service, the generated Medical Data can be respectively projected to an outpatient site block chain (HC _ chain), an emergency site block chain (HE _ chain), a residential site block chain (IH _ chain), an operating site block chain (MO _ chain), an examination site block chain (ME _ chain), and a Data access log and user behavor block chain (DU _ chain) for recording Data access logs and user behaviors, thereby forming a multi-chain distinguishing recording mode.

And (3) a user layer: mainly comprises users of unions such as hospitals, medical research institutions, public security, court, insurance companies and the like. Hospitals play both a contributor and visitor role in medical data sharing, and also undertake block generation and verification, with the responsibility of the block chain miners (HBMs). Medical research institutes may access data after desensitization of patient information for scientific research. When doctor-patient disputes occur, judicial authorities such as public security and court can intervene to access medical data. The insurance company has partial access to medical data when confirming the medical insurance reimbursement.

And (3) a management layer: the Certificate authority system mainly includes a digital Certificate Authority (CA), a Key Management Center (KMC), a management Certificate Revocation List (CRL), an Anonymous Server (AS), and a Data Sharing Manager (DSM), and is deployed on a plurality of servers of a health administration. The management layer only executes the authentication and authorization functions, does not store any medical data, and can effectively reduce the load pressure of the management layer. The CA is responsible for applying and issuing digital certificates of alliance users; the KMC is responsible for permanent keys and zero-time keys of the federation users; the AS is responsible for anonymization of the identity of the patient and protecting the identity privacy of the patient; when a federated user requests access to medical data, the DSM not only verifies its digital certificate at the CA, but also verifies whether the digital certificate is invalid on the CRL, and can pass authentication and confirm identity and give corresponding access rights.

Fig. 2 depicts the overall framework of a multi-cloud, multi-chain collaborative medical electronic data security sharing scheme. Taking patient John as an example, when he completes a medical diagnosis, new medical electronic data generated according to his type of medical service will be uploaded to the hospital's proprietary cloud for storage. At the same time, the data will be projected onto the corresponding tile chain, and the tiles containing the projections will be broadcast to all HBMs via multi-chain consensus. In the access phase, the alliance users can obtain the required medical electronic data from the SP through the confidentiality transit access protocol only after the alliance users pass the CA authentication and authorization.

Multiple anonymized medical data storage phases

In order to guarantee the sharing safety, data generated by patients seeking medical services in different hospitals needs to be subjected to multi-anonymization storage. As shown in fig. 3, the implementation of the multiple anonymization medical data storage method includes three phases: patient identity multi-anonymization, private cloud encrypted storage, and on-chain data projection.

By introducing multiple anonymization measures, each patient can obtain an anonymous identity when visiting a hospital in the medical institution alliance, and the anonymous identities in different hospitals are not repeated. Take John's patient as an example, his ID_jIn number HBM_kThe anonymization process of the hospital can be carried out in an anonymization serverCalculation of anonymous identities PID with the help of (AS)_jk. Obviously, John executes the identity anonymization process once every time he visits a hospital, which causes low anonymization efficiency and delays the time of visiting a doctor. By designing the identity multi-anonymization algorithm, when John visits a medical association for the first time, he is combined with a hospital set h ═ HBM over a medical association at AS₁,…,HBM_k,…,HBM_hRunning the algorithm, calculating the anonymous identity list gamma of John in batches_j. The identity anonymization process is implemented in three steps as shown in fig. 4.

Step1, John chooses a random data r_jkAS an anonymous parameter, issuing an anonymous service request AR [ ID ] to the AS_j]＝E_PKAS(r_jk||ID_j||Sig_SKj(r_jk)||iat₁) Wherein PKAS is the public key of AS, Sig_SKj(r_jk) For John to r_jkSKj is John's private key, iat₁For the timestamp of the request message, the AS holds an anonymous parameter list xi for John_jChecking r_jkWhether or not in xi_jAnd mainly avoids anonymous identity duplication of John on the federation of medical institutions. If r is_jk∈Ξ_jThe AS asks John to select a random number and resend the anonymous service request until it is not repeated. If it is not

AS calculates identity anonymous PID_jk＝h_A(ID_j*r_jk). Wherein h is_A(-) is a hash function that performs anonymous operations, and is irreversible and collision resistant. AS sends an anonymous service response SR [ AS ] to John]＝E_PKj(PID_jk||Sig_SKAS(PID_jk)||iat₂). PKj is the public key of John, Sig_SKAS(PID_jk) AS to PID_jkSKAS is the private key of the AS, iat₂A timestamp for the response message;

step2, SK for John_jDecrypting ASR [ AS ]]To obtain an anonymous identity PID_jkH, a collection of hospitals over a federation of medical institutions { HBM₁,…,HBM_k,…,HBM_hThe anonymous identity list held by AS for John is denoted AS Γ_jThe algorithm 1 can be operated at the AS to realize the identity anonymization;

When John goes to a hospital HBM_kIn hospitalization, John first selects a random number r_jkAs an anonymity parameter, if r_jkHaving existed in the anonymous parameter List xi_jIn (1), John must reselect a new r_jk(ii) a Otherwise will r_jkPut into xi_jAnd calculates John at HBM_kAnonymous identity PID in_jk＝h_A(ID_j*r_jk) Finally, it is applied to HBM_kThe anonymous identity in (1) is added to the anonymous identity list Γ held by John_jIn the medical alliance, for each hospital in the medical alliance, cyclic calculation is carried out, and finally an anonymous identity list gamma of John is output_jDifferent anonymous identity information that John has in all hospitals;

having anonymous identity, John goes to HBM_kHospitalization can be realized by only anonymous identity authentication in four steps, as shown in fig. 5.

Step1, John to HBM_kSending anonymous identity docket AIB [ ID ]_j]＝E_PKk(PID_j||Sig_SKj(PID_j)||pvt₁). Wherein PKk is HBM_kOf public key, Sig_SKj(PID_jk) For John to PID_jkSignature of, pvt₁A timestamp for the docket message;

Step2，HBM_ksending AIV [ HBM ] for John anonymous authentication to AS_k]＝E_PKAS(PID_jk||Sig_SKk(PID_jk)||pvt₂) Wherein, Sig_SKk(PID_jk) Is HBM_kTo PID_jkSignature of SK_kIs HBM_kPrivate key of (1), pvt₂Is the experimentA timestamp of the certificate message;

step3, AS at Γ_jUp-verification PID_jkIf PID exists_jk∈Γ_j

Verification result v

_jk1 if not, v_jk0, AS to HBM_kReturning anonymous identity confirmation AIC AS]＝E_PKk(v_jk||Sig_SKAS(v_jk)||pvt₃) Wherein, Sig_SKAS(v_jk) AS to v_jkSignature of, pvt₃A timestamp for the verification message;

Step4，HBM_kAIC [ AS ] decrypted with SKk]After, if v_jkIf 1, then use PID_jkStore medical data for John anonymization, if v_jk0, John in HBM_kThe medical service application is difficult to pass;

john on HBM_kAfter the medical treatment is finished, the generated medical data MD_jk＝{C_jk,Data_jk,mdt_jkHas to be stored encrypted to the PCloud_kWherein, C_jkThe value ranges Λ ═ 1,2,3,4,5 correspond to { outpatient service, emergency treatment, hospitalization, operation, examination }, respectively. Data_jkAll electronic medical records, treatment records, diagnostic reports, etc. generated by John during the course of his visit. C_jkMay take a subset or a full set of Λ, mdt_jkIs MD_jkThe generation time of (c);

for PCloud_kLocal access to medical data, HBM_kHas direct access rights, while John wants to access the HBM_kIs applied for access. Thus, PK may be used_kEncrypted MD_jkIs denoted as EMD_jk. If the alliance user is not authorized, it is difficult to decrypt the EMD_jkAnd obtaining MD_jkTherefore, the privacy of the patient and the safety of medical data sharing are effectively guaranteed.

On-chain data projection phase

HBM_kWill EMD_jkExtracted as projection DS_jk＝{PID_jk,HBM_k,C_jk,sp_jk,E_PKj(access_jk),Sig_SKk(EMD_jk),Sig_SKj(EMD_jk),AD_jk,mdt_jkAnd packed into the corresponding on-chain block. Wherein sp_jkIs EMD_jkStorage path of E_PKj(access_jk) Is EMD_jkThe access password of (2). Federated user John, with John's knowledge and permission, uses the private key to decrypt E_PKj(access_jk) Later, only has an opportunity to access the EMD_jk。Sig_SKk(EMD_jk),Sig_SKj(EMD_jk) Are HBM respectively_kAnd John to EMD_jkThe signature of (2). AD_jkFor EMD_jkSummary information description of (1).

Selection of the corresponding block chain, depending on C_jk. For example, C_jkIf 3, IH _ chain is selected for projection. In the packed projection process, DS_jkCan be disassembled into two parts of DSH_jk＝{PID_jk,HBM_k,C_jk} and DSB_jk＝{sp_jk,E_PKj(access_jk),Sig_SKk(EMD_jk),Sig_SKj(EMD_jk),AD_jk,mdt_jk}。

The capacity of one block is usually set to about 1MB, and the data that can be recorded in the block is small. Therefore, it is necessary to improve the block structure of bitcoin, and pack DSH based on inheriting the original parameters { previous block hash, block ID, timestamp, Merkle root }_jkInto the block header, DSB_jkIt is packed into a zone block in the form of a Merkle tree. The block structure of the packed projection is shown in fig. 6.

Unlike the traditional block structure, the new block is generated when the transaction volume record reaches the upper limit of the block capacity, the improved block structure takes a single patient as a reference, and only the projection related to the anonymous identity of a certain patient is packaged in one block. This may result in an increased blockchain length, but the longer the blockchain, the stronger the tamper resistance. In addition, the PID_jkThe block head is arranged, so that subsequent projection data query is facilitated, and the query efficiency is improved.

Zero trust transit access phase

When a alliance user requests to access electronic medical data, zero trust authentication is required, and then the requested medical data are obtained in a sharing pool in a confidentiality transfer mode;

the core component of the zero trust authentication can be embedded into a Data Sharing Manager (DSM) of a management layer of a medical institution alliance, and mainly comprises a zero trust gateway, a zero trust authentication engine, a zero trust access control engine and a zero trust audit engine. With alliance user AU_iFor example, the implementation of the zero-trust transit access policy to which the DSM sends an access request is mainly divided into six stages, as shown in fig. 7;

and (3) authorization policy: zero trust gateway from AU_iOf the respective right ar granted in the set of access rights Σ_i. The set of access permissions Σ ═ {1,2,3,4 }, respectively corresponds to { high, medium, low }. High-level rights mean that all electronic medical data of a patient can be accessed, high-level rights can access part of the data, intermediate-level rights can access desensitized medical data, and low-level rights can only access limited medical data such as diagnostic certificates, electronic invoices, expense details and the like. At the same time, the zero trust gateway relies on PID_jkAll the multiple anonymous identities of the patient are correlated at the AS, then the search is simultaneously expanded on a plurality of block chains according to the type of the requested data, and the inquired projection data is loaded to the search result sr_iIn, feed back to AU_i。

Transfer sharing strategy: AU (AU)_iAccording to the projection data in the search result, the requested electronic medical data is found to be positioned in the HBM_pAfter the treatment, the mixture is put into the furnace,immediately starting a confidentiality transfer access control protocol according to the search result sr_iAlthough the federation user can know the storage path, abstract information, access password and the like of the requested data, the federation user cannot directly access the data, and the authorization ar is required_iAnd sr_iThe authentication is sent to a hospital where the electronic medical data is located, the authorization of the alliance user is confirmed to be correct from the zero trust gateway, and the hospital selects a random number as a temporary symmetric key and sends the temporary symmetric key to the alliance user; then, the hospital downloads the requested electronic medical data in the private cloud, decrypts the electronic medical data by using a private key of the hospital, encrypts the electronic medical data by using a temporary symmetric key and forwards the electronic medical data to the sharing pool; finally, the federated user presents the authorization, gets the electronic medical data in the shared pool, and decrypts with the temporary symmetric key. Once access is complete, the data in the shared pool is destroyed immediately.

The authentication of the access request sent by the alliance user is completed by the authentication system deployed in the management layer. With alliance user AU_iAs an example, AU_iThe transmitted access request authentication procedure can be implemented by the DSM of the management layer in 5 steps, as shown in figure 8,

step2, DSM verifies CA at CA_iAnd examining CA on CRL_iIf it is invalid, if true, authentication is passed, and then CA is confirmed_iWhether or not equal to CA_kIf CA_i＝CA_kDirectly jumping to Step5, otherwise, continuing to execute the next Step;

AU_iaccording to the projection data in the search result, the medical data requested by the search result is found to be positioned in the HBM_pAfter that, the confidentiality relay access control protocol is started immediately, and the process can be implemented in 9 steps (here, it is indicated that the following steps 1 to 9 are limitations on the confidentiality relay access control protocol) as shown in fig. 8.

step4 if rc_i＝1，HBM_pTo PCloud_pSending data call DT [ HBM ] for John_p]＝E_PKcp(access_jp||ara_i||HBM_p||PID_jp||Sig_SKp(access_jp)||Sig_SKp(ara_i)||crt₄) Wherein access is_jpAccess password, Sig, decrypted using SKi for John_SKp(access_jp)、Sig_SKp(ara_i) Are HBM respectively_pFor access_jpAnd ara_iSignature, crt₄A timestamp for the invocation message;

Step6，HBM_pto AU_iSending a relay access response RAR [ HBM ]_p]＝E_PKi(s_ip||PID_jp||Sig_SKp(s_ip)||crt₆)，HBM_pSelecting a random number s_ipAs temporary transfer symmetric key, it is used to encrypt medical data MD of John_jp，crt₆A timestamp for the response message;

step9, SP verifies AU_iTransmitted ar_iHBM (hepatitis B M)_pTransmitted ar_iAfter the agreement, to AU_iReturning shared data SD SP]＝E_PKi(PID_jp||HBM_p||TEMD_jp||Sig_PKSP(TEMD_jp)||crt₉) Which isMiddle, crt₉For the timestamp of the shared data, then SP deletes the temporarily stored TEMD_jpSaving space and protecting TEMD_jpSecurity of, AU_iUsing s_ipDecrypting TEMD_jpThen, the final MD is obtained_jp。

The application advantages of the invention are:

through a large amount of relevant literature research and actual demand analysis at home and abroad, the fact that a block chain is beneficial to promoting medical data sharing but difficult to store large-size audio and video data is found; the cloud storage space is large, but a single cloud mode easily causes single-point failure, and large-scale data leakage is easy to occur after the single cloud mode is attacked due to centralized targets. Existing related work is biased to a single-cloud single-chain mode or a multi-cloud single-chain mode, the advantages of cloud chain cooperation cannot be fully exerted, and a single-chain hybrid storage mode may cause confusion and low efficiency of shared data query.

The invention adopts a multi-cloud and multi-chain cooperation mode to safely share the electronic medical data. In practical application, a hospital with better urban digital construction can form a city-level medical institution alliance. Through a cross-link interaction protocol, a cross-link node is additionally arranged on a city-level alliance management layer, a plurality of city-level medical institution alliances can be connected, a provincial-level medical institution alliance is further formed, and the provincial information query and sharing of electronic medical data is achieved. In the whole alliance architecture, all hospitals are responsible for storing electronic medical data generated by the hospitals in respective proprietary clouds, and data backup is well done. Each hospital holds the private key and does not disclose the private key to the outside. Without authentication and authorization, even federated users have difficulty obtaining encrypted data. After the electronic medical data is stored in a private cloud encryption mode, according to the type of medical service of a patient, index information is extracted and packaged to a corresponding block chain for information inquiry and sharing in a projecting mode. When a cross-city access request occurs, after zero trust authentication and authorization of a provincial alliance management layer are successful, the access user transmits the access request to a target city level cross-link node by the node at the city level cross-link node, and the cross-city transfer method has positive data query and sharing significance for cross-city transfer of patients.

In conclusion, the multi-cloud and multi-chain collaborative mode designed by the invention has better elasticity and expansibility, and is beneficial to being put into practical application of electronic medical data security sharing.

Claims

1. A secure sharing method of electronic medical data based on multi-cloud and multi-chain collaboration is characterized by comprising the following steps:

multi-cloud layer: each hospital has a proprietary cloud that stores the various types of medical data it generates. Medical data in the private cloud can be directly accessed locally, and alliance users cannot directly access the medical data and only can encrypt the medical data and put the encrypted medical data into a sharing pool to obtain the encrypted medical data;

step two, a multi-anonymization medical data storage stage

step three, on-chain data projection stage

step four, zero trust transfer access phase

the core component of the zero trust authentication can be embedded into a data sharing manager of a healthcare institution alliance management layer.

2. The secure sharing method of multi-cloud and multi-chain collaborative electronic medical data according to claim 1, wherein the patient identity is anonymized, comprising the following steps:

step1, selecting a random data r by the patient_jkAs an anonymity parameter, an anonymity service request AR [ ID ] is issued to an anonymity server_j]＝E_PKAS(r_jk||ID_j||Sig_SKj(r_jk)||iat₁) Wherein PKAS is the public key of anonymous server, Sig_SKj(r_jk) Is a patient pair r_jkSKj is the private key of the patient, iat₁For the time stamp of the request message, the anonymity server holds an anonymity parameter List XI for the patient_jChecking r_jkWhether or not in xi_jIn the medical institution alliance, anonymous identity repetition of patients on the medical institution alliance is mainly avoided; if r is_jk∈Ξ_jThe anonymizing server asks the patient to select a random number and resends the anonymizing service request until it is not repeated, if

Anonymous server computing identity anonymous PID_jk＝h_A(ID_j*r_jk) Wherein h is_A(.) is a hash function performing anonymous operations, irreversible and collision-resistant, the anonymous server sending an anonymous service response ASR [ AS ] to the patient]＝E_PKj(PID_jk||Sig_SKAS(PID_jk)||iat₂) Wherein PKj is the public key of the patient, Sig_SKAS(PID_jk) Being anonymous clothesServer pair PID_jkSKAS is the private key of the anonymous server iat₂A timestamp for the response message;

step2 patient uses SKj to decipher ASR [ AS ]]To obtain an anonymous identity PID_jkH, a collection of hospitals over a federation of medical institutions { HBM₁,…,HBM_k,…,HBM_hThe anonymous server keeps a list of anonymous identities for the patient denoted as Γ_jAlgorithm 1 can be run at the anonymity server to achieve patient identity de-anonymization; having anonymous identity, the patient goes to HBM_kHospitalizing, only anonymous identity authentication is needed;

HBM when patient goes to certain hospital_kAt the time of hospitalization, the patient first selects a random number r_jkAs an anonymity parameter, if r_jkHaving existed in the anonymous parameter List xi_jIn (1), the patient must reselect a new r_jk(ii) a Otherwise will r_jkPut into xi_jAnd calculating the HBM of the patient_kAnonymous identity PID in_jk＝h_A(ID_j*r_jk) Finally, it is applied to HBM_kThe anonymous identity in (a) is added to an anonymous identity list Γ held by the patient_jIn the medical alliance, each hospital in the medical alliance is circularly calculated, and finally, an anonymous identity list gamma of the patient is output_jWhich contains different anonymous identity information that the patient has in all hospitals.

3. The multi-cloud and multi-chain collaborative electronic medical data security sharing method according to claim 2, wherein the anonymous identity authentication specifically includes the following steps:

step1, patient is administered to HBM_kSending anonymous identity docket AIB [ ID ]_j]＝E_PKk(PID_j||Sig_SKj(PID_j)||pvt₁) Wherein, in the step (A),PK_kis HBM_kOf public key, Sig_SKj(PID_jk) For patient to PID_jkSignature of, pvt₁A timestamp for the docket message;

step3, the anonymous server is arranged in the gamma_jUp-verification PID_jkIf PID exists_jk∈Γ_jVerification result v_jk1 if not, v_jk0, anonymous Server to HBM_kReturning anonymous identity confirmation AIC AS]＝E_PKk(v_jk||Sig_SKAS(v_jk)||pvt₃) Wherein, Sig_SKAS(v_jk) AS to v_jkSignature of, pvt₃A timestamp for the verification message;

step4, HBM_kUsing SK_kDecrypting AIC [ AS ]]After, if v_jkIf 1, then use PID_jkAnonymizing the patient to store medical data, if v_jk0, patients in HBM_kThe medical service application is difficult to pass;

for PCloud_kLocal access to medical data, HBM_kHas direct access rights and the patient is going to the HBM_kApplication forCan be accessed, and thus, the PK may be used_kEncrypted MD_jkIs denoted as EMD_jkIf the alliance user is not authorized, it is difficult to decrypt the EMD_jkAnd obtaining MD_jkTherefore, the privacy of the patient and the safety of medical data sharing are effectively guaranteed.

4. The method for safely sharing electronic medical data in cooperation with multiple clouds and multiple chains according to claim 1, wherein in the step, the zero trust relay access comprises the following six stages:

and (3) authorization policy: zero trust gateway from AU_iOf the respective right ar granted in the set of access rights Σ_iThe access authority set Σ ═ 1,2,3,4, } corresponds to { high, medium, low }, respectively, high authority means that all electronic medical data of a patient can be accessed, high authority can access part of the data, medium authority can access desensitized medical data, low authority can access only limited medical data such as a diagnosis certificate, an electronic invoice, a charge detail, and the like, and meanwhile, the zero trust gateway relies on PID_jkAll the multiple anonymous identities of the patient are correlated at the AS, then the search is simultaneously expanded on a plurality of block chains according to the type of the requested data, and the inquired projection data is loaded to the search result sr_iIn, feed back to AU_i；

Transfer sharing strategy: AU (AU)_iAccording to the projection data in the search result, the requested electronic medical data is foundIn HBM_pAfter the processing, starting the confidentiality transfer access control protocol immediately, and according to the search result sr_iAlthough the federation user can know the storage path, abstract information, access password and the like of the requested data, the federation user cannot directly access the data, and the authorization ar is required_iAnd sr_iThe authentication is sent to a hospital where the electronic medical data is located, the authorization of the alliance user is confirmed to be correct from the zero trust gateway, and the hospital selects a random number as a temporary symmetric key and sends the temporary symmetric key to the alliance user; then, the hospital downloads the requested electronic medical data in the private cloud, decrypts the electronic medical data by using a private key of the hospital, encrypts the electronic medical data by using a temporary symmetric key and forwards the electronic medical data to the sharing pool; finally, the alliance user shows authorization, obtains the electronic medical data in the sharing pool and decrypts the electronic medical data by using the temporary symmetric key; once the access is completed, the data in the shared pool can be destroyed immediately; the access request sent by the alliance user is completed cooperatively by an authentication system deployed in a management layer.

5. The secure sharing method of electronic medical data with multi-cloud and multi-chain cooperation according to claim 4, wherein the authentication process of the access request comprises the following steps:

Step1，AU_isending an access request AR [ AU ] to DSM_i]＝E_PKDSM(ara_i||CA_i||HBM_k||PID_jk||Sig_SKi(ara_i)||art₁) Wherein ara_iFor access request applications, CA_iIs AU_iIf AU_iIs simply HBM_kItself, then CA_i＝CA_k，PK_DSMPublic keys DSM, Sig for DSM_SKi(ara_i)AU_iTo ara_iSignature, art₁A timestamp for the request message;

AU_iaccording to the projection data in the search result, the medical data requested by the search result is found to be positioned in the HBM_pAfter processing, the confidentiality relay access control protocol is started immediately.

6. The method according to claim 5, wherein the implementation of the confidentiality transit access control protocol comprises the following steps:

step3 DSM-to-HBM_pReturn authorization confirmation RC DSM]＝E_PKp(rc_i||HBM_p||PID_jp||Sig_SKDSM(rc_i)||crt₃) If, DSM validates ar_iEffective, then rc_i1, otherwise, rc_i＝0，Sig_SKDSM(rc_i) As DSM vs rc_iSignature, crt₃A timestamp for the acknowledgment message;

step9, SP verifies AU_iTransmitted ar_iHBM (hepatitis B M)_pTransmitted ar_iAfter the agreement, to AU_iReturning shared data SD SP]＝E_PKi(PID_jp||HBM_p||TEMD_jp||Sig_PKSP(TEMD_jp)||crt₉) Wherein, crt₉For the timestamp of the shared data, then SP deletes the temporarily stored TEMD_jpSaving space and protecting TEMD_jpSecurity of, AU_iUsing s_ipDecrypting TEMD_jpThen, the final MD is obtained_jp。