Medical data security sharing method and system based on block chain

Abstract

The invention discloses a medical data security sharing method and system based on a block chain, and relates to the field of data security, and the method comprises the steps: constructing a medical data sharing block chain system; encrypting the medical data of the user by adopting a fully homomorphic encryption algorithm; organizing the encrypted medical data by adopting a Merkle tree structure, encrypting and storing the medical data in the Merkle tree through an IPFS distributed storage system provided by a third-party service node, and storing the root hash of the Merkle tree and the encrypted IPFS address of the medical data as index information of the medical data in a block chain through a medical data uplink smart contract; calling a privacy protection smart contract to verify the identity and authority of the requester by using a zero-knowledge proof method; according to index information of the request data, obtaining corresponding Merkle tree root hash and an encrypted IPFS address of the medical data, and returning the Merkle tree root hash and the encrypted IPFS address to the requester; in view of insufficient privacy protection in a medical data sharing process in the prior art, the security of privacy data is improved.

Description

Technical Field

[0001] The present application relates to the field of data security, and in particular to a blockchain-based medical data security sharing method and system. Background Art

[0002] With the rapid development of medical information technology, medical and health big data is increasingly used in disease prevention, clinical medicine, drug development, medical insurance and other fields, and its potential value is being gradually explored. The aggregation and sharing of medical and health big data will help improve the efficiency and quality of medical services, promote medical research innovation, and promote the development of the health industry. While vigorously promoting the aggregation and sharing of medical data, the privacy and security of medical data has also become a major technical challenge that needs to be solved urgently.

[0003] Medical data contains various sensitive privacy information such as patient identity information, disease diagnosis and treatment information, and genomic information. Once leaked or stolen, it will cause irreparable privacy infringement and economic losses to patients. Although the traditional hospital-based medical data island management model protects data security to a certain extent, it is difficult to support cross-institutional and cross-regional data circulation and sharing, which hinders the release of the value of medical big data. In recent years, with the development of privacy protection technology, researchers have begun to explore the application of emerging technologies such as privacy computing and federated learning in the field of medical data sharing, so that data can be circulated "available but invisible" under the premise of protecting privacy. While achieving certain results, it still faces many challenges.

[0004] Existing privacy protection technologies usually perform heavy desensitization or encryption on the original data. Although this protects privacy and security, it also loses the data's own semantic information and associated information, making it difficult to support the in-depth use of medical data and the full mining of data value. Summary of the invention

[0005] In response to the problem of insufficient privacy protection in the medical data sharing process in the prior art, the present application provides a blockchain-based medical data security sharing method and system. By constructing a medical data sharing blockchain system based on a consortium chain architecture, the medical data is encrypted using fully homomorphic encryption, and the ciphertext medical data is organized using Merkle trees to form a multi-level index, and the Merkle trees are stored in IPFS. At the same time, smart contracts are called to verify data call requests and identity authority verification, etc., thereby improving the security of private data.

[0006] The purpose of this application is achieved through the following technical solutions.

[0007] The present application provides a method for securely sharing medical data based on blockchain, including: building a medical data sharing blockchain system based on a consortium chain architecture, wherein the blockchain system is composed of hospital nodes, regulatory nodes, and third-party service nodes, and a PBFT consensus algorithm is used to reach a consensus; the hospital node uses a fully homomorphic encryption algorithm to encrypt the user's medical data to obtain the encrypted medical data, and calls a medical data on-chain smart contract to upload the encrypted medical data to the blockchain; the hospital node uses a Merkle tree structure to organize the encrypted medical data, encrypts and stores the medical data in the Merkle tree through an IPFS distributed storage system provided by a third-party service node, and uses the root hash of the Merkle tree and the encrypted IPFS address of the medical data as the medical data The index information is stored in the blockchain through the medical data on-chain smart contract; the medical data call smart contract receives the data call request initiated by the medical data requester, and calls the privacy protection smart contract to verify the identity and authority of the requester using the zero-knowledge proof method; after the identity and authority of the requester are verified, the medical data call smart contract obtains the corresponding Merkle tree root hash and the encrypted IPFS address of the medical data according to the index information of the requested data, and returns it to the requester; the requester uses the obtained Merkle tree root hash and the encrypted IPFS address of the medical data to obtain the encrypted medical data through IPFS, and after verifying the data integrity through the Merkle tree, obtains the data decryption key from the blockchain system, decrypts the encrypted medical data, and obtains the plaintext medical data.

[0008] Among them, the PBFT consensus algorithm (Practical Byzantine Fault Tolerance) is a practical Byzantine fault-tolerant algorithm used to reach consensus in distributed systems. The PBFT algorithm assumes that when the total number of nodes is 3f+1, at most f nodes are allowed to fail or behave maliciously. The Merkle Tree is a hash binary tree that is often used to efficiently verify the integrity of large-scale data. The leaf nodes of the Merkle tree contain the hash values ​​of the data blocks, and the non-leaf nodes are obtained by recursively hashing the hash values ​​of their child nodes. The root hash (MerkleRoot) of the Merkle tree represents the encrypted fingerprint of the entire data set. IPFS (InterPlanetary File System) is a distributed file storage and sharing system that aims to build a permanent, decentralized Web. IPFS uses content addressing instead of traditional location addressing, and files are identified and accessed by their encrypted hash values ​​instead of locations. The nodes in the IPFS network are interconnected to form a peer-to-peer mesh structure to achieve distributed storage and fast retrieval of files. Consortium Blockchain is a blockchain architecture between public and private chains, which is jointly maintained and managed by multiple pre-selected participants. Consortium chains have an access mechanism, and only authorized nodes can join the network and participate in the consensus process. Participants in consortium chains are usually business-related institutions or organizations, who jointly formulate rules and protocols to achieve trusted data sharing and business collaboration. Compared with public chains, consortium chains provide better scalability, privacy protection, and compliance; compared with private chains, consortium chains achieve multi-party participation and decentralized governance.

[0009] Furthermore, a medical data sharing blockchain system based on the alliance chain architecture is constructed. The blockchain system consists of hospital nodes, regulatory nodes and third-party service nodes, and the PBFT consensus algorithm is used to reach consensus, including: deploying hospital nodes created by various medical institutions according to their respective medical data sharing needs; deploying regulatory nodes created by medical regulatory agencies, which are used to formulate permission management strategies for medical data sharing and supervise the compliance of medical data sharing behaviors; deploying third-party service nodes created by independent third-party service agencies, which are used to provide an IPFS distributed storage system to encrypt and store medical data in the Merkle tree organized by hospital nodes; between hospital nodes, regulatory nodes and third-party service nodes, based on the alliance chain networking method, the PBFT consensus algorithm is used to achieve distributed consensus of the blockchain system; based on the Fabric blockchain platform, medical data chain smart contracts, medical data call smart contracts and privacy protection smart contracts are deployed in the blockchain system.

[0010] Among them, Fabric blockchain platform (Hyperledger Fabric) is an open source enterprise-level permissioned blockchain platform, developed by the Linux Foundation, aiming to provide enterprises and organizations with a flexible, scalable and secure blockchain solution. Fabric adopts a modular architecture design, supports plug-in consensus mechanism, identity management and encryption algorithm, and adapts to different business scenarios and needs. In the medical data sharing system based on the Fabric blockchain platform, multiple smart contracts can be deployed, including medical data chain smart contract, medical data call smart contract and privacy protection smart contract, to achieve the safe chain, access control and privacy protection of medical data. The medical data chain smart contract is responsible for receiving the encrypted medical data uploaded by the hospital node, storing it on the blockchain, and generating the corresponding index information. The medical data call smart contract is responsible for receiving the call request from the data requester, verifying the legitimacy of the request, and returning the corresponding medical data according to the index information of the request. The privacy protection smart contract is responsible for verifying the identity and authority of the requester, ensuring that only the authorized requester can access the corresponding medical data and protect the privacy of the patient. Specifically, the medical data chain smart contract refers to the smart contract deployed on the blockchain for medical data chain transactions. Smart contracts encapsulate the main logic of medical data on-chain, including verification and storage of uploaded encrypted medical data and data index information. When medical institutions encrypt and upload medical data to the blockchain, the medical data on-chain smart contract will be called. The contract receives encrypted medical data, the root hash of the Merkle tree, the IPFS address of the medical data, and other information, checks the data format and integrity, and writes the verified data into the blockchain ledger, while storing the data index information (such as Merkle root hash, IPFS address) in the blockchain state database. The contract also triggers the medical data on-chain event, broadcasting the hash time-locked data key shards to the relevant authorized nodes. The medical data call smart contract refers to a smart contract deployed on the blockchain for processing medical data call requests. The smart contract encapsulates the main process of data call, including receiving data call requests, verifying the identity and authority of the requester, retrieving and returning the data storage address according to the data index, etc. When the data requester needs to call medical data, it will initiate a data call request to the medical data call smart contract. The contract will first check the request format and integrity, and then call the privacy protection smart contract to verify the identity and authority of the requester. For requests that pass verification, the contract will retrieve the corresponding data index information (Merkle tree IPFS address, encrypted data IPFS address) from the blockchain's state database based on the Merkle root hash of the requested data, and return it to the requester. The requester can use these addresses to obtain and decrypt data on the IPFS network. For requests that fail verification, the contract will reject the request and return the reason for failure.Privacy-preserving smart contracts refer to smart contracts deployed on blockchain for medical data privacy protection related functions. Smart contracts encapsulate the main mechanisms of privacy protection, including fully homomorphic key generation and distribution, requester identity and authority verification, zero-knowledge proof verification, etc. Privacy-preserving smart contracts are used in both the on-chain and call processes of medical data. When the data is on-chain, medical institutions need to obtain the fully homomorphic public key from the contract to encrypt the data, and at the same time obtain the private key shard generated by the contract. When the data call request is verified, the medical data call contract will call the contract, use the PKI system to verify whether the identity of the requester is authentic and legal, and use zero-knowledge proof to verify whether the requester's authority is satisfied. In addition, when the number of authorized nodes reaches the statutory number, the privacy-preserving smart contract is also responsible for coordinating each node to submit private key shards and restore the complete data decryption private key.

[0011] Furthermore, the hospital node uses a fully homomorphic encryption algorithm to encrypt the user's medical data to obtain the encrypted medical data, and calls the medical data on-chain smart contract to upload the encrypted medical data to the blockchain, including: the hospital node obtains the fully homomorphic public key and the private key shard generated by the privacy protection smart contract based on threshold secret sharing of the fully homomorphic private key shard from the privacy protection smart contract, and uses the fully homomorphic public key to encrypt the user's medical data to obtain the encrypted medical data; the hospital node organizes the encrypted medical data based on the Merkle tree structure and uploads it to the IPFS distributed storage system provided by the third-party service node. The system encrypts and stores the medical data in the Merkle tree to obtain the encrypted IPFS address of the medical data; the hospital node calls the medical data chain smart contract to upload the encrypted medical data, the root hash of the Merkle tree, the encrypted IPFS address of the medical data, and the private key shards locked by the hash time to the blockchain; the medical data chain smart contract writes the encrypted medical data into the blockchain ledger, stores the root hash of the Merkle tree and the encrypted IPFS address of the medical data as the index information of the medical data in the blockchain, and broadcasts the private key shards locked by the hash time to the corresponding authorized nodes.

[0012] Furthermore, the hospital node obtains the fully homomorphic public key and the private key shard generated by the privacy-preserving smart contract based on threshold secret sharing of the fully homomorphic private key shard from the privacy-preserving smart contract, and uses the fully homomorphic public key to encrypt the user's medical data to obtain the encrypted medical data, including: the hospital node initiates a request to obtain the fully homomorphic encrypted public key and private key shard by calling the privacy-preserving smart contract in the blockchain system; the blockchain system reaches a consensus among the hospital node, the supervision node and the third-party service node through the PEFT consensus algorithm, and records the requested transaction in the blockchain ledger; the privacy-preserving smart contract uses the fully homomorphic encryption algorithm to encrypt the user's medical data. A fully homomorphic encrypted public-private key pair is generated by the method, and the (t, n) threshold secret sharing scheme is used to shard the fully homomorphic encrypted private key to generate n private key shards; the hospital node obtains the fully homomorphic encrypted public key and the private key shard corresponding to the corresponding hospital node from the privacy-preserving smart contract. The complete fully homomorphic encrypted private key can be restored only when and only when at least t nodes in the blockchain system collaborate to provide their own private key shards; the hospital node reads the user's plaintext medical data from the database of the hospital's internal system, and uses the fully homomorphic encryption public key obtained from the privacy-preserving smart contract to perform fully homomorphic encryption on the plaintext data to generate encrypted medical data.

[0013] Furthermore, the hospital node uses a Merkle tree structure to organize the encrypted medical data, encrypts and stores the medical data in the Merkle tree through the IPFS distributed storage system provided by the third-party service node, and uses the root hash of the Merkle tree and the encrypted IPFS address of the medical data as the index information of the medical data and stores them in the blockchain through the medical data on-chain smart contract, including: after obtaining the ciphertext medical data after full homomorphic encryption, the hospital node uses the Merkle tree data structure to organize the ciphertext medical data and construct a Merkle tree; wherein, the leaf nodes of the Merkle tree store the ciphertext medical data, the non-leaf nodes store the concatenated hash of the hash values ​​of the corresponding child nodes, and the root node stores the hash value of the entire Merkle tree; the hospital node serializes the Merkle tree in a depth-first or breadth-first manner to obtain a serialized string of the Merkle tree; the hospital node calls the third-party service node to provide The IPFS distributed storage interface provided by the hospital uploads the serialized string of the Merkle tree to the IPFS network for encrypted storage, and obtains the IPFS address of the serialized string of the Merkle tree; the hospital node calls the medical data chain smart contract, and uploads the index information consisting of the root hash of the Merkle tree, the IPFS address of the Merkle tree, and the IPFS address of the ciphertext medical data to the chain, and triggers the medical data chain smart contract to store the index information in the blockchain ledger; wherein, the blockchain system reaches a consensus on the medical data chain transaction and records it on the chain; the medical data chain smart contract stores the key-value pairs consisting of the Merkle tree root hash, the Merkle tree IPFS address, and the ciphertext medical data IPFS address in the blockchain ledger, and uses the Merkle tree root hash as the primary index, and the Merkle tree IPFS address and the ciphertext medical data IPFS address as auxiliary indexes for retrieval, verification, and recovery of medical data.

[0014] The entire Merkle tree structure is stored in IPFS in the form of a serialized string, rather than just storing the leaf node data of the Merkle tree. In this way, the entire Merkle tree structure can be obtained through the IPFS address of the Merkle tree during retrieval, which facilitates the reconstruction and verification of the Merkle tree and improves the efficiency of data integrity verification. The Merkle tree root hash, the Merkle tree IPFS address, and the ciphertext medical data IPFS address are stored in the blockchain as a composite index, forming a multi-level index structure. The Merkle tree root hash serves as the primary index, providing an anchor point for medical data integrity verification; the Merkle tree IPFS address provides a retrieval entry for the Merkle tree structure; and the ciphertext medical data IPFS address provides a retrieval entry for the ciphertext of medical data. This composite index structure can quickly retrieve and locate medical data at different granularities. The medical data index information stored in the blockchain contains the storage location of the Merkle tree structure and ciphertext data, realizing a trusted index of medical data based on the blockchain. The tamper-proof and auditable features of blockchain ensure the integrity and accuracy of index information, provide a reliable data location and verification mechanism for medical data sharing, and improve the security and credibility of medical data sharing.

[0015] Furthermore, after obtaining the ciphertext medical data after full homomorphic encryption, the hospital node uses a Merkle tree data structure to organize the ciphertext medical data and construct a Merkle tree; wherein the leaf nodes of the Merkle tree store the ciphertext medical data, the non-leaf nodes store the concatenated hash of the hash values ​​of the corresponding child nodes, and the root node stores the hash value of the entire Merkle tree, including: the hospital node receives the ciphertext medical data after full homomorphic encryption, groups the ciphertext medical data according to a predetermined data grouping rule, and designates each group of ciphertext medical data as a leaf node of the Merkle tree; wherein the data grouping rule is set based on the type and size of the medical data; the hospital node applies a predetermined hash algorithm to the ciphertext medical data of each leaf node to perform a hash operation, and calculates the hash value of the leaf node as the unique identifier of the leaf node; the hospital node traverses The leaf nodes of the Merkle tree are paired in pairs according to a predetermined pairing rule, the hash values ​​of the paired nodes are concatenated, and a predetermined hash algorithm is applied to the concatenated result to perform a hash operation to calculate the hash value of the corresponding parent node; the hospital node recursively executes the pairing, concatenation and hash operation steps until the hash value of the root node of the Merkle tree is calculated; wherein the pairing rule is based on the construction algorithm of the Merkle tree, and the empty node uses a predetermined hash value to participate in the calculation; the hospital node constructs a hierarchical data structure of the Merkle tree based on the node hash value and parent-child relationship of the Merkle tree, and associates the structural information of the Merkle tree with the ciphertext medical data of the leaf node for storage; wherein the structural information of the Merkle tree includes the hash value of the node, the parent-child relationship between the nodes, and the position of the node in the Merkle tree.

[0016] Furthermore, the hospital node serializes the Merkle tree in a depth-first or breadth-first manner to obtain a serialized string of the Merkle tree; the hospital node uploads the serialized string of the Merkle tree to the IPFS network for encrypted storage by calling the IPFS distributed storage interface provided by the third-party service node, and obtains the IPFS address of the Merkle tree serialized string, including: the hospital node traverses the Merkle tree according to a predetermined traversal rule based on the constructed Merkle tree to generate a serialized representation of the Merkle tree; wherein the traversal rule includes a depth-first traversal or a breadth-first traversal, and the serialized representation includes the node hash values ​​of the Merkle tree, the parent-child relationship between the nodes, and the hierarchical structure information of the nodes; the hospital node formats the serialized representation of the Merkle tree to generate a serialized string of the Merkle tree; wherein the format of the serialized string is defined according to a predetermined serialization protocol, and includes the complete structural information and Node data; the hospital node establishes a connection with the third-party service node through the network interface, calls the IPFS distributed storage interface provided by the third-party service node, and sends the serialized string of the Merkle tree as uploaded data to the IPFS network; wherein, the IPFS distributed storage interface is based on the IPFS protocol and is used for distributed storage and retrieval of data; the third-party service node receives the Merkle tree serialized string uploaded by the hospital node, encrypts and segments the serialized string, and distributes the segmented data blocks to multiple nodes of the IPFS network, and generates an IPFS address of the Merkle tree serialized string; wherein, the IPFS address is generated based on the content addressing method, and uniquely identifies the storage location of the Merkle tree serialized string; the third-party service node returns the generated IPFS address of the Merkle tree serialized string to the hospital node; the hospital node receives and stores the IPFS address of the Merkle tree serialized string as a retrieval credential for obtaining the complete structure of the Merkle tree.

[0017] Furthermore, the medical data call smart contract receives a data call request initiated by a medical data requester, and calls the privacy protection smart contract to verify the identity and authority of the requester using a zero-knowledge proof method, including: the medical data requester initiates a data call request to the medical data call smart contract, and the data call request includes the identity information of the requester, the Merkle tree root hash of the requested data, the purpose of use of the requested data, and zero-knowledge proof parameters; wherein the identity information of the requester is composed of the digital identity certificate and digital signature of the requester, the Merkle tree root hash of the requested data is obtained by the requester according to the constructed multi-level index structure of medical data, and the purpose of use of the requested data indicates that the requester calls the medical data. The purpose of medical data, zero-knowledge proof parameters are generated by the requester according to the corresponding data call authority; the medical data call smart contract receives the data call request and verifies the format and integrity of the data call request; after verification, the medical data call smart contract calls the privacy protection smart contract and passes the identity information in the data call request, the Merkle tree root hash of the request data, the purpose of the request data and the zero-knowledge proof parameters to the privacy protection smart contract; the privacy protection smart contract uses the PKI system of the medical data sharing blockchain system to verify the authenticity and legitimacy of the requester's identity information; the KPI system is based on digital certificates and digital signature mechanisms to verify the digital identity of the requester. Whether the identity certificate is issued by a trusted CA organization, and whether the digital signature of the requester matches the corresponding digital identity certificate; the privacy-preserving smart contract accesses the access control list of the medical data sharing blockchain system, and obtains the corresponding data call authority of the requester based on the identity information of the requester; among them, the access control list is formulated and maintained by the regulatory node according to the regulatory requirements of medical data sharing, and stipulates the data call authority and constraints of data callers with different identities; the privacy-preserving smart contract verifies whether the purpose of the requested data is in line with the data call authority of the requester, and verifies whether the zero-knowledge proof parameters match the data call authority of the requester; the privacy-preserving smart contract sends a request to the medical data according to the verification results. The calling smart contract returns the identity and permission verification results of the requester; for requests that pass the verification, the privacy protection smart contract returns the confirmation information of the verification; for requests that fail the verification, the privacy protection smart contract returns the reason for the verification failure; for requests that pass the identity and permission verification, the medical data calling smart contract calls the constructed medical data multi-level index structure according to the Merkle tree root hash of the request data in the data call request, and obtains the Merkle tree IPFS address and ciphertext medical data IPFS address corresponding to the request data; for requests that fail the identity and permission verification, the medical data calling smart contract rejects the data call request and returns the reason for the request failure to the requester.

[0018] Among them, the PKI system (Public Key Infrastructure) is a security infrastructure based on public key cryptography, which is used to manage the life cycle of digital certificates and realize functions such as identity authentication, data encryption and digital signature. The PKI system consists of multiple components, including certificate authority (CA), registration authority (RA), certificate revocation list (CRL), certificate repository, etc. The PKI system binds the identity of an entity to its public key through a digital certificate to ensure the identity authenticity and data integrity of both parties in communication. In the medical data sharing blockchain system, the PKI system is used to verify the digital identity certificate and digital signature of the requester to ensure the legitimacy and non-repudiation of the requester's identity. The CA institution (Certificate Authority) is the core component of the PKI system and is responsible for issuing, managing and revoking digital certificates. As a trusted third party, the CA strictly reviews and verifies the identity of the certificate applicant to ensure that the identity information in the digital certificate matches the actual identity. The CA uses its own private key to digitally sign the digital certificate to ensure the authenticity and integrity of the certificate. The issuance of digital certificates follows strict certificate policies and certification practice statements, which stipulate the format, content, validity period, etc. of the certificate. In the medical data sharing blockchain system, the CA organization is responsible for issuing digital identity certificates to participants such as medical institutions, regulatory authorities, and data requesters, providing a trusted basis for identity authentication.

[0019] Furthermore, the privacy protection smart contract uses the PKI system of the medical data sharing blockchain system to verify the authenticity and legitimacy of the requester's identity information; the KPI system is based on digital certificates and digital signature mechanisms to verify whether the requester's digital identity certificate is issued by a trusted CA organization and whether the requester's digital signature matches the corresponding digital identity certificate, including: the privacy protection smart contract extracts the requester's digital identity certificate and digital signature from the data call request; the privacy protection smart contract accesses the PKI system of the medical data sharing blockchain system to obtain a list of digital certificates of the trusted CA organization; the privacy protection smart contract uses the public key of the trusted CA organization to verify the digital signature of the digital certificate. If the verification passes, it proves that the corresponding digital signature is generated by the private key corresponding to the digital identity certificate; if both the digital identity certificate and the digital signature are verified, the privacy protection smart contract confirms the authenticity and legitimacy of the requester's identity information, otherwise the privacy protection smart contract determines that the verification of the requester's identity information has failed.

[0020] Another aspect of the present application also provides a blockchain-based medical data security sharing system for executing a blockchain-based medical data security sharing method of the present application.

[0021] Compared with the prior art, the advantages of this application are:

[0022] The alliance chain is jointly participated and reached by multiple parties. No party can tamper with the data and rules alone, providing a safe and reliable infrastructure for medical data sharing. The introduction of hospital nodes, regulatory nodes, and third-party service nodes realizes the trusted collaboration of all parties involved in data sharing. The PBFT consensus algorithm ensures the consistency and tamper-proofness of the blockchain system.

[0023] The privacy protection strategy of the entire life cycle of medical data is adopted to protect patient privacy to the maximum extent. The hospital node uses fully homomorphic encryption to encrypt the medical data before uploading and circulating it, ensuring the confidentiality of the data during static storage and use. Fully homomorphic encryption allows direct analysis and processing of ciphertext, greatly expanding the scope of use of private data.

[0024] Merkle trees are used to build multi-level indexes of medical data to achieve fine-grained access control and data verification. Merkle trees can quickly locate and verify each piece of medical data. The requester can only call the data branch that it has access to, achieving fine-grained authorized access control. The root hash of the Merkle tree is stored on the chain to verify the integrity and accuracy of the returned data, ensuring that the data is not tampered with during use.

[0025] Storing Merkle trees and ciphertext data in IPFS solves the storage problem of massive medical data. As a distributed storage system, IPFS can carry massive medical data while ensuring the reliability and availability of the data. The hash and location information of the Merkle tree and ciphertext data are uploaded to the chain through smart contracts, which not only reduces the storage pressure of the blockchain, but also facilitates data retrieval.

[0026] Smart contracts are used to automate the data sharing process, improve sharing efficiency and reduce management costs. Key data on-chain, permission verification, data retrieval and other processes are automatically executed by smart contracts, reducing manual operations and improving the efficiency and security of data sharing. Data sharing rules are written into smart contracts and cannot be modified at will by any party, which facilitates supervision.

[0027] Zero-knowledge proof is used to verify the identity of the requester, which achieves precise control of permissions while protecting the privacy of the requester. Zero-knowledge proof allows the requester to prove to the smart contract that he has the corresponding attributes and permissions without providing sensitive information. After the privacy-preserving smart contract is verified, the requester's call request can be legally forwarded, achieving a balance between identity privacy protection and permission control. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] The present application will be further described in the form of exemplary embodiments, which will be described in detail by the accompanying drawings. These embodiments are not restrictive, and in these embodiments, the same number represents the same structure, wherein:

[0029] Figure 1 This is a schematic diagram of an exemplary application scenario of a blockchain-based medical data security sharing method according to some embodiments of the present application;

[0030] Figure 2 is an exemplary flow chart of a blockchain-based medical data security sharing method according to some embodiments of the present application;

[0031] Figure 3 is an exemplary flow chart of encrypting medical data and uploading it to a blockchain system according to some embodiments of the present application;

[0032] Figure 4 This is an exemplary flowchart for obtaining a primary index and a secondary index according to some embodiments of the present application. DETAILED DESCRIPTION

[0033] The method and system provided in the embodiments of the present application are described in detail below with reference to the accompanying drawings.

[0034] Figure 1 is a schematic diagram of an exemplary application scenario of a blockchain-based medical data security sharing method according to some embodiments of the present application. Figure 2This is an exemplary flow chart of a blockchain-based medical data security sharing method shown in some embodiments of the present application, including: building a medical data sharing blockchain system based on a consortium chain architecture, the blockchain system consists of hospital nodes, regulatory nodes and third-party service nodes, and using the PBFT consensus algorithm to reach a consensus; the hospital node uses a fully homomorphic encryption algorithm to encrypt the user's medical data to obtain the encrypted medical data, and calls the medical data chain smart contract to upload the encrypted medical data to the blockchain; the hospital node uses a Merkle tree structure to organize the encrypted medical data, and encrypts and stores the medical data in the Merkle tree through the IPFS distributed storage system provided by the third-party service node, and the root hash of the Merkle tree and the encrypted IPFS address of the medical data are linked together. The address is stored in the blockchain as the index information of the medical data through the medical data on-chain smart contract; the medical data call smart contract receives the data call request initiated by the medical data requester, and calls the privacy protection smart contract to verify the identity and authority of the requester using the zero-knowledge proof method; after the identity and authority of the requester are verified, the medical data call smart contract obtains the corresponding Merkle tree root hash and the encrypted IPFS address of the medical data according to the index information of the requested data, and returns it to the requester; the requester uses the obtained Merkle tree root hash and the encrypted IPFS address of the medical data to obtain the encrypted medical data through IPFS, and after verifying the data integrity through the Merkle tree, obtains the data decryption key from the blockchain system, decrypts the encrypted medical data, and obtains the plaintext medical data.

[0035] Build a consortium chain network, select Hyperledger Fabric as the underlying platform of the consortium chain, and build a permissioned chain network with the participation of multiple institutions. The network includes multiple hospital nodes, regulatory nodes and third-party service nodes, and the nodes are authenticated and authorized through CA services. The PBFT (Practical Byzantine FaultTolerance) consensus algorithm is used in the consortium chain to ensure the fault tolerance and consistency of the system through the confirmation of 3f+1 nodes. Deploy hospital nodes. Each medical institution deploys hospital nodes in the consortium chain network according to its own needs. Hospital nodes can use the SDK provided by Fabric (such as Java, Node.js) to develop client applications to interact with the blockchain network. Hospital nodes have the authority to store and query medical data on the blockchain and participate in the relevant business processes of medical data sharing. Deploy regulatory nodes. As the manager of the consortium chain, medical regulatory agencies deploy regulatory nodes in the network. Regulatory nodes manage the permissions of medical data by formulating access control policies (such as role-based access control) and supervise the life cycle of data. Regulatory nodes conduct compliance audits on data sharing behaviors by subscribing to medical data sharing transactions on the blockchain.

[0036] Deploy third-party service nodes. Independent third-party service agencies deploy service nodes in the alliance chain network. The service node integrates the IPFS distributed storage system to provide decentralized storage services for medical data. When the hospital node uploads the medical data (ciphertext) to IPFS, the service node is responsible for the encrypted storage and management of the data to ensure the confidentiality and integrity of the medical data. Based on the distributed consensus of PBFT, transaction requests in the blockchain network (such as medical data on-chain and access to data) need to be confirmed and sorted through the consensus algorithm. Using the PBFT consensus algorithm, the validity of the transaction is confirmed by voting by multiple nodes, and the transaction is packaged into blocks. The PBFT algorithm tolerates up to f Byzantine nodes through the confirmation of 3f+1 nodes to ensure the reliability of the system.

[0037] Deploy smart contracts. Develop smart contracts based on the chaincode provided by Fabric to implement various business logics for medical data sharing. Develop medical data on-chain contracts, responsible for medical data encryption, Merkle tree construction and IPFS storage. Develop medical data call contracts, responsible for processing data access requests, coordinating data retrieval and decryption. Develop privacy protection contracts, responsible for requester identity authentication, permission management and zero-knowledge proof verification. Deploy the developed smart contracts to the Fabric network, and call and interact through the SDK.

[0038] Figure 3 This is an exemplary flow chart of encrypting medical data and uploading it to the blockchain system according to some embodiments of the present application. Medical data is uploaded to the chain, a fully homomorphic encryption key is obtained, and the hospital node calls the privacy protection smart contract. The hospital node builds a client application through the Fabric SDK (such as Java, Node.js) to interact with the blockchain network. The hospital node calls the relevant functions of the privacy protection smart contract in the application, such as requestEncryptionKey(), to initiate a request to obtain a fully homomorphic encryption key. The request parameters include the identification information of the hospital node, the request timestamp, etc., which are used for identity authentication and anti-replay attacks. Consensus is reached and transaction records are recorded. The hospital node sends the key request as a transaction proposal to the endorsement node (such as other hospital nodes, regulatory nodes, and third-party service nodes) in the blockchain network. The endorsement node verifies the transaction proposal and executes the relevant logic in the privacy protection smart contract. Through the PBFT consensus algorithm, the endorsement node reaches a consensus on the transaction proposal and generates a transaction response. The hospital node sends the transaction response to the sorting node, which packages the transaction into blocks and broadcasts it to all nodes. All nodes update their local ledgers based on the consensus results and record the key request transaction in the blockchain.

[0039] Generate fully homomorphic encryption keys. After receiving the key request from the hospital node, the privacy-preserving smart contract triggers the fully homomorphic encryption key generation logic. The smart contract uses a fully homomorphic encryption algorithm (such as BGV, CKKS, etc.) to generate a pair of public and private keys. The public key is used for data encryption, and the private key is used for data decryption and homomorphic computing. Private key sharding and distribution. The smart contract uses a (t, n) threshold secret sharing scheme (such as Shamir secret sharing) to shard the fully homomorphic encryption private key. The private key is divided into n shards, of which at least t shards are required to recover the complete private key. The smart contract distributes the generated private key shards to the corresponding hospital nodes, and each hospital node obtains a unique shard. The private key shards are transmitted through a secure channel (such as TLS) to ensure the confidentiality of the shards. The hospital node obtains the key. The hospital node obtains the fully homomorphic encryption public key and the corresponding private key shard from the event or query result of the privacy-preserving smart contract. The public key is used for subsequent medical data encryption, and the private key shard is used to participate in the key recovery process. The hospital node stores the obtained public and private key shards securely locally, such as using a hardware security module (HSM) for protection.

[0040] Medical data encryption, reading plaintext medical data, hospital nodes read the user's plaintext medical data from the database through the API of the internal system or database query. Plaintext medical data includes sensitive information such as patients' personal information, medical records, examination reports, and medical orders. Using fully homomorphic public key encryption, hospital nodes use the fully homomorphic encryption public key obtained from the privacy protection smart contract to encrypt plaintext medical data. Use the encryption function of the fully homomorphic encryption algorithm (such as BGV, CKKS) to convert plaintext data into ciphertext. The encryption process is completed locally at the hospital node, and the plaintext data will not leave the internal environment of the hospital. Generate ciphertext medical data, and the encrypted medical data is called ciphertext data, which has homomorphic properties and allows calculations on ciphertext. The format of ciphertext data varies depending on the fully homomorphic encryption scheme selected, usually in polynomial or vector form. The hospital node securely stores the generated ciphertext medical data for subsequent on-chain storage and shared use.

[0041] Figure 4This is an exemplary flowchart for obtaining the primary index and the auxiliary index according to some embodiments of the present application. The hospital node uses the Merkle tree to organize the ciphertext data and stores it through IPFS. The ciphertext medical data is grouped. The hospital node receives the encrypted ciphertext medical data from the fully homomorphic encryption module. The data format can be JSON, XML or other agreed formats. According to the predetermined data grouping rules, the hospital node divides the ciphertext medical data into multiple groups. The grouping rules can be based on the following factors: Patient ID: Group the medical data of the same patient into a group. Time period: Group the medical data according to time dimensions such as the time of consultation and the time of examination, such as grouping by day, week, and month. Data type: Group according to the type of medical data (such as medical records, examination reports, doctor's orders, etc.). Data size: Group according to the size of the ciphertext medical data to ensure that the data size of each group is within a certain range. The grouping process can be implemented by programming, such as using Python's Pandas library or Java's StreamAPI to group and aggregate data. Each data group is regarded as a leaf node of the Merkle tree, and the data of the leaf node is the ciphertext medical data of the group.

[0042] Leaf node hash calculation, for each leaf node, the hospital node uses a predetermined hash algorithm to perform hash operations on the ciphertext medical data it contains. Common hash algorithms include SHA-256, SHA-3, BLAKE2, etc. It is crucial to choose a safe and reliable hash algorithm. The hash operation can be implemented using the built-in library of the programming language or a third-party library, such as Python's hashlib library or Java's MessageDigest class. The result of the hash operation is used as the hash value of the leaf node, which is used to uniquely identify the data fingerprint of the node. Construct a Merkle tree, and the hospital node pairs the leaf nodes in pairs according to the predetermined pairing rules. The pairing rules can be adjacent pairing or cross-layer pairing, etc. For each pair of paired nodes, their hash values ​​are concatenated to form a new string. The concatenated string is hashed using a predetermined hash algorithm to obtain the hash value of the parent node. The steps of pairing, concatenation, and hashing are recursively performed until the hash value of the root node of the Merkle tree is calculated. In the case where the number of leaf nodes is an odd number, a predetermined empty hash value can be used as an empty node to participate in pairing and calculation to maintain the balance of the Merkle tree. The construction process of the Merkle tree can be implemented using a recursive algorithm or an iterative algorithm to generate the structure of the tree based on the hash value of the node and the pairing rule.

[0043] The Merkle tree structure is stored, and the hospital node constructs a hierarchical data structure of the Merkle tree according to the node hash value and parent-child relationship of the Merkle tree. A tree data structure (such as a binary tree, a multi-branch tree) or a graph database (such as Neo4j) can be used to represent the structure of the Merkle tree. The structural information of the Merkle tree is associated with the ciphertext medical data of the leaf node and stored to establish a mapping relationship between the node and the data. The stored structural information includes the hash value of the node, the parent-child relationship between the nodes, and the position of the node in the Merkle tree (such as level, sequence number, etc.). The storage process can be implemented using a relational database (such as MySQL) or a non-relational database (such as MongoDB), and a suitable storage solution is selected according to specific performance and scalability requirements. Specifically, in this embodiment, a multi-branch tree is used to represent and store the Merkle tree, and a multi-branch tree node structure is defined. In order to represent the nodes of the Merkle tree, a data structure of a multi-branch tree node needs to be defined. Each node contains the following fields: hash: the hash value of the node, which is used to uniquely identify the node; level: the level of the node in the Merkle tree, the level of the root node is 0; index: the sequence number of the node in the current level, numbered from left to right, starting from 0; children: the node's child node list, storing pointers or references to child nodes; data: the data associated with the node, for leaf nodes, the IPFS address of the medical data is stored; for non-leaf nodes, this field is empty.

[0044] The multi-tree representation of the construction of the Merkle tree is that when the hospital node is on-chain, the corresponding multi-tree is constructed according to the Merkle tree structure calculated from the medical data. The construction process is as follows: create a root node, use the Merkle tree root hash as the hash value of the root node, the level is 0, and the sequence number is 0; traverse each layer of the Merkle tree, from top to bottom, from left to right: for the current node, find the corresponding node in the multi-tree according to its hash value as the parent node; create a child node of the current node and add the child node to the children list of the parent node; set the hash value, level (parent node level + 1), and sequence number (numbered from left to right at the current level) of the child node; if the current node is a leaf node, store the associated medical data IPFS address in the data field; repeat the above steps until all nodes of the Merkle tree are added to the multi-tree.

[0045] The constructed multi-branch tree needs to be persistently stored. You can choose a relational database (such as MySQL) or a non-relational database (such as MongoDB). The multi-branch tree data stored in the database can support flexible queries and Merkle tree reconstruction. For example: according to the hash value of the node, query the node's level, sequence number, associated data and other information; according to the node ID, query the ID list of its child nodes, and recursive query can restore the complete subtree structure; according to the hash value of the root node, query the node data of the entire Merkle tree and reconstruct the complete Merkle tree.

[0046] The Merkle tree is serialized, and the hospital node traverses the Merkle tree according to the predetermined traversal rules to generate a serialized representation of the tree. Common traversal rules include depth-first traversal (DFS) and breadth-first traversal (BFS), and the appropriate traversal method can be selected according to the needs. The serialized representation contains the node hash value of the Merkle tree, the parent-child relationship between the nodes, and the hierarchical structure information of the nodes. The serialized representation of the Merkle tree is formatted to generate a serialized string that is easy to store and transmit. The format of the serialized string can be JSON, XML, or a custom compact format, which is defined according to a predetermined serialization protocol. The serialization process can use the built-in serialization library of the programming language or implement the serialization logic by itself to convert the structure of the Merkle tree into a string representation. Specifically, in this embodiment, the Merkle tree is serialized using depth-first traversal (DFS) to define the Merkle tree node structure. In order to represent the nodes of the Merkle tree, it is necessary to define a node data structure. Each node contains the following fields: hash: the hash value of the node, used to uniquely identify the node; left: the hash value of the left child node, if there is no left child node, it is empty; right: the hash value of the right child node, if there is no right child node, it is empty; data: the data associated with the node, for leaf nodes, the IPFS address where medical data is stored; for non-leaf nodes, this field is empty.

[0047] Recursive depth-first traversal can be used to implement depth-first traversal of the Merkle tree. Define an auxiliary function dfs_serialize, which accepts the current node and serialized string as parameters, recursively traverses the Merkle tree and generates a serialized representation. First, determine whether the current node is empty. If it is empty, return the current serialized string directly. Otherwise, concatenate the hash value of the current node, the hash values ​​of the left and right child nodes, and the associated data into a node string according to a predetermined format and add it to the serialized string. Then, recursively traverse the left and right subtrees of the current node and append their serialized results to the serialized string. When the hospital node needs to serialize the Merkle tree, call the dfs_serialize function and pass in the root node of the Merkle tree and an empty string as the initial serialized string. The function recursively traverses the entire Merkle tree to generate a complete serialized representation. The generated serialized string can be stored and transmitted as required. It can be written to a file, a database, or transmitted to other nodes over the network. The receiver can parse the string according to the predetermined serialization format and reconstruct the original Merkle tree structure.

[0048] Upload the Merkle tree to IPFS. The hospital node establishes a connection with the third-party IPFS service node through the network interface. The HTTP / HTTPS protocol or the dedicated API interface provided by IPFS can be used. The hospital node uses the serialized string of the Merkle tree as the uploaded data and sends it to the upload interface of the IPFS service node through a POST request. After receiving the upload request, the IPFS service node processes the received serialized string: encrypt the serialized string. Symmetric encryption algorithms (such as AES) or asymmetric encryption algorithms (such as RSA) can be used to encrypt the data to ensure the confidentiality of the data. The encrypted data is segmented into multiple fixed-size data blocks, each of which has a unique content identifier (CID). The segmented data blocks are distributed and stored on multiple nodes of the IPFS network to achieve data redundancy and reliability. IPFS generates a unique IPFS address based on content addressing. The address is calculated by the CID of the data block and is used to identify the storage location of the Merkle tree serialized string. The IPFS service node returns the generated IPFS address to the hospital node as a response to the successful upload.

[0049] Obtain the IPFS address. After the hospital node receives the IPFS address returned by the IPFS service node, it stores it in the local database or file system. The IPFS address is used as a retrieval credential for obtaining the complete structure of the Merkle tree. The hospital node can retrieve the serialized string of the Merkle tree from the IPFS network through the address. The hospital node can store the IPFS address in association with the corresponding metadata (such as patient ID, timestamp, etc.) to facilitate subsequent query and management. Store index information on the chain. The hospital node calls the medical data chain smart contract pre-deployed on the blockchain network to submit the root hash value of the Merkle tree, IPFS address and other index information to the blockchain. After receiving the index information submitted by the hospital node, the smart contract stores it in the blockchain ledger. The consensus mechanism of the blockchain network ensures the immutability and traceability of the index information, and multiple nodes participate in verifying and recording the submission of index information. The smart contract can provide a query interface, allowing other nodes in the blockchain network to query the corresponding index information through the root hash value or IPFS address of the Merkle tree. Other nodes can verify the integrity of medical data through index information, such as comparing the locally calculated Merkle tree root hash value with the root hash value stored on the chain. If the complete Merkle tree structure and ciphertext data are required, other nodes can retrieve the corresponding serialized string from the IPFS network according to the IPFS address in the index information.

[0050] The hospital node calls the medical data chain smart contract, uploads the index information consisting of the Merkle tree root hash, the Merkle tree IPFS address, and the ciphertext medical data IPFS address to the chain, and triggers the medical data chain smart contract to store the index information in the blockchain ledger; wherein, the blockchain system reaches a consensus on the medical data chain transaction and records it on the chain; the medical data chain smart contract stores the key-value pairs consisting of the Merkle tree root hash, the Merkle tree IPFS address, and the ciphertext medical data IPFS address in the blockchain ledger, and uses the Merkle tree root hash as the primary index, and the Merkle tree IPFS address and the ciphertext medical data IPFS address as auxiliary indexes for medical data retrieval, verification, and recovery.Including: the medical data on-chain smart contract receives the medical data on-chain transaction initiated by the hospital node, obtains the Merkle tree root hash, Merkle tree IPFS address and ciphertext medical data IPFS address carried in the transaction; among them, the Merkle tree root hash is calculated by the hospital node when building the Merkle tree, the Merkle tree IPFS address is obtained by the hospital node after uploading the Merkle tree serialized string to the IPFS network, and the ciphertext medical data IPFS address is generated by the third-party service node after uploading the ciphertext medical data to the IPFS network; the medical data on-chain smart contract receives the received medical data Verify the on-chain transaction to check the compliance of the transaction format and the validity of the transaction parameters; after verification, the medical data on-chain smart contract packages the Merkle tree root hash, Merkle tree IPFS address and ciphertext medical data IPFS address into a key-value pair, and writes the key-value pair into the blockchain ledger; the key of the key-value pair is the Merkle tree root hash, and the value is the combination of the Merkle tree IPFS address and the ciphertext medical data IPFS address; the consensus node of the blockchain system confirms the medical data on-chain transaction, packages the medical data on-chain transaction into a block, and links the block to the main chain of the blockchain, completing The medical data chain transaction is confirmed and recorded; the consensus confirmation process is based on the consensus algorithm of the blockchain, which ensures that the medical data chain transaction cannot be tampered with and is traceable; the medical data chain smart contract is based on the key-value pairs stored in the blockchain ledger to build a multi-level index structure for medical data; the Merkle tree root hash is used as the primary index, and the Merkle tree IPFS address and the ciphertext medical data IPFS address are used as auxiliary indexes; the multi-level index structure allows for rapid retrieval and positioning of medical data based on the Merkle tree root hash, the Merkle tree IPFS address and the ciphertext medical data IPFS address; medical data The on-chain smart contract provides interfaces for retrieval, verification and recovery of medical data. The retrieval interface allows querying the corresponding medical data based on the Merkle tree root hash, Merkle tree IPFS address or ciphertext medical data IPFS address. The verification interface allows verification of the integrity and consistency of medical data based on the Merkle tree root hash and Merkle tree IPFS address. The recovery interface allows obtaining the Merkle tree serialized string from the IPFS network based on the Merkle tree IPFS address, reconstructing the Merkle tree structure, and obtaining ciphertext medical data from the IPFS network based on the ciphertext medical data IPFS address.

[0051] The medical data access request includes: the medical data requester initiates a data call request, the requester prepares identity information, and the requester applies for a digital identity certificate from a trusted CA organization through the PKI system of the medical data sharing blockchain system. The CA organization verifies the identity information of the requester, such as name, organization, position, etc., and issues a corresponding digital identity certificate. The digital identity certificate contains the public key, identity information and digital signature of the CA organization of the requester, which is used to verify the authenticity of the identity of the requester. The requester uses the private key corresponding to the digital identity certificate to generate a digital signature to prove that the requester owns the digital identity certificate and signs the request content. The requester obtains the Merkle tree root hash of the requested data, and the requester determines the scope of medical data to be called according to the multi-level index structure of medical data constructed in step S3. The requester accesses the medical data sharing blockchain system to query the Merkle tree root hash value corresponding to the required data. The Merkle tree root hash value uniquely identifies the integrity and source of the requested data, which is used for subsequent data verification and retrieval.

[0052] The requester shall explain the purpose of using the requested data. The requester shall specify the specific purpose of calling the medical data based on actual needs, such as medical research, disease diagnosis, clinical decision support, etc. The purpose of use shall comply with the regulatory requirements and ethical standards for medical data sharing and shall not be used for illegal or improper purposes. The requester generates zero-knowledge proof parameters. The requester generates proof parameters using the zero-knowledge proof algorithm based on the corresponding data call permissions. The zero-knowledge proof parameters include the public key of the prover (requester), the proof content (such as the requester has specific attributes or meets specific conditions), and random numbers. The generation process of the proof parameters ensures that it can prove that the requester does have the corresponding permissions without leaking sensitive information.

[0053] The requester packages the data call request. The requester packages the prepared identity information (digital identity certificate and digital signature), the Merkle tree root hash of the requested data, the purpose of the requested data, and the zero-knowledge proof parameters into a complete data call request. The data call request is organized in a specific format, such as JSON or XML format, to facilitate subsequent transmission and parsing. The requester sends the data call request. The requester sends the packaged data call request to the smart contract through the interactive interface provided by the medical data call smart contract. The interactive interface can be a WebAPI, an RPC interface, or a dedicated interactive protocol for the smart contract, depending on the implementation of the blockchain platform. The requester sends the data call request as a transaction to the blockchain network, which is received and processed by the medical data call smart contract.

[0054] The medical data call smart contract receives and verifies the request. The smart contract receives the data call request. The medical data call smart contract listens to transactions on the blockchain network and captures the data call request transaction sent by the requester. The smart contract parses the transaction content and extracts the data call request information sent by the requester. The smart contract verifies the request format and integrity. The smart contract checks whether the received data call request contains all the required fields, such as identity information, Merkle tree root hash, purpose of use, and zero-knowledge proof parameters, according to the predefined request format. The smart contract verifies whether the data type and length of each field meet the requirements to ensure that the request is in the correct format. The smart contract checks the integrity of the request to ensure that no necessary information is missing.

[0055] The smart contract passes the request information to the privacy protection smart contract. If the data call request passes the format and integrity verification, the medical data call smart contract passes the request information to the privacy protection smart contract. The medical data call smart contract sends the identity information, Merkle tree root hash, purpose of use and zero-knowledge proof parameters to the privacy protection smart contract through internal function calls or message passing mechanisms. After receiving the request information, the privacy protection smart contract begins further verification and processing. The privacy protection smart contract verifies the identity information of the requester, and the smart contract extracts the digital identity certificate and digital signature of the requester. The privacy protection smart contract extracts the digital identity certificate and digital signature of the requester from the received data call request information. The digital identity certificate and digital signature exist as separate fields in the request information, and the smart contract obtains the values ​​of these two fields by parsing the request information.

[0056] The smart contract obtains the digital certificate list of the trusted CA institution. The privacy protection smart contract accesses the PKI system of the medical data sharing blockchain system and obtains the digital certificate list of the pre-configured trusted CA institution. The PKI system maintains a list of trusted CA institutions, and the digital certificates of these CA institutions are considered to be trusted. The smart contract verifies the digital identity certificate of the requester. The privacy protection smart contract uses the public key of the trusted CA institution to verify the digital signature of the digital identity certificate provided by the requester. If the digital signature verification is successful, it means that the digital identity certificate is issued by a trusted CA institution and the certificate content has not been tampered with. The smart contract verifies the digital signature of the requester. The privacy protection smart contract uses the public key in the digital identity certificate of the requester to verify the digital signature of the requester. The smart contract performs a hash operation on the request information and then verifies the digital signature using the public key of the requester. If the digital signature verification is successful, it means that the requester has the private key corresponding to the digital identity certificate and the request is indeed initiated by the requester. The smart contract confirms the authenticity and legitimacy of the requester's identity information. If the digital identity certificate and digital signature of the requester are both verified, the privacy protection smart contract confirms the authenticity and legitimacy of the requester's identity information. This means that the identity of the requester has been authenticated by a trusted CA and the request is indeed initiated by the requester himself. If the digital identity certificate or digital signature verification fails, the identity information of the requester is considered untrustworthy and the identity authentication fails.

[0057] The privacy-preserving smart contract obtains the requester's data call permission. The smart contract accesses the access control list (ACL). The privacy-preserving smart contract obtains the access control list (ACL) maintained by the system through interaction with the medical data sharing blockchain system. The ACL can be stored in a specific contract on the blockchain or provided by an external access control service. The smart contract searches for the requester's data call permission. The privacy-preserving smart contract uses the requester's identity information (such as the identity in the digital ID card) as a key to find the corresponding data call permission and constraints in the ACL. The permission information in the ACL can be represented by models such as role-based access control (RBAC) or attribute-based access control (ABAC). The permission information includes the data range that the requester can access, the allowed operation types, time limits, and usage purpose restrictions. The smart contract obtains the requester's data call permission. If the requester's corresponding permission information is found in the ACL, the privacy-preserving smart contract extracts it as the basis for subsequent permission verification. If the requester does not have the corresponding permission information in the ACL, it means that the requester does not have the permission to call medical data, and the smart contract will reject the request.

[0058] The privacy-preserving smart contract verifies the purpose of use of the requested data and the zero-knowledge proof. The smart contract verifies the purpose of use of the requested data. The privacy-preserving smart contract compares the purpose of use of the data provided by the requester with the permitted purpose specified in its data call permissions. If the purpose of use of the requester meets the provisions of the permissions, the verification is passed; otherwise, the purpose of use verification fails. The smart contract verifies the zero-knowledge proof. The privacy-preserving smart contract uses the zero-knowledge proof parameters provided by the requester to execute the zero-knowledge proof verification algorithm. The smart contract constructs the corresponding verification statement based on the data call permissions of the requester, such as "the requester has a specific role" and "the requester meets specific conditions". The smart contract takes the verification statement and zero-knowledge proof parameters as input, runs the zero-knowledge proof verification algorithm, and checks whether the proof is valid. If the zero-knowledge proof verification passes, it means that the requester does have the corresponding permissions; otherwise, the zero-knowledge proof verification fails. Specifically, according to the specific needs and performance requirements of privacy protection, select a suitable zero-knowledge proof protocol. Common zero-knowledge proof protocols include zk-SNARKs, zk-STARKs, Bulletproofs, etc. This embodiment uses zk-SNARKs to perform zero-knowledge proof verification, and constructs corresponding verification statements based on the data call permissions of the requester. The verification statement represents the attributes or conditions that the requester needs to prove, for example: "The requester has a specific role identity (such as doctor, patient, etc.)"; "The organization to which the requester belongs is an organization authorized by the data owner"; "The requester has specific usage permissions for the requested data (such as reading, analysis, etc.)". The verification statement is converted into a circuit representation in the zk-SNARKs protocol. The circuit consists of a series of logic gates and is used for the calculation process of the verification statement. The requester generates zero-knowledge proof and verification parameters based on the verification statement. This process is usually completed off-chain. The requester uses the proof generation algorithm provided by the zk-SNARKs protocol to calculate the proof and verification parameters based on its own secret information (such as identity credentials, attribute proof, etc.). The proof parameters include: proof: zero-knowledge proof, containing the prover's encrypted proof of the satisfaction of the verification statement; inputs: public input, containing the public part of the verification statement, such as the requested data hash value, etc. Verification parameters include: vk: verification key, used to verify the validity of the proof; inputs: public input, consistent with the inputs in the proof parameters. The requester submits the generated proof parameters (proof and inputs) and verification parameters (vk and inputs) to the privacy-preserving smart contract. After receiving these parameters, the smart contract begins the verification process of the zero-knowledge proof. The smart contract uses the submitted verification parameters to execute the verification algorithm of the zk-SNARKs protocol.The verification process includes the following steps: check the correctness of the public inputs to ensure that they are consistent with the requirements in the verification statement; use the verification key (vk) and proof to execute the verification algorithm of the zk-SNARKs protocol; the verification algorithm calculates a Boolean value based on the circuit definition and verification parameters to indicate whether the proof is valid; if the verification result is true, it means that the requester does meet the verification statement and has the corresponding permissions; otherwise, the verification fails. The smart contract decides whether to allow the requester to access the corresponding data based on the verification result. Integrate zero-knowledge proof verification into the data call process of the smart contract. When the requester initiates a data call request, it submits the zero-knowledge proof and verification parameters at the same time. When processing a request, the smart contract first performs zero-knowledge proof verification, and only when the verification passes will it continue with the subsequent data access and processing logic.

[0059] The privacy protection smart contract returns the verification result. The smart contract returns the verification result. If the identity information, data call permission and zero-knowledge proof of the requester are all verified, the privacy protection smart contract will return the verification result to the medical data call smart contract. The verification result can include the identity of the requester, the Merkle tree root hash of the requested data, the purpose of the requested data, and other information for subsequent data calls. The smart contract returns the verification failure result. If the identity information, data call permission or zero-knowledge proof of the requester fails to be verified, the privacy protection smart contract will return the verification failure result to the medical data call smart contract. The verification failure result includes the reason for the failure, such as "identity information verification failed", "insufficient permissions", "zero-knowledge proof invalid", etc., for the medical data call smart contract to handle accordingly.

[0060] Medical data calls the smart contract to process the request. The smart contract processes the request that has passed the verification. For the request that has passed the identity and permission verification, the medical data calls the smart contract to extract the Merkle tree root hash of the request data. The smart contract calls the medical data multi-level index structure constructed in step S3, and uses the Merkle tree root hash as the retrieval key. The smart contract obtains the Merkle tree IPFS address and the ciphertext medical data IPFS address corresponding to the request data from the index structure. The smart contract returns the retrieved IPFS address to the requester, so that it can obtain the corresponding Merkle tree structure and ciphertext medical data from the IPFS network. The smart contract processes the request that has failed the verification. For the request that has not passed the identity and permission verification, the medical data calls the smart contract to reject the request. The smart contract returns the reason for the verification failure to the requester, indicating the specific reason for the request being rejected, such as "identity information verification failed" and "insufficient permissions". After receiving the rejection message, the requester can perform corresponding processing according to the reason for the failure, such as resubmitting the request, updating the permission information, etc.

[0061] Medical data acquisition, the requester obtains the Merkle tree structure and ciphertext medical data. The requester extracts the Merkle tree IPFS address and the ciphertext medical data IPFS address from the result returned by the medical data call smart contract. The requester accesses the Merkle tree IPFS address through the IPFS network to obtain the Merkle tree structure corresponding to the requested data. The requester uses the IPFS protocol to connect to the node in the IPFS network. The requester uses the Merkle tree IPFS address as the content identifier (CID) to initiate a content request to the IPFS network. The nodes in the IPFS network look up and return the corresponding Merkle tree structure data based on the CID. The requester accesses the ciphertext medical data IPFS address through the IPFS network to obtain the encrypted medical data. The requester uses the IPFS protocol to connect to the node in the IPFS network. The requester uses the ciphertext medical data IPFS address as the content identifier (CID) to initiate a content request to the IPFS network. The nodes in the IPFS network look up and return the corresponding encrypted medical data based on the CID.

[0062] The requester verifies the integrity of the medical data. The requester calculates the Merkle tree root hash of the ciphertext medical data based on the obtained Merkle tree structure. The requester divides the obtained ciphertext medical data into blocks and calculates the hash value of each data block. The requester calculates the hash value layer by layer from bottom to top based on the Merkle tree structure, and finally obtains the root hash of the Merkle tree. The requester compares the calculated Merkle tree root hash with the Merkle tree root hash obtained from calling the smart contract for medical data. If the two root hash values ​​are the same, it means that the obtained ciphertext medical data is consistent with the original data, and the data integrity is verified. If the two root hash values ​​are different, it means that the obtained ciphertext medical data may have been tampered with or damaged, and the data integrity verification fails.

[0063] The requester obtains the medical data decryption key. The requester initiates a request to obtain the data decryption key to the medical data sharing blockchain system. The requester constructs a request to obtain the decryption key based on its identity information and data call permissions. The requester sends the request to the smart contract responsible for managing the data decryption key. The smart contract verifies the identity and permissions of the requester and confirms that it has the right to obtain the corresponding data decryption key. The smart contract verifies the identity information of the requester to ensure that it is consistent with the previous data call request. The smart contract checks the data call permissions of the requester and confirms that it has the right to obtain the decryption key of the requested data. The smart contract returns the decryption key corresponding to the requested data to the requester. If the identity and permission verification is passed, the smart contract obtains the decryption key corresponding to the requested data from the secure storage of the blockchain system. The smart contract sends the decryption key to the requester through a secure channel to ensure the confidentiality of the key.

[0064] The requester decrypts the medical data. The requester uses the obtained data decryption key to decrypt the ciphertext medical data. The requester uses the decryption key and the ciphertext medical data as input according to the requirements of the encryption algorithm to perform the decryption operation. The decryption process can be performed using a symmetric encryption algorithm (such as AES) or an asymmetric encryption algorithm (such as RSA). The requester obtains the plaintext medical data. After the decryption is completed, the requester obtains the original plaintext medical data. The requester can further process and analyze the plaintext medical data according to the purpose of use and constraints specified in the data call permission.

Claims

1. A method for secure sharing of medical data based on blockchain, characterized in that: include: Build a medical data sharing blockchain system based on the alliance chain architecture. The blockchain system consists of hospital nodes, regulatory nodes and third-party service nodes, and uses the PBFT consensus algorithm to reach consensus; The hospital node uses a fully homomorphic encryption algorithm to encrypt the user's medical data, obtains the encrypted medical data, and calls the medical data chain smart contract to upload the encrypted medical data to the blockchain; The hospital node uses the Merkle tree structure to organize the encrypted medical data, and encrypts and stores the medical data in the Merkle tree through the IPFS distributed storage system provided by the third-party service node. The root hash of the Merkle tree and the encrypted IPFS address of the medical data are used as the index information of the medical data and stored in the blockchain through the medical data on-chain smart contract; The medical data call smart contract receives the data call request initiated by the medical data requester, and calls the privacy protection smart contract to verify the identity and authority of the requester using the zero-knowledge proof method; After the identity and authority of the requester are verified, the medical data calls the smart contract to obtain the corresponding Merkle tree root hash and the encrypted IPFS address of the medical data according to the index information of the requested data, and returns it to the requester; The requester uses the obtained Merkle tree root hash and the encrypted IPFS address of the medical data to obtain the encrypted medical data through IPFS. After verifying the data integrity through the Merkle tree, the requester obtains the data decryption key from the blockchain system, decrypts the encrypted medical data, and obtains the plaintext medical data.

2. The method for securely sharing medical data based on blockchain according to claim 1, characterized in that: Build a medical data sharing blockchain system based on the alliance chain architecture. The blockchain system consists of hospital nodes, regulatory nodes and third-party service nodes, and uses the PBFT consensus algorithm to reach consensus, including: Deploy hospital nodes created by various medical institutions based on their respective medical data sharing needs; Deploy supervision nodes created by medical regulatory agencies to formulate permission management policies for medical data sharing and supervise the compliance of medical data sharing behaviors; Deploy third-party service nodes created by independent third-party service organizations. The third-party service nodes are used to provide an IPFS distributed storage system to encrypt and store medical data in the Merkle tree organized by hospital nodes. Between hospital nodes, regulatory nodes and third-party service nodes, the PBFT consensus algorithm is used to achieve distributed consensus of the blockchain system based on the alliance chain networking method; Based on the Fabric blockchain platform, smart contracts for medical data on-chain, medical data calling and privacy protection are deployed in the blockchain system.

3. The method for securely sharing medical data based on blockchain according to claim 2 is characterized in that: The hospital node uses a fully homomorphic encryption algorithm to encrypt the user's medical data, obtains the encrypted medical data, and calls the medical data on-chain smart contract to upload the encrypted medical data to the blockchain, including: The hospital node obtains the fully homomorphic public key and the private key shard generated by the privacy-preserving smart contract based on threshold secret sharing from the fully homomorphic private key shard from the privacy-preserving smart contract, and uses the fully homomorphic public key to encrypt the user's medical data to obtain the encrypted medical data; The hospital node organizes the encrypted medical data based on the Merkle tree structure, and encrypts and stores the medical data in the Merkle tree through the IPFS distributed storage system provided by the third-party service node to obtain the encrypted IPFS address of the medical data; The hospital node calls the medical data chain smart contract to upload the encrypted medical data, the root hash of the Merkle tree, the encrypted IPFS address of the medical data, and the private key shards locked by the hash time to the blockchain; The medical data on-chain smart contract writes the encrypted medical data into the blockchain ledger, stores the root hash of the Merkle tree and the encrypted IPFS address of the medical data as index information of the medical data in the blockchain, and broadcasts the hash time-locked private key shards to the corresponding authorized nodes.

4. The method for securely sharing medical data based on blockchain according to claim 3 is characterized in that: The hospital node obtains the fully homomorphic public key and the private key shard generated by the privacy-preserving smart contract based on threshold secret sharing from the fully homomorphic private key shard, and uses the fully homomorphic public key to encrypt the user's medical data to obtain the encrypted medical data, including: The hospital node initiates a request to obtain the fully homomorphic encryption public key and private key shard by calling the privacy-preserving smart contract in the blockchain system. The blockchain system reaches a consensus among the hospital node, the regulatory node, and the third-party service node through the PEFT consensus algorithm, and records the request transaction in the blockchain ledger. The privacy-preserving smart contract uses a fully homomorphic encryption algorithm to generate a fully homomorphic encrypted public-private key pair, and uses a (t, n) threshold secret sharing scheme to shard the fully homomorphic encrypted private key to generate n private key shards. The hospital node obtains the fully homomorphically encrypted public key and the private key shard corresponding to the corresponding hospital node from the privacy-preserving smart contract. The complete fully homomorphically encrypted private key can be recovered only when at least t nodes in the blockchain system collaborate to provide their own private key shards. The hospital node reads the user's plaintext medical data from the database of the hospital's internal system, and uses the fully homomorphic encryption public key obtained from the privacy-preserving smart contract to perform fully homomorphic encryption on the plaintext data to generate encrypted medical data.

5. The method for securely sharing medical data based on blockchain according to claim 3 is characterized in that: The hospital node uses the Merkle tree structure to organize the encrypted medical data, and encrypts and stores the medical data in the Merkle tree through the IPFS distributed storage system provided by the third-party service node. The root hash of the Merkle tree and the encrypted IPFS address of the medical data are used as the index information of the medical data and stored in the blockchain through the medical data chain smart contract, including: After obtaining the ciphertext medical data after full homomorphic encryption, the hospital node uses the Merkle tree data structure to organize the ciphertext medical data and construct a Merkle tree; the leaf nodes of the Merkle tree store the ciphertext medical data, the non-leaf nodes store the concatenated hash of the corresponding child node hash values, and the root node stores the hash value of the entire Merkle tree; The hospital node serializes the Merkle tree in a depth-first or breadth-first manner to obtain a serialized string of the Merkle tree; the hospital node calls the IPFS distributed storage interface provided by the third-party service node to upload the serialized string of the Merkle tree to the IPFS network for encrypted storage, and obtains the IPFS address of the serialized string of the Merkle tree; The hospital node calls the medical data chain smart contract, uploads the index information consisting of the root hash of the Merkle tree, the IPFS address of the Merkle tree, and the IPFS address of the ciphertext medical data to the chain, and triggers the medical data chain smart contract to store the index information in the blockchain ledger; the blockchain system reaches consensus on the medical data chain transaction and records it on the chain; The medical data on-chain smart contract stores the key-value pairs consisting of the Merkle tree root hash, the Merkle tree IPFS address and the ciphertext medical data IPFS address in the blockchain ledger, and uses the Merkle tree root hash as the primary index, the Merkle tree IPFS address and the ciphertext medical data IPFS address as the auxiliary index for the retrieval, verification and recovery of medical data.

6. The method for securely sharing medical data based on blockchain according to claim 5 is characterized in that: After obtaining the ciphertext medical data after full homomorphic encryption, the hospital node uses the Merkle tree data structure to organize the ciphertext medical data and construct a Merkle tree; the leaf nodes of the Merkle tree store the ciphertext medical data, the non-leaf nodes store the concatenated hash of the corresponding child node hash values, and the root node stores the hash value of the entire Merkle tree, including: The hospital node receives the ciphertext medical data after full homomorphic encryption, groups the ciphertext medical data according to a predetermined data grouping rule, and designates each group of ciphertext medical data as a leaf node of the Merkle tree; wherein the data grouping rule is set based on the type and size of the medical data; The hospital node applies a predetermined hash algorithm to the encrypted medical data of each leaf node to perform a hash operation, and calculates the hash value of the leaf node as the unique identifier of the leaf node; The hospital node traverses the leaf nodes of the Merkle tree, pairs the leaf nodes in pairs according to the predetermined pairing rules, concatenates the hash values ​​of the paired nodes, applies the predetermined hash algorithm to the concatenated result, and calculates the hash value of the corresponding parent node; the hospital node recursively performs the pairing, concatenation and hashing steps until the hash value of the root node of the Merkle tree is calculated; wherein the pairing rules are based on the Merkle tree construction algorithm, and the empty nodes use the predetermined hash value to participate in the calculation; The hospital node constructs a hierarchical data structure of the Merkle tree based on the node hash value and parent-child relationship of the Merkle tree, and stores the structural information of the Merkle tree in association with the ciphertext medical data of the leaf nodes; the structural information of the Merkle tree includes the hash value of the node, the parent-child relationship between the nodes, and the position of the node in the Merkle tree.

7. The method for securely sharing medical data based on blockchain according to claim 6 is characterized in that: The hospital node serializes the Merkle tree in a depth-first or breadth-first manner to obtain the serialized string of the Merkle tree; the hospital node uploads the serialized string of the Merkle tree to the IPFS network for encrypted storage by calling the IPFS distributed storage interface provided by the third-party service node, and obtains the IPFS address of the serialized string of the Merkle tree, including: Based on the constructed Merkle tree, the hospital node traverses the Merkle tree according to the predetermined traversal rules to generate a serialized representation of the Merkle tree; wherein the traversal rules include depth-first traversal or breadth-first traversal, and the serialized representation includes the node hash value of the Merkle tree, the parent-child relationship between the nodes, and the hierarchical structure information of the nodes; The hospital node formats the serialized representation of the Merkle tree to generate a serialized string of the Merkle tree; wherein the format of the serialized string is defined according to a predetermined serialization protocol and includes the complete structural information and node data of the Merkle tree; The hospital node establishes a connection with the third-party service node through the network interface, calls the IPFS distributed storage interface provided by the third-party service node, and sends the serialized string of the Merkle tree as uploaded data to the IPFS network; the IPFS distributed storage interface is based on the IPFS protocol and is used for distributed storage and retrieval of data; The third-party service node receives the Merkle tree serialized string uploaded by the hospital node, encrypts and segments the serialized string, distributes and stores the segmented data blocks on multiple nodes of the IPFS network, and generates the IPFS address of the Merkle tree serialized string; the IPFS address is generated based on the content addressing method and uniquely identifies the storage location of the Merkle tree serialized string; The third-party service node returns the IPFS address of the generated Merkle tree serialization string to the hospital node; the hospital node receives and stores the IPFS address of the Merkle tree serialization string as a retrieval credential for obtaining the complete structure of the Merkle tree.

8. The method for securely sharing medical data based on blockchain according to claim 5 is characterized in that: The medical data call smart contract receives the data call request initiated by the medical data requester, and calls the privacy protection smart contract to verify the identity and authority of the requester using the zero-knowledge proof method, including: The medical data requester initiates a data call request to the medical data call smart contract. The data call request includes the identity information of the requester, the Merkle tree root hash of the requested data, the purpose of use of the requested data, and zero-knowledge proof parameters. The identity information of the requester is composed of the digital identity certificate and digital signature of the requester. The Merkle tree root hash of the requested data is obtained by the requester according to the medical data multi-level index structure constructed in step S3. The purpose of use of the requested data indicates the purpose of the requester calling the medical data. The zero-knowledge proof parameters are generated by the requester according to the corresponding data call authority. The medical data call smart contract receives the data call request and verifies the format and integrity of the data call request. After verification, the medical data call smart contract calls the privacy protection smart contract and passes the identity information in the data call request, the Merkle tree root hash of the requested data, the purpose of the requested data, and the zero-knowledge proof parameters to the privacy protection smart contract. The privacy-preserving smart contract uses the PKI system of the medical data sharing blockchain system to verify the authenticity and legitimacy of the requester's identity information. The KPI system is based on digital certificates and digital signature mechanisms to verify whether the requester's digital identity certificate is issued by a trusted CA organization and whether the requester's digital signature matches the corresponding digital identity certificate. The privacy-preserving smart contract accesses the access control list of the medical data sharing blockchain system and obtains the corresponding data call permissions of the requester based on the identity information of the requester. The access control list is formulated and maintained by the regulatory node according to the regulatory requirements of medical data sharing, and specifies the data call permissions and constraints of data callers with different identities. The privacy-preserving smart contract verifies whether the purpose of the requested data is consistent with the requester’s data call permissions, and verifies whether the zero-knowledge proof parameters match the requester’s data call permissions; The privacy protection smart contract returns the identity and authority verification results of the requester to the medical data calling smart contract based on the verification results. For requests that pass the verification, the privacy protection smart contract returns confirmation information of the verification; for requests that fail the verification, the privacy protection smart contract returns the reason for the verification failure. For requests that pass identity and permission verification, the medical data call smart contract calls the constructed medical data multi-level index structure according to the Merkle tree root hash of the request data in the data call request, and obtains the Merkle tree IPFS address and ciphertext medical data IPFS address corresponding to the request data; for requests that fail identity and permission verification, the medical data call smart contract rejects the data call request and returns the reason for the request failure to the requester.

9. The method for securely sharing medical data based on blockchain according to claim 8, characterized in that: The privacy protection smart contract uses the PKI system of the medical data sharing blockchain system to verify the authenticity and legitimacy of the requester's identity information. The KPI system is based on digital certificates and digital signature mechanisms to verify whether the requester's digital identity certificate is issued by a trusted CA organization and whether the requester's digital signature matches the corresponding digital identity certificate, including: The privacy-preserving smart contract extracts the requester’s digital identity certificate and digital signature from the data call request; The privacy-preserving smart contract accesses the PKI system of the medical data sharing blockchain system and obtains a list of digital certificates from trusted CA organizations; The privacy-preserving smart contract uses the public key of a trusted CA to verify the digital signature of a digital certificate. If the verification is successful, it proves that the corresponding digital signature is generated by the private key corresponding to the digital identity certificate. If both the digital identity certificate and the digital signature are verified, the privacy protection smart contract confirms the authenticity and legitimacy of the requester's identity information. Otherwise, the privacy protection smart contract determines that the requester's identity information verification has failed.

10. A medical data security sharing system based on blockchain.

Images