Medical data cross-domain authentication method, system and device based on block chain and medium

Abstract

The invention belongs to the technical field of cross-domain identity authentication, and provides a medical data cross-domain authentication method, system, equipment and medium based on a block chain in order to solve the problems of single-point failure, information stealing and the like in existing identity authentication, which are used for identity authentication between a first hospital of a first domain and a second hospital of a second domain. A first domain committee of the first domain and a second domain committee of the second domain respectively serve as nodes on the alliance block chain, all the domain committee jointly operate a Byzantine fault-tolerant protocol, and the second domain committee calls a registration contract to obtain a registration state of an account of a user in a first hospital in a domain to which the user in a second hospital belongs; if the registration state is valid, the user in the second hospital performs hash processing on the user in the first hospital, and if the hash processing result is consistent with the hash value in the registration contract, authentication succeeds, so that the problem of single-point failure is avoided, and the reliability and stability of the system are improved.

Description

Technical Field

[0001] The present invention belongs to the technical field of cross-domain identity authentication, and in particular to a blockchain-based medical data cross-domain authentication method, system, device and medium. Background Art

[0002] The statements in this section merely provide background information related to the present invention and do not necessarily constitute prior art.

[0003] Driven by emerging technologies, cross-space and cross-departmental smart medical systems are developing actively. Under this trend, electronic health records have become a substitute for traditional paper medical records, circulating in hospitals and electronic health systems, and electronic health records are inseparable from people's lives. Electronic health records can conveniently store patients' diagnosis and treatment data and health records, providing data support for people's health management and medical care. When people seek medical treatment, doctors can make a more comprehensive and accurate analysis of the condition based on previous medical data, thereby providing patients with more efficient treatment plans. The popularity of electronic health record data requires hospitals to break the constraints between regions and institutions. Although the establishment of medical consortiums is promoted nationwide in the cross-domain field of medical data, there are still various security issues, such as unauthorized cross-domain operations, user privacy leakage, and data loss and leakage.

[0004] In order to achieve the sharing of electronic health records, authorized legitimate users are allowed to access medical resources in other domains. Therefore, it is necessary to design a secure and scalable cross-domain authentication mechanism. In the traditional cross-domain authentication architecture, one or more trusted third parties such as certification authorities are usually relied on for authentication. These third parties act as intermediaries to ensure trust and security between different domains. However, this approach has limitations and will lead to trust concentration, single point failure and scalability issues.

[0005] Blockchain technology provides data immutability, transparency, and a decentralized consensus mechanism that can enhance the trust and security of the system. The introduction of blockchain technology can establish trust in an untrusted environment and ensure the security of the cross-domain authentication process. However, there are two potential challenges in the process of using blockchain for authentication: the limited size of each block in the blockchain may cause a throughput bottleneck, and each transaction must be verified before being written into a new block, which will cause delays in the authentication process.

[0006] In summary, the problems and defects of the existing technology include at least: First, the centralized identity authentication scheme has the risk of single point failure; second, electronic health records involve the patient's personal privacy and are easily stolen and tampered with by illegal users; third, people of different identities are subject to relatively strict restrictions when accessing and sharing electronic health records, and verifying the authenticity of identity and data requires a lot of resources and time. Summary of the invention

[0007] In order to overcome the shortcomings of the above-mentioned prior art, the present invention provides a blockchain-based cross-domain authentication method, system, device and medium for medical data, introduces a domain committee and combines it with the Byzantine consensus protocol to improve the level of decentralization and trust; the domain committee shares the authentication task, avoids the problem of single point failure, and improves the reliability and stability of the system.

[0008] In order to achieve the above object, the present invention adopts the following technical solution: In a first aspect, the present invention provides a cross-domain authentication method for medical data based on blockchain, the method is used for identity authentication between a first hospital in a first domain and a second hospital in a second domain, a first domain committee of the first domain and a second domain committee of the second domain are respectively used as nodes on a consortium blockchain, and all domain committees on the consortium blockchain jointly run a Byzantine fault-tolerant protocol, the method comprising: The user in the second hospital accepts the transfer initiated by the user in the first hospital and stores the account of the user in the first hospital; The second domain committee calls the registration contract to obtain the registration status of the account of the user in the first hospital in the domain to which the user belongs in the second hospital; If the registration status of the account of the user in the first hospital is valid in the domain to which the user in the second hospital belongs, the user in the second hospital performs hash processing on the user in the first hospital. If the result of the hash processing is consistent with the hash value in the registration contract, the identity of the user in the first hospital is legal and the authentication is successful.

[0009] In the second aspect, the present invention provides a cross-domain authentication system for medical data based on blockchain, including domains corresponding to at least two hospitals, and the domain committees in each domain serve as nodes on the alliance blockchain. All domain committees on the alliance blockchain jointly run a Byzantine fault-tolerant protocol. When users in two hospitals perform cross-domain identity authentication, specifically: Users in the second hospital: used to accept transfers initiated by users in the first hospital and store the accounts of users in the first hospital; The second domain committee is used to call the registration contract to obtain the registration status of the account of the user in the first hospital in the domain to which the user belongs in the second hospital; and determine whether the registration status of the account of the user in the first hospital in the domain to which the user belongs in the second hospital is valid; The user in the second hospital is used to perform hash processing on the user in the first hospital when the registration status of the account of the user in the first hospital in the domain to which the user in the second hospital belongs is valid, and to determine whether the result of the hash processing is consistent with the hash value in the registration contract. If they are consistent, the identity of the user in the first hospital is legal and the authentication is successful.

[0010] In a third aspect, the present invention provides an electronic device comprising a memory and a processor, and computer instructions stored in the memory and executed on the processor, wherein when the computer instructions are executed by the processor, the method described in the first aspect is performed.

[0011] In a fourth aspect, the present invention provides a computer-readable storage medium for storing computer instructions, wherein when the computer instructions are executed by a processor, the method described in the first aspect is performed.

[0012] One or more of the above technical solutions have the following beneficial effects: In the present invention, a domain committee is introduced. Each hospital is an independent domain and has a local domain committee. Each domain committee serves as a node of the alliance blockchain and jointly maintains the operation of the blockchain. All domain committees jointly run a Byzantine protocol to ensure decentralized decision-making among domain committee members. The domain committee is used to share the authentication task, maintain the consistency and fault tolerance within each domain, avoid the problem of single point failure, and improve the reliability and stability of the system.

[0013] Advantages of additional aspects of the present invention will be given in part in the following description, and in part will become obvious from the following description, or will be learned through practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The accompanying drawings in the specification, which constitute a part of the present invention, are used to provide a further understanding of the present invention. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute improper limitations on the present invention.

[0015] Figure 1 This is an architecture diagram of cross-domain authentication based on blockchain in Embodiment 1 of the present invention; Figure 2 This is a cross-domain authentication flow chart in Embodiment 1 of the present invention; Figure 3 This is a flow chart of session key negotiation in Embodiment 1 of the present invention. DETAILED DESCRIPTION

[0016] It should be noted that the following detailed descriptions are exemplary and are intended to provide further explanation of the present invention. Unless otherwise specified, all technical and scientific terms used herein have the same meanings as those commonly understood by those skilled in the art to which the present invention belongs.

[0017] It should be noted that the terms used herein are for describing specific embodiments only and are not intended to be limiting of exemplary embodiments according to the present invention.

[0018] In the absence of conflict, the embodiments of the present invention and the features of the embodiments may be combined with each other.

[0019] Embodiment 1 This embodiment discloses a cross-domain authentication method for medical data based on blockchain, which is used for identity authentication between a first hospital in a first domain and a second hospital in a second domain. A first domain committee of the first domain and a second domain committee of the second domain are respectively used as nodes on a consortium blockchain. All domain committees on the consortium blockchain jointly run a Byzantine fault-tolerant protocol. The method includes: The user in the second hospital accepts the transfer initiated by the user in the first hospital and stores the account of the user in the first hospital; The second domain committee calls the registration contract to obtain the registration status of the account of the user in the first hospital in the domain to which the user belongs in the second hospital; If the registration status of the account of the user in the first hospital is valid in the domain to which the user in the second hospital belongs, the user in the second hospital performs hash processing on the user in the first hospital. If the result of the hash processing is consistent with the hash value in the registration contract, the identity of the user in the first hospital is legal and the authentication is successful.

[0020] This embodiment takes into account the complexity of cross-domain interactions and data security issues in the process of medical data sharing between different hospitals, and designs a cross-domain identity authentication scheme under a partial trust model; the traditional architecture that relies on a third party as the executor of authentication is no longer applicable. The domain committee architecture is introduced in the cross-domain authentication scheme. The domain committee achieves decentralization through the BFT protocol, so that each domain can independently manage and update the member structure. The interaction between domain committees can ensure the consistency of cross-domain data sharing strategies among different hospitals; in order to solve the storage limitations and authentication delays in the blockchain authentication process, the user is registered in a smart contract containing an access control table for dynamic identity management and authentication; a simplified cross-domain identity authentication scheme is designed to quickly complete cross-domain identity authentication and reduce authentication overhead. The domain committees of all domains jointly run a Byzantine protocol, and then the domain committees run the Byzantine protocol to reach a consensus on the transactions sent by the user to ensure the validity of the transaction.

[0021] The method of this embodiment designs a partial trust model and a registration contract, and a complete cross-domain identity authentication is constructed through the technical support of these two parts.

[0022] 1. Design a partial trust model.

[0023] The lack of a strong trust mechanism between different hospitals will reduce the security and reliability of the certification process. If we rely on a centralized certification agency, there will be a risk of the centralized agency failing or being attacked, and the flexibility and scalability will be poor.

[0024] Therefore, considering the issues of flexibility and scalability, this embodiment introduces a domain committee architecture, and all domain committees run a Byzantine Fault Tolerant protocol, namely the BFT protocol: each hospital, as an independent domain, has a local domain committee, and each domain committee serves as a node of the alliance blockchain to jointly maintain the operation of the alliance blockchain. The domain committee is responsible for data management, access control and interaction with the alliance blockchain within the hospital. All domain committees jointly run a BFT algorithm to ensure decentralized decision-making among domain committee members, while ensuring that the domain committee is honest in each period.

[0025] Domain committee members may change over time, so regular reconfiguration is required to ensure that there are enough honest nodes in the committee. Under the partial trust model, a domain will have a certain degree of trust in other domains. The BFT consensus algorithm ensures that even if some domains behave dishonestly, other honest nodes can still ensure the normal operation and data consistency of the system as a whole. All hospitals run a BFT consensus algorithm together. The consensus algorithm of each hospital may be different, but as long as its BFT consensus can output the corresponding consensus certificate, the domain can still provide correct services even if some nodes are offline or compromised.

[0026] This embodiment introduces the domain committee architecture and combines it with the Byzantine consensus mechanism to design a partial trust model, thereby improving the level of decentralization and trust. The domain committee shares the authentication task, and each domain only needs to handle transactions within its own domain, rather than processing all requests for cross-domain authentication. The Byzantine consensus mechanism can ensure that the system can reach a consensus even when a certain proportion of nodes may be malicious, maintain consistency and fault tolerance within each domain, and provide stronger security. Traditional solutions may be vulnerable to node failure or malicious behavior.

[0027] 2. Design a registration contract.

[0028] Doctors and patients who have just joined the hospital need to register their identities. This is done by designing a registration contract, and designing an access control table in the registration contract to store the identity information of users who have completed registration in the domain. Each doctor or patient who needs to register needs to register an account in advance on the alliance blockchain through the domain committee, and then the user saves the account address Addr on the blockchain for subsequent operations.

[0029] The design of the registration contract mainly includes the following contents: Input: The user account address Addr that needs to be registered i 、Registration validity period T i , the hash value h of the user identifier i , the corresponding domain committee uses its private key sk A Signature sig generated for the user i And the identifier GID of the corresponding domain as the input of the smart contract; Output: Execute the smart contract.

[0030] Specifically, the domain committee performs the following operations: Get the public key: through the public key pk of the corresponding domain i ; Construct message: Add the user's account address Addr i and the hash value h of its identifier i Connect them to form a message m=Addr i || h i ; Calculate the first elliptic curve logarithm: Use the message m and the public key pk of the corresponding domain i Calculate the first elliptic curve logarithm e1 = e(m,pk i ); Verify the signature: Use the generator g and the signature sig i Calculate the second elliptic curve logarithm e2 = e(g,sig i ); if e1=e2, the signature is valid. This step ensures that the message has not been tampered with during transmission, and the following steps are continued; if e2 is not equal to e1, null is output, which means that the signature is invalid; the domain committee uses its private key to encrypt the hash value of the user's account address and identity identifier to generate a digital signature sig i ; Get the domain object and the index of the last registered user: Get the domain object D = Domain[GID] according to GID, and get the index of the last registered user l = D.endindex; Update domain object: register user account address Addr i , user identifier hash value h i , Expiration date T i and the state true are stored in the corresponding positions of the access control table: D.addr[l+1] = Addr i , D.Hash[l+1] = h i , D.Time[l+1] = T i , D.Status[l+1] = true; After the domain object is updated, it means that the user registration is successful, and the alliance blockchain will generate a smart contract address Wsc.

[0031] Output smart contract address: smart contract address Wsc.

[0032] Finally, the user identity information registration is completed, and the blockchain returns the address Wsc to the user for storage.

[0033] This embodiment designs a registered smart contract to complete the user registration process. An access control table is designed in the smart contract to record the identity information of the registered user. This design can dynamically manage the identity of the user and update the status of the device in real time. The smart contract helps prevent unauthorized access and data tampering, and ensures the legitimacy of both parties in communication.

[0034] 3. Design a secure and effective distributed authentication mechanism.

[0035] When doctor i of hospital A wants to access the file of patient j of hospital B, doctor With patients It is necessary to apply consortium blockchain to achieve identity authentication and thus establish communication.

[0036] Assume Doctor Want to be with patients Establishing communication includes the following: Initiate transaction: Doctor To patients Initiate a transfer, the recipient of the transfer is the patient Blockchain account; Receive transfers and get information: Patient Upon receiving the doctor After the transfer, the doctor will be stored The account information is then connected to the consortium blockchain; patient Get the doctor by calling the registration contract access control and registration information; Only when a doctor In patients If it is registered in the domain and the registration status is valid, proceed to the next step; Hash Match: Patient For doctors Hash the identity identifier of the registered contract. If the hash result matches the hash value returned by the registered contract, proceed to the next step. Establish communication connection: Establish communication connection.

[0037] Compared with the existing cross-domain authentication scheme, this embodiment takes into account the security issues of user identity leakage in the cross-domain authentication process and the poor scalability of the authentication scheme, and thus designs a distributed, secure and scalable cross-domain authentication scheme to reduce authentication overhead.

[0038] Combine the following Figure 1-Figure 3 A blockchain-based cross-domain medical data authentication method proposed in this embodiment is described in detail: Step 1: Initialization.

[0039] Each hospital is a domain, and each domain has a domain committee. The domain committee serves as a node in the alliance chain. All domain committees jointly run a BFT protocol and generate public-private key pairs for each domain.

[0040] Step 2: Doctor / Patient Registration.

[0041] Each doctor / patient registers at this stage. Whenever a user registers, the domain committee first registers an account for the registered user on the blockchain and sends the account address Addr to the registered user for storage.

[0042] Step 21: Register User First send a query request Qrequest to query Addr i Whether there is valid registration information in domain N.

[0043] If a registered user Already registered, but the validity of the registration is T i Expired, then Delegates validity update requests to the appropriate domain council DC A .

[0044] Domain Committee DC A Submit validity update request to domain council DC N , Domain Committee DC N Generate signature and sends it to the domain committee DC A , then the domain committee DC A Call the identity update algorithm to complete the update process. Among them, T j Indicates the new validity period. Domain Committee DC N If If the user is not registered in domain N, go to step 22.

[0045] Step 22: Register User Submit request registerglobal= (GRrequest || Addr i|| h i ) to the domain committee, where GRrequest is the registration request, h i = H(ID i ), H(ID i ) for users ID i The hash value of Addr i For users The account address of .

[0046] GRrequest includes two types of requests: one is for registering users The registration request in domain A and the other one in other domain N i (i=1,2,3…,n), where n is the number of domains on the consortium blockchain except domain A. For the first category, the domain committee DC A Use its private key sk A For users Account address and a hash of the identifier Encrypt and generate digital signature , then jump to step 24; for the second category, continue to step 23.

[0047] Step 23: Domain Council DC A Domain Committee DC N Submit a registration request to obtain a signature .

[0048] Step 24: Domain Council DC A Register user Message and Signature As the input of the registration contract, the registration contract algorithm is called to implement the registration.

[0049] Execute smart contract: register user Account addressAddr i and the hash value h of its identifier i Connect them to form a message m=Addr i || h i ; Calculate the first elliptic curve logarithm: Use the message m and the public key pk of the corresponding domain i Calculate the first elliptic curve logarithm e1 = e(m,pk i ); Use generator g and signature sig i Calculate the second elliptic curve logarithm e2 = e(g,sig i). If e1 is equal to e2, it means the signature is valid and you can continue to execute the following steps; otherwise, null is output, which means the signature is invalid.

[0050] Step 25: The registration contract determines the validity of the signature.

[0051] Registered User The information is written into the access control table in the contract and can only be accessed after the signature is verified. After that, the signature field will be written; get the domain object D = Domain[GID] according to GID, and get the index of the last registered user l = D.endindex; register the user account address Addr i , user identifier hash value h i , Expiration date T i and the state true are stored in the corresponding positions of the access control table: D.addr[l+1] = Addr i , D.Hash[l+1] = h i , D.Time[l+1] = T i , D.Status[l+1] = true; then initiate transaction Tx to complete the status update in the alliance blockchain.

[0052] Step 26: After successful registration, the alliance blockchain will generate a smart contract address Wsc, and the alliance blockchain will return the address Wsc to the registered user for storage.

[0053] Step 3: Session key negotiation.

[0054] Doctor D i and patients Before establishing communication, a session key needs to be negotiated. The process is as follows: Step 31: Hospital D i and patients Exchange the public keys they obtained when registering on the consortium blockchain and , and the public key assigned to them by the domain committee and .

[0055] Step 32: Hospital D i Randomly select a first number , and use the public key right Perform asymmetric encryption to obtain ,in, is an integer coprime with p, is the multiplication group modulo p; p is a large prime number, generated randomly; is the timestamp, Indicates the use of public key right and Asymmetric encryption is performed; subsequently, the hospital d i Send the encrypted message c to the patient .

[0056] Step 33: Patient After receiving the encrypted message c, use your own private key Decrypt message c and get ,extract and , Indicates the use of patients Private key Decrypt the ciphertext c; then randomly select a second number , using public key PK i right and the current timestamp Perform an asymmetric encryption algorithm to obtain the message , then the message Send to hospital i； in, Indicates the use of public key right and Perform asymmetric encryption.

[0057] Step 34: Hospital D i Receive message Then, use your own private key Decrypting the message ,get , thus obtaining and , For hospital i The private key of

[0058] Step 35: Hospital D i and patients Will As input to the key generator, generate the session key ks = H( ).

[0059] Step 4: Cross-domain authentication.

[0060] Patients in Domain B Certified Doctor in Domain A The process is as follows: Step 41: Doctor in Domain A Call the contract function Valid(Addr i ) checks whether its registration time in domain B has expired, performs a query operation on the alliance blockchain, and returns the result.

[0061] If T i Invalid, Doctor in Domain A Submit an update request Urequest and identity information (Addr i ||h i ) to the domain committee DC A ; if T i If valid, execute step 44.

[0062] Step 42: Domain Council DC A Call the blockchain contract function Valid(Addr i ) to check Whether it belongs to domain A. If so, the domain committee DC A represent Domain Committee DC B Send an identity update request Urequest.

[0063] Domain Committee DC A Getting a signature and the new validity period T j After that, the domain committee DC A Call the registered contract and run the algorithm in the registered contract to initiate the transaction.

[0064] Step 43: After all domain committees reach a consensus on the validity of the transaction, the transaction is allowed to be added to the blockchain, thereby updating the ledger, and the result Uresponse is returned to the doctor in domain A through the BFT consensus mechanism. .

[0065] Step 44: Doctor in Domain A Through a secure channel Sent to patients in domain B .

[0066] Step 45: Doctor in Domain A Using Domain Committee DC A The public key pk generated for it i Identifier ID i Perform asymmetric encryption to obtain , hash the identifier to get , and generate a request ;in, Identifier Perform hash operation.

[0067] Then, the doctor in domain A Initiate a transaction , where the payer is the doctor in domain A Account , the recipient is the patient in domain B Account , the transaction amount is , additional information is op.

[0068] Step 46: The Domain Committee node in Domain B verifies and adds the transaction to the new block, and then returns the transaction identifier TxID to the doctor in Domain A after reaching consensus , and update the account The balance of

[0069] Step 47: After receiving the transfer, the patient in domain B Call the contract through the smart contract address Wsc and obtain Registration status in domain B.

[0070] Patients in Domain B Submit a certification request , where ks represents the session key, GID B Indicates the identifier of the B domain.

[0071] Step 48: Domain A blockchain node obtains ciphertext through encryption algorithm , and the ciphertext Sent to patients in domain B ; Indicates using the negotiated session key ks to the account address ,state , Timestamp , hash value Perform symmetric encryption to obtain the ciphertext .

[0072] If the account If it is already registered in domain B, status=true; otherwise, status=false.

[0073] Step 49: Patients in Domain B Run the symmetric decryption algorithm to obtain If status=false, exit; otherwise, determine the timestamp The effectiveness of Represents the ciphertext Perform symmetric decryption to obtain the corresponding account address ,state , Timestamp , hash value .

[0074] If the timestamp Expired, exit; if the timestamp Not expired, execute hash function If h == , then the doctors in domain A The identity is legal and the authentication is successful; otherwise, the authentication fails.

[0075] Through the above-mentioned cross-domain authentication design, the need for trust in a third party is eliminated, allowing direct authentication between different domains; by introducing the domain committee and the Byzantine consensus mechanism, the security and reliability of the entire authentication process are enhanced; the dynamic management of identity is achieved by registering smart contracts, making the authentication process more flexible; the two parties to the authentication negotiate the session key before authentication to ensure the security of subsequent communications.

[0076] Embodiment 2 The purpose of this embodiment is to provide a medical data cross-domain authentication system based on blockchain, including domains corresponding to at least two hospitals, and the domain committees in each domain serve as nodes on the alliance blockchain. When users in the two hospitals perform cross-domain identity authentication, specifically: Users in the second hospital: used to accept transfers initiated by users in the first hospital and store the accounts of users in the first hospital; The second domain committee is used to call the registration contract to obtain the registration status of the account of the user in the first hospital in the domain to which the user belongs in the second hospital; and determine whether the registration status of the account of the user in the first hospital in the domain to which the user belongs in the second hospital is valid; The user in the second hospital is used to perform hash processing on the user in the first hospital when the registration status of the account of the user in the first hospital in the domain to which the user in the second hospital belongs is valid, and to determine whether the result of the hash processing is consistent with the hash value in the registration contract. If they are consistent, the identity of the user in the first hospital is legal and the authentication is successful.

[0077] Since the registration contract is stored in the consortium blockchain, the user's registration information will be replicated and stored on multiple blockchain nodes, providing redundant backup. The blockchain is maintained by multiple domains, so the blockchain is fault-tolerant and the system can tolerate the failure of certain nodes without affecting the function of the overall system. The blockchain solves the problem of single point failure through distributed node maintenance, while avoiding the problem of inefficiency that may occur in centralized systems.

[0078] In further embodiments, there is also provided: An electronic device includes a memory and a processor, and computer instructions stored in the memory and executed on the processor, wherein when the computer instructions are executed by the processor, the method described in Embodiment 1 is performed. For the sake of brevity, it will not be described in detail here.

[0079] It should be understood that in this embodiment, the processor may be a central processing unit CPU, and the processor may also be other general-purpose processors, digital signal processors DSP, application-specific integrated circuits ASIC, off-the-shelf programmable gate arrays FPGA or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.

[0080] The memory may include a read-only memory and a random access memory, and provide instructions and data to the processor. A portion of the memory may also include a non-volatile random access memory. For example, the memory may also store information about the device type.

[0081] A computer-readable storage medium is used to store computer instructions. When the computer instructions are executed by a processor, the method described in embodiment 1 is completed.

[0082] The method in the first embodiment can be directly embodied as a hardware processor, or a combination of hardware and software modules in the processor. The software module can be located in a mature storage medium in the field such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware. To avoid repetition, it will not be described in detail here.

[0083] A computer program product includes a computer program, and when the computer program is executed by a processor, the method described in the first embodiment is implemented.

[0084] The present invention also provides at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. The computer program product includes computer executable instructions, such as instructions included in a program module, which are executed in a device on a real or virtual processor of the target to perform the process / method as described above. Typically, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform specific tasks or implement specific abstract data types. In various embodiments, the functions of program modules can be combined or divided between program modules as needed. Machine executable instructions for program modules can be executed in local or distributed devices. In distributed devices, program modules can be located in local and remote storage media.

[0085] The computer program code for implementing the method of the present invention can be written in one or more programming languages. These computer program codes can be provided to the processor of a general-purpose computer, a special-purpose computer or other programmable data processing device, so that the program code, when executed by the computer or other programmable data processing device, causes the function / operation specified in the flow chart and / or block diagram to be implemented. The program code can be executed completely on a computer, partially on a computer, as an independent software package, partially on a computer and partially on a remote computer or completely on a remote computer or server.

[0086] In the context of the present invention, computer program codes or related data may be carried by any appropriate carrier to enable a device, apparatus or processor to perform the various processes and operations described above. Examples of carriers include signals, computer readable media, etc. Examples of signals may include electrical, optical, radio, acoustic or other forms of propagation signals, such as carrier waves, infrared signals, etc.

[0087] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with this embodiment can be implemented in electronic hardware or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0088] Although the above describes the specific implementation mode of the present invention in conjunction with the accompanying drawings, it is not intended to limit the scope of protection of the present invention. Those skilled in the art should understand that various modifications or variations that can be made by those skilled in the art on the basis of the technical solution of the present invention without creative work are still within the scope of protection of the present invention.

Claims

1. A cross-domain authentication method for medical data based on blockchain, characterized in that: The method is used for identity authentication between a first hospital in a first domain and a second hospital in a second domain, wherein a first domain committee of the first domain and a second domain committee of the second domain are respectively used as nodes on a consortium blockchain, and all domain committees on the consortium blockchain jointly run a Byzantine fault-tolerant protocol, and the method comprises: The user in the second hospital accepts the transfer initiated by the user in the first hospital and stores the account of the user in the first hospital; The second domain committee calls the registration contract to obtain the registration status of the account of the user in the first hospital in the domain to which the user belongs in the second hospital; If the registration status of the account of the user in the first hospital is valid in the domain to which the user in the second hospital belongs, the user in the second hospital performs hash processing on the user in the first hospital. If the result of the hash processing is consistent with the hash value in the registration contract, the identity of the user in the first hospital is legal and the authentication is successful.

2. A cross-domain authentication method for medical data based on blockchain as claimed in claim 1, characterized in that: Before the user in the first hospital initiates a transfer to the user in the second hospital, the method further includes: The user in the first hospital calls a contract function to check whether the registration time in the domain where the user in the second hospital is located has expired; If the registration time is valid, the domain where the user is located in the second hospital calls the blockchain contract function to check whether the user in the first hospital belongs to its domain; If yes, then the domain where the user is located in the second hospital sends an identity update request to the domain where the user is located in the first hospital; When the domain where the user is located in the second hospital obtains the signature and updated validity period returned by the domain where the user is located in the first hospital, the registration contract is called and the registration contract is run to start the transaction; Update the node ledger and return it to users in the First Hospital through the Byzantine fault-tolerant consensus mechanism.

3. A cross-domain authentication method for medical data based on blockchain as claimed in claim 1, characterized in that: The user in the second hospital accepts the transfer initiated by the user in the first hospital and stores the account of the user in the first hospital, further comprising: The user in the second hospital calls the registration contract to obtain the access control and registration information of the user in the second hospital; When the user in the second hospital registers in the second domain where the second domain committee is located and the registration status is valid, the user in the second hospital hashes the identity identifier of the user in the first hospital. If the result of the hash processing is consistent with the hash value returned by the registration contract, the identity of the user in the first hospital is legal and the authentication is successful.

4. A cross-domain authentication method for medical data based on blockchain as claimed in claim 1, characterized in that: When a new user registers, specifically: If the registrant is not registered in any domain other than the domain to which it corresponds, the registrant submits a registration request to the domain committee; If a registered user submits a registration request to the corresponding domain committee, the domain committee corresponding to the registered user will use its own private key to encrypt the hash value of the registered user's account address and identity identifier, generate a digital signature, and use the registered user information and the generated digital signature as input to the smart contract, calling the smart contract to complete the registration of the registered user; If a registered user submits a registration request to a domain committee other than the domain committee to which he or she corresponds, the domain committee to which the registered user corresponds shall submit the registration request to the other domain committee, obtain the signature, and use the registered user information and the obtained signature as the input of the smart contract, and call the smart contract to complete the registration of the registered user.

5. A cross-domain authentication method for medical data based on blockchain as claimed in claim 4, characterized in that: Call the smart contract to complete the registration of the registered user, specifically: Concatenate the registered user's account address and the hash value of the registered user's identity identifier to form a message; Calculate the first elliptic curve logarithm using the message and the public key of the corresponding domain of the registered user; Calculate the second elliptic curve logarithm using the generator and the signature generated by the corresponding domain committee for the registered user using its private key; If the first elliptic curve logarithm is equal to the second elliptic curve logarithm, the signature is valid, and the domain object is updated to complete the registration of the registered user's information.

6. A cross-domain authentication method for medical data based on blockchain as claimed in claim 5, characterized in that: If the first elliptic curve logarithm is equal to the second elliptic curve logarithm, the signature is valid, and the domain object is updated to complete the registration of the registered user's information, specifically: Get the domain object and the index of the last registered user; Store the registered user account address, user identity identifier hash value, expiration date and status in the corresponding positions of the access control table respectively; The alliance blockchain generates a smart contract address and returns the generated smart contract address to the registered user for storage.

7. A blockchain-based cross-domain medical data authentication method as claimed in claim 1, characterized in that: Before the first hospital and the second hospital establish communication, a session key negotiation is performed, specifically including: The first hospital and the second hospital exchange public keys obtained after registration on the alliance blockchain; The first hospital randomly selects a first number, and uses the public key obtained after the first hospital registers on the hospital alliance blockchain to asymmetrically encrypt the first number and the timestamp to obtain a ciphertext and sends the ciphertext to the second hospital; The second hospital decrypts the ciphertext received from the first hospital to extract the first number and the timestamp, and randomly selects a second number, and asymmetrically encrypts the second number and the corresponding timestamp using the public key obtained after the second hospital registers on the hospital alliance blockchain, obtains the ciphertext and sends it to the first hospital; The first hospital decrypts the ciphertext received from the second hospital and extracts the second number and the corresponding timestamp; The first hospital and the second hospital use the first number and the second number as inputs of a key generator to generate a session key.

8. A blockchain-based cross-domain medical data authentication system, characterized in that: It includes domains corresponding to at least two hospitals. The domain committees in each domain serve as nodes on the alliance blockchain. All domain committees on the alliance blockchain jointly run a Byzantine fault-tolerant protocol. When users in two hospitals perform cross-domain identity authentication, the specific steps are as follows: Users in the second hospital: used to accept transfers initiated by users in the first hospital and store the accounts of users in the first hospital; The second domain committee is used to call the registration contract to obtain the registration status of the account of the user in the first hospital in the domain to which the user belongs in the second hospital; and determine whether the registration status of the account of the user in the first hospital in the domain to which the user belongs in the second hospital is valid; The user in the second hospital is used to perform hash processing on the user in the first hospital when the registration status of the account of the user in the first hospital in the domain to which the user in the second hospital belongs is valid, and to determine whether the result of the hash processing is consistent with the hash value in the registration contract. If they are consistent, the identity of the user in the first hospital is legal and the authentication is successful.

9. An electronic device, characterized in that: The method comprises a memory and a processor and computer instructions stored in the memory and executed on the processor, wherein when the computer instructions are executed by the processor, the method according to any one of claims 1 to 7 is completed.

10. A computer-readable storage medium, characterized in that: Used to store computer instructions, which, when executed by a processor, complete the method described in any one of claims 1 to 7.

Images