In this section, the accuracy and performance of MedChain are evaluated. First, the system security is analyzed by studying the related properties. Then, the system efficiency is studied through theoretical analysis and experiments. Lastly, the evaluation is summarized through a comprehensive discussion.
5.1. Security Analysis
This section validates the security requirement fulfillment, including the analysis on attack resistance, privacy protection, and non-repudiation. Assume the users of the system never expose their private keys and secret keys to others. The encryption algorithm cannot be compromised and an adversary cannot recover the keys. In addition, the authorized requesters are assumed to be trustworthy. For example, related laws and regulations are enacted to restrain healthcare data secondary usage. To facilitate description, some conventions are made first. A message m sent from C to B is denoted by where represents the signature of the message signed with C’s private key. C(A) represents the scenario that C is disguised as A. Let PKadv and SKadv be the public-private key pair of an adversary.
Resilient to Masquerade Attack: An adversary may pretend to be a user to gain unauthorized access to a data inventory, a session, or a ledger. For example, an adversary C pretends to be patient A and sends PKA to healthcare provider B for inventory creation for patient A: C(A) → B: (m = PKA, ). This attack can be defeated by checking the message signature. In the above example, B can discover that and ignore the inventory creation request.
Resilient to Replay Attack: An adversary may intercept the message sent from one party to another party and replay the message to access the information without authorization. There could be three cases of a replay attack to MedChain.
Case 1. Assume an adversary C
can intercept a message from a healthcare provider A
to a patient B
for accessing the inventory and the data on a directory service node D
With the InvID, C can ery the information from the directory service. However, without SKA, C can neither learn the identity of B nor decrypts for accessing the inventory of B under the InvID.
Case 2. Assume an adversary C
can successfully intercept an inventory update message from a healthcare provider A
to a directory node B
for tampering the inventory.
Since InvContent ≠ InvContent’, . Message authentication will fail on B and B will not approve the change on the inventory. The similar inference can be applied to the replay attack on session change and session removal.
Case 3. Assume an adversary C
can successfully intercept a session request message from a requester A
to a directory node B
for accessing the session.
Without Ksec, SKsp, SKreq, and SKpat, C can only get a piece of encrypted information without the decryption method. Thus, C cannot access the content of the session. The similar inference can be applied to the same replay attack between a user or a healthcare provider and a directory server.
Forward Secrecy: An adversary may have compromised the secret key of one session section Ksec and tries to use it to access other sections and sessions. However, different sections share different Ksec. Thus, the adversary cannot use the same section key to access other sections and sessions. The similar inference can be applied to the forward secrecy of Sdata.
: The data in integrity analysis can be classified into on-chain data and off-chain data. The on-chain data integrity is ensured by the immutability of the blockchain [8
]. The off-chain data can be further divided into healthcare data and directory information. The integrity of healthcare data is verified with the data digest stored on the blockchain. Since the data storage on blockchain is tamper-proof, users can trust the healthcare data if they pass the integrity check.
On the other hand, malicious servers could tamper the directory information from an internal attack. Yet, it will not be a disaster for two reasons. First, all sensitive information is encrypted before storage. Thus, they will not be leaked out even if the directory information is tampered with. Most likely, it will result in data not found (due to ID corruption) or decryption failure (due to content corruption), and users will then be informed of it. Second, once data corruption occurs, the healthcare provider (for inventory) or the patient (for session) can easily recover the directory information. The healthcare provider can reconstruct an inventory with the data from the local legacy system, while the patient can reconstruct the corrupted session with the data from his/her inventory.
Directory information reconstruction may bring additional overhead, since Ref
could be lost and only be reconstructed by traversing the blockchain for the event search. Without a single point of failure, fortunately, the decentralized network structure can minimize the chance of directory information recovery by storage redundancy [41
Privacy protection: Privacy protection is achieved from information encryption. In terms of P2P storage, an adversary can retrieve some directory files. However, the adversary cannot access the content of the inventories without Sdata. An adversary can also intercept some messages between healthcare providers and directory servers, learning the InvID, PKpat, and PKsp. Without Sdata, however, the adversary cannot derive InvID with H(PKpat Sdata), unable to associate a patient with a healthcare provider. Therefore, the location of the actual data is not exposed. Similarly, an adversary cannot learn the content of a section without Kkey, which can only be retrieved with SKsp, SKreq, and SKpat. In terms of blockchain, an adversary cannot access the encrypted content of the events without SKpat, including the patient identity PKuser, PKreq, and the DIDs. Therefore, the adversary cannot identify a patient from an EventDG or a requester from an EventSC, which is unable to associate a patient with any healthcare record or diagnosis.
Non-Repudiation of Unauthorized Data Access: In one case, an adversary may successfully retrieve and abuse some patient data without authorization. The digest in a block and the immutability property of blockchain can provide the evidence that a session, which authorizes the adversary the data access, does not exist, proving the illegality of the behavior. In another case, an adversary may access the data out of the authorized access range and deny it. The immutability property of blockchain can also provide evidence for the range of data sharing (i.e., st, et) in an EventSC, which can provide the evidence that the data access is out of the range.
Without compromising security, privacy, and scalability, MedChain shows higher efficiency than the existing designs in the previously discussed communication overhead and storage overhead. Furthermore, another advantage is flexibility. By separating the mutable information of healthcare data from the immutable information, MedChain allows healthcare providers to readily update the description of data with minimal overhead. For example, a hospital may change its domain name, which results in the change of all the data locations. If they are stored on blockchain, either a description update is not allowed, or new events and blocks have to be generated for new descriptions, increasing both computation and storage overhead. Such an advantage is intuitive. Therefore, it is not shown in the experiment.
The scalability from the patient point of view is a common issue of all patient-centric solutions, since patients have to respond to each data-sharing request and add each requested data into a session for access authorization. This is a tradeoff between patient controllability and overhead. By controlling session creation and revocation, MedChain is no worse than other solutions. If a patient wants to reduce the overhead from the same requester, he/she can leave the session open forever. Then the data sharing overhead in MedChain is similar to Reference [32
]. A more elegant solution could be constructed by introducing attribute-based data sharing and medical history-based data sharing to further reduce overhead, which is complementary to the session-based scheme. Attribute-based data sharing [46
] can allow a patient to share his/her healthcare data to a group of requesters tagged with the same set of attributes, e.g., physician and biomedical laboratory. Medical history-based data sharing [47
] can enable a patient to grant access to all his/her medical data related to a specific disease/symptom. We will study them in future work.
In summary, Table 4
compares MedChain with other solutions. The result shows the advantage of the proposed scheme in many aspects.