Abstract
Medical data sharing is of great significance in promoting smart medicine. However, the heterogeneity of information systems used by various medical institutions makes sharing difficult. In addition, since medical data involves a great deal of sensitive information, sharing it could easily lead to the leakage of personal privacy. Blockchain, gained popularity as a distributed ledger technology, has great potential to connect heterogeneous systems and provides authenticity and integrity guarantees for medical data sharing. Focusing on the issues of medical data sharing and privacy protection, we propose a medical data sharing scheme based on consortium blockchain. To achieve access control, attribute-based access control technique is implemented, where patients preset attribute-specific access policies for their medical records, and record requesters are described by a set of attributes. For patients, we devise a hybrid storage mode to write access policies of medical records on the consortium blockchain network and store encrypted medical records off-chain. Leveraging blockchain and smart contracts, access privilege control and access history tracking can be realized. To enhance the key management, a tree of medical records is constructed for each patient, and by simply keeping the medical record trees, patients can recover their encryption keys at any time. Furthermore, we carry out an extensive analysis to show the high security and efficiency of our proposed scheme. Finally, we build a Quorum consortium blockchain on the Tencent Cloud and deploy smart contracts on the chain to simulate transactions in our scheme. The experiment results indicate the proposed scheme achieves good feasibility.
1. Introduction
With the continuous improvement in the informatization degree of medical institutions, the scale of medical data is also increasing [1]. In order to realize the efficient integration of medical resources and improve the efficiency of doctors’ diagnosis and treatment, it is essential to promote the sharing of electronic medical data. Patients’ medical data, on the other hand, is a valuable personal asset containing a great deal of sensitive information. In medical data sharing, there are significant risks of data privacy leakage and abuse, posing a major threat to the lives and property of patients. Therefore, the problem of data security and privacy in the process of data sharing arouses high concern. In addition, medical records are scattered among various medical institutions, and different data storage formats make it difficult to realize data exchange, resulting in information islands [2]. This is incompatible with the needs of patients for rapid, convenient, and accurate diagnosis and treatment, as well as the advancement of medical science. As a result, figuring out how to achieve data sharing and break down information barriers between various medical information systems while ensuring the security and privacy of medical data has become a pressing issue that must be addressed.
At present, mainstream solutions [3] to this problem include identity authentication, access control, cryptography and log analysis, etc. These methods focus on how to ensure the privacy and security of patient data but lack the transparency guarantee of data access. Patients can only believe that medical data maintenance organizations will not abuse data for profit and other factors. However, as the owner of data, patients should control the access rights of their own medical data and have the right to know who, when, and for what purpose they access their data.
The introduction of bitcoin [4] in 2009 presented a new direction for overcoming the challenges mentioned above. It has been discovered that the underlying technology of bitcoin, blockchain, could not only serve as a decentralized payment system, but also play an important role in many industries [5], such as finance, healthcare, utilities, identity management, asset registration, government agencies, etc. Subsequently, a lot of research on blockchain has been carried out, including the application of blockchain in medical treatment. With the characteristics of decentralized, unforgeable and tamper resistant, openness, anonymity, transparency, and autonomy, blockchain realizes the value transfer between peer nodes without trust and solves the problems of low security, high cost, low efficiency, and poor reliability in the current centralized mode. Attempting to apply blockchain technology [6, 7] to the medical industry is conducive to finding timely and effective medical data sharing solutions among different institutions, improving the accuracy and efficiency of diagnosis in the medical industry, and promoting the construction of smart medical systems. This study aims to contribute to this growing area of research by exploring how to harness the advantages of blockchain to facilitate privacy-preserving and access-controlled medical data sharing.
The main contributions of this article are as follows:(1)We adopt a hybrid data storage pattern of off-chain and on-chain to reduce storage load of blockchain. The medical data is encrypted and off-chain stored on a cloud server or decentralized storage system, while the relevant metadata of the medical data is recorded on blockchain.(2)Patients can specify access policies for their own data, which are recorded in a smart contract by initiating a transaction. Each requester is described by a set of attributes, which are also recorded in a smart contract. Thus, access control can be performed automatically by smart contracts. A medical record can be accessed only if the requester’s attributes satisfy the access policy specified for the record.(3)Due to the transparency and immutability of the blockchain, all the user’s actions are actually recorded on the blockchain, allowing patients to track the access history of their medical data.(4)To facilitate key management, the scheme enables patients to generate subkeys based on a built medical record tree. A patient just needs to preserve the medical record tree, regardless of how many records he has. The patient can also backup the medical record tree with family or friends for unexpected situations.(5)We deploy a consortium blockchain on Quorum project on Tencent Cloud Host and deploy smart contracts on the consortium blockchain to simulate transactions in the scheme. The experiment shows that the scheme is feasible, and the analysis carried out shows that the scheme is both secure and efficient.
2. Related Work
Blockchain technology has already shown its application potential in many fields, such as e-health [8,9], decentralized storage and data retrieval [10–12], crowdsourcing collaboration [13, 14], etc. In this section, we will introduce some previous works related to the application of blockchain technology in the medical record sharing in terms of privacy protection and access control, respectively.
2.1. Blockchain-Based Electronic Medical Record Sharing with Privacy Protection
Previous studies [15] have explored the efficacy of blockchain to achieve electronic medical record sharing with security and privacy preservation. Azaria et al. [16] proposed MedRec, an innovative decentralized medical record management system with capabilities for certifiability, privacy, auditability, and data sharing. It also provides tamper-proof logging records that can be accessed by patients across organizational structures. Xia et al. [17] presented a blockchain-based data sharing framework for electronic medical records. Leveraging cryptographic techniques, access to sensitive data from a shared repository is only permitted by authenticated users. The accountability is guaranteed by the properties of permissioned blockchain. Xia et al. [18] designed an effective medical record management system: MedShare, which allows data entities to share medical records in a trustless setting. Based on blockchain, data access control, tracing, and auditing are provided in MedShare. Jayabalan and Thiruchelvam [19] proposed a general patient data transparent framework based on blockchain and cloud storage, which implements electronic medical record authorization management by analyzing the generated log events. For the problem of patients being unable to manage questionnaire data in the medical industry, Kim et al. [20] presented a blockchain-based medical questionnaire data sharing management system which can interoperate with other systems. Based on the characteristics of the blockchain, the solution not only ensures the integrity of the questionnaire data, but also improves the security of the patient’s personal medical data. Zhao et al. [21] designed a lightweight backup and efficient recovery scheme for the medical blockchain key through the sensor network, which can help the medical blockchain effectively protect privacy information and promote the development of medical blockchain. Because data storage and synchronization have not been effectively implemented, it is difficult to share data between medical institutions. Abdellatif et al. [22] designed a medical-edge-blockchain, MEdge-Chain, that leverages blockchain and edge computing technology to provide optimized and intelligent medical data exchange among various entities. To enable medical data exchange and speedy data retrieval, Zou et al. [23] designed a new block and chain structure and proposed a privacy-preserving e-health system. Also, a reputation-based mechanism system is being constructed to motivate miners.
2.2. Blockchain-Based Electronic Medical Record Sharing with Access Control
In the management of medical data, only the traditional data protection methods are applied, the patient’s privacy information is not effectively guaranteed. Patients cannot control their medical image data while receiving treatment. Tang et al. [24] suggested a medical image security sharing system based on blockchain and smart contract technology. The system realizes medical image data sharing across systems and regions and provides a novel idea to making medical image sharing more secure and dependable. With the development of mobile networks and wearable electronic devices, the collection and sharing of personal health data is becoming more and more valuable. To address the privacy problem during the process and the vulnerability of the data storage system, Liang et al. [25] proposed a user-centric medical record sharing solution using the permissioned blockchain technology and using Hyperledger Fabric [26] blockchain to simulate the implementation of the scheme. Zhang and Poslad [27] introduced an electronic medical record architecture that differs from existing blockchain methods. The architecture’s access model enables fine-grained access authorization while maintaining compatibility with blockchain. Zhang and Lin [28] proposed a personal health information sharing scheme based on blockchain, which realizes data security, access control, privacy protection, and secure search. This article constructs two kinds of blockchains, private blockchain and consortium blockchain, to store personal health data and its security index records, respectively. Using immutable and verifiable features of transaction records in blockchain technology, Chen et al. [29] proposed a new medical data processing architecture. Under this architecture, medical data can be safely shared without intermediaries, avoiding data leakage risks caused by improper operation during processing. Wang et al. [30] proposed a blockchain-based framework that combines decentralized storage system, Ethereum blockchain, smart contract, and attribute-based encryption (ABE) technology to achieve fine-grained access control and keyword search in the decentralized storage systems. Rajput et al. [31] designed an access control management system for emergency situations based on Hyperledger Fabric blockchain. The system realizes smart contract based on emergencies and specific time-limited rules, enabling access to patient data via smart contract in an emergency. Tanwar et al. [32] proposed an architecture for an electronic medical record sharing system based on the Hyperledger and designed an access control algorithm based on symmetric key cryptography to improve data accessibility between healthcare providers. Utilizing the blockchain technique and smart contract, Wang et al. [9] established a decentralized and trusted framework, MedShare, for healthcare centers to securely share their encrypted EHR. In their article, fine-grained access control can be realized by devising a lightweight ABE. Besides, multi-keyword Boolean search operations on encrypted EHR is also allowed for authorized users.
3. Preliminaries
3.1. Blockchain and Smart Contract
3.1.1. Blockchain
Blockchain can not only serve as a decentralized payment system, its enabler blockchain technology can also play an important role in many industries such as finance, public utilities, identity management, asset registration, government agencies, etc., especially in the medical industry. In the medical field, blockchain is mainly applied to the preservation of personal medical records. The main characteristics of blockchain technology, including decentralization, immutability, consensus mechanism, etc., can provide the security and privacy protection for medical information.
Blockchain can be classified into three types based on the admission principle of blockchain nodes: public blockchain, consortium blockchain, and private blockchain. This article employs consortium blockchain to provide a technical support for personal medical record storage and sharing. In consortium blockchain, nodes need to be authorized to join the network, and the read-write rights and account rights are set according to the consortium rules.
3.1.2. Smart Contract
Smart contract is a computer protocol that does not require human intervention once it is deployed. It can automatically execute contract-related operation under specified conditions and generate verifiable evidence after execution to illustrate the validity of the contract operation. Smart contracts were not used in the actual industry until the advent of blockchain due to lack of a trustworthy execution environment. Ethereum was the first platform to achieve the full integration of smart contracts and blockchain technology.
3.2. Quorum
Quorum [33, 34] is an open-source blockchain platform based on the Ethereum protocol developed by J.P. Morgan since 2016, which can be regarded as the enterprise version of Ethereum. Quorum is designed to provide a permissioned Ethereum solution for industries to support the privacy of transactions and contracts. Quorum code is a branch of go-ethereum, and it can quickly integrate and seamlessly connect with Ethereum updates. The main features of Quorum over public Ethereum are as follows:(i)Transaction and contract privacy(ii)Multiple consensus mechanisms based on votes(iii)Authority management of network/peer nodes(iv)More superior performance
The main components of Quorum include the Quorum node and Constellation module. The Quorum node is intentionally designed as a lightweight Geth fork so that it can take advantage of the Ethereum’s node design. Therefore, Quorum will update and adjust accordingly with each release of Geth in the future.
Quorum’s Constellation module consists of two submodules: Transaction Manager and Enclave. The Transaction Manager is responsible for transaction privacy. It stores the contents of the private transaction and interacts with other Transaction Managers concerned. It also uses the Enclave to encrypt or decrypt the private transactions it receives.
In distributed ledger, cryptography is widely used in transaction authenticity verification, participants’ verification, historical information traceability, etc. In order to achieve state separation and improve performance through some parallelized encryption operations, Quorum delegates much of the encryption work to the Enclave, including symmetric key generation and data encryption/decryption. Enclave works with the Transaction Manager to enforce privacy, managing encryption/decryption in a segregated manner.
3.3. Istanbul BFT
The original PBFT consensus algorithm [35] requires quite a bit of adjustments to work with blockchain. The improved PBFT that implemented in the Quorum project is named Istanbul BFT (IBFT) [36]. IBFT inherits the three consensus phases of PBFT, namely pre-prepare, prepare, and commit, and combines them with block generation. In a consensus network with validator nodes, up to Byzantine nodes can be tolerated, where .
IBFT is a state machine replication algorithm. Each validator maintains a state machine replica in order to reach block consensus. IBFT sets six consensus states: new round, pre-prepared, prepared, committed, final committed, and round change. Figure 1 shows the state transition process in a round of consensus.(1)New round: The validators pick one of them as a proposer. The proposer will propose a new block proposal and broadcast it along with the pre-prepare message (as step ① in Figure 1). The other validators wait for the pre-prepare message (as step ② in Figure 1).(2)Preprepared: After receiving the pre-prepare message from the proposer, a validator will enter the pre-prepared state and broadcast the prepare message (as step ③). It then waits for prepare messages (as step ④).(3)Prepared: A validator enters the prepared state after receiving prepare messages and broadcasts a commit message (as step ⑤). It then waits for commit messages (as step ⑥).(4)Committed: After receiving the commit messages, a validator enters the committed state and attempts to add the block at the end of the local blockchain (as step ⑦).(5)Final committed: After the block is inserted successfully (as step ⑧), a verifier enters the final committed state and is ready for the next round.(6)Round change: The round change state would be triggered in three cases: round change time expiration, invalid pre-prepare message, and block insertion failure. When a verifier finds one of the three conditions, it broadcasts a round change message and waits for round change messages from the other verifiers. Upon receiving round change messages for the same round, a validator enters new round state.
The blockchain using IBFT consensus algorithm will not fork, and the valid blocks are bound to appear on the main chain. In order to prevent the Byzantine nodes from generating a different chain from the main chain, each validator will add at least signatures of received confirm message to the extraData field of the block header, and then insert the block to the blockchain. Therefore, the light node can also verify the correctness of the block. However, the dynamic extraData field will cause the inconsistency of block hash calculation. Since for the same block, different validators may add different confirm signatures, resulting in inconsistent block hashes. To solve this problem, the extraData field will be removed when calculating the block hash.
3.4. Cryptographic Primitive
3.4.1. Hash Function
In addition to the hash function used in the blockchain system, we also need to choose a cryptographic collision-resist hash function , which maps any strings to a fixed th strings, that is .
3.4.2. Encryption and Signature
We assume that a secure symmetric encryption algorithm , a secure asymmetric encryption algorithm , and an unforgeable digital signature algorithm are available. We denote , to be the ciphertext of the message encrypted by the public key , and to be the signature of the message signed by the secret key .
3.5. Access Control
We use attribute-based access control model for more precise access control and consider as access control policy. Let be the universal set of possible attributes that are publicly known. Given an attribute set and an access policy , where , we say that satisfy if .
4. The Proposed Scheme
4.1. System Model
4.1.1. Entities
As illustrated in Figure 2, the key entities of our scheme can be listed as: blockchain, supervision center, storage server, record owner, and record requester. Blockchain: We utilize consortium blockchain in this scheme, and choose IBFT, a PBFT variant algorithm, as the consensus algorithm. The identity of nodes in the consortium blockchain needs to be authenticated, so there is a certain trust foundation between members. The members in the blockchain network can be ordinary users such as doctors and patients, as well as large medical institutions, disease research institutions, etc. As medical institutions and research institutes often have certain authority and rich hardware resources, some of them will be selected by the supervision center as IBFT consensus nodes to maintain the blockchain. The consortium blockchain is defined to accept only four types of transactions: for identity authentication; for new record upload; for access control management; and for access policy update. Supervision center : The supervision center acts as an administrator of the data sharing system. The is responsible for initializing the consortium blockchain network and deploying smart contracts on it. The also needs to verify the identities of users who want to join the network. Storage server: The storage server is responsible for executing the instructions of storage and access issued by users. After users upload their data, the storage server will return location information from which the encrypted record can be accessed, such as the URL returned by dropbox or the hash returned by IPFS [37]. Record owner : The record owner is a patient who owns a number of medical records and intends to share his medical records. The s define access policies for their medical records to enforce access control. The s store their medical records in a hybrid mode, that is, the raw records are encrypted and stored on the storage server, while the access policy, storage location, and other information are uploaded to the blockchain. Record requester : A record requester can be a doctor who needs to view a case of a patient or an institution conducting a case study of an infectious disease. To join the consortium blockchain network, the needs to register with the to obtain an attribute certificate. An can access the owners’ medical records if it has satisfiable authority.
4.1.2. Workflow
As illustrated in Figure 2, the workflow of this scheme can be summarized into five phases, namely system establishment, identity authentication, record generation and upload, record access, and access policy update.(1)System establishment: In this phase, the supervision center initializes the consortium blockchain network and deploys smart contracts on it (as step ① in Figure 2).(2)Identity authentication: In this phase, each user who wants to join the network submits real-life identification materials to the (as step ② in Figure 2). The will issue a certificate to the user after verifying the authenticity and validity of identification materials (as step ③). The also initiates an authorization transaction to record the attributes of the registrant on blockchain (as step ④).(3)Record generation and upload: In this phase, the encrypts his medical record and submits the encrypted medical record to the storage server (as step ⑤). The also defines an access policy for medical record and anchors it to blockchain by initiating an upload transaction (as step ⑥).(4)Record access: This phase allows the to request access to the ’s medical record by initiating an access transaction (as step ⑦). If the ’s attributes meet the access policy of record, the access request is accepted and the will secretly transmit the decryption key to the (as step ⑧). The can download the encrypted record from the storage server and decrypt it (as step ⑨).(5)Access policy update: This phase enables the to make changes to the access policy of the uploaded records by initiating an access transaction (as step ⑩).
4.2. Threat Model
We assume that all the adversaries have bounded computational capability, so they cannot break the security properties of the blockchain and the cryptographic tools used in our scheme. The supervision center and record owners are assumed to be trusted and will exactly follow the protocol. We also consider the following threats:(i)Semi-trusted storage server: We assumed that the storage server is semi-trusted, that is, honest but curious. It will honestly follow the protocol, but it is also curious about users’ private data and tries to learn any information from the data stored on the server.(ii)Unauthorized access attack: We also consider the record requesters may be malicious that attempts to break data access control. Specifically, the adversary might collude with the storage server to gain some content of medical records out of its authority.(iii)Standard Byzantine threat model: In our design, medical institutions work as consensus nodes to execute IBFT protocol to generate new blocks. We consider a Byzantine adversary who may cause faulty nodes to exhibit arbitrary behavior (drop, delay, reorder). However, we assume the assumptions hold: the number of Byzantine nodes in IBFT-based consensus does not exceed one-third of the total consensus members.
4.3. Design Goals
The design goals of our work are listed as follows:(i)Access control: Medical records should be enforced by fine-grained access control so that only authorized users can access.(ii)Integrity and confidentiality: Raw data are stored on a semi-honest storage server, so it is critical to keep information from being corrupted or modified and accessed without authorization during transmission and storage.(iii)Auditability: Various operations on medical records such as uploading, updating, and accessing should be recorded in a tamper-resistant way, making them easy to be audited.(iv)Key management: When a user has a large number of medical records, there is a corresponding need for multiple symmetric keys, so we believe that efficient key management is of necessity.
4.4. Key Management
To facilitate key management, a hierarchical tree structure is introduced in this article. Patients can classify the diseases they suffer from based on the types of diseases (refer to the departments’ setting structure of a hospital) and build their own medical record tree with a hierarchical classification of diseases.
4.4.1. Medical Record Tree
We now describe how a patient creates his own medical record tree, taking Figure 3 for example. The patient chooses a master key and takes it as the root node of a tree. Each leaf node of the tree is described by a medical record of the patient. Each interior node of the tree represents the hierarchical classification of a medical record. The hierarchical relationship of the interior node can refer to departments’ setting structure of a hospital.
To facilitate working with the tree, an ordering is defined between the children of each non-leaf node. That is, the children of a non-leaf node are numbered in serial order starting from 1. Specifically, the number of the root node is set to 1. In Figure 3, the number of a node is highlighted in orange. Besides, for each leaf node, let denote the concatenation of numbers of all nodes on the shortest path from the root node to the leaf node. For example, in Figure 3, the of leaf node associated with the medical record (marked with blue boxes) is: 1223 (marked with red boxes).
4.4.2. Generating Keys from the Medical Record Tree
With a medical record tree, the patient can generate keys for all medical record in the tree. For a leaf node, the key of its associated medical record can be calculated as follows:where “ ” indicates concatenation.
4.5. Construction
In this section, we will describe the construction of the scheme in detail and show how to use the features of blockchain and smart contract to achieve the privacy protection and secure sharing of medical data.
The cryptographic hash function used in our system is implemented by SHA256, the symmetric encryption algorithm is implemented using AES, and the asymmetric encryption algorithm and the signature algorithm are implemented using ECC with secp256k1 curve.
4.5.1. System Establishment
In the system establishment stage, the first creates a blockchain account for itself, where the public-private key pair is denoted as , and the account address derive from the public key is denoted as . The selects a number of hospitals and research institutes as consensus nodes, which are authoritative or have a high reputation score counted by a reputation management system. The also deploys smart contracts on the consortium blockchain network—Authorize, MedicalRecord, and AccessControl—the details of which are described in Section 4.6.
4.5.2. Identity Authentication
To join in the consortium blockchain network, each user ( and ) needs to apply for identity registration with the supervision center . Before that, each or chooses a pair of public and private key, denoted as or . Then, an application for registration and a signature on can be submitted to the ,
A registration application should include his public key , identification materials that can prove the real-life role. The will verify the registrant’s signature,and the authenticity and validity of the identification materials. If the verification passes, the formalize the registrant’s role as a set of descriptive attributes Att according to the provided identification materials,where . Also, the derives a blockchain account address from the registrant’s public key , denoted as or . Then, a certificate along with the ’s signature on it will be issued to the registrant,
The also initiates an authorization transaction to the consortium blockchain network. The transaction structure is shown as Table 1.
This transaction will trigger the interface setAuthorization() of the smart contract Authorize, by which registrant’s attribute authorization information will automatically be stored in smart contract.
Upon receipt of the certificate, the registrant will verify the signature of the to confirm the integrity of the certificate and the authenticity of its source,
4.5.3. Record Generation and Upload
When the patient goes to the hospital for medical treatment or examination, a medical record will be generated and given to the patient. Patients can share their historical medical data with doctors for more accurate treatment or research institutions for case studies. To protect the privacy of medical data when sharing, it is often necessary to encrypt it.
The key management method is described in Section 4.4; the patient, that is the record owner , first creates a medical record tree with his master key and all historical medical records as Figure 3. For a medical record with index in the tree, generates the subkey
To share the medical record , the takes as the symmetric key and calculates
The uploads to the storage server, which will return the storage location . The records the ciphertext hash and the storage location .
In order to control the access privilege of medical record, the specifies an attribute-based access policy for his record,where , , is the universe of possible attributes. The medical record can only be accessed if the number of identical attributes in requester’s attributes set and access policy is equal to or greater than the threshold.
The assembles as an upload transaction , where can be a few keywords for the record or a simple description of the condition, Then is broadcast to the consortium blockchain network. The structure of is shown as Table 2.
This transaction will trigger the interface uploadRecord() of the smart contract MedicalRecord, by which transaction data related to the medical record will be automatically stored in the smart contact.
4.5.4. Record Access
The data on blockchain is available to members of the consortium, and the requesters can monitor the blockchain to find medical resources of interest. When a requester would like to access a medical record written in an upload transaction with transaction ID , he can determine for himself whether his attributes set satisfy the access policy recorded in the transaction. If yes, he assembles an access request transaction as Table 3 and broadcasts it on the consortium blockchain network.
This transaction will trigger the interface requestAccess() of the smart contract AccessControl, which automatically check whether the attributes of the requester satisfy the access policy in the transaction , that is, if the following condition holds:
If not, the access request will be denied; otherwise, the request will be accepted and the result will be recorded in the event log.
Once the of the medical record listens for an authorized access request event, he uses the ’s public key to encrypt the symmetric key of the medical record,then sends to the by an off-chain communication channel.
After receiving , the decrypts with his private key ,
Further, the downloads the encrypted record according to the location information in transaction and calculatesto check if holds. If it does, make the final decryptionto get the raw medical record .
4.5.5. Access Policy Update
Although the data on the blockchain are tamper resistant, the can broadcast a new transaction to update the access policy. The consensus nodes always verify the permissions based on the latest transactions, thereby enabling the to update the access policy for the records on the blockchain. To update the access policy, the assembles as a policy update transaction , where is the upload transaction ID where the medical record needs to be updated, is the new access policy, and broadcasts to the blockchain network. The transaction structure is shown as Table 4.
This transaction will trigger the interface updateRecord() of the smart contract MedicalRecord, which automatically performs policy updates.
4.6. Smart Contract Design
In this section, we mainly introduce the smart contract-related interface and algorithm logic used in this article. Smart contracts are coded in the programming language Solidity [38]. The smart contracts we designed include Authorize contract, MedicalRecord contract, and AccessControl contract.
4.6.1. Authorize Contract
The Authorize contract is deployed by the , and the contract design can be seen in Figure 4. Through the contract, tamper-resistant information is written on the blockchain to enable authorization for organizations and users.(1)Authorize contract initialization: This process defines some variables of the contract when the contract is created.(a)The supervisionCenter variable of address types, which defines the address of the . This variable defines the address of the and is initialized when the contract is created.(b)The authorizedUsers variable of mapping types, which defines a mapping collection from authorized user addresses to the string of attribute set. The can add, modify, and delete the collection through the relevant function interfaces of the contract.(2)Authorize contract interfaces. The following two function interfaces are provided in the Authorize contract:(a)setAuthorization (address, attributeSet): This function can only be executed by the . When the authorizes organizations and users, the authorized account address will be added to the authorizedUsers variable. This function can be used to add, modify, or delete authorizations for organizations and users. The attribute set string is set to the corresponding attribute values.(b)getAuthorization (address): This function can be executed by anyone. We can use the function to query the attribute set of a specific account address. The type of the function is constant, meaning it does not modify the state of the blockchain.
4.6.2. MedicalRecord Contract
The MedicalRecord contract is deployed by the , and the contract design can be seen in Figure 5. Through the contract, we can upload medical records, update access policy, or obtain the metadata information of medical records.(1)MedicalRecord contract initialization: This process defines some variables of the contract when the contract is created.(a)The supervisionCenter variable of address types, which defines the address of the . This variable defines the address of the and is initialized when the contract is created.(b)The MedRec variable of custom data struct types, which defines the structure of a medical record, containing variables like policy, threshold, index, hash, location, and metadata.(c)The MedRec variable of mapping types, which a mapping collection from user address to the array of struct MedRec.(2)MedicalRecord contract interfaces: The following four function interfaces are provided in the MedicalRecord contract.(a)uploadRecord(policy, threshold, index, hash, location, metadata): The function can be executed by anyone. It is used to upload the metadata information of medical records. A serious limitation of this is that one can only add the medical record collection corresponding to one’s own address.(b)updateRecord(location, newPolicy): The function can be executed by anyone. It is used to update the access policies of medical records. A serious limitation of this is that one can only update the access policies of medical record collection corresponding to one’s own address.(c)getRecord(): This function is used to obtain the metadata information of medical records already uploaded. The type of the function is constant, meaning it does not modify the state of the blockchain.(d)getAccessPolicy(address, location): This function is used to obtain the access policy of medical record that the account address and location are specified.
4.6.3. AccessControl Contract
The AccessControl contract is deployed by , and the contract design can be seen in Figure 6. Through the contract, one can issue access request or obtain the access history of medical record.(1)AccessControl contract initialization: This process defines some variables of the contract when the contract is created.(a)The supervisionCenter variable of address types, which defines the address of the . This variable defines the address of the and is initialized when the contract is created.(b)The AccessStruct variable of custom data struct types, which defines the structure of an access, containing variables like txid, time, and requester.(c)The access variable of mapping types, which defines a mapping collection from authorized user address to the array of struct AccessStruct.(d)The object instance medicalRecord of MedicalRecord contract. In the AccessControl contract, the getAccessPolicy function of the MedicalRecord contract needs to be invoked. Therefore, a MedicalRecord contract object instance needs to be initialized.(e)The object instance authorize of Authorize contract. In the AccessControl contract, the getAuthorization function of the Authorize contract needs to be invoked. Therefore, a Authorize contract object instance needs to be initialized.(2)AccessControl contract interfaces: The following function interfaces are provided in the AccessControl contract.(a)setContract(address of MedicalRecord contract, address of Authorize contract): The function is used to set the address of the Authorize instance and the address of the MedicalRecord instance.(b)requestAccess(address, txid, location): The function is used to issue an access request for a medical record. The access history will be recorded on the blockchain.(c)getAccessRequest(): The function is used to obtain the access history of medical records.
5. Performance Analysis
5.1. Security Analysis
In this section, we present our analysis of the security. The proposed scheme can satisfy all the security requirements described in Section 3.3, based on the designed transactions, smart contacts, blockchain, and the exploited cryptographic schemes.
5.1.1. Access Control
In the proposed scheme, we adopt a -threshold access control structure and employ smart contract to automate the matching of access policies and attribute sets. A record owner can preset the access policy for his medical record as , . Each record requester is also assigned a set of attributes , based on his identity and role in reality. The attribute set of a requester is considered to satisfy an access policy only when . It should be noted that we stored the access policies and attribute sets on smart contract. Thus, access control can be automatically executed by smart contract, ensuring that only requesters whose attribute sets satisfy the access policy of a record can obtain access permissions. The fine-grained access control is thus realized.
5.1.2. Key Management
In our proposal, a tree storage structure named medical record tree is devised to provide owners with efficient key management. An owner can construct his own medical record tree according to the hierarchical structure of his medical records. The tree takes master key as root and medical records as its leaf nodes. And for a medical record, index is denoted as a cascade of node numbers on the shortest path to the root. With the medical record tree, the owner can further generate a subkey for a record: . Instead of recording each subkey, he only needs to keep his medical record tree, and then he can deduce the corresponding subkey of each record. In this way, the efficient management of symmetric key can be realized.
5.1.3. Confidentiality
The symmetric encryption algorithm AES utilized in our proposal can prevent medical records from being accessed without owners’ permission. Note that the raw medical record is encrypted with symmetric key by the symmetric encryption algorithm, , and encrypted medical record is uploaded to the storage sever. Even if the storage server is compromised and stored on the server is obtained illegally, no meaningful information can be revealed without the corresponding symmetric key . The symmetric key is kept secretly by the owner. When someone requests to access the medical record, the owner will send the requester the decryption key only if he has access authorization, which ensures that the owners’ medical records are not exposed to the unauthorized users. Thus, the confidentiality of owners’ medical records can be guaranteed.
5.1.4. Integrity
The immutability and transparency of blockchain and the hash algorithm used ensure the integrity of medical records. The hash values of encrypted medical records, , are published on the blockchain, and it cannot be modified once the block is chained. Any user in the blockchain network can confirm the integrity of medical records stored on storage server by comparing their hash value h’ with h on the blockchain. In other words, once owners’ records are tampered with or corrupted, it can be detected immediately. That ensures data integrity.
5.1.5. Auditability
In our design, there are four types of transactions in blockchain, namely, , , , and . Before a transaction can be packaged, it must be signed by the transaction initiator. Through the transaction logs of the blockchain, any behaviors of users can be audited. Specifically, the auditability for access history of medical records is also provided leveraging smart contact. So that owners can check who and when they have accessed their medical records.
5.2. Compared with the Similar Schemes
We compare the characteristics of our scheme with several state-of-the-art blockchain-based works for secure data sharing. The results are given in Table 5.
From the perspective of consensus mechanism, the proposed scheme uses IBFT, an improved algorithm of PBFT. IBFT and PBFT have significantly better block output speed than PoW and PoS. In addition, in contrast to PBFT, IBFT does not need a specified client to send requests and wait for responses, and each verifier can be considered a client. Therefore, the adoption of IBFT mechanism can greatly increase the throughput of the consortium blockchain.
In terms of access control, the scheme [16] achieves access restrictions from the time dimension, the scheme [25] realizes access control through the channel in the fabric. The scheme [30] and our scheme supports fine-grained access policy-based attributes. In particular, our scheme supports the update of access policy. In our scheme and scheme [30], the data owners have full control over their data. While in other schemes, the access permission is authorized by a central authority, which can decrypt all the data when they compromise.
It can be seen that none of the other solutions can realize efficient key management except for ours. Furthermore, our scheme achieves data confidentiality, data integrity, data auditability, and detailed simulation experiments.
5.3. Efficiency Evaluation
In this section, we will evaluate the performance of off-chain operation, which mainly involves cryptography algorithms. Here, we conduct our implementation for hash function, symmetric encryption, asymmetric encryption, and signature using SHA256, AES, ECELG, and ECDSA, respectively. In particular, the standardized elliptic curve secp256k1 is selected for ECC algorithm. Performance evaluation will be carried out in terms of computing cost and communication cost, respectively.
5.3.1. Computational Cost
Execution time is the most intuitive measure of computational complexity. First, we use Python to implement cryptography algorithms used in our scheme and estimate the time cost. Table 6 presents the run-time cost of our used cryptographic algorithm, which is metric on a 100-run basis.
Then, we summarize the cryptographic operations involved in each phase of the whole process. According to the corresponding running time costs in Table 6, we estimate the time costs of each entity in each phase of the scheme, and the results are shown in Table 7. It can be observed that the execution time of the off-chain operation for each entity is less than 1 second, which is within the acceptable overhead range.
5.3.2. Communication Cost
In addition, we list the major communication costs between the entities, as shown in Table 8. Here, and denote the bit size of ciphertext and signature data, respectively.
As we can see, communication costs are directly affected by and . Since the signature size of ECDSA and ciphertext size of ECEGL are fixed when the elliptic curve is selected, communication cost between supervision center S and and between and is close to constant. While the ciphertext size of AES is linearly and positively related to the plaintext size, communication costs between and storage server and between and storage server are also positively related to the size of the plaintext. Combined with the real medical application scenarios, we believe that the size of plaintext, that is medical records, should not be overwhelming. In general, communication costs are also within acceptable loads.
5.4. Experimental Simulation
To show the feasibility of the scheme, we simulated the transactions of the proposed scheme through the smart contracts under the Quorum blockchain platform. Because the contracts are deployed on the consortium blockchain, we do not have to pay as much attention to the spending of gas that was consumed in the stage of transaction operations and contract deployment as in the Ethereum blockchain.
Following the official 7-node example of Quorum [39], we setup a 7-nodes Quorum blockchain network with IBFT consensus on the Tencent cloud host, CentOS 7.6 system. Then we connected MetaMask-Chrome to the deployed Quorum blockchain network in the custom RPC mode with port 22000 and chainId 10. Next, we deployed smart contracts on Quorum blockchain network using Remix [40], that is, the Solidity online compiler, via the Injected Web3 connection.
We regard a node with the address 0x951190d1fa0efcd6de9d1657d5c65caeaf421786 as the supervision center and use this node to compile and deploy three smart contracts of Authorize, MedicalRecord, and AccessControl in turn. After successfully deployed, the Authorize contract will provide the following two interfaces: setAuthorization() and getAuthorization(). The MedicalRecord contract will provide the following four interfaces: uploadRecord(), updateRecord(), getRecord(), and getAccessPolicy(). The AccessControl contract will provide the following three interfaces: setContract(), requestAccess(), and getAccessRequest().
Using the contract’s address and ABI, we can interact with smart contracts deployed to the Quorum network. To perform a write operation, we need to send a transaction to trigger smart contract to update the stored value. To perform a read operation, the “get” function is called from the contracts’ list of methods. Next, we will test some of these interfaces and demonstrate the interaction with the contracts.
A requester with account address 0xdd8af2f297143ae142e85ed40d1a17311031a5a2 is set to be a message sender. When the getAuthorization function is called, an empty string is obtained, as shown in Figure 7(a). It indicates that there is no permission for the requester.
(a)
(b)
As shown in Figure 7(b) , the requester first calls setAuthorize function with the inputs “0xdd8af2f297143ae142e85ed40d1a17311031a5a2”, and “Xi’an University of Technology School of Automation Lecturer”, and then calls getAuthorization function, and he will get the authorization information “Xi’an University of Technology School of Automation Lecturer”. Here we use the symbol “” to connect the attribute.
In MedicalRecord contract, as shown in Figure 8(a), the patient can upload the related information of medical record through the uploadRecord function, including policy, index, provider, hash, location, and metadata. After the medical record is uploaded, one can view the corresponding access policy by calling the getAccessPolicy function, as shown in Figure 8(b). Through the updateRecord function, the patient can update the corresponding access policy of the medical record uploaded by himself, as shown in Figure 9(a). Figure 9(b) shows the updated access policy by calling getAccessPolicy.
(a)
(b)
(a)
(b)
As shown in Figure 10(a), after a patient uploads his medical record, the patient can obtain the medical record uploaded by calling the getRecord function. The symbol “ ” is used as the segmentation symbol of the record. As shown in Figure 10(b), the patient can view the access history of their medical records by calling the getAccessRequest function.
(a)
(b)
6. Conclusion
In the medical industry, with the rapid development of electronic medical records, how to store and share patients’ medical data among authorized participants in a privacy-preserving way is a thorny and urgent problem to be solved. In this article, we propose a blockchain-based medical data secure storage and sharing scheme to provide privacy and security guarantees such as confidentiality, integrity, and auditability. In addition, the functions of fine-grained access control and key management are supported. The scheme can open a medical data sharing channel to solve the current information island problem. Compared with the existing scheme, this scheme has a greater advantage in functionality, security, and efficiency. In the future, the security sharing of medical data in the human domain network can be further studied in the context of the rapid development of wearable devices and the Internet of Things.
Data Availability
The software code used to support the findings of this study is available from the corresponding author upon reasonable request.
Ethical Approval
The article does not contain any studies with human participants or animals performed by any of the authors.
Conflicts of Interest
The authors declare that they have no relevant financial or nonfinancial interests to declare that are relevant to the content of this article.
Acknowledgments
This work was supported by the National Natural Science Foundation of China (Grant no. 61572019), the Shaanxi Province Key Research and Development Program (Grant no. 2020GY-006), and the Science and Technology Project of Shaanxi Province (Grant no. 2022GY-040).