Redact-Chain for Health: A Scheme Based on Redactable Blockchain for Managing Shared Healthcare Data

Abstract

As blockchain technology evolves, it has become a crucial component in medical data sharing. However, current needs reveal that healthcare-focused blockchain schemes increasingly require the capabilities of modification and deletion. Moreover, traditional blockchain-based systems for medical data sharing often need help with a single point of failure, which undermines the system’s robustness. To address these challenges, we propose Redact-Chain for Health, a scheme based on the redactable blockchain for managing shared healthcare data. This scheme allows users to encrypt data for privacy protection and decrypt data when sharing medical information. By substituting the SHA-256 with the chameleon hash, Redact-Chain for Health introduces a fine-grained data editing scheme, facilitating medical institutions in effectively editing and managing data on the blockchain. Moreover, Redact-Chain for Health integrates a distributed trapdoor management scheme. This scheme empowers medical institutions to manage the trapdoor of the chameleon hash effectively, thereby circumventing the issue of a single point of failure. Our scheme also incorporates a symmetric encryption-based authentication algorithm to deter potential cyberattacks. Lastly, the security analysis of our proposed system demonstrates its effectiveness in preserving patients’ privacy, while performance analysis confirms Redact-Chain for Health’s efficiency.

1. Introduction

Electronic Health Records (EHRs) are a relatively new computer technology that can help major medical systems cope with the complex problems of traditional medical records, such as storage and sharing [1]. The COVID-19 pandemic has also led independent healthcare organizations to develop their own EHR management systems [2,3].

The traditional EHR model relies on a centralized storage center. With the application of cloud services, more and more medical institutions are transferring data to cloud service providers [4,5]. The traditional EHR model also allows for data sharing within a limited range of healthcare organizations. However, the conventional EHR model faces several challenges:

1.

Health data is exceedingly sensitive and necessitates robust protection. Storage servers, however, may compromise user privacy for financial gain. For instance, although users authorize professional healthcare staff to access their health data, storage servers could leak users’ personalized EHRs for medical research, drug advertising, and other purposes without obtaining users’ consent, thereby enhancing their profits [6].

2.

When medical disputes arise, users may suspect that the original EHRs stored in the storage systems have been tampered with due to their mistrust of third parties. Moreover, sharing data stored in these systems across different platforms with specific access control policies is challenging [7].

Blockchain technology provides a public, digitized, distributed ledger, as first proposed by Nakamoto [8]. It has been widely used in cryptocurrency transactions, such as Bitcoin [8], Ether [9], HyperLedger [10], and ZeroCash [11], and has become the key technology for data-sharing systems [12]. All nodes in the blockchain construct a peer-to-peer (P2P) network to interconnect. All participating nodes are equal, collaboratively providing services without a single central point, which can avoid the risk of the single-point bottleneck.

Due to its excellent characteristics of decentralization, openness, and so on, the blockchain-based EHR model can widely carry out data sharing [13,14]. It is worth noting that the blockchain-based EHR model has the characteristics of decentralization and openness compared with the traditional EHR model, which is very suitable for multi-party medical data sharing. The blockchain-based EHR model is the future trend of EHR model development. However, introducing a blockchain-based EHR model with the possibility of third-party storage institutions leads to not completely decentralized storage, and the related privacy protection scheme is still worth perfecting [15,16].

With the introduction of the General Data Protection Regulation (GDPR), the concept of the user’s “right to be forgotten” has been widely recognized, and the immutability of blockchain is contrary to this. Therefore, redactable blockchain has been widely proposed [17,18,19]. Presently, redactable blockchains primarily find application in the Internet of Things (IoT) [20,21,22].

However, the relevant applications of redactable blockchain are mainly in IoT. The reason to study redactable blockchain applications in medical scenarios is that medical systems have higher privacy requirements for users [23,24,25]. How to design a redactable blockchain model that can be promoted and applied in the medical field is worthy of further study [25,26].

Therefore, our motivation for conducting this research is as follows:

1.

How to ensure that medical data can be shared and users’ privacy will not be disclosed is a problem that we need to study;

2.

Making the blockchain model as decentralized as possible and improving the privacy protection measures are worthwhile goals;

3.

Applying the redactable blockchain model to the medical field and perfecting its functionality is an issue that requires constant attention.

To address the challenges above, we propose the Redact-Chain for Health (RCH), an innovative healthcare data-sharing system premised on redactable blockchain technology. Compared with the prior schemes, our proposal explores how redactable blockchain can be used in a specific scenario in the medical field. In addition, our solution combines the need for privacy protection and data sharing. Our solution realizes decentralized storage, ensuring the system will not produce a single point of failure and privacy disclosure caused by third-party services.

Moreover, from a technical point of view, our solution enables fine-grained access control (i.e., transaction-level data access), and our solution also allows uploading, deleting, and modifying transactions, which has yet to be studied in previous medical scenarios. Our solution adopts a decentralized design for the relevant entities as much as possible, which ensures the system does not suffer from a single point of failure. To ensure decentralized storage, in addition to redactable blockchain, we also use IPFS as a storage method; IPFS is also a decentralized storage technology based on blockchain technology. Finally, to ensure the authenticity of the user’s identity, our scheme also designs an authentication algorithm based on discrete logarithm and symmetric encryption, and the authentication process can effectively ensure the user’s privacy. These have not been studied in previous medical scenarios, and our research tries to improve the use of redactable blockchain in medical plans as much as possible.

The critical contributions of our approach are as follows:

•

Through the application of blockchain and IPFS, we achieve distributed storage, which is conducive to data sharing, user data preservation, and user privacy protection;

•

To ensure users’ privacy, we have designed a series of algorithms and measures, including identity authentication, distributed management of trapdoors, data encryption, and other criteria;

•

We apply the redactable blockchain model to the medical field and achieve as much decentralization as possible to ensure user privacy;

•

The results of the performance tests show that our solution balances the need for privacy protection and performance.

We organize the scheme as follows. Section 2 contains the literature review. Section 3 introduces the system model and the threat model of RCH. Section 4 introduces the details of RCH. Security analysis is included in Section 5. The performance results appear in Section 6. Section 7 includes the discussion of our scheme. Section 8 details the conclusion of RCH and our future work.

2. Literature Review

In this section, we discuss the related works in terms of traditional EHR models, blockchain-based EHR models, and redactable blockchain and its applications in the medical field.

2.1. Traditional EHR Models

Cloud-based Electronic Health Record (EHR) models form the foundation of most contemporary healthcare data management systems. For instance, Zhou et al. introduced a cloud storage-based multi-copy medical data storage scheme [4]. This solution enables multiple parties to share medical data. However, it heavily relies on a third-party auditor, necessitating a shift towards decentralization.

Furthermore, Hua et al. proposed CINEMA, a framework that allows users to query medical data at the service provider level without requiring decryption [5]. Notably, the decryption process is exclusive to users, enhancing access to online medical services while mitigating data leakage risks. However, CINEMA requires cloud servers with high computing and storage performance to enable simultaneous queries from millions of users.

Additionally, Wei et al. developed RS-HABE, a revocable hierarchical encryption storage scheme leveraging Attribute-Based Encryption (ABE) [27]. This scheme incorporates user revocation, key delegation, and ciphertext update functionalities. However, RS-HABE is encumbered by lengthy key generation times and sizable key lengths, necessitating substantial storage space for key retention.

It is worth noting that traditional EHR models are becoming increasingly aligned with the medical needs of the current era. For example, traditional EHR models adopt cloud services, eliminating the data-sharing issues prevalent in previous EHR models. Moreover, the implementation of encryption makes traditional EHR models more secure.

While these schemes provide secure storage and fine-grained access control in the cloud, they still face challenges, such as preventing internal malicious attacks and cloud server crashes.

Hence, this paper proposes a distributed blockchain-based system as an alternative to cloud servers for data storage and privacy protection.

2.2. Blockchain-Based EHR Models

Traditional EHR models have shortcomings, and many researchers are exploring using blockchain to address challenges in medical data sharing. The primary applications of blockchain technology in this context revolve around patient privacy protection and efficient patient data management.

Firstly, blockchain-based healthcare data-sharing schemes show potential for adequate patient privacy protection. For instance, Xu et al. proposed a blockchain-based medical IoT privacy protection scheme named HealthChain [28]. Though effective, HealthChain’s double-chain structure escalates computational costs. Meanwhile, Wang et al. developed MedShare, a trusted data-sharing platform utilizing innovative contracts, offering fine-grained access control to enhance patient privacy [6]. However, Xu et al.’s blockchain-based scheme for COVID-19 pandemic tracing relies on third-party storage services, introducing potential privacy leakage risks [12].

Secondly, blockchain technology promises advantages in healthcare data management. A data-sharing scheme in the consortium blockchain illustrates how users can initiate search requests to data owners [29]. Nonetheless, this system lacks full decentralization. Wang’s blockchain-based data management scheme for the Internet of Medical Things (IoMT) calls for nuanced user privacy distinction to prevent potential information leaks [30]. Zhang and Poslad [16] utilized Shamir’s secret sharing to authenticate users and doctors for fine-grained access authorization. However, in Zhang et al.’s scheme, EMRs are stored in a blockchain, which is maintained in a trusted cloud, leading to centralization. Zaabar et al. proposed a decentralized storage scheme called HealthBlock [31]. In HealthBlock, the introduction of blockchain and IPFS technology has enabled a decentralized medical system, and this decentralized storage is conducive to preventing data leaks and sharing medical data.

It is worth noting that the blockchain-based EHR model has the characteristics of decentralization and openness compared with the traditional EHR model, which is very suitable for multi-party medical data sharing. Moreover, with continuous research improvement, a blockchain-based EHR model can effectively protect patients’ medical privacy data. It can be said that the blockchain-based EHR model is the future trend of EHR model development [23,24].

Although blockchain-based EHR models are the emerging trend in this field, numerous challenges must be addressed. The primary issues involve achieving maximum decentralization and protecting user privacy to the greatest extent possible. These problems require our immediate attention and resolution [13,14,32].

Furthermore, it is critical to highlight that blockchain-based EHR models can safeguard users’ privacy effectively. However, there is ample room for improvement, particularly in balancing privacy protection with operational efficiency. Blockchain-based EHR models must also prevent the privacy issues third parties pose whenever possible [15,33].

Thus, the central question posed in this paper is how can we strengthen privacy protection without compromising efficiency and how can we decentralize related systems to the greatest possible degree?

2.3. Redactable Blockchain and Its Applications in the Medical Field

The unique properties of blockchain technology, including decentralization, immutability, and anonymity, have attracted significant attention from researchers [34,35,36]. However, malicious actors can also exploit these characteristics for illicit activities, such as inserting unlawful information and taking advantage of blockchain’s immutability [37,38]. In light of the emerging concept of the “right to be forgotten”, the immutable nature of blockchain necessitates adaptation to contemporary needs [39]. Consequently, the field of redactable blockchains has garnered substantial attention. Redactable blockchain has been extensively studied, and many models have emerged [40,41,42].

Redactable blockchains are primarily employed in the Internet of Things (IoT) [20,22]. For instance, Wei et al. propose a redactable blockchain-based framework for federated learning [21]. The method employs a trapdoor distributed management mode, making it difficult to tamper with blockchain data. Additionally, Xu et al. [43] proposed a redactable identity management scheme in which users can delete or modify their identity information on the chain when they exit the network after completing authentication. It is worth noting that these redactable blockchain models used in the IoT field exhibit excellent performance. These solutions enable decentralized management and storage.

However, the redactable blockchain applications mentioned above are specific to the IoT context. The application of redactable blockchain in the medical field necessitates corresponding modifications and adjustments. The primary reason for these changes is that in the IoT environment, blockchain-based applications should prioritize speed [25]. At the same time, the demand for privacy protection in the medical field is more significant than that, in the IoT environment. In the medical field, blockchain-based applications must prioritize user privacy. If user privacy is compromised, it may lead to the disclosure of patients’ disease information, medical data, and other sensitive information, resulting in significant losses for patients [44,45].

However, a scheme outlined in [26] utilized a redactable blockchain in the healthcare sector at a block-level data editing scale. This approach requires modifying all data on the block when only a single piece requires alteration, impeding efficient data maintenance on the redactable blockchain. In contrast, Rahul et al. introduced DS-Chain, an EHR storage system based on a deletable blockchain [46]. However, it lacks the functionality to add and modify medical data. Lastly, Zhang et al. developed a medical data-sharing system using a redactable blockchain with chameleon hashing, maintaining hash consistency pre- and post-block modification [47]. However, this system’s reliance on an administrator for the chameleon hash’s trapdoor raises potential security concerns.

The literature above shows that the current research on redactable blockchain in the medical field requires continuous improvement. Moreover, it is paramount to propose a fully functional data access control scheme that supports transaction-level access.

Related work has the following areas in need of improvement:

•

The traditional EHR model is plagued by centralized storage and limited data-sharing capabilities, which not only contravenes the spirit of collaboration but also rapidly compromises patients’ privacy;

•

Blockchain-based EHR models may be incompletely decentralized, and incomplete decentralization may lead to a single point of failure and privacy disclosure, so ensuring the characteristics of decentralization is very important for blockchain-based EHR models;

•

At present, most of the applications related to redactable blockchain are in the IoT. How to apply the redactable blockchain model to the medical field maturely and maintain a relatively perfect function is a problem that needs to be solved.

In order to solve the problems, we propose RCH.

3. The System Model and Threat Model of RCH

In this section, we propose the methods of RCH. This section combines the overview of RCH and the details of RCH.

3.1. The System Model of RCH

In this subsection, we introduce the system model of the RCH.

The system model of the RCH is depicted in Figure 1. It is composed of five entities, two components, and seven phases. The five entities include the Administrator, the Medical Institution (MI), the Verification Institution (VI), the Key Generation Center (KGC), and the Patients. The two components are redactable blockchain and IPFS. Furthermore, the RCH can be categorized into six phases and an additional phase: the initialization phase, the registration and verification of MIs phase, the registration and verification of patients phase, the editing of EHRs phase, the trapdoor recovery phase, and the uploading of EHRs phase. The additional phase is the patients querying EHRs phase. We divide these phases into initialization, identity management, and data editing. Identity management includes the registration and verification of MIs and patients phase, while data editing encompasses the EHRs phase, the trapdoor recovery phase, and the upload of EHRs phase. Additionally, we classify the patient querying EHRs phase as a phase in data editing.

The system model of RCH consists of five main components, including the Administrator, Verification Institution (VI), Key Generation Center (KGC), Medical Institutions (MIs), and Patients. The following is a description of the five entities of RCH.

• The Administrator is responsible for initializing the redactable blockchain network, setting up system parameters, and establishing the key generation center and verification institution. Once these tasks are completed, the Administrator withdraws from the system and ceases to be actively involved in its management.
• The Verification Institution (VI), which is composed of several reputable nodes, is implemented by the Administrator. Its principal function is to register and verify the identities of both medical institutions and patients.
• The Key Generation Center (KGC), established by the Administrator, has all the necessary parameters for key generation after initialization. It is responsible for producing the trapdoor and distributing trapdoor segments and authentication keys to the Medical Institutions.
• Medical Institutions (MIs) provide medical services to patients and participate in the management of information within the RCH network. They can exist in two states: authenticated (on-chain) and unauthenticated (off-chain). Only on-chain MIs can provide medical services and contribute to managing the redactable blockchain.
• Patients can collaborate with MIs to modify their EHRs. After registration or verification, patients have the option to participate in the EHR sharing scheme or not.

RCH also includes two components: redactable blockchain and IPFS. The following is an introduction to the two components.

• The redactable blockchain is a storage technology that stores sections of patients’ EHRs. Because each block’s maximum capacity is limited to 1 MB, a careful selection of medical information to be held on the blockchain is required, a process involving patients and MIs. Within the blockchain, patients’ EHRs are saved in the form of transactions.
• On the other hand, the InterPlanetary File System (IPFS) is employed for storing comprehensive EHRs. After the selection process of medical information for blockchain storage, patients can participate in data-sharing schemes. If a patient chooses to participate in such a scheme, their complete EHR is stored within the IPFS by the corresponding MI.

After introducing the entities and components of RCH, we introduce the general steps of RCH:

Initially, an administrator is responsible for generating system parameters, initializing the blockchain network, and deploying IPFS, VI, and KGC. The administrator’s participation in the RCH ceases upon completion of the initialization phase.

During the registration and verification phase for MIs, first-time users must be registered by the VI. Subsequently, the KGC assigns each MI a unique authentication and public key for signature purposes, while the VI disseminates trapdoor segments. For subsequent logins, MIs must utilize their unique authentication key to establish a connection with the VI for authentication. Successful authentication transitions MIs from off-chain to on-chain status, enabling their active participation in RCH management. Additionally, KGC must send MIs their keys for signature.

For patient registration, patients must coordinate with the VI to register their information during their initial access to RCH. The KGC then distributes unique keys to patients for patient verification, EHR encryption, and decryption, ensuring data manipulation is exclusive to the patient. Furthermore, the KGC provides a private key for signature purposes to patients. Patient verification procedures mirror those of MIs, and KGC must also send patients their keys for signature.

During the EHR editing phase, patients must maintain a connection with any on-chain MI while receiving medical services to edit their EHRs. Before uploading EHRs to the redactable blockchain, patients encrypt their records and determine their willingness to share the data.

Upon completing the EHR editing process, the on-chain MI facilitates trapdoor recovery, and trapdoor recovery uses the Shamir key sharing protocol.

Following trapdoor recovery in the EHR upload phase, the MI providing medical services commits the EHRs to the redactable blockchain. If a patient consents to participate in medical data sharing, the MI must also upload comprehensive EHRs to the IPFS.

Lastly, during the querying EHRs phase, patients can decrypt and verify their EHRs.

3.2. The Threat Model of RCH

In the RCH framework, we establish certain assumptions regarding the roles and behaviors of the various participants. It is presumed that on-chain MIs and patients act with honesty. This assumption suggests that potential threats are more likely to arise from uncertified users.

For MIs and patients engaging with RCH for the first time, we provide a secure communication channel during the registration process and the subsequent interactions between registered patients and on-chain MIs. However, we cannot guarantee communication security during the verification process for MIs and patients. It should be recognized that potential attackers might eavesdrop on the entire verification process. This work does not discuss the specific content of the registration information, enabling the VI to determine the information required for MI registration based on real-world needs.

Additionally, we operate under the assumption that the redactable blockchain is reliable. RCH is designed to be compatible with various consensus mechanisms. For illustrative purposes, we discuss the Proof of Work (PoW) mechanism, employed within the RCH framework in this instance.

Table 1. Abbreviations of RCH.

Abbreviations	Descriptions
$\lambda$	Security parameters
p, q and g	System parameters
$Z_p^{*}$	The integer modulus p multiplication group
$Z_q^{*}$	The integer modulus q multiplication group
$iden{t}_{MI}$	The identification information of MI
$iden{t}_{Pat}$	The identification information of patient
$I{D}_{MI}$	The ID of MI
$I{D}_{Pat}$	The ID of patient
$ke{y}_{MI}$	The authentication key of MI
$ke{y}_{Pat}$	The authentication and encryption key of patient
$trap$	The trapdoor of the redactable blockchain
$ran{d}_{Info}$	Notification information
$ran{d}_{Verify}$	The random number used for the current validation
$tem{p}_{MI}$	MI’s temporary information generated during verification process
$tem{p}_{VI}$	VI’s temporary information generated during verification process
$tem{p}_{Pat}$	Patient’s temporary information generated during verification process
$iden{t}_{Ver}$	The verification information with $iden{t}_{MI}$ or $iden{t}_{Pat}$
$inf{o}_{Ver}$	The verification information used for the alignment generated by VI
$ve{r}_{Msg}$	The message for verification generated by MI or patient
$ve{r}_{Res}$	The result of verification
T	Timestamp
$si{g}_{Pat}$	Signature of patient
$E_{Block}$	EHRs stored on the blockchain
$E_{IPFS}$	EHRs stored in IPFS
$tx$	Transaction stored in the redacrable blockchain
$t{x}_{new}$	Modified transaction stored in the redacrable blockchain
$E_{New}$	Modified EHR message
$p{k}_{MI}$	MI’s public key
$s{k}_{Pat}$	Patients’ private key

shows the notations of RCH.

4. The Details of RCH

In this section, we explain the details of the six phases and the additional phase of RCH: initialization phase, registration and verification of MIs phase, registration and verification of patients phase, editing of EHRs phase, trapdoor recovery phase, upload of EHRs phase, and querying EHRs phase.

4.1. Initialization

In this phase, given a security parameter $\lambda$, the administrator generates system parameters; initializes the redactable blockchain network; and deploys IPFS, VI, and KGC.

•

The administrator, by utilizing the given security parameters $\lambda$, generates the system parameters p, q, and g. These parameters must satisfy two conditions: p and q must be large prime numbers and $q\left|\right(p-1)$. Further, g should be an element of order q in $Z_p^{*}$. A significant component of this phase involves the administrator generating $Z_q^{*}$, which is utilized to generate the trapdoor, denoted as $trap$, and to manage the identity information of both the MIs and the patients.

•

Following the generation of the system parameters, the administrator identifies honest miners and generates the genesis block, thereby establishing the structure of the redactable blockchain network. Concurrently, the administrator deploys the VI and the KGC, retaining the system parameters p, q, and g. The KGC generates and disseminates keys and trapdoor fragments, relying on system parameters.

After the initialization phase, the administrator exits RCH and does not participate in the scheme’s subsequent phases.

4.2. Registration and Verification of MIs

This phase contains two operations: registration and verification. MIs that access the RCH for the first time are in the registration, and MIs that re-access the RCH are in the verification.

•

In the registration, MIs using RCH for the first time need to contact VI to register. MIs need to transmit their MIs’ information to VI. VI makes judgments based on this information and decides whether to allow MIs to register successfully. VI can check the MI’s medical qualification, scale, and other information. The specific check information can be changed according to the actual situation. When MIs are successfully registered, VI issues the identification information $iden{t}_{MI}$ to the MIs, along with $iden{t}_{MI}\in Z_q^{*}$. The identification information is unique. Moreover, the VI needs to generate the IDs of MIs $I{D}_{MI}$ to determine which MI issued the authentication request.

•

In post-registration, the MIs become an integral part of the blockchain network, or in other terms, they become ‘on-chain.’ VI needs to distribute $ke{y}_{MI}$ to the MI used for verification. VI transmits $ke{y}_{MI}$ to MIs over a secret channel. VI backs up $ke{y}_{MI}$ and looks up keys against $iden{t}_{MI}$ and $I{D}_{MI}$ when needed. MIs initiating the use of the RCH system also partake in the distribution of trapdoor segments, whereby KGC summons all on-chain MIs to distribute these segments. The generation of trapdoor segments employs the Shamir secret-sharing scheme, with KGC generating the trapdoor $trap$, a member of $Z_q^{*}$. KGC determines the minimum number of MIs t required for trapdoor recovery, documents the current number of MIs n, and randomly selects n different random numbers $x_1,x_2,\cdots ,x_n$. Each MI then inserts its own generated random number x into the following equation:

$$f\left(x\right)=\left[t+a_1{x}^1+a_2{x}^2+\dots +a_{(t-1)}{x}^{t-1}\right]modp$$

(1)

Upon computation using the above equation, MIs obtain $f\left(x_1\right), f\left(x_2\right),\cdots ,f\left(x_n\right)$. Finally, the trapdoor segments following the pattern $(x_1,f\left(x_1\right)), (x_2,f\left(x_2\right))\cdots ,(x_n,f\left(x_n\right))$ are distributed among each on-chain MI.

•

Within the verification phase, an MI initiates the process by generating a substantial random integer denoted as notification information $ran{d}_{Info}$. This random integer will notify the VI about an MI seeking current authentication. Upon receipt of the encrypted $ran{d}_{Info}$, the VI decrypts it and dispatches an encrypted message denoted as $ran{d}_{Verify}$, an element in $Z_q^{*}$. It should be noted that $ran{d}_{Verify}$ is exclusively utilized within the current verification instance.

Upon receiving and decrypting the encrypted $ran{d}_{Verify}$, the MI is tasked with generating certification information, represented as $ve{r}_{Msg}$, utilizing $iden{t}_{MI}$, $ran{d}_{Verify}$, and $I{D}_{MI}$. The MI begins by computing a temporary variable:

$$tem{p}_{MI}=iden{t}_{MI}\oplus ran{d}_{Verify}$$

(2)

In addition, the meaning of ⊕ is xOR.

Subsequently, the MI determines the $iden{t}_{Ver}$ using the following mathematical formula:

$$iden{t}_{Ver}=g^{tem{p}_{MI}}modp$$

(3)

As the final step, the MI generates the certification message $ve{r}_{Msg}$, utilizing $iden{t}_{Ver}$ and $I{D}_{MI}$. Notably, $I{D}_{MI}$ requires a calculation through any collision-resistant hash function, $h(·)$. Algorithm 1 delineates the generation process of $ve{r}_{Msg}$. Upon receiving the encrypted $ve{r}_{Msg}$, the VI decrypts it and verifies $iden{t}_{Ver}$.

VI performs the calculations $tem{p}_{VI}=iden{t}_{MI}\oplus ran{d}_{Verify}$ with the known $iden{t}_{MI}$ and $ran{d}_{Verify}$. Subsequently, VI calculates $inf{o}_{Ver}=g^{tem{p}_{VI}}modp$. The final step of the verification process entails the comparison $iden{t}_{Ver}==Inf{o}_{Ver}$, as detailed in Algorithm 2.

After completing the verification process, VI returns the verification result $ve{r}_{Res}$ and a timestamp T. The verification result incorporates two possible outcomes: success or failure. The MI can transition to on-chain MI status only after it decrypts $ve{r}_{Res}$ and retrieves the successful verification information alongside the current timestamp.

The encryption process can employ any symmetric encryption algorithm, with AES-256 as the RCH system’s default choice. All outgoing messages must be encrypted using $ke{y}_{MI}$, while all incoming messages must be decrypted using the same key. Figure 2 visually represents the verification process for the MIs.

•

After receiving the verification result, if the MI is successfully verified, it converts to on-chain and can provide medical services and participate in the RCH management. If the MI fails to pass the verification, it cannot enter the system.

Algorithm 1 Generation of $ve{r}_{Msg}$.

Input:   Encrypted message $ran{d}_{Verify}$   MI’s identification information $iden{t}_{MI}$   MI’s ID $I{D}_{MI}$ Output:   Encrypted identity information for verification $ve{r}_{Msg}$   1:   Decrypt $ran{d}_{Verify}=Dec\left(ran{d}_{Verify}\right)$   2.   Calculate $tem{p}_{MI}=iden{t}_{MI}\oplus ran{d}_{Verify}$   3.   Calculate $iden{t}_{Ver}=g^{tem{p}_{MI}}modp$   4.   Generate $ve{r}_{Msg}=\{Enc\left(iden{t}_{Ver}\right),h\left(I{D}_{MI}\right)\}$   5.   return  $ve{r}_{Msg}$

Algorithm 2 Verification of MI.

Input:   Encrypted certification information $ve{r}_{Msg}$   MI’s identification information $iden{t}_{MI}$   Message $ran{d}_{Verify}$   Timestamp T Output:   Encrypted verification result $ve{r}_{Res}$   1.   $ve{r}_{Res}= “fail“$   2.   Decrypt $ve{r}_{Msg}=Dec\left(ve{r}_{Msg}\right)$   3.   Calculate $tem{p}_{VI}=iden{t}_{MI}\oplus ran{d}_{Verify}$   4.   Calculate $inf{o}_{Ver}=g^{tem{p}_{VI}}modp$   5.   if  $iden{t}_{Ver}==inf{o}_{Ver}$ then   6.     $ve{r}_{Res}=“success”$   7.   end if   8.   Encrypt $ve{r}_{Res}=\{Enc\left(ve{r}_{Res}\right),T\}$   9.   return  $ve{r}_{Res}$

4.3. Registration and Verification of Patients

Analogous to MIs, patients must interact with the VI for initial access to the RCH system to complete the registration process. Patients need to transmit their information to the VI. The VI makes judgments based on this information and decides whether to allow patients to register successfully. When patients are successfully registered, VI issues the identification information $iden{t}_{Pat}$ to the patients, along with $iden{t}_{Pat}\in Z_q^{*}$. The identification information is utilized for the identity verification of patients and is unique. Moreover, the VI needs to generate the IDs of patients, $I{D}_{Pat}$, to determine which patient issued the authentication request.

Upon successful enrollment, the VI designates the patient’s identification data, $iden{t}_{Pat}$, which is presumed to be a member of $Z_q^{*}$, to the patient. In addition, KGC provides both the patient and VI with an identity key, $ke{y}_{Pat}$, which is instrumental in safeguarding EHR encryption and subsequent verification. The patients are presented with distinctive IDs, symbolized as $I{D}_{Pat}$. The VI securely transmits $ke{y}_{Pat}$ to the patient over a confidential channel.

Before receiving medical services, patients must verify their identities with the VI. The identity verification process of the patients echoes that of the MIs. The patients receive $ran{d}_{Verify}$ from the VI and subsequently calculate a temporary variable, $tem{p}_{Pat}=iden{t}_{Pat}\oplus ran{d}_{Verify}$. Patients then compute $iden{t}_{Ver}=g^{tem{p}_{Pat}}modp$, encrypt it along with $h\left(I{D}_{Pat}\right)$ using $ke{y}_{Pat}$ to generate $ve{r}_{Msg}$, and transmit it to the VI.

In the final stage, the VI performs calculations on $tem{p}_{VI}=iden{t}_{Pat}\oplus ran{d}_{Verify}$ and $inf{o}_{Ver}=g^{tem{p}_{VI}}modp$ with the known $iden{t}_{Pat}$ and $ran{d}_{Verify}$. Moreover, $iden{t}_{Ver}$ is also incorporated into the patient’s $ve{r}_{Msg}$, rendering the patient’s $ve{r}_{Msg}$ as $\{Enc\left(iden{t}_{Ver}\right),h\left(I{D}_{Pat}\right)\}$. After receiving $ve{r}_{Msg}$, the VI extracts $iden{t}_{Ver}$ and verifies the equality $iden{t}_{Ver}==inf{o}_{Ver}$; after that, it transmits the verification result $ve{r}_{Res}$, accompanied by the current timestamp, to the patients. Notably, patients can only avail themselves of medical services from MIs after they decrypt $ve{r}_{Res}$, inspect the timestamp, and receive successful verification information.

Figure 3 illustrates the patient authentication process, which resembles the identity authentication process of MIs. In this process, the patient initiates the authentication by transmitting $ran{d}_{Info}$, followed by the reception of $ran{d}_{Verify}$ from the VI. After receiving $ran{d}_{Verify}$, the patient modifies $ve{r}_{Msg}$ before transmitting it back to the VI. Subsequently, the VI undertakes validation of the received information and provides the verification result $ve{r}_{Res}$. It is essential to highlight that encryption is imperative to ensure the above information’s confidentiality.

4.4. Editing of EHRs

Patients seeking medical services must engage with an on-chain MI within the RCH framework. This interaction necessitates creating and refining EHRs between the patient and the MI.

Figure 4 shows the process of editing EHRs. Figure 4 mainly includes the negotiation between the patient and MI and the EHR signing process.

Firstly, The patient and the doctor can jointly negotiate the relevant diagnostic records to form an EHR. When the negotiation is complete, the MIs edit the EHRs. An EHR consists of data uploaded to the blockchain, $E_{Block}$, and data uploaded to IPFS, $E_{IPFS}$. It should be noted that the patient has the right to decide whether to generate $E_{IPFS}$, and $E_{IPFS}$ can participate in data sharing permanently.

After the EHR is generated, the patient encrypts it with their key, $ke{y}_{Pat}$. When other institutions want to query the EHR, the patient must decrypt it with their own key, $ke{y}_{Pat}$.

After the refinement of EHRs, the patient is required to append a signature to the EHR. MIs and patients need to issue a request to the KGC to assign the signed key. The KGC gives the signed public key, $p{k}_{MI}$, to the MI via a secret channel, and the patient receives the signed private key, $s{k}_{Pat}$. The patient needs to sign the EHRs using $s{k}_{Pat}$, and the MI needs to validate the patient’s signature using $p{k}_{MI}$. The mathematical representation of the patient’s signature can be expressed as:

$$si{g}_{Pat}=Sig\{H\left(iden{t}_{Pat}\right),H\left(iden{t}_{MI}\right)\}$$

(4)

Within this formula, $H(·)$ denotes a collision-resistant hash function, while $Sig·$ represents an arbitrary signature algorithm.

4.5. Trapdoor Recovery

Following the generation or modification of EHRs, the MI interfacing with a given patient and other on-chain MIs within the blockchain system engages in restoring trapdoor segments. This recovery mechanism leverages the principles underlying Shamir’s secret-sharing scheme.

Critical to the success of the trapdoor restoration process is the requirement for a minimum of t MIs to be part of the blockchain ecosystem. In situations where the number of participating MIs surpasses the threshold, t, these MIs utilize fragments of the trapdoor, denoted as $(x_1,f\left(x_1\right)),(x_2,f\left(x_2\right))\cdots ,(x_j,f\left(x_j\right))$$\left(j\le n\right)$, to restore the trapdoor, $trap$. The mathematical expression governing the trapdoor recovery process can be represented as:

$$trap=\sum _{i=1}^{t}f\left(x_i\right)\prod _{\begin{array}{c}j=1j\ne i\end{array}}^t\frac{x-x_j}{x_i-x_j}modp$$

(5)

Upon completing the trapdoor recovery process, the MI gains access to the trapdoor, denoted as $trap$. Subsequently, the MI can utilize $trap$ to generate the public key, $y=g^{trap}modp$.

Figure 5 demonstrates how an MI can recuperate the trapdoor and upload EHRs to the redactable blockchain. Initially, the MI collaborates with other on-chain MIs to recover the trapdoor through the secret sharing protocol. Following the recovery of the trapdoor, the MI encapsulates the EHRs into transactions and proceeds to upload them to the redactable blockchain.

4.6. Upload, Modification, and Deletion of EHRs on the Blockchain

Upon completion of the trapdoor recovery process, MIs need to edit the data of the blockchain, and the editing operation of the data includes uploading, modifying, and deleting the data.

1.

In the process of uploading EHRs, the MI constructs an EHR message, $E_m$ = {T, $E_{Block}$, $si{g}_{Pat}$}. This message encompasses $E_{Block}$ and the associated timestamp, T. Subsequently, a network miner produces a new transaction, $tx$ = {$E_m$, h}, that incorporates a hash value, h. In addition, after generating the $tx$, the MIs set the IDs of the EHRs according to the ID rules of the medical institution itself and inform the patient of the IDs of the EHRs.

The generation process of a transaction is briefly illustrated in Algorithm 3. It should be noted that h is a chameleon hash, ensuring the preservation of the hash value’s consistency preceding and following the modification of the transaction. This meticulous procedure enables the generation of a new EHR in a manner that upholds the integrity and reliability of the system.

Algorithm 3 Transaction generation.

Input:   Timestamp T   Encrypted EHR message $E_{Block}$   Patient’s signature $si{g}_{Pat}$ Output:   Transaction $tx$   1.   Set the EHR message $E_m$={T, $E_{Block}$, $si{g}_{Pat}$}   2.   Calculate chameleon hash $h=CHash(E_{Block},r,y)$   3.   Set $tx$={$E_m$, h}   4.   return  $tx$

After generating the $tx$, the MIs calculate the hash value of $tx$ as the IDs of the EHRs and inform the patient that their EHRs are $H\left(tx\right)$.

Every time RCH generates a new block, miners calculate a new hash. The chameleon hash formula is as follows:

$$CHash\left(m,r,y\right)=h=y^{H\left(m\right)}{g}^{r}modp$$

(6)

Figure 6 shows the uploading of new medical data. MIs must encapsulate EHRs as transactions, calculate chameleon hashing, and then upload them to the redactable blockchain.

2.

In the event of modifying EHRs, the MI generates an updated EHR message, $E_m^{\prime }$ = {T,$E_{New}$, $si{g}_{Pat}$}, where $E_{New}$ signifies the updated medical data. Subsequently, it becomes incumbent on the miner to induce a hash collision, a necessary step to ensure the Merkle Tree’s consistency both before and after modification.

To ensure historical integrity and authenticity, MIs need to modify the time stamp to some extent when modifying a transaction and add the time stamps of all past modifications to ensure the historical authenticity of data.

Moreover, the miner constructs a fresh transaction, $t{x}_{New}$={$E_m^{\prime }$, h}, which is intended to replace $tx$ in the transaction field. The procedure for modifying EHRs is thoroughly detailed in Algorithm 4. Furthermore, after generating $t{x}_{New}$, the miners incorporate $t{x}_{New}$ into the block. This systematic and rigorous process ensures the accurate and effective modification of EHRs within the blockchain network.

Algorithm 4 Transaction modification.

Input:   Timestamp T   Modified EHR message $E_{New}$   Patient’s signature $si{g}_{Pat}$   Chameleon hash value h Output:   Modified transaction $t{x}_{New}$   1.   Set new EHR message $E_m^{\prime }$={T, $E_{New}$, $si{g}_{Pat}$}   2.   Make chameleon hash collision through $r^{\prime }=r+(H\left(E_m\right)-H\left(E_{m^{\prime }}\right))trapmodq$   3.   Set $t{x}_{New}$={$E_m^{\prime }$, h}   4.   return  $t{x}_{New}$

When a transaction needs to be modified, MIs must construct a hash collision to maintain the same hash value before and after the modification. The formula for constructing a hash collision is as follows:

$$r^{\prime }=r+(H\left(m\right)-H\left(m^{\prime }\right))trapmodq$$

(7)

In addition, the chameleon hash value of the transaction does not change during the transaction modification process.

Figure 7 shows the process of modifying medical data. MIs must encapsulate new EHRs as new transactions, making the chameleon hash collision, and then upload them to the redactable blockchain.

3.

To eliminate EHRs within the redactable blockchain, MIs edit empty EHRs, i.e., $E_{m^{\prime }}$ = NULL. After MIs edit the empty EHRs, MIs construct chameleon hash collisions. It should be noted that MIs need to encapsulate empty EHRs as “empty transactions”, i.e., $t{x}_{New}$ = {$E_{m^{\prime }}$, h}. MIs need to upload “empty transactions” to the redactable blockchain. The precise algorithm for removing medical data is illustrated in Algorithm 5.

After uploading the empty transactions, MIs upload a consolidated declaration on the IPFS. This statement confirms the timestamp of all edits to the data and ensures the preservation of historical integrity and authenticity.

Algorithm 5 Transaction deletion.

Input:   An existed EHR $E_m$   An NULL EHR $E_{m^{\prime }}$   Chameleon hash value h Output:   A transaction without EHR $t{x}_{NULL}$   1.   Set $E_{m^{\prime }}$ = NULL   2.   Make chameleon hash collision through $r^{\prime }=r+(H\left(E_m\right)-H\left(E_{m^{\prime }}\right))trapmodq$   3.   Set $t{x}_{New}$={$E_m^{\prime }$, h}   4.   return  $tx$

Figure 8 shows the process of deleting medical data. Firstly, MIs edit empty EHRs. Then, MIs must upload “empty transactions” to the redactable blockchain. After the upload is complete, MIs must upload declarations to IPFS and label all edit dates for the medical data.

In addition, the chameleon hash used to modify a block is the same as the chameleon hash used to modify a transaction, and miners need to make the hash collision.

In summary, MIs must modify the timestamp when altering a transaction with certain limitations to preserve historical integrity and authenticity. The timestamps of all previous modifications are appended to confirm the historical genuineness of the data. Throughout the deletion process, historical integrity and authenticity are preserved in concrete forms. Following the deletion of medical data by MIs, a joint statement confirming the deletion of the data and specifying the modification time is provided by the patient and MIs and subsequently uploaded to the IPFS. Additionally, given that the medical data is uploaded to the IPFS, whose immutability ensures permanent storage once the data is uploaded, it further strengthens the historical integrity and authenticity.

Furthermore, the RCH framework strengthens the solution’s security throughout the modification process. This consolidation is based on the premise that “MIs and patients exhibit honesty”; hence, MIs are restricted from uploading data onto the redactable blockchain until after the patient and the MIs have inscribed the EHRs. The implementation of digital signatures ensures that medical data remains traceable and accountable. Moreover, this approach guarantees the preservation of historical integrity and authenticity.

4.7. Additional Phase: Querying EHRs

Patients can access their EHRs using their unique $ke{y}_{Pat}$. When they share data, patients can verify the comprehensive EHRs stored in the IPFS, utilizing the same key. Notably, only on-chain MIs can request access to a patient’s EHRs. Any remaining off-chain MIs are required to engage with the MI that furnishes the patient with medical services. Following this, the MI liaises with the patient, who then decrypts the EHRs and transfers the medical data to the requesting MIs, thereby completing the data-sharing process. $E_{Block}$ and $E_{IPFS}$ may be disseminated among MIs.

In addition, when there is a problem with medical data, any institution can apply to the VI to track patients. The VI can quickly determine the identity of the MI by decoding the corresponding signature through $p{k}_{MI}$ and then choose the information of the MI and patient according to the content of the signature, $\{h\left(iden{t}_{Pat}\right),h\left(iden{t}_{MI}\right)\}$.

5. Security Analysis

In this section, we analyze the security of RCH. We conduct security analysis from the following perspectives: privacy protection, identity management, scalability, and non-repudiation.

5.1. Privacy Protection

In this section, we present Theorems 1 and 2 and their subsequent proof, demonstrating the privacy preservation capabilities of our proposed protocol. The goal of privacy protection is that a malicious user cannot obtain the trapdoor and cannot directly access the data.

Theorem 1. 

The malicious user Eve cannot directly obtain $trap$ to manipulate the chameleon hash.

Proof. 

For the sake of argument, we postulate that Eve lacks access to the trapdoor $trap$ before the onset of an attack. Without $trap$, Eve cannot generate a chameleon hash collision, failing to discover a novel random $r^{\prime }$.

Given that Eve procures r, m, and $m^{\prime }$, Eve is mandated to discover an $r^{\prime }$, and the hash collision is determined by $r^{\prime }=r+(H\left(m\right)-H\left(m^{\prime }\right))·trapmodq$. This means that Eve must ascertain the public key $y=g^{trap}modp$ and the trapdoor $trap$ to manufacture the hash collision successfully. It is recognized that $trap\in Z_q^{*}$, and G signifies the cyclic group of order q, wherein g is an element of order q. The resolution of the discrete logarithm problem is required for Eve to calculate $trap$, an undertaking deemed improbable due to the lack of a probabilistic polynomial-time algorithm. Thus, the malicious user Eve cannot directly obtain $trap$ to manipulate the chameleon hash.  □

Theorem 2. 

The malicious user Eve could not view the decrypted medical data.

Proof. 

If Eve wants to obtain decrypted medical data, it needs to get the patient’s key, $ke{y}_{Pat}$, to interpret and view the data. Based on the assumption that the patient is verified to be honest, the patient can keep $ke{y}_{Pat}$ in safe custody, so Eve cannot obtain $ke{y}_{Pat}$ and therefore cannot decrypt the patient data.  □

5.2. Identity Management

In this section, we present Theorem 3 and its accompanying proof, delineating the ability of our protocol to guarantee identity management security. The security goal of identity management is that malicious users cannot obtain user identity information through the verification process.

Theorem 3. 

Malicious users cannot obtain user identity information through the verification process.

Proof. 

Based on verifying MIs’ identity, we can divide the process into four steps. We perform security analysis on the results of each monitoring step.

Step 1. When malicious user Eve intercepts $ran{d}_{Info}$ and impersonates the MI or the patient, the VI will send an encrypted $ran{d}_{Verify}$ because Eve does not have the AES-256 key $ke{y}_{MI}$ or $ke{y}_{Pat}$, and it cannot be decrypted in polynomial time without the AES-256 key, so Eve cannot decrypt $ran{d}_{Verify}$.

Step 2. When malicious user Eve obtains $ran{d}_{Verify}$, because it cannot decrypt it, it cannot construct the correct $ve{r}_{Msg}$, so Eve cannot impersonate the MI or the patient.

Step 3. When malicious user Eve obtains $ve{r}_{Msg}$, Eve can impersonate the MI or the patient to receive the encrypted result information $ve{r}_{Res}$ from the VI. Because Eve has no key, it cannot decrypt in polynomial time and cannot obtain the decrypted result; it cannot impersonate the MI or the patient to log into the system.

Step 4. When malicious user Eve obtains $ve{r}_{Res}$, because Eve has no key and cannot decrypt in polynomial time, Eve cannot obtain the decrypted result, so it cannot impersonate the MI or the patient to log into the system.

Additional Discussion. Let us assume a situation where Eve knows the decrypted $ve{r}_{Msg}$ and $ran{d}_{Verify}$. Eve needs to use $ran{d}_{Verify}$ to obtain user identity information. The validation information is calculated as $g^{ident\oplus ran{d}_{Verify}}modp$. Moreover, in the process of user identity information decryption, because $ident\oplus ran{d}_{Verify}\in Z_q^{*}$, there is a lack of algorithms that can solve the discrete logarithm problem in polynomial time.Therefore, Eve knows that the decrypted $ve{r}_{Msg}$ and $ran{d}_{Verify}$ cannot obtain user identity information $ident$ by solving the discrete logarithm.

Therefore, due to the characteristics of the discrete logarithm problem itself, the user identity $ident$ cannot be solved, even if Eve obtains it again. Therefore, this scheme is also safe from calculation.  □

In conclusion, given the assumption that “registered and on-chain MIs are honest” in the security model, the verification procedures involving MIs and patients are inherently secure.

However, the security of our scheme is based on “verified MIs and patients are honest”. If MIs, patients, and malicious users conspire to forge identities, security issues will arise, which must be addressed in future work.

5.3. Reliability

In this section, we present Theorem 4 and its accompanying proof, delineating the ability of our protocol to guarantee reliability. The goal of reliability centers around the trapdoor, which is managed in such a way that it is secure and the system does not suffer from a single point of failure.

Theorem 4. 

The malicious user Eve cannot crack the trapdoor by obtaining the trapdoor fragment $(x_i,f\left(x_i\right))$, so Eve cannot obtain trapdoor tampering data. Thus, the trapdoor has reliability.

Proof. 

RCH uses Shamir’s secret sharing protocol to manage the trapdoor. The Shamir secret sharing protocol also requires at least t trapdoor fragments to be recovered

Let us assume a situation: Eve has gained the $t-1$ trapdoor fragments $(x_1,fleft\left(x_{1}right\right)),$$(x_2,fleft\left(x_{2}right\right)),\cdots (x_{t-1},f\left(x_{t-1}\right))$. At this point, Eve only needs to obtain $(x_t,f\left(x_t\right))$ to recover the trapdoor. On the assumption that all on-chain MIs are honest, MIs will keep their trapdoor fragment $(x_i,f\left(x_i\right))$ well. This prevents Eve from retrieving the last trapdoor fragment $(x_t,f\left(x_t\right))$.

It should be noted that since the trap recovery process ensures secure communication, Eve cannot guarantee the reliability of the trap by listening to the trap recovery.

Therefore, assuming all on-chain MIs are honest, Eve cannot obtain trapdoors by obtaining trapdoor fragments. Of course, in future studies, we will design a more general model to ensure that the MI can still keep trapdoors safe in the case of dishonesty.

Attention: It should be noted that other RCH designs also reflect reliability. Notably, during the initialization phase, the administrator deploys VI and KGC, which consist of several nodes. This configuration allows VI and KGC to simultaneously register, verify, and distribute keys and trapdoor fragments for multiple MIs. This proposition enhances the efficiency of registration and verification, ensuring that neither VI nor KGC are susceptible to a single point of failure, which could compromise their operational integrity. Therefore, our scheme can effectively prevent single issues of failure.  □

5.4. Non-Repudiation

In this section, we present Theorem 3 and its accompanying proof, delineating the ability of our protocol to guarantee non-repudiation. The goal of non-repudiation is when errors occur in medical data and no MI and no patient can deny all of their faulty data.

Theorem 5. 

When errors occur in medical data, no MI and no patient can deny all of their faulty data.

Proof. 

When generating $E_{Block}$ and $E_{IPFS}$, the MI and the patient need to generate signatures, $si{g}_{Pat}$, where the patient uses the private key $s{k}_{Pat}$ to sign, while the MI uses the public key $p{k}_{MI}$ to crack the patient’s signature, $si{g}_{Pat}$.

When data errors occur, either party can request KGC to use $p{k}_{MI}$ to crack $si{g}_{Pat}$, and the cracked $si{g}_{Pat}$ will obtain the information. Since $p{k}_{MI}$ and $s{k}_{Pat}$ are unique, if either party can crack $si{g}_{Pat}$, then the corresponding MI and patient can be found.

Therefore, MI and patients must acknowledge medical data that is incorrect.  □

5.5. The Advantages of RCH

As depicted in Table 1, we juxtapose the RCH scheme with those discussed in references [41,42,48,49,50]. Our protocol satisfies various crucial criteria, including privacy protection, identity management, scalability, redaction, and non-repudiation. Additionally, we scrutinize the functionalities of the blockchain, encompassing the capacity for redaction and deletion of EHRs within the blockchain and the use of transaction-level data redaction. For systems not incorporating blockchain technology, we denote this with the symbol “✕”.

RCH exhibits several distinct advantages compared to the schemes delineated in references [26,46,48,49,50].

Table 2. Security and functions comparison with related work.

Scheme	[48]	[49]	[50]	[46]	[26]	Ours
Blockchain-based	NO	NO	YES	YES	YES	YES
Privacy protection	YES	YES	YES	YES	YES	YES
Indentity management	NO	YES	YES	YES	NO	YES
Reliability	YES	NO	NO	NO	NO	YES
Non-repudiation	YES	YES	YES	NO	NO	YES
Redaction	✕	✕	NO	NO	YES	YES
Deletion	✕	✕	NO	YES	NO	YES
Transaction-level	✕	✕	NO	YES	NO	YES

shows the security and functions comparison with related work of RCH.

1.

RCH demonstrates exceptional reliability. Compared with [48,49,50], our protocol employs a fully decentralized storage approach, amplifying the system’s robustness. Compared with [26], our scheme actualizes distributed management of the chameleon hash trapdoor, effectively mitigating the risk of trapdoor leakage due to a single point of failure.

2.

RCH maintains an effective equilibrium between identity management and privacy protection. Following registration, our protocol promptly deletes personal information submitted by the MIs and patients. Furthermore, medical data sharing is conditional upon consent from the MIs and patients, underscoring the commitment to privacy for both MIs and patients. To forestall intrusions from malevolent agents impersonating legitimate MIs and patients to infiltrate RCH, we devised an authentication algorithm predicated on symmetric encryption and validated the security of this algorithm. This design approach harmonizes identity management with privacy protection.

3.

We effectuate fine-grained data editing and uphold the functional integrity of redactable blockchains. Compared with [26], we administer transaction-level medical data modification operations, ensuring that other Electronic Health Records (EHRs) within the same block remain unaltered when data within a block requires modification. Moreover, compared to [46], we enhance the blockchain network functionality to include transaction deletion and modification capabilities.

6. Performance Evaluation

The performance of the scheme is simulated and the corresponding results are obtained. In this section, we cover the background of performance analysis and the results of performance analysis.

6.1. Background

Performance evaluation for RCH was undertaken utilizing simulation experiments leveraged on a PC, incorporating a 64-bit Windows 11 Professional operating system, version 21H2. The plan was furnished with an 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80 GHz and 32.0 GB of RAM. Python 3.8 was the backbone for the RCH simulation, supplemented with the Crypto library.

The approach for performance analysis integrated open-source datasets, thereby circumventing potential constraints linked to sampling methodology and participant engagement procedures. Data for performance analysis underwent encryption before uploading onto the local IPFS and redactable blockchain. Completing the performance test necessitated this encrypted data (Further information associated with the data guiding this investigation can be found at http://www.cdc.go.kr/contents.es?mid=a40504070100 (accessed on 17 April 2020).

A 64-bit Ubuntu 18.04 architecture with 4 GB RAM was deployed as the VI to assess the effectiveness of authentication. Concurrent programming methodologies were employed to facilitate swift simulation of MI authentication.

Furthermore, repeated tests were conducted for each virtual scenario to ensure the precision of experimental results. Every test comprised 50 cycles of 100 trials per cycle. The final empirical findings were computed as the average over the 50 cycles to portray the experimental results accurately.

Our performance examination embraces time as the chief measurement indicator, acknowledging the potential for numerous end users to access the medical data-sharing system within minimal time frames. Ensuring system operation efficiency under such conditions is a pivotal aspect. Nevertheless, our methodology does come with certain limitations. Primarily, we utilized concurrent programming to emulate swift user authentication, albeit its effectiveness can be improved further.

Additionally, time, although a worthy criterion, also varies depending on the capabilities of the experimental apparatus. Consequently, the temporal cost results highlight our scheme’s efficiency but should be interpreted with cognizance of the potential influence the practical setting may exert.

To show that our scheme is optimal in terms of performance, we need to compare it with [51,52,53]. The result is shown in “Efficiency Comparison”.

We divided the efficiency comparison into Stages 1 and 2. Stage 1 embraces the initialization phase, MIs’, and patients’ registration and verification. In contrast, Stage 2 encapsulates EHR editing, the trapdoor recovery phase, and uploading. The performance analysis of uploaded data efficiency is predominantly evident within Stage 2. Owing to the immutability of the conventional blockchain model, discussion about eliminating medical data from the blockchain is consciously excluded from the analysis. Simultaneously, the comparative experiments utilize a consistent dataset of medical records.

6.2. The Result of Performance

In this section, we present the performance analysis results.

6.2.1. The Efficiency of Verifying MIs

Figure 9 encapsulates the efficiency results of verifying MIs, presenting the time needed to verify MIs. Crucially, Figure 9 underscores that as the volume of MIs accessing the VI escalates, the time taken by the comprehensive verification system exhibits a proportional increase. When 100, 200, 300, 400, and 500 MIs are authenticating simultaneously, the time overhead is 39.49217 ms, 44.79286 ms, 51.14956 ms, 60.00942 ms, and 79.67241 ms, respectively.

Despite the escalation in the time required for the validation process, the overall efficacy of this process has been notably improved by adopting parallel processing techniques, resulting in an acceptable time overhead for validation.

6.2.2. Uploading and Deleting Medical Data

The experimental results are visually depicted in Figure 10. The process of uploading and deleting data includes recovering the chameleon hash trapdoor and constructing the chameleon hash collision. Notably, the data upload procedure incorporates two additional steps: structuring the transaction and transferring data to IPFS. Nevertheless, it is demonstrated in Figure 10 that these supplementary processes engaged in data uploading do not substantially contribute to fluctuations in the system’s overall time overhead.

On average, the time expenditure for random data upload and deletion operations is 29.2747 ms. This observable data concurs with the assertion that the augmented procedural steps associated with data upload do not significantly impact the system’s time overhead.

6.2.3. Efficiency Comparison

Following our initial analysis, we conducted simulation experiments. We began by modeling the time consumption required for a single MI to participate in all stages. Subsequently, we compared the computational expense of our protocol with three alternative strategies. A visualization of the computational costs incurred by these three strategies is presented in Figure 11. Furthermore, we performed simulations of Stage 1 and Stage 2 under different schemes, and the results can be found in Figure 12.

As evident in Figure 11, the associated time overhead for stages [51,52,53] are 59.897 ms, 74.426 ms, and 149.497 ms, respectively, in comparison with a minimal time overhead of 50.801 ms exhibited by our scheme. These results reinforce the superiority of our scheme in minimizing time costs.

Figure 12 provides a comprehensive view of time cost outcomes for all tested scenarios during Stages 1 and 2. These experimental findings suggest that our scheme delivers impressive performance in both stages. It is crucial to highlight that, as per [51,52,53], the time cost in Stage 1 surpasses that of Stage 2. However, our scheme comprises data encryption, which results in a comparatively greater time cost in Stage 2 than in Stage 1.

7. Discussion

In the rapidly evolving landscape of information technology and blockchain innovation, medical data sharing has garnered significant attention in the academic research community. An increasing number of studies propose implementing blockchain-based systems for medical data sharing. The introduction of the GDPR "right to be forgotten" has created a pressing need to enhance the protection of this user right within related systems. Although redactable blockchains have been gradually adopted, these solutions’ relative immaturity and incompleteness have necessitated further improvement. In response, we introduce our proposed RCH, which aims to refine relevant functions and incorporate nuanced considerations for privacy protection.

Our program achieves a crucial balance between academic theory and practical application. Firstly, we explore promising methods to protect users’ “right to be forgotten” within a medical data-sharing framework. Secondly, we enhance the scheme’s functionality to enable transaction-level data upload, modification, and deletion. Lastly, we introduce a groundbreaking trapdoor management method supported by a secret sharing protocol. This decentralized approach reinforces the security of the trapdoor system.

Though we have advanced essential functions within the existing framework, we acknowledge the ongoing need for improvement and expansion. The trapdoor management scheme within our proposed system requires universal applicability due to its dependence on the honesty of MIs and patients. Consequently, we plan to refine our model to achieve universalization of the trapdoor management scheme. Furthermore, our algorithm still necessitates further research to enhance historical integrity and authenticity. The authentication process also relies on “the patient and MIs being honest”, and it is crucial to study methods to prevent collusion between registered users and malicious users.

8. Conclusions and Future Work

This study introduces a novel medical data-sharing approach grounded on the redactable blockchain model. More specifically, our scheme manifests patients’ “right to be forgotten”. It safeguards individual patient privacy, achieved via the strategically designed interaction between patients and medical institutions and the process upheld for data upload. To enhance the functionality of ongoing solutions, we have also incorporated a transaction-level data access methodology, wherein data operations such as creation, deletion, modification, and re-deletion can transpire in the guise of transactions. Our scheme leverages Shamir’s Secret Sharing principle to facilitate distributed management of the trapdoor and ascertain its security. We must also look at mechanisms to prevent collisions between registered and malicious users during authentication.

Moving forward, we aim to devise a more universally applicable trapdoor management scheme to further reinforce the security of trapdoors. Moreover, we plan to explore deeper methodologies for ensuring medical data’s historical integrity and authenticity.