A hybrid blockchain-based solution for secure sharing of electronic medical record data

Patient blockchain

The patient blockchain stores the signature signed by the patient, along with hashed data that includes encrypted personal information $C_{pk}\left(P{I}_i\right)$. This information encompasses sensitive patient data such as name, age, gender, and other privacy-related information. To ensure the security and privacy of the data, it is uploaded to InterPlanetary File System (IPFS) by the patient and then hashed by IPFS. Given the smaller size of personal data compared to medical data, CP-ABE is employed to encrypt personal data, allowing for a higher degree of privacy protection. Personal information and EHR are stored separately in distinct blockchains to enhance the security of EHR. This approach prevents adversaries from associating medical data with specific patients, thereby reducing the risk of data breaches and safeguarding patient privacy.

Patients and healthcare providers can access data from the patient blockchain and retrieve ciphertext from IPFS. This ciphertext can then be decrypted to reveal the actual personal information of the patient. In typical scenarios, healthcare providers require access to medical data from a healthcare provider blockchain that is connected to a patient’s personal information, which can then be used to make a diagnosis.

Healthcare provider blockchain

The healthcare provider blockchain primarily stores aggregate signatures $S_A$, which are composed of signatures generated by various institutions, along with dataset $D_i$, where $T_i=D_i||S_A$. The dataset is comprised of the medical data ciphertext $C_i=E_k\left(M_i\right)$, its hash value $H\left(C_i\right)$, and the symmetric key $k$ encrypted with the patient’s public key for encrypting medical data $E_{P{K}_u}\left(k\right)$. Specifically, $D_i$ can be expressed as $D_i=C_i\left|\left|H\left(C_i\right)\right|\right|E_{P{K}_u}\left(k\right)$. This approach ensures that the medical data and associated signatures are securely stored, while also maintaining the privacy and confidentiality of patient information.

Similarly to the patient blockchain, patients and healthcare providers can access data from the healthcare provider blockchain and retrieve ciphertext from IPFS. Given the critical nature of medical data during physician diagnostic and data access procedures, additional security measures are necessary to enhance the protection of sensitive medical data.

Social blockchain

The social blockchain serves as a crucial component in our scheme, facilitating connections to external blockchain networks. Transactions involving data sharing with other systems are uploaded to this blockchain. Each transaction includes the hashed ciphertext that has already been shared with others and the signature of the data’s owner. To enable better differentiation of which parts of a patient’s EHR are shared, a data processor is used to classify the medical records, dividing the data into finer-grained categories. When a patient transfers to another hospital, the social blockchain connects to the external blockchain network system, and the relevant patient data is transferred accordingly. The social blockchain does not require direct interaction with patients and healthcare providers. Our data classification scheme provides an effective solution for transferring different types of data, thereby reducing the workload for users.

Aggregate signature $S_{A_s}$

The process of obtaining the signature $S_{A_s}$ is illustrated in Fig. 4A, with the protocol flow shown in Fig. 4B. As an example of patient-generated data, the details of the signature process are as follows:

Our scheme needs a bilinear pairing e: ${\mathbb{G}}_0\times {\mathbb{G}}_1\to {\mathbb{G}}_{\mathrm{T}}$, the hash function H₀: $\mu \to {\mathbb{G}}_0$, and a second hash function H₁: ${\mathbb{G}}_1^n\to R^n$ where $R:=\left\{1,2,\dots ,2^{128}\right\}$.

a) KeyGen ( )

The system assigns the public key $P{K}_1$ and secret key $S{K}_1$ to medical staff for signing.

b) Prepare data $D_1$

The patient’s personal data, denoted as $M_1$, is self-generated by the patient, followed by encryption to derive the ciphertext $C_1=E_k\left(M_1\right)$. Subsequently, $C_1$ is subjected to a hashing process to yield the hashed data, denoted as $H\left(C_1\right)$. The culmination of this process results in the final prepared data $D_1=C_1||H\left(C_1\right)$.

c) Sign $\left(D_1,S{K}_1\right)$

This algorithm takes the prepared data $D_1$ and the signing key $S{K}_1$ as inputs. Eventually, it returns the signature $S_1$ as a result.

$$S_1\leftarrow H_0{\left(D_1\right)}^{S{K}_1}\in {\mathbb{G}}_0$$

d) Share data $D_1$ and sign

The patient shares the data $D_1$ with other healthcare providers, thus each provider has the same data $D_1$ and uses their signing key $S{K}_i$ to output different signatures $S_i$.

$$S_i\leftarrow H_0{\left(D_1\right)}^{S{K}_i}\in {\mathbb{G}}_0$$

e) Signature aggregate $\left(\left(P{K}_1,S_1\right),\left(P{K}_2,S_2\right),\dots ,\left(P{K}_n,S_n\right)\right)$

This algorithm takes all the individual signatures related to different users, then computes $t_1,t_2,\dots ,t_n$ and outputs the aggregation signature $S_{A_s}$.

$$\left(t_1,t_2,\dots ,t_n\right)\leftarrow H_1\left(P{K}_1,P{K}_2,\dots ,P{K}_n\right)\in R^n$$

$$S_{A_s}\leftarrow S_1^{t_1}\dots S_n^{t_n}\in {\mathbb{G}}_0$$

f) Public key aggregate

This process involves advanced preparation for verifying the signature. The algorithm incorporates all the relevant individual public keys associated with different healthcare providers, then computes $t_1,t_2,\dots ,t_n$ and outputs the aggregation of the public key $P{K}_A$.

$$\left(t_1,t_2,\dots ,t_n\right)\leftarrow H_1\left(P{K}_1,P{K}_2,\dots ,P{K}_n\right)\in R^n$$

$$P{K}_A\leftarrow P{K}_1^{t_1},P{K}_2^{t_2},\dots ,P{K}_n^{t_n}\in {\mathbb{G}}_1$$

g) Verify $\left(H\left(D_1\right),P{K}_A,S_{A_s}\right)$

This algorithm takes the hashed data $H\left(D_1\right)$, the aggregation of the public key $P{K}_A$, and the aggregation signature $S_A$ to verify if $e\left(g_1,S_A\right)=e\left(P{K}_A,H_0\left(H\left(D_1\right)\right)\right)$ the output “accepts”, or otherwise output “rejects”.

The verification process is proven as below:

$$\begin{array}{rl}e\left(g_1,S_{A_s}\right)& =e\left(g_1,S_1^{t_1}\dots S_n^{t_n}\right)=e\left(g_1,S_1^{t_1}\right)\cdot e\left(g_1,S_2^{t_2}\right)\cdot \dots \cdot e\left(g_1,S_n^{t_n}\right)\\ & =e\left(g_1^{t_1},S_1\right)\cdot e\left(g_1^{t_2},S_2\right)\cdot \dots \cdot e\left(g_1^{t_n},S_n\right)\\ & =e\left(g_1^{t_1},H_0{\left(D_i\right)}^{{\alpha }_1}\right)\cdot e\left(g_1^{t_2},H_0{\left(D_i\right)}^{{\alpha }_2}\right)\cdot \dots \cdot e\left(g_1^{t_n},H_0{\left(D_i\right)}^{{\alpha }_n}\right)\\ & =e\left({\left(g_1^{t_1}\right)}^{{\alpha }_1},H_0\left(D_i\right)\right)\cdot e\left({\left(g_1^{t_1}\right)}^{{\alpha }_2},H_0\left(D_i\right)\right)\cdot \dots \cdot e\left({\left(g_1^{t_1}\right)}^{{\alpha }_n},H_0\left(D_i\right)\right)\\ & =e\left({\left(g_1^{{\alpha }_1}\right)}^{t_1},H_0\left(D_i\right)\right)\cdot e\left({\left(g_1^{{\alpha }_2}\right)}^{t_1},H_0\left(D_i\right)\right)\cdot \dots \cdot e\left({\left(g_1^{{\alpha }_n}\right)}^{t_1},H_0\left(D_i\right)\right)\\ & =e\left(P{K}_1^{t_1},H_0\left(D_i\right)\right)\cdot e\left(P{K}_2^{t_2},H_0\left(D_i\right)\right)\cdot \dots \cdot e\left(P{K}_n^{t_n},H_0\left(D_i\right)\right)\\ & =e\left(P{K}_1^{t_1}\dots P{K}_n^{t_n},H_0\left(D_i\right)\right)\\ & =e\left(P{K}_A,H_0\left(D_i\right)\right)\end{array}$$

Aggregate signature $S_{A_f}$

The process of obtaining the signature $S_{A_f}$ is illustrated in Fig. 5A, and the protocol flow is shown in Fig. 5B. This process is generally similar to the one described above, with the signing data being the privacy data generated by User 1 at different times. At time $T_n$, all signatures of User 1 are $S_{1T_1},S_{1T_2},\dots ,S_{1T_n}$. The aggregate signature $S_{A_{f_1}{T}_n}$ is then computed as $S_{A_{f_1}{T}_n}\leftarrow {S_{1T_1}}^{t_1}\dots \dots {S_{1T_1}}^{t_n}$.

The property of aggregate signatures, which allows for the verification of individual signature existence, is utilized to create an invisible chain formed by the aggregate signatures. This enables the identification and categorization of all data uploaded by a particular user from the mixed data, achieving the fitting of a specific type of data. This not only organizes the system’s data more effectively but also enhances the efficiency and accuracy of data management.

Suppose User 1 updates data at time $T_n$ and generates the aggregate signature $S_{A_{f_1}{T}_n}$. This data and signature are then uploaded to the off-chain IPFS distributed storage system. Additionally, at times $T_{n-1},T_{n-2},\dots ,T_1$, the system stores aggregate signatures of a large amount of user data, denoted as $S_{A_{f_i}{T}_j}$. All these signature sets are referred to as $\mathcal{H}$. For $\mathrm{\forall }{S}_{A_{f_i}{T}_j}\in \mathcal{H}$, the system can search and verify all data generated by User 1 at times $T_j<T_n$ within the aggregate signatures. The existence of $S_{A_{f_1}{T}_j}$ can be confirmed through effective aggregation. The verification formula is $e\left(S_{A_{f_1}{T}_n},g_1\right)=e\left(H\left(D\right),P{K}_A\right)\cdot e{\left(S_{A_{f_1}{T}_{n-1}},g_1\right)}^{-1}$.

a) The aggregate signature $S_{A_{f_1}{T}_n}$ and the aggregate public key $S_{A_{f_1}{T}_n}$ are considered. Suppose $S_{A_{f_1}{T}_{n-1}}$ is a part of the aggregate signature $S_{A_{f_1}{T}_n}$.

$$\begin{array}{rl}e& \left(S_{A_{f_1}{T}_n},g_1\right)\\ & =e\left(S_{1T_1}\cdot S_{1T_2}\cdot \dots \dots \cdot S_{1T_n},g_1\right)\\ & =e\left(S_{A_{f_1}{T}_{n-1}}\cdot S_{1T_n},g_1\right)\end{array}$$b) Next, the following computation is performed:

$$\begin{array}{rl}e& \left(H\left(D\right),P{K}_A\right)\cdot e{\left(S_{A_{f_1}{T}_{n-1}},g_1\right)}^{-1}\\ & =e\left(H\left(D\right),P{K}_1^n\right)\cdot e{\left(S_{A_{f_1}{T}_{n-1}},g_1\right)}^{-1}\\ & =e\left(H\left(D\right),P{K}_1\cdot P{K}_1\cdot \dots \dots \cdot P{K}_1\right)\cdot e{\left(S_{A_{f_1}{T}_{n-1}},g_1\right)}^{-1}\\ & =e{\left(H\left(D\right),g_1\right)}^{SK\cdot n}\cdot e{\left(SK\cdot H\left(D\right),g_1\right)}^{-1}\\ & =e{\left(H\left(D\right),g_1\right)}^{SK\cdot n}\cdot e{\left(SK\cdot H\left(D\right),g_1\right)}^{-SK}\\ & =e{\left(H\left(D\right),g_1\right)}^{SK\cdot \left(n-1\right)}\end{array}$$

Here, $e{\left(S_{A_{f_1}{T}_{n-1}},g_1\right)}^{-1}$ is used to “cancel out” the contribution of $S_{A_{f_1}{T}_{n-1}}$ in the aggregate signature. If the equation holds, then it can be concluded that the signature $S_{A_{f_1}{T}_{n-1}}$ is indeed a part of the aggregate signature $S_{A_{f_1}{T}_n}$.

c) Finally, the expression $e\left(S_{A_{f_1}{T}_n},g_1\right)=e{\left(H\left(D\right),g_1\right)}^{SK\cdot \left(n-1\right)}$ is obtained, which is equal to the left-hand side of the equation, indicating that the signature $S_{A_{f_1}{T}_{n-1}}$ is a part of the aggregate signature $S_{A_{f_1}{T}_n}$.

Patient blockchain: personal information addition

When a patient is initially registered in the system, they are required to provide basic personal information. To ensure privacy, the CP-ABE encryption method is utilized to encrypt the patient’s private data. The encrypted data is uploaded into IPFS, where a hash value is generated and then transferred to the patient blockchain along with the signature $S_A$. The corresponding process flow is illustrated in Fig. 6.

a) Setup $\left(\lambda \right)\to \left(pk,mk\right)$

This procedure takes the security parameter $\lambda$ as input and produces the public parameter $p$ and master key $mk$ for the proposed CP-ABE mechanism.

b) KeyGen $\left(mk,A\right)\to sk$

This procedure takes the master key $mk$ and the attribute set $A$ as input and generates the user attribute secret key $sk$.

c) Encrypt $\left(p,T,M\right)\to C$

This procedure takes the public parameter $p$, accesses the structure $T$ and the patient’s personal information $M$, and encrypts the plaintext $M$ into the ciphertext $C$.

d) Sign $\left(C\right)\to S_A$

In this process, the user generates shareable data $D_i$ using the signature algorithm described above and signs $D_i$ to obtain the corresponding signed data $S_A$.

e) Data upload to the blockchain

The signature $S_A$ and the $hash$ value returned by IPFS are incorporated into a data transaction $T_i=D_i\left|\left|S_A\right|\right|hash$ and subsequently uploaded to the patient blockchain.

f) Decrypt $\left(p,C,sk\right)\to M$

This procedure takes the public parameter $p$, ciphertext $C$, and secret key $sk$. as input and generates the plaintext $M$.

Healthcare provider blockchain: health record addition

Healthcare data is decentralized among a variety of healthcare providers, and encompasses entities such as hospitals, insurers, pharmacies, and governmental regulatory bodies. Different from the ciphertext present in the patient blockchain, this medical data is considerably more substantial in volume. Initially, the medical data is encrypted using symmetric encryption. Subsequently, the symmetric encryption key itself is encrypted via CP-ABE. The final encrypted data can be procured by concatenating these two ciphertexts. The process is illustrated in Fig. 7.

a) Key generation

When a user affiliated with a healthcare provider partakes in the system, a symmetric encryption key $k$ is allocated by the system. The key assignment for CP-ABE is the same as that in the patient blockchain and is not described in detail here.

b) Encrypt $\left(k,p,T,M\right)\to C$

Within this process, the healthcare provider generates the medical data $M$, which is encrypted using the key $k$, resulting in $C_s=En{c}_k\left(M\right)$. Following this, attribute encryption is performed on the key $k$ $Encrypt\left(P,T,k\right)\to C_a$. $(C_s||C_a)$ which is the final ciphertext data $C$.

c) Sign $\left(C\right)\to S_A$

In this process, the user generates shareable data $D_i$ using the signature algorithm described above and signs $D_i$ to obtain the corresponding signed data $S_A$.

d) Data upload to the blockchain

The signature $S_A$ and the $hash$ value returned by IPFS are incorporated into a data transaction $T_i=D_i\left|\left|S_A\right|\right|hash$ and subsequently uploaded to the healthcare provider blockchain.

e) Decrypt $\left(p,C,sk,k\right)\to M$

This procedure takes the public parameter $p$, the ciphertext $C_a$, and the secret key $sk$. as input and generates the symmetric encryption key $k$. The key $k$ is subsequently employed to decrypt the ciphertext $C_s$, facilitating the retrieval of the original data $M$.

Social blockchain: data sharing externally

The social blockchain establishes a connection with the external blockchain system to facilitate the sharing of medical data among different healthcare institutions. To ensure proper data sharing and protection, a data processor categorizes the medical data into five levels of sensitivity. This approach aligns closely with the principles of ISO/IEC 27001 Information Security Management (ISO/IEC, 2022), which emphasizes the classification of information based on its importance, sensitivity, and associated risks. By implementing this structure, the classification ensures that appropriate protection measures are applied to safeguard the data’s confidentiality, integrity, and availability.

The five-level classification reflects a progressive sensitivity model, gradually increasing the restrictions and controls as the data moves from being fully public to highly sensitive. This clear and logical progression aligns with ISO/IEC 27001’s principle of risk-based classification and access control. Each level is designed to mitigate risks associated with unauthorized access or misuse, ensuring that data is accessed only by authorized entities and under defined conditions.

Here is a detailed explanation of the five levels of sensitivity:

Level 1: Fully public data. This category includes information such as the hospital’s name, address, and telephone number, which can be openly shared with the public on the Internet without any restrictions or privacy concerns.

Level 2: Data available for widespread access. This category is comprised of data that can be accessed on a large scale, typically after obtaining approval through a formal application process. These datasets are often made available for research and analysis purposes, facilitating scientific investigations and advancements in various domains.

Level 3: Data available for restricted access. This category includes data that can be accessed on a medium scale, typically limited to usage within the authorized project team operating under the purview of a specific institution. Access to this data is granted only to team members involved in the project, ensuring compliance with institutional policies and safeguarding the privacy and security of the data.

Level 4: Data available for limited access. This category pertains to data that can be accessed on a smaller scale, specifically restricted to individuals directly involved in the consultation process. Access to this data is confined to healthcare professionals and relevant stakeholders who require access to providing healthcare services and facilitating the consultation. Strict confidentiality measures are implemented to protect the privacy and sensitivity of the data.

Level 5: Data available for highly restricted access. This category encompasses data that can only be accessed on a very limited scale and under stringent restrictions. For instance, specific disease-related information, such as on Acquired Immune Deficiency Syndrome (AIDS) or sexually transmitted diseases (STDs), is strictly limited to access by primary care providers who require the data for clinical purposes. Comprehensive controls and protocols are in place to ensure the utmost confidentiality and privacy protection of this sensitive information, adhering to regulatory guidelines and ethical considerations.

The data-sharing process is shown in Fig. 8. When an external user requires access to medical data, the system employs an automated process to determine the appropriate levels of data accessibility based on the user’s attributes. Upon identification, the user can retrieve the corresponding hash from the social blockchain, which serves as a reference for obtaining the authorized data from the IPFS storage system. This dynamic approach ensures that users can securely retrieve and access the specific data they are permitted to view, maintaining the privacy and confidentiality of the overall healthcare ecosystem.

Two algorithms have been conceptualized, specifically tailored for the tasks of automatic data hierarchy creation and data dissemination. Algorithm 1 illustrates the mechanism of data categorization. This mechanism involves a detailed stratification of data according to sensitivity levels, thereby differentiating information that is permissible for open distribution from datasets that demand heightened sensitivity.

Algorithm 2 elaborates the process of medical information distribution leveraging social blockchain technology. This process necessitates an evaluation of user permissions, only those users satisfying the specified criteria are granted data access. Furthermore, the data distribution procedure is inscribed in the framework of the social blockchain infrastructure, thereby establishing unequivocal transparency and traceability.

Provable security

Definition: In a prime-order cyclic group $\mathbb{G}$, given a generator $g$ and elements $g^a,g^b$, where $a,b\in Z_q^{\ast }$, the task of computing $g^{ab}$ considered computationally infeasible.

Our algorithm utilizes bilinear pairings and aggregate signatures to enhance data security. By analyzing the difficulty of forging signatures under the CDH assumption, we demonstrate the security of the scheme.

• a.

  Threat model

An attacker $\mathcal{A}$ attempts to forge a valid aggregate signature $S_A$ without knowledge of the private key $S{K}_i$, such that the verifier accepts the equation:

$$e\left(g_1,S_A\right)=e\left(P{K}_A,H_0\left(H\left(D\right)\right)\right)$$where $g_1$ is the generator of group ${\mathbb{G}}_1$, $S_A$ is the aggregate signature, $P{K}_A$ is the aggregate public key, $H_0$ is the hash function mapping data to group ${\mathbb{G}}_0$, and $H\left(D\right)$ is the hash value of the data $D$.

• b.

  Difficulty of signature forgery based on the CDH assumption

Lemma 1: Under the CDH assumption, the probability of an attacker forging a valid aggregate signature $S_A$ without knowledge of the private key is negligible.

Suppose there exists an attacker $\mathcal{A}$ that can forge a valid aggregate signature $S_A$ with non-negligible probability ${ϵ}_{forge}$. We construct a simulator $\mathcal{B}$ that uses $\mathcal{A}$ to solve the CDH problem.

Simulator $\mathcal{B}$:

• Input: A CDH problem instance $\left(g,g^a,g^b\right)$, The goal is to compute $g^{ab}$.

• Setup:

Set $g_1=g$, public keys $P{K}_1=g^a$, and $P{K}_2=g^b$. The simulator does not know the corresponding private keys $S{K}_1=a$ and $S{K}_2=b$.

• Challenge:

Choose a random message $D$, compute its hash value $H\left(D\right)$, and compute $H_0\left(H\left(D\right)\right)$.

• Interaction with the Attacker:

Provide $\mathcal{A}$ with $P{K}_1,P{K}_2$, and $H_0\left(H\left(D\right)\right)$, and request $\mathcal{A}$ to output a forged aggregate signature $S_A$.

• Attacker’s Output:

If $\mathcal{A}$ outputs a signature $S_A$ such that:

$$e\left(g_1,S_A\right)=e\left(P{K}_A,H_0\left(H\left(D\right)\right)\right)$$where $P{K}_A=P{K_1}^{t_1}P{K_2}^{t_2}$ and $t_1,t_2$ are known coefficients.

• Calculation:

Based on the verification equation and the properties of bilinear pairings, we compute:

$e\left(g_1,S_A\right)=e\left(P{K}_1^{t_1}P{K}_2^{t_2},H_0\left(H\left(D\right)\right)\right)=e{\left(P{K}_1,H_0\left(H\left(D\right)\right)\right)}^{t_1}\cdot e{\left(P{K}_2,H_0\left(H\left(D\right)\right)\right)}^{t_2}$

Substituting $P{K}_1=g^a,P{K}_2=g^b$, we get:

$$e\left(g_1,S_A\right)=e{\left(g,H_0\left(H\left(D\right)\right)\right)}^{a{t}_1+b{t}_2}$$

• Extracting $g^{ab}$:

Simulator $\mathcal{B}$ cannot directly extract $g^{ab}$ from $a{t}_1+b{t}_2$. However, if $\mathcal{A}$ is able to forge a signature with non-negligible probability, it implies that $\mathcal{B}$ can solve the CDH problem with the same probability, which contradicts the assumption.

Since, under the CDH assumption, the probability of solving the above problem is negligible, the probability of the attacker successfully forging a signature is also negligible.

$${ϵ}_{forge}\le {ϵ}_{CDH}$$where ${ϵ}_{CDH}$ is the negligible probability of solving the CDH problem.

Blockchain security

Attacks on blockchain systems are typically centered around the concept of computational power. Specifically, in a 51% attack, when an attacker controls more than 50% of the total computational power in the blockchain network, they can potentially compromise the system by rewriting the blockchain, double-spending coins, or invalidating transactions. This article analyzes the security of blockchain systems based on the gambling probability attack model.

In this article, we assume that a malicious attack node (MAN) successfully joins the proposed blockchain-based EMR system and launches an attack on any of the chains, causing a consensus node on that chain to fork. The health node (HN), which is responsible for maintaining the integrity of the data and ensuring the security of the blockchain, is also involved in the consensus process. According to the Bitcoin whitepaper, blockchain nodes always follow the longest chain as the correct one and extend it. Therefore, if the MAN can control more than 50% of the computational power, it can generate a longer chain to replace the honest nodes’ chain, thereby succeeding in the attack. This attack process can be viewed as a binomial random walk. The specific discussion of this process is as follows:

$$\{\begin{array}{c}1,k>z\\ {\left({\displaystyle \frac{q}{p}}\right)}^{z-k},k\le z\end{array}$$where $k$ represents the number of blocks successfully mined by MAN, $z$ denotes the number of blocks mined by the honest nodes before MAN attempts to replace the chain, $q$ s the probability of MAN successfully mining a block (representing the attacker’s computing power proportion), and $p$ is the probability of the honest nodes mining a block (representing the honest nodes’ computing power proportion, where $p+q=1$).

As $k$ can be any non-negative integer, the probability distribution of $k$ follows a Poisson distribution, which is calculated as follows:

$$\sum _{k=0}^{\mathrm{\infty }}{\displaystyle \frac{{\lambda }^k{e}^{-\lambda }}{k!}}$$where $\lambda$ represents the expected number of events (blocks mined) occurring in the given time interval. It is the mean of the distribution.

Therefore, the formula for calculating the probability of MAN successfully attacking the chain is as follows:

$$P=\sum _{k=0}^{\mathrm{\infty }}{\displaystyle \frac{{\lambda }^k{e}^{-\lambda }}{k!}\cdot \{\begin{array}{c}1,k>z\\ {\left({\displaystyle \frac{q}{p}}\right)}^{z-k},k\le z\end{array}}$$

The formula after simplification is:

MAN uses a “gambling attack” to attack the EMR system in order to obtain all EMR data. The probability of a successful attack depends mainly on the probability of MAN generating the next block and the number of “chains” used in the blockchain system. This solution combines smart healthcare with a three-chain structure, while the solutions presented in Shuaib et al. (2022) and Guo et al. (2022) are single-chain structures, and the solutions presented in Liu et al. (2020, 2022) are both double-chain structures.

Based on the above analysis, the specific experimental plan of this article is to have MAN generate the next block with probabilities of 0.10, 0.15, 0.20, 0.25, 0.30, 0.35, 0.40, and 0.45 respectively. These probabilities were selected to model a range of realistic scenarios, from low-intensity attacks where MAN has minimal computing power $\mathrm{q}=$ 10 to high-intensity attacks nearing the critical threshold $\mathrm{q}=$ 0.45. This range reflects the typical distribution of computational power in blockchain networks, where attackers rarely possess more than half of the network’s total power. The incremental increase of 0.05 between values ensures sufficient granularity to capture the system’s response under varying levels of attack intensity, enabling a comprehensive evaluation of the proposed system’s resilience.

The selection of probabilities from 0.10 to 0.45 was based on the following considerations:

1. Representativeness: These probabilities cover a range from low to high attack success rates, fully reflecting the system security under different levels of attack intensity.

2. Practical application: In actual blockchain applications, attackers usually find it challenging to obtain extremely high computing power. Therefore, selecting probabilities that increment from low values is more in line with real-world scenarios.

3. Scientific basis: The commonly used blockchain attack models in the literature also adopt similar probability ranges, ensuring the comparability and scientific validity of our experiments.

The minimum secure block number that HN needs to generate is then calculated and counted for the EMR system of the blockchain to ensure the attack success probability is below 0.1, 0.01, and 0.001 respectively.

In the experimental design, several potential confounding variables were controlled to ensure the reliability of the results:

1. Node type and number: The type and number of nodes used in all experiments were kept consistent.

2. System load: The system load was controlled throughout the experiments to maintain uniform starting conditions.

3. Environmental settings: All experiments were conducted in the same hardware and software environment to avoid discrepancies due to equipment differences.

4. Repetition of experiments: Each set of experiments was repeated multiple times, and the average value was taken to reduce random errors.

To implement the theoretical framework described earlier, we used MATLAB to calculate the attack success probabilities and the corresponding minimum number of secure blocks required. Specifically, we applied the Poisson distribution and the formulas outlined earlier to model the attack scenarios. Using the thresholds for attack success probabilities of 0.1, 0.01, and 0.001, the MATLAB code calculates the minimum number of secure blocks that HN need to generate to ensure the attack success probability remains below each of these thresholds.

The experimental tools and simulation environment used in this article were a personal computer with an Intel(R) Core(TM) i5-1035G1 CPU @ 1.00 GHz 1.19 GHz processor, 8.00 GB memory, and a 64-bit Windows operating system. The experimental results are shown in Figs. 9–11.

a) Probability of MAN attack below 0.1

Experimental results presented in Fig. 9 demonstrate that to maintain the probability (P) of a successful MAN attack on the blockchain system below 0.1; this scheme’s increase in the minimum number of secure blocks required is smaller than that of other comparison schemes once the MAN’s block generation probability reaches 0.2. Furthermore, elevating the MAN’s block generation probability to 0.45 leads to a substantial enhancement in security. Specifically, the required minimum number of secure blocks is lowered by 73.5% in comparison to the single-chain scheme, and by 44.4% relative to the double-chain scheme.

b) Probability of MAN attack below 0.01

Experimental results depicted in Fig. 10 indicate that, to maintain the probability (P) of a successful MAN attack on the blockchain system below 0.01, increasing the MAN’s block generation probability to 0.45 significantly enhances security. Specifically, this adjustment reduces the minimum number of secure blocks required by 71.3% compared to the single-chain scheme and by 38.2% when compared to the double-chain scheme.

c) Probability of MAN attack below 0.001

Experimental findings presented in Fig. 11 reveal that, to keep the probability (P) of a MAN successfully attacking the blockchain system under 0.001, the increase in the minimum number of secure blocks required at the genesis block by this scheme is less than that required by comparison schemes. Further, when the probability of MAN generating the next block is raised to 0.45, there is a significant improvement in security. Specifically, the minimum number of secure blocks needed by this scheme is reduced by 70.0% compared to the single-chain scheme, and by 36.2% in comparison to the double-chain scheme.

The experimental results clearly demonstrate that our approach significantly enhances the security of blockchain systems. By reducing the minimum number of secure blocks required to keep the attack success probability below the thresholds of 0.1, 0.01, and 0.001, our method reduces the required number of blocks by approximately three times compared to existing schemes, thereby significantly improving the system’s resilience against 51% attacks.

Performance evaluation

To further valaaidate the scheme, the Faker library was used to generate random medical data, and smart contracts were deployed on a local Ethereum network using Solidity. The evaluation focused on transaction latency and throughput, as these metrics are widely recognized as critical indicators of a blockchain system’s responsiveness, operational efficiency, and scalability. Furthermore, the emphasis on these metrics aligns with the standard practices in blockchain performance research, where transaction-related benchmarks are considered foundational for assessing system performance.

A sample size of 1,000 transactions was selected to evaluate the performance of the system. This choice was based on the following considerations:

a) Representativeness: A sample size of 1,000 transactions is large enough to capture the variability in transaction latency and throughput under typical operating conditions, providing a comprehensive assessment of the system’s performance.

b) Practical application: In real-world blockchain applications, it is common to handle a large number of transactions. Testing with 1,000 transactions ensures that the evaluation reflects realistic usage scenarios and can provide insights into how the system performs under substantial load.

c) Scientific basis: Prior studies and benchmarks in blockchain performance testing often utilize similar or smaller sample sizes to evaluate system performance metrics, ensuring the comparability and scientific validity of our experiments.

By varying transaction send rates, the average latency per transaction was tested on the Patient blockchain, Healthcare provider blockchain, and Social blockchain. As shown in Fig. 12, latency increases with the number of transactions, remaining under 6 s at 50 transactions per second (tps). The Social blockchain exhibits slightly lower latency compared to the Patient and Healthcare provider blockchains, attributed to the pre-classification of data, allowing only low-sensitivity data to be shared.

Furthermore, the maximum and minimum throughput of the Patient blockchain, Healthcare provider blockchain, Social blockchain, and the entire system were evaluated at transaction send rates ranging from 10 to 40 tps. As shown in Fig. 13, the throughput across different transaction send rates concentrates around 35 tps.

In the performance testing, several potential confounding variables were controlled to ensure the validity of the results:

a) Data generation: The Faker library was used to generate random but consistent medical data across different experiments.

b) Smart contract deployment: All smart contracts were deployed using the same configuration and version of Solidity on the same local Ethereum network to maintain consistency.

c) System environment: The tests were conducted on the same hardware and software environment used in the block security comparison tests, ensuring uniformity.

d) Repetition and averaging: Each performance test was repeated multiple times, and the results were averaged to minimize random variations.

Our findings indicate that while the use of blockchain introduces some overhead, it does not significantly degrade the overall system performance. Specifically, the latency and throughput metrics remain within acceptable ranges, demonstrating that the integration of blockchain is feasible without compromising efficiency. More importantly, the blockchain-based system significantly enhances data security and integrity, offering robust protection against tampering and unauthorized access.

These results underscore the practicality and feasibility of using blockchain in our system. The enhanced security and data integrity provided by blockchain outweigh the modest increase in complexity and resource consumption, making it a valuable addition to our EMR system.

Storage optimization analysis

In addition to the performance metrics, storage optimization is another key benefit of the proposed system. The use of aggregated signatures has led to significant storage savings. Both types of signatures essentially combine multiple individual signatures into a single one, compressing storage requirements from linear growth to a constant size.

Aggregated signatures compress multiple signatures into a single one using bilinear pairings and hash functions. Without aggregation, the system would require storing individual signatures, consuming significantly more storage space. With aggregated signatures, only one signature is needed, reducing the storage requirement substantially.

Assuming each signature is 25 bytes, the storage requirements and savings for different numbers of signatures are shown in Table 3.

As the number of signatures increases, the storage savings rapidly approach 100%, making this approach particularly suitable for scenarios requiring the storage of a large number of signatures.

Moreover, aggregated signatures not only optimize storage but also significantly improve the efficiency of signature verification. In traditional methods, each signature requires individual verification, with a complexity of $O\left(\mathrm{n}\right)$ operations, where nnn is the number of signatures. In our approach, aggregated signatures require a single verification, reducing the complexity to $\mathrm{O}\left(1\right)$, thus making the system more efficient.

Performance and storage efficiency comparison

Based on the related work referenced in Cerchione et al. (2023), Chelladurai & Pandian (2022), Kim et al. (2020), Fatokun, Nag & Sharma (2021), Shuaib et al. (2022), Liu et al. (2020), Guo et al. (2022), Liu et al. (2022), Yuan et al. (2022), Okegbile, Cai & Alfa (2022), Zaabar et al. (2021), Hegde & Maddikunta (2023), the proposed scheme is compared with those of Kim et al. (2020), Liu et al. (2020), and Egala et al. (2021). The primary focus of the comparison is to analyze the total computation time, complexity, and storage space required during the authentication, encryption, and signing processes before uploading medical data, as well as the minimum number of blocks required to resist attacks. The results of this comparison are summarized in Table 4.

Assume that $T_{ecenc}$ denotes the encryption time in the elliptic curve cryptography system, $T_h$ represents the computation time of the hash function, $T_{ReKeyGen}$ refers to the re-encryption key generation time, $T_{exp}$ is the time for an exponentiation operation, $T_{bp}$ is the time for a bilinear pairing operation, $T_S$ is the time for generating a signature, and $n$ represents the number of attributes involved in the encryption process.

For storage space, let $M_{meta}$ epresent the storage size of metadata, $M_{enc}$ represent the storage size of the encrypted data, and $M_S$ represent the storage size of the aggregated signature.

Moreover, let $N$ represent the minimum number of blocks required by the HN to prevent an attacker from successfully inferring the data’s source or tampering with it, based on attack success probabilities.

Table 4 presents a performance comparison between the proposed scheme and the referenced schemes in terms of data generation time, computational complexity, storage space, and attack resistance (measured by the minimum number of secure blocks). The experimental results indicate that the proposed scheme effectively maintains data generation time within a reasonable range by avoiding re-encryption key generation time $T_{ReKeyGen}$, encryption time in the elliptic curve cryptography system $T_{ecenc}$, and reducing the time for bilinear pairing operations $T_{bp}$. Additionally, the time complexity of the scheme remains at $O\left(n\right)$ with no significant increase, ensuring the system’s efficiency. By utilizing aggregated signatures $M_s$, the scheme reduces the on-chain data storage burden, thereby optimizing storage efficiency. Moreover, while maintaining a low probability of attack success, the proposed scheme reduces the minimum number of secure blocks required by approximately 2~3 times compared to the referenced schemes, enhancing attack resistance and significantly improving the overall security of the system.