Provably secure and lightweight blockchain based cross hospital authentication scheme for IoMT-based healthcare

Abstract

Portable devices and sensors-based Internet of Medical Things (IoMT) healthcare can remotely detect patients’ physiological data and provide first-class healthcare services. However, the high privacy and sensitivity of medical data make IoMT healthcare systems vulnerable to various attacks. While numerous authentication protocols have been introduced in recent years to guarantee authorized access, these schemes continue to face challenges such as privacy disclosure, untraceability of malicious behavior, insufficient cross-hospital access, and concerns related to single points of failure and trust. To address these issues, we propose a Double Anonymity Strategy to hide identities between doctors and the patients while allowing the authorized party to track their malicious behavior, enhance users’ privacy and track malicious users. Our approach leverages the advantages of blockchain, such as decentralization, and replaces trusted third parties with smart contracts for efficient and automatic identity authentication. Additionally, we introduce a cross-hospital authentication scheme that incorporates three-factor secrecy, ensuring that even if any two of the three factors (device, biometric information and password) are compromised, the security of the proposed scheme will not be affected. The security of our scheme is formally proven under the random oracle model, which formally measures that the probability of an adversary breaking the scheme is negligible. We also provide informal security analysis showing that our scheme prevents privacy breaches, achieves decentralization, and addresses existing various attacks. Furthermore, through simulation of the proposed scheme and comparison with related works, we demonstrate that our scheme achieves 23% to 87% reduction in computational cost while maintaining higher security properties.

Introduction

With the aging of the global population and the continuous increase of chronic patients, changing traditional healthcare methods has become a consensus. Thanks to the rapid development and application of emerging technologies, such as wearable devices, Internet of Things, and mobile Internet, IoMT-based healthcare dynamically connects devices and medical-related participants, intelligently builds a convenient, efficient, and personalized medical system. Compared with the traditional medical model, IoMT-based healthcare system provides more professional medical services for patients and improves doctors’ diagnoses, which represents the future development direction. However, although mobile communication is convenient, it also suffers from several security risks, which not only reveal doctors’ and patients’ privacy but also pose a threat to patients’ health and system security. To resist them, research works have been continuously conducted to improve the authentication protocols for IoMT-based healthcare.

Many password-based authentication schemes for medical scenarios continue to emerge, which do not require additional hardware devices. However, unreasonable verification strategies or password storage methods may lead to serious password guessing attacks and pre-computation attacks¹. To enhance security, biometric key was introduced as an authentication factor². In addition, several cryptographic primitives, such as Chebyshev chaotic map (The Chebyshev chaotic map is a mathematical function derived from Chebyshev polynomials, which exhibit chaotic behavior under certain conditions), RSA (Rivest-Shamir-Adleman is an asymmetric cryptographic algorithm used for secure data transmission. It relies on the mathematical difficulty of factoring large composite numbers), Elliptic Curve Cryptography (ECC, which is an asymmetric cryptographic technique based on the algebraic structure of elliptic curves over finite fields. ECC provides the same level of security as traditional systems like RSA but with much smaller key sizes, making it more efficient in terms of computational power and memory usage), and bilinear pairing (Bilinear pairing is a mathematical operation on two groups that maps them into a third group, preserving certain linear properties) are used in authentication protocols to ensure perfect forward secrecy and session key secrecy. Among them, bilinear pairing is seldomly adopted due to high computational cost. Besides, the above authentication schemes must rely on a Trusted Third Party (TTP) to complete authentication and key agreement, while the communication is limited to a cluster centered on the TTP. Furthermore, privacy protection and tracking malicious behavior seem to mutually exclusive to each other and hard to be addressed.

Blockchain serves as a decentralized and tamper-proof distributed shared ledger and database with traceability. With the above properties, blockchain balances the information asymmetry in some application scenarios, and realizes the trust and concerted action of multiple participants. As a technology closely combined with blockchain, smart contracts are computer programs that support automagical execution. The rules of smart contract execution are transparent and cannot be maliciously tampered. Therefore, it can replace TTP as an honest transponder. Recently, blockchain and smart contracts have been widely valued and applied to medical authentication protocols to solve the above problems.

Related works

In 2016, Mettler³ proposed the idea of using blockchain instead of TTP in medical field to eliminate the limitation of centralized storage. However, he did not design a specific and realizable scheme. Next year, Sullivan and Burger⁴ demonstrated the idea of widely applying blockchain to citizenship authentication from the aspects of law, policy, and technology. Srivastava et al.⁵ designed a data sharing scheme based on blockchain for patient IoT devices. Wearable devices are used to monitor patients, while the events are recorded by smart contracts on the public blockchain to support traceability. However, the proposed idea lacks of specific protocol and cannot meet the instantiation requirements. Dwivedi et al.⁶ proposed a decentralized privacy-preserving blockchain for health IoT, which uses ring signature to ensure users’ anonymity and authenticity, but excessive expenses remain the major obstacle to practicality. In 2020, Yazdinejad et al.⁷ designed an efficient authentication method based on blockchain for distributed hospital networks. But we found that the scheme lacks of necessary security in the sense that it cannot prevent impersonation attacks. In addition, the scheme based on public blockchain cannot guarantee privacy protection and anonymity in the authentication process. Xiang et al.⁸ designed a user authentication protocol based on blockchain for E-healthcare. They treat the blockchain as a trusted distributed ledger without considering its application in scaling the communication cluster. Deebak et al.⁹ proposed an authentication protocol for cloud-assisted healthcare systems. Jia et al.¹⁰ presented an overarching framework for a blockchain-integrated IoMT system within the fog computing architecture, encompassing diverse entities. The system incorporates an ECC-based authentication scheme focused on preserving user privacy in communications between end users and fog nodes. Saha et al.¹¹ proposed an authentication and access control for healthcare based on blockchain. Private blockchain stores patients’ encrypted information. However, the key is shared by trusted hospital nodes, implying that it cannot protect the patients’ privacy and cannot resist known key attack. Addressing the challenge of cross-domain authentication within the PKI system, Chen et al.¹² introduced an innovative solution that separates the storage and control layers. They employ a multi-layered Merkle hash tree structure to handle extensive identity data efficiently and devise a streamlined correctness validation protocol to enhance response times. The incorporation of a zero-knowledge proof algorithm, coupled with constraints on data types within the distributed ledger, ensures the protection of users’ privacy during cross-domain authentication. Javed et al.¹³ proposed a blockchain based identity management system, which supports service providers and patients to authenticate and identify transparently and safely. Blockchain is used to build indexes and provide distributed identity management services. However, the authentication process still needs the participation of a TTP and the registry. Nguyen et al.¹⁴ designed a blockchain and Mobile-Edge Computing based framework for IoMT network, which realizes data sharing and data offloading in the distributed hospital network. Furthermore, the authentication strategy based on smart contracts is combined with Mobile Edge Computing (MEC) to realize access control of users without central authorization. Egala et al.¹⁵ designed a blockchain-based framework for IoMT, which realizes decentralized Electrical Health Records (EHR) and automated services based on smart contracts. To raise security, device authentication and patient anonymity rely on distributed selective ring-based access control strategy.

In 2023, Tomar et al.¹⁶ proposed a protocol named Blockchain-based IoMT Authenticated Key Exchange (BIoMTAKE) key exchange to create a distributed environment using Hyperledger Fabric for private/consortium blockchains. This protocol eliminates the necessity for a singular trusted authority and ensures secure data access from IoMT devices. Prior to data sharing or access within the distributed healthcare system, the BIoMTAKE scheme establishes a secured shared session for authenticated devices to prevent unauthorized entry. Wazid and Gope¹⁷ introduced a novel blockchain-powered access control and key management protocol, named "BACKM-EHA," for IoMT-based e-healthcare systems. Through rigorous security analyses conducted in accordance with the Real-Or-Random model, the robustness of BACKM-EHA against various potential attacks is demonstrated. Kumar et al. introduce the RAPCHI protocol¹⁸, which has important features such as establishing authentication and key agreement between patients, cloud servers, and doctors, forming session keys without storing data in the cloud database, resisting various security threats, and meeting multiple security requirements. Chen et al.¹⁹ propose a new provably secure remote patient monitoring healthcare system protocol to address data security issues in IoMT systems. The protocol incorporates user biometric information and is proven secure using the random oracle model. Compared to other similar works, it offers more protection and has advantages in execution and communication costs.

In 2024, Ali et al.²⁰ mainly discuss the integration of 5G edge computing in IoMT. They highlight that while it brings the prospect of decentralized healthcare services, it also raises significant security issues, particularly concerning data integrity and access control. The paper proposes an innovative encryption solution called Online/Offline Remote Signcryption (O2RSC), which effectively addresses these limitations by providing integrity and access control services while reducing computational operations in the online mode. Zhang et al.²¹ point out that recent certificateless signcryption (CLSC) schemes in IoMT are vulnerable to attacks. Based on elliptic curve cryptography and specific security assumptions, including entities in the system model such as sensor devices, key generation centers, cloud servers, and doctors, as well as the corresponding security model and security objectives, they propose a pairing-free CLSC scheme for secure data transmission. This scheme features public verifiability, low computational and communication overhead, and can resist both Type I and Type II attacks. Mahmood et al.²² explore a cost-effective authentication solution (CAS) for 6G-enabled Artificial Intelligence of Medical Things (AIoMT) healthcare applications. In 6G-enabled AIoMT healthcare applications, the security and seamlessness of information exchange are major challenges. The authors design the CAS protocol using simple cryptographic primitives to reduce development complexity, capable of defending against network and physical threats. Performance comparisons show that it has advantages in enhancing security and cost-effectiveness. Singh and Dash²³ point out that the Internet of Medical Things (IoMT) faces numerous challenges related to data processing, storage, management, and security. For example, third-party authentication can present single points of failure and data loss risks, while centralized architectures are vulnerable to attacks. Although smart contract authentication eliminates the need for third parties, it is susceptible to Sybil attacks and 51% attacks. Additionally, issues related to physical layer security and scalability remain unresolved. The authors employ PUF, fuzzy extractors, and smart contract-enabled Inter Planetary File System (IPFS) clusters to achieve two-factor authentication for users and devices, providing security at both the physical and network layers. This ensures data confidentiality, integrity, and anonymity. They conduct both formal and informal security analyses and performance evaluations. Table 1 provides a summary of the most relevant technologies for IoMT authentication protocols and their advantages and disadvantages. Xie et al.²⁴ note that IoMT data is vulnerable to cyberattacks as existing multi-server authentication protocols lack continuous monitoring. They propose multi-server authentication scheme with integrated monitoring, which combines three-factor-based static authentication (TFSA) and deep learning-based continuous authentication (DLCA). TFSA ensures privacy and security, and DLCA validates users via behavior analysis, with both components demonstrating strong security and feasibility. Qu et al.²⁵ note that Electrocardiogram (ECG) leakage is common in the context of arrhythmia detection, and classical blockchain fails to safeguard ECG data in the quantum era. They propose QADS (Quantum Arrhythmia Detection System), a smart healthcare system for arrhythmia. It uses a quantum blockchain for secure data handling and a quantum neural network. Rehman et al.²⁶ note that the digital transformation of the healthcare industry makes patient data accessible, and blockchain applications in healthcare have drawbacks. They propose an IoMT-based hybrid blockchain architecture. This architecture combines Ethereum and Hyperledger Fabric blockchains with SQLite, introduces access control, and uses machine learning algorithms, and its performance is validated by the M/M/1 queuing model.

Table 1.

Summary of related schemes.

Schemes	Years	Techniques	Advantages	Limitations (Not Achieve)
7	2020	(No implementation details provided)	, , , , , , , , ,	, , , , , , , , ,
8	2020	, ,	, , , , ,	, , , , , , , , , , , , , ,
10	2022	, , ,	, , , , , , , , , , , , ,	, , ,
12	2020	, ,	, , , , , , , , , ,	, , , , , ,
14	2021	, ,	, , , , , , ,	, , , , , , , , , , ,
18	2022	,	, , , , , , , , ,	, , , , , , , , ,
19	2023	,	, , , , , , , , , , ,	, , , , , ,
22	2024	,	, , , , , , , , , , ,	, , , , ,
23	2024	, , ,	, , , , , , , , , , , ,	, , , ,

Techniques: . Chaotic maps; . Modular exponentiation; . Symmetric encryption; . Fuzzy extractor; . PUF; . ECC; . Blockchain; . Bilinear map.

Advantages: Achieve Security Properties: . Perfect forward secrecy; . Anonymity and Unlinkability; . Lightweight; . Mutual authentication; . Session key secrecy; . N-factor security; . Decentralization; . Scalability; . Cross-cluster. and Resist Attacks: . Privileged-insider attack; . Off-line password guessing attack; . Impersonation attack; . Replay attack; . Man-in-middle attack; . Smart card (Device) loss attack; . Node captured attack; . Stolen-verifier attack; . Desynchronization attack; . Known session key attack.

Limitations: cannot achieve above security properties and may suffer from above attacks.

We noticed that in the above research on applying blockchain to healthcare, the mainstream method is to treat blockchain as the carrier of records to achieve decentralization, traceability, and prevent records from being tampered with. However, they suffer from some defects, such as incomplete decentralization, privacy disclosure, and restricted communication range. To overcome these issues, how to apply blockchain and smart contracts to design an authentication protocol for IoMT’s healthcare is a challenge.

Motivations and contributions

IoMT, facilitated by advancements in wearable devices, IoT, and mobile internet, offers a promising solution by creating an interconnected, efficient, and personalized healthcare system. Despite its benefits, IoMT-based healthcare faces significant security challenges, including privacy risks and system vulnerabilities, which must be addressed to ensure patient and data security.

The current authentication protocols for IoMT-based healthcare often rely on Trusted Third Parties (TTP), which limits their communication range and scalability while integrating privileged parties poses a threat to privacy. The mismatch between existing research and practical application requirements motivates us to apply blockchain and smart contracts in the medical field, aiming to achieve a more effective decentralized authentication mechanism without relying on TTP. To overcome the limitations of existing authentication protocols, such as privacy disclosure, untraceability of malicious behavior, attack threats, limited communication scope, and lack of cross-cluster access, we propose a blockchain-based cross-cluster authentication protocol. Our protocol leverages the decentralized and secure nature of blockchain and smart contracts to provide efficient, secure, and scalable authentication without the need for a central authority, making it a robust solution for nowadays healthcare requirements. Our contributions are summarized as follows:

1. We propose a blockchain-based cross-cluster authentication protocol with three-factor secrecy for IoMT healthcare, which addresses several critical issues including privacy disclosure, untraceability of malicious behavior, attack threats, limited communication scope, and the lack of cross-cluster access. Our protocol leverages the decentralized nature of blockchain and the security provided by three-factor authentication to ensure robust protection of sensitive medical data while enabling seamless communication across different healthcare clusters.

2. We design a Double Anonymity Strategy (DAS) to protect user privacy and track the identity of malicious users. This strategy takes advantage of blockchain’s inherent transparency and immutability, utilizing smart contracts to replace the traditional Trusted Third Party (TTP). By doing so, we achieve efficient and automatic identity authentication, as well as secure cross-cluster communication and data transmission. The DAS ensures that user identities remain anonymous during regular operations, while still allowing for the identification of malicious actors when necessary.

3. We formally prove the security of the proposed scheme under the random oracle model, providing a rigorous theoretical foundation for its reliability. Additionally, we simulate the proposed protocol and compare it with other related protocols. The results demonstrate that our scheme not only meets the required security standards but also maintains higher efficiency. This is evidenced by its lower computational overhead and faster processing times, making it a practical and effective solution for modern IoMT healthcare systems.

In the following two sections, we present the system and adversary models, along with the preliminary concepts. Our proposed scheme is detailed in “Proposed scheme” section IV. Subsequently, “Formal security proof” section provides a formal proof, while “Informal security analysis” section offers an analysis of additional security properties. The simulation results and a comparative study with relevant schemes are presented in “Performance comparison” section. This paper is concluded in “Conclusion” section.

System model and adversary model

System model

In our scheme, we use the alliance blockchain instead of the public blockchain²⁷. The openness of the alliance blockchain is weaker than that of the public blockchain, the participant nodes of the alliance blockchain are screened out in advance or directly designated. We assume that each hospital acts as a node and is official and trusted to jointly maintain the alliance blockchain. Each hospital has its independent registration center and smart contracts, for its convenience to verify the identity of doctors and patients at the registration stage. We require that only the smart contracts have the permission to write on the blockchain and participants can only get reading permission by joining the system. Considering the possible node failure in the network, we use the Rotation Practical Byzantine Fault Tolerance (RPBFT) consensus algorithm to improve the robustness of the system. RPBFT maintains lower time and computation overhead, keeping its operation at millisecond level. In addition, the algorithm and network complexity are independent of the number of nodes.

As shown in Fig. 1, many hospital nodes jointly maintain the alliance blockchain. Each node contains the patients, the doctors, the smart contracts, and the registration center. In each hospital, there are two smart contracts for users and patients respectively in private storage. The registration center is officially credible and responsible for verifying the identity of doctors and patients on registration and for disputes arbitration. The doctor and the patient register in the registration center and the smart contracts as step 1. When the doctor tries to check the patient’s status or communication, he/she sends the request to the doctors’ smart contract. The smart contract first verifies the legitimacy of the doctor after receiving the request as step 2, then uploads the parameters sent by the doctor to the blockchain and informs the patient’s device to download as step 3. Meanwhile, the smart contract updates the temporary identity of the doctor. The patient device downloads the parameters of key agreement, then calculates the session key and sends the response to the patients’ smart contract as step 4. After verifying the identity of the patient, the smart contract uploads the parameters in step 5. The doctor downloads the parameters, computes and verifies the session key. If the verification is passed, the authentication and key agreement are completed, then the doctor and the patient communicate based on the session key as step 6. Doctors can also establish communication with patients in other clusters (hospitals) in the same process. At the end of each session, the doctor’s device will automatically send the session data encrypted by the session key to the smart contract, which will upload it to the blockchain for record.

Fig. 1.

System model.

Figure 2 shows the relationship between the patient’s sensors and the doctor’s device. The registered patient device is connected with sensors to monitor and analyze the patient’s status in real time. If the above data exceeds the alarm threshold, the patient’s device immediately broadcasts alarms. In addition, the certified doctor can establish communication with the patient through the process shown in Fig. 1, so as to monitor the patient’s condition and view the health data stored in the patient’s device.

Fig. 2.

Patient sensors and device.

Adversary model

According to the blockchain-based cross-hospital authentication scenario, and inspired by the Dolev-Yao (DY) model, the adversary model is articulated as follows:

1. The adversary, denoted as , may be a legitimately registered user or an internal adversary with access to certain system components.

2. can obtain at most two of the three factors (1. user’s password; 2. biometric information; 3. information stored in the user’s devices) to launch any attacks, but cannot simultaneously obtain all three factors.

3. In the context of perfect forward secrecy, may have access to long-term private keys. In the model of three-factor secrecy, may know the user’s biometric information. In the model of known session key secrecy, may know a session key.

4. The smart contracts and registration center are trusted, but may attempt to exploit any vulnerabilities in the implementation or usage of these components.

5. This adversary model is based on the Dolev-Yao model, which assumes that the adversary has complete control over the communication channel and may impersonate, intercept, replay or modify messages to compromise the system’s security.

Definition of the adversary in random oracle model

Definition 1 (Participants and partnering): The proposed scheme consists of several entities: doctors (), smart contracts (), patient devices (), and the registration center. Among these, the doctor (), smart contracts (), and patient’s device () can engage in mutual authentication and session key agreement. These entities are collectively referred to as participants . In the i-th instance, the participants , , , and are denoted as , , , and , respectively.

Session Identity: In the i-th instance, participants that share the same session identity are considered to be in the same session. The session identity ensures that the communication and session management are correctly aligned among the entities involved.

Partner Identity: (resp. ) is the partner identity of (resp. ). This means that the partner identity records which participant each instance is interacting with or partnered with during the session.

Acceptance State: If a participant receives a legal and correct message, its state transitions to . This acceptance state indicates that the participant has successfully validated the incoming message and can proceed with the session.

Partnering Conditions: and can be called partners if they satisfy the following conditions:

1. Both participants are in the acceptance state.

2. The session identities match, i.e., .

3. The partner identities are reciprocal, i.e., and .

4. The agreed session keys among the partners are the same, i.e., .

Definition 2 (Queries): To simulate the malicious behavior of the adversary , the queries are defined as follows:

Execute (): When this query is executed, the adversary can obtain all the messages that are transmitted openly during the public communication session. This allows to eavesdrop on the messages exchanged between the participants.

Send (, ): In this query, the adversary sends a message to participant . If the message is legal and correct according to the protocol, will respond appropriately to the message. If the message is not valid, will neglect and ignore it. This simulates the adversary’s attempt to inject messages into the communication.

Reveal (, ): If the query Test has not been executed and both and have been successfully generated, executing this query will allow to obtain the session key. This query simulates the scenario where the adversary tries to learn the session key after the key exchange process has been completed.

Corrupt (): When the adversary executes this query, they obtain all the secret information stored on the doctor’s device. Specifically, gains access to . This query represents the adversary compromising the doctor’s device.

Test (, , r): When this query is executed, it first generates a random bit . Depending on the value of , the behavior of the query is as follows:

• If , and the session key has been generated, the query returns the actual session key to .

• If , the query returns a random number instead of the actual session key.

• If neither condition is met, nothing is returned.

This query is allowed to be executed at most once, simulating a challenge-response test to verify if can distinguish the real session key from a random value.

Definition 3 (Freshness): An instance can be regarded as fresh if it satisfies the following conditions:

1. Corrupt Query Condition: The Corrupt query, which allows the adversary to gain access to sensitive information such as the internal state of a participant, has been executed at most once. Additionally, the Reveal query, which allows to learn the session key, has not been executed. This condition ensures that the adversary has limited exposure to the internal workings and secrets of the participants, maintaining the integrity of the session.

2. Accept State Condition: Both participants involved in the instance, denoted as (the doctor’s instance) and ​ (the patient’s device instance), must be in the Accept state. This state indicates that the participants have successfully completed the mutual authentication process and have agreed upon a session key. The freshness condition ensures that the session is valid and uncompromised at the time of assessment.

Definition 4 (Semantic security): Semantic security in this context refers to the inability of the adversary to distinguish the session key from a random value. The security definition is as follows:

Guessing Bit: The adversary generates a random bit to guess the bit generated by the Test query. The Test query is a critical part of the security game, where it either returns the actual session key or a random value based on the bit .

Condition for Compromised Security: If , it implies that the adversary has successfully guessed whether the output of the Test query corresponds to the actual session key or a random number. This success indicates that has enough information to distinguish between the session key and a random value, thereby compromising the semantic security of the scheme .

Advantage of the Adversary: The adversary’s advantage is quantified as: . This formula measures how much better the adversary is at guessing compared to random guessing. If this advantage is less than a small threshold , the scheme is considered semantically secure. Here, represents a negligible probability, ensuring that the adversary’s advantage is minimal.

Semantic Security Conclusion: For the scheme to be deemed semantically secure, the adversary’s advantage must be less than the small threshold . This ensures that cannot effectively distinguish between the session key and a random value, thereby protecting the confidentiality of the session key and maintaining the overall security of the cryptographic protocol.

Preliminaries

Blockchain technology

Blockchain is a decentralized, immutable, and transparent distributed ledger system, first introduced in 2008 by Nakamoto as the underlying technology for cryptocurrency²⁸. It ensures that information stored is tamper-proof and traceable. Blockchain can be categorized into public, consortium, and private chains²⁹, each serving different purposes based on openness, decentralization, and transaction speed. Public chains, like Bitcoin, offer high decentralization but come with higher costs. Consortium and private chains are more suitable for applications that prioritize privacy, speed, and internal oversight.

A blockchain consists of a series of blocks, each containing a header and body. The Merkle tree within each block serves as a digital fingerprint of transaction data, ensuring the integrity of records³⁰.

Smart contract

Proposed by Nick Szabo in 1997, smart contracts are self-executing agreements coded into a blockchain, eliminating the need for trusted third parties³¹. These contracts are transparent, decentralized, and automatically enforce rules and agreements between parties. They are widely used in cryptocurrency transactions and can also automate identity authentication in various applications. Smart contracts improve efficiency, fairness, and security, while traditional third-party intermediaries face issues like trust, failure points, and high costs.

Fuzzy extractor

Fuzzy extractor technology was proposed by Dodis et al.³² in 2004. Fuzzy extractor algorithm can convert the input biological information into random string and public information , which can be described as . At the same time, the random string can also be recovered by using public information and similar biological information , which can be described as . The error of and is within the allowable range .

Fuzzy extractor technology is widely used in IoT and IoMT authentication protocols. Biometric information used for authentication can effectively avoid potential password guessing attacks.

Physical unclonable function

Physical Unclonable Function (PUF) is hardware security primitive, which uses the internal physical structure to uniquely identify the digital chip³³. Because of its uniqueness and randomness, PUF is used for security authentication and key generation.

PUF exploits variances in the chip fabrication process to manifest a distinctive function aligned with the challenge and response signals. In essence, when confronted with the identical challenge, the PUF has the capacity to furnish a consistent response falling within the acceptable margin of error. In addition, it is not feasible to speculate on the output result of PUF. Due to physical differences, the responses of different chips are different for the same challenge. PUF in the hardware device cannot be tampered. When a device is subjected to corruption attacks or side-channel attacks, the physical characteristics of the chip will change, and the response of the PUF will be different.

Proposed scheme

The notations of the proposed scheme as shown in Table 2.

Table 2.

Notations.

Notations	Description
	Personal identity of
	Password of
	Identity of the device of patient
	Session key
	Base point of elliptic curve
	Temporary identity of
	Hash function
	Concatenation
	XOR operation
,	Fuzzy Extractor algorithm for reproduction and generation
	The bioinformatics of
	Public parameter of Fuzzy Extractor algorithm
	Biometric key of Fuzzy Extractor algorithm
	Timestamps
	The maximum transmission delay time
	The secret key of registration center
	Physical unclonable function (PUF)
	Challenge and response for PUF
	The secret parameter of smart contract for user and patient respectively

Initialization phase

The registration center selects its secret key and computes its public key . The smart contracts for the doctors and the patients select secret keys and , compute their public keys and , respectively.

Registration phase

The registration phase consists of the doctor registration phase and the patient’s device registration phase.

Registration phase of a doctor

The registration phase of the doctor is shown in Fig. 3.

Fig. 3.

The registration phase of doctor (device).

Step RU1: The doctor inputs his/her identity , password , and biometric into the device. Then the device selects a random number , and computes: ), . The device transmits to the registration center via an insecure channel.

Step RU2: Upon receiving the registration center first computes and verifies the real identity and information of the doctor to ensure that it is not a malicious user counterfeiting registration. Then the registration center checks the legitimacy and uniqueness of , if not, requests the doctor to select a new . Else, the registration center generates a random number and computes: , , where is the secret key of the registration center. Then, the registration center transmits to the server of smart contract for doctors.

Step RU3: The smart contract for doctors generates a nonce , and computes: , , , , . Then, it sends to the registration center. The registration center recovers and , computes and sends to the doctor.

Step RU4: On receiving , the doctor’s device calculates: , , , , , where n belongs to 16 to 256³⁴, and stores .

Registration phase of patient device

The registration phase of the patient’s device is shown in Fig. 4.

Fig. 4.

The registration phase of patient (device).

Step RP1: The patient’s device selects a random number , computes and sends to the registration center.

Step RP2: The registration center first selects a unique identity of the patient’s device, computes and sends to the smart contract for patients.

Step RP3: The smart contract generates a nonce , and computes: , , , .

Then it sends to the registration center. The registration center decrypts by ), and checks the correctness of . After that it computes and sends to the patient’s device.

Step RP4: The patient’s device generates a challenge , and computes: , checks the correctness of and computes: , .

Where is the physical unclonable function. The device stores .

Mutual authentication and key agreement phase

If a doctor wants to obtain a patient’s body information (his/her identity is ) in the same hospital or different hospitals, he/she and the patient’s device needs to pass the identity authentication of the smart contract first, and then agree on the session key through blockchain as shown in Fig. 5. The details are as follows:

Fig. 5.

Mutual authentication and key agreement phase.

Step AK1: The doctor first inputs identity , password , and biometric into the device, and the device computes: , .

if , abort it. Else, it computes: , .

Then, the device generates nonce , and a timestamp , and computes: , . After that, the doctor’s device sends to the smart contract for doctors via a public channel.

Step AK2: The smart contract for doctors gets the current timestamp and computes: , , , if or , abort it. Else, the smart contract generates a timestamp , uploads onto the blockchain, and notifies the patient’s device of to download them.

The smart contract for doctors generates a nonce , the current timestamp , and computes: , . Then, the smart contract for doctors sends to the doctor’s device.

On receiving from the smart contract for doctors, the doctor’s device computes: .

The device generates the current timestamp , and checks if and , if not, terminates the session, else, replaces with . .

Step AK3: The patient’s device downloads from the blockchain, then checks the freshness of , if not, aborts it, else, computes: .

The patient’s device generates a nonce , the current timestamp , and computes: , , , ,. Then device sends to the smart contract for patients.

Step AK4: Upon receiving from the patient’s device, the smart contract for patients first checks the freshness of , if not, terminates the session, else, it computes: , , () = (). If or , the smart contract aborts the session, else, generates a timestamp , and uploads on the blockchain. Then, the smart contract notifies the doctor’s device to download them.

The smart contract generates nonce , , timestamp , and computes: , , . Then it sends to the patient’s device.

The patient’s device computes: . The device checks the freshness of , if not, terminates it. Else, computes: . If , abort it. Else, replace with .

Step AK5: After downloading from the blockchain, the doctor’s device first checks the freshness of , if not, terminates the session, else, it computes: , , .

If , the device aborts the session, otherwise, the authentication and session key agreement are successfully completed.

Anonymous identity tracking

Although the identities of the doctor and the patient’s device are dynamically anonymous, their true identities can still be tracked when needed.

In case of dispute, the patient can submit the doctor’s to the smart contract for doctors, who can recover the doctor’s pseudo-identity by calculating , where is the doctor’s anonymous identity, is the secret parameter of the smart contract, is a nonce, and . After that, the smart contract for doctors sends to the registration center, who can recover the doctor’s real identity by computing , where is the registration center’s secret parameter, is a nonce.

The smart contract for patients recovers the identity of the patient’s device by calculating , where is the identity of the device, is a nonce, is the device’s anonymous identity, and is the secret parameter of the smart contract.

Formal security proof

In this segment, we furnish a formal proof of security within the context of the random oracle model, validating the semantic security of the proposed blockchain-based scheme . We aim to illustrate that the advantage of an adversary in breaking the semantic security of within probabilistic polynomial time (PPT) is negligible, under the assumption of the intractability of ECDLP.

Formal security proof

Theorem 1

We define the advantage of breaking the semantic security of by in PPT is . runs , , and times Hash, Send, and Execute queries, respectively. , , and represent the bit-length of the hash, nonce, and the biometric key. and are the regression parameters of the password space. The advantage can be defined as:

Proof

We define a series of games to simulate attacks against semantic security launched by the adversary . represents breaks the semantic security of in . The definitions are as follows:

: This constitutes a genuine attack initiated by the adversary . She/he first selects a random bit . According to the definition, we have:

1

: In this simulation, the adversary initiates the Execute query to acquire openly transmitted messages between participants. Finally, executes the Test query and judges whether the output of Test is the actual session key.

In the proposed scheme, the session key is defined as . Among the intercepted messages, parameters , , , and ​ are related to the session key. However, the adversary cannot establish an association between these messages and the session key due to the Computational Diffie-Hellman Problem (CDHP). Even though intercepts all the transcripts, whether the result corresponds to the session key remains indistinguishable.

Based on the above analysis, we get:

2

: The adversary tries to find collisions in the hash values used in the protocol. According to the birthday paradox, which describes the probability of two or more values hashing to the same output, the maximum probability of a hash collision is ​​, where ​ is the number of hash queries and is the length of the hash output in bits. Since hash functions are designed to be collision-resistant, the likelihood of successfully finding a collision is extremely low if ​ is large enough (e.g., 256 bits). Thus, cannot easily exploit hash collisions to distinguish the session key. Nonces (numbers used once) are crucial for ensuring the freshness of messages. The collision probability of a nonce is at most ​, where ​ and are the number of Execute and Send queries, respectively, and ​ is the bit length of the nonce. Nonce collisions are similarly unlikely if ​ is sufficiently large. Nonce collisions could undermine the security of the protocol by allowing to replay or predict messages. However, a properly sized nonce (e.g., 256 bits) minimizes this risk.

XOR operations are used in various cryptographic protocols to combine different values. The security of these operations relies on the unpredictability of the inputs. Even if intercepts XOR values, without knowing the individual components, it remains computationally infeasible to reverse-engineer them. The strength of the XOR operation in this context depends on the secrecy and randomness of the involved values (e.g., session keys, nonces). Given the above analysis, the probability that can successfully distinguish the session key in Game 2 by exploiting hash collisions, nonce collisions, or XOR operations is negligible. Thus, the probability difference between the success in Game 2 and Game 1 is bounded by:

3

: Which simulates the corruption attack based on the doctor’s device launched by . On beginning, executes Execute to obtain , where , , and , is the public parameter for recovering the biometric key by calculating . The adversary needs to guess the password and the biometric key to obtain valuable information and launch attacks. According to Zipf’s law³⁴, which describes the frequency distribution of words (or passwords) in natural language, the maximum probability of guessing a password is ​. The password dictionary space is denoted as , where and are the regression parameters of . The probability of guessing is at most ​​, where represents the bit length of the biometric key ​. This bound illustrates that the probability of a successful corruption attack by remains limited, ensuring that the proposed scheme’s security is maintained even when attempts to exploit potential weaknesses through corruption attacks. Therefore, we get:

4

: In the proposed scheme, the session key , whose agreement and generation are based on CDHP and one-way hash. This game simulates that tends to calculate the session key after executing queries Execute and Hash. In the first scenario, launches a hash collision attack against the session key. The probability of a hash collision occurring is at most ​​, where ​ is the number of hash queries made by and is the bit length of the hash output. The likelihood of successfully finding a hash collision is inversely proportional to the bit length of the hash output. In the second scenario, obtains and and then attempts to calculate . The maximum probability of success for this calculation is ​, where represents 's advantage in solving the Elliptic Curve Discrete Logarithm Problem (ECDLP). According to the definition, , where is a sufficiently small constant representing the negligible advantage of in solving the ECDLP.

Combining both scenarios, the probability difference between the success in Game 4 and Game 3 is bounded by:

5

From the above games, still have no advantage to guess the random bit . That is:

6

From formula (1), we know:

7

Therefore, combining formulas (2) to (7), we get:

That is: .

Informal security analysis

Stolen-verifier attack

In our proposed system, both the smart contracts and the registration center are considered trusted entities and do not retain verification tables for identity authentication. This design aspect enhances the scheme’s resilience against stolen-verifier attacks.

Desynchronization attack

The temporary user identity will be changed in each session and only the user (doctor) stores , where . Even if the adversary intercepts, tampers, or deletes the message to prevent the user (doctor) from updating the temporary identity, the user (doctor) can still successfully complete the next session of authentication and session key agreement with the previous temporary identity. This strategy of updating user temporary identity avoids desynchronized updates. Similarly, the desynchronization attack against the patient device does not work. Therefore, our scheme can resist desynchronization attacks.

Device node captured attack

The device of the patient stores , where , . According to the characteristics of PUF, even if the adversary obtains the device, he/she cannot recover the secret parameters by side-channel attacks and corruption attacks. In addition, the adversary cannot obtain the secret parameter and patient’s real identity.

Off-line identity/password guessing attack

In the device, the identity and the password are included in , assume an adversary compromised the device and obtained the biometric information, and attempt to guess to match . When , there are candidates of pair. Therefore, the adversary cannot know which pair is correct, the proposed scheme can resist off-line identity/password guessing attacks.

Three-factor secrecy

Assume an adversary compromised the device and obtained the biometric information, according to above analysis, he/she cannot verify the guessed pair.

Assuming an adversary has acquired the biometric information and password, he/she remain unaware of the stored information so he/she cannot launch any attacks.

Assume an adversary obtained the password and compromised the device, he/she cannot obtain any valuable information to launch any attacks.

Therefore, our scheme can achieve three-factor secrecy.

Anonymity and unlinkability

The temporary identities and are updated in each session, where , . The updated temporary identities are , . The nonce is independent in each session run, so the different temporary identities are unlinkable. The adversary also cannot recover the real identities from the temporary identities without knowing the secret keys of the registration center and the smart contracts.

Smart card (device of doctor) lost attack

The device of the user (doctor) stores , where , , , and is the public parameter of fuzzy extractor for recovering the biometric key of the user. Suppose the adversary gets the device and obtains the information stored, he/she cannot recover any unencrypted information without the bioinformatics and the password of the user (doctor). Hence, in the event of the doctor’s device being lost, the adversary is unable to acquire any valuable information or execute attacks.

Impersonation attack

Suppose the adversary attempts to forge the message to impersonate the doctor, where . However, forging is impossible because is unavailable for the adversary. Meanwhile, replaying is also useless because of the timestamp and the nonce . Therefore, the user cannot be impersonated by the adversary.

Assume that the adversary impersonates the smart contract and forges or , where . The forged messages cannot pass the authentication of the doctor because is unavailable. Similarly, and cannot be forged without knowing , where and . Therefore, the smart contracts cannot be impersonated.

Replay attack

In our scheme, all transmitted messages are combined with the timestamp and random nonce. Therefore, the proposed scheme can resist replay attacks.

Perfect forward secrecy

Assuming the adversary has acquired long-term keys, implying the capability to decrypt all transcripts from the authentication and key agreement process. However, the session key is computed based on the CDHP, the adversary cannot obtain the nonce and to calculate because they are not transmitted. As a result, even with knowledge of all the long-term keys, the adversary remains unable to compute past session keys. Thus, the proposed scheme attains impeccable forward secrecy.

Known session key secrecy

Assuming that the current session key is leaked to the adversary, where . He/she cannot obtain any other valuable information according to . Meanwhile, the session keys are independent because of the nonce. Therefore, the adversary cannot discover or calculate previous or subsequent session keys. The proposed scheme has known session key secrecy.

Session key secrecy

The session key , where and represent distinct random numbers. Due to the CDHP and the one-way hash function, an adversary would be unable to gain any valuable information, even if they were to acquire the session key.

Performance comparison

In this section, we use several devices to simulate and analyze the proposed scheme. We deploy an alliance blockchain and smart contracts based on FISCO BCOS on Ubuntu 16.04 64bit, Intel (R) Core (TM) i7-1165G7 @ 2.80 GHz, where the nodes simulate different hospitals. The requests of doctors and patients are simulated on Python 3.8.6, Windows Intel (R) Core (TM) i5-6300HQ CPU @ 2.30 GHz, and the number of requests can be controlled. The consensus mechanism of FISCO BCOS is RPBFT, so it can accurately simulate our scheme. To highlight the advantages of our authentication scheme, we compare it with^7,8,18,19,22 in different performance indicators. Among them, the comparison of security properties is shown in Table 3.

Table 3.

Comparison of security properties.

	Attacks/properties	7	8	18	19	22	Ours
Security	n-factor security	–	✗	✗	✗	✗	✓
	Off-line password guessing attack	✓	✓	✗	✗	✓	✓
	Impersonation attack	✗	✗	✗	✓	✓	✓
	Replay attack	✓	✗	✓	✓	✓	✓
	Man-in-the-middle attack	✓	✗	✓	✓	✓	✓
	Smart card (device) loss attack	✓	✓	✗	✓	✓	✓
	Device node capture attack	✓	✓	✗	✓	✓	✓
	Stolen-verifier attack	✗	✗	✗	✓	✓	✓
	Desynchronization attack	✓	✓	✓	✓	✓	✓
	Mutual authentication	✗	✓	✓	✓	✓	✓
	Session key secrecy	✗	✗	✓	✓	✗	✓
	Know session key attack	✗	✓	✓	✓	✓	✓
	Perfect forward secrecy	✗	✗	✓	✗	✗	✓
Privacy	Doctor anonymity	✗	✗	✗	✓	✓	✓
	Patient anonymity	✗	✗	✗	✓	✓	✓
	Unlinkability	✗	✗	✗	✓	✓	✓
Applicability	Decentralization	✓	✗	✗	✗	✗	✓
	Scalability	✓	✗	✗	✗	✗	✓
	Cross-cluster	✓	✗	✗	✗	✗	✓

✓: Resist(attacks)/possess(properties), ✗: suffer(attacks)/no(properties).

The scheme of Yazdinejad et al.⁷ is a decentralized authentication scheme based on blockchain for hospital networks, which uses public blockchain and PoW to realize decentralization, message traceability, and cross-cluster communication. The scheme of Xiang et al.⁸ is a permissioned blockchain-based identity management and user authentication protocol for E-healthcare. In their protocol, doctors and patients are regarded as users, and the blockchain is used as a trusted distributed ledger to record user registration information.

Computation and energy overheads

Firstly, we simulate the case that a single node completes authentication and key agreement when it receives multiple requests concurrently, and calculate the average time. This represents the situation where doctors and patients in the same hospital request to establish communication. The specific parameters of the consensus mechanism PoW are not given in⁷, we refer to the research on PoW in³⁵. In the competitive consensus mechanism, calculating the random value in each round is an uncertain calculation problem, therefore, the delay of blocks generated by nodes in different rounds fluctuates from 50 to 6000 . PoW has the characteristics of high computational overhead and low Transaction Per Second (TPS). The goal of this simulation is to verify the authentication efficiency of a single node in a single cluster, so the competition between nodes is not considered. We use , , , , and to denote the time overhead of Hash operation, elliptic curve multiplication, symmetric encryption, and consensus mechanism of PoW and RPBFT, respectively. The environment of Raspberry Pi 4B is quad-core 64bits ARM Cortex-A72, 1.5 GHz, and we use 2 GB LPDDR4 SDARM to simulate the portable devices of doctors and patients. In the above environment, , , . and vary according to the number of nodes and the number of requests. Generally speaking, and . The overhead of our scheme is mainly the computational overhead of authentication and the overhead of the consensus mechanism. We denote the overhead of a single authentication as (). According to the specific protocol of Xiang et al., the overhead of the protocol is denoted as (). Since Yazdinejad et al. do not propose a specific protocol, we believe that the overhead is slightly greater than ().

In Kumar et al.’s scheme¹⁸, patients and doctors hold each other’s public keys and negotiate a session key through the cloud server. The session key negotiation involves multiple symmetric encryptions, signatures, and ECC point multiplications. The cost of a single authentication is approximately (), and it increases linearly with the number of authentication requests. In Chen et al.’s scheme¹⁹, users agree with a sensor node a session key through the gateway. The security of the scheme is based on pre-shared secrets and hash functions, and it does not provide forward security. Specific security details can be found in Table 3. The authentication process involves 30 hash operations and asymmetric encryption/decryption. We measured that, according to the parameters given in this paper, encrypting and decrypting 256 bits data using AES-256 takes approximately 734.657 . The cost of a single authentication is approximately (), and it increases linearly with the number of authentication requests. In Mahmood et al.’s scheme²², users and sensors negotiate a session key through the cloud server. The authentication involves ().

As shown in Fig. 6a, we evaluated the time complexity of six schemes to deal with different numbers of authentication requests. We simulate the overhead spent by a single node processing different numbers of authentication requests in parallel. This reflects the efficiency of concurrently processing multiple authentications in one hospital. In our solution, the cost of processing one authentication request is about 12 ms, which can meet the requirements of fast access to medical data in emergency medical environments. we tested the blockchain’s throughput under high-concurrency conditions. On the other hand, the blockchain throughput scales with the number of requests, and the RPBFT consensus mechanism maintains a throughput of 1000 TPS to 100,000 TPS. This demonstrates that our solution can fully meet the demand for real-time, high-volume data processing in practical emergency scenarios. Additionally, the total overhead for one node to process 50 requests is approximately 500 ms, which we believe is fast enough to ensure efficient and timely data access in high-pressure environments like emergency rooms, without compromising patient care. The overhead of Xiang et al.’s protocol is slightly higher than our scheme. The inefficiency of PoW consensus mechanism limits the throughput of public blockchain, hence each authentication of Yazdinejad et al.’s protocol is accompanied by unnecessary overhead, resulting in that its authentication time is much higher than the above two schemes. In the case of a single cluster, the centralized authentication protocols are generally more efficient than the blockchain-based decentralized authentication protocols. Nevertheless, in the actual medical scenario, the centralized authentication protocols cannot meet the needs of cross-hospitals communication.

Fig. 6.

(a) The authentication time of one node. (b) CPU invocation time of each node. (c) The transaction per second (TPS) of blockchain.

In order to test the scalability of the blockchain-based authentication protocols and the computational overhead in the case of multiple nodes, we simulated the situation by calculating the computational overhead of protocols under different numbers of nodes. We record the time spent calling the CPU during the simulation in the python environment. As shown in Fig. 6b, we tested the CPU invocation time of a single node with different numbers of nodes and each node handles 20 authentication requests. For Yazdinejad et al.’s scheme, the computational cost of nodes keeps approximately linear growth to the number of nodes. The reason for the increasing is that nodes based on the PoW consensus mechanism need to calculate a large number of hash operations to find an eigenvalue to compete for the permission of generating blocks. Besides, the consensus mechanism requires all nodes to participate in the confirmation operation, resulting in low efficiency and long confirmation time which is difficult to be reduced. The RPBFT consensus mechanism used in our scheme can replace the verification node in turn. Its algorithm complexity and network complexity are independent of the number of nodes, and its scalability and consensus efficiency are higher than Practical Byzantine Fault Tolerance (PBFT). Therefore, even with an increase in the number of nodes, the overhead of each node in our solution remains below 300 ms when processing the same number of requests, which can meet the needs of multiple medical service providers to access patient data across hospitals in real-time. According to the simulation results, the computational overhead of our scheme is much lower than the other schemes.

As shown in Fig. 6c. We test the Transaction Per Second (TPS) of the blockchain in our scheme and Yazdinejad’s scheme. In Xiang et al.’s scheme, the blockchain is only used in the registration phase, therefore it is out of our consideration. The throughput of blockchain based on PoW consensus mechanism has an upper limit, say the maximal throughput per second of blockchain in Yazdinejad’s scheme is maintained at about 7, which has greatly affected the efficiency of their scheme. In our scheme, the throughput of the blockchain equals to the number of requests, for that the throughput of RPBFT can be maintained at 1000TPS-100000TPS. Therefore, our solution can fully meet the demand for instantaneous throughput in practical application scenarios.

Communication and storage overheads

In Tables 4 and 5, we present a comparison of the storage and communication overhead of the protocols. The output sizes for various cryptographic operations are as follows: SHA-256 hash (256 bits), RSA-1024 encryption/decryption (1024 bits), DSA-1024 signature (1024 bits), AES-128 symmetric encryption (128 bits), an ECC point (160 bits), and a random number (256 bits). Additionally, the lengths for the identity, password, and timestamp are all 32 bits.

Table 4.

Comparison of storage overhead.

Scheme	Storage overhead
	Server	Device (smart card)	Total
8	800bit	1312bit	2112bit
18	1536/1024bit	1536/1024bit	5120bit
19	288/288bit	544/544bit	1664bit
22	544/544bit	768/800bit	2656bit
Ours	0bit	1032/800bit	1832bit

Table 5.

Comparison of communication overhead.

Scheme	Communication overhead verification
8	1920bit
18	7872bit
19	3200bit
22	1568bit
Ours	2784bit

Yazdinejad’s scheme⁷ does not provide specific storage and communication details, so its corresponding overhead cannot be accurately evaluated. In Xiang et al.’s scheme⁸, user devices interact with the medical server, which stores approximately 800 bits of user registration information on the blockchain. The smart card stores about 1312 bits of data. The communication overhead for registration and verification are approximately 1056 bits and 1920 bits, respectively. In Kumar et al.’s scheme¹⁸, patients and doctors use different devices, so in Table 4, we differentiate between the devices used by patients and doctors with a slash. During verification, the server forwards a large amount of encrypted data, resulting in a total overhead of approximately 7872 bits. In Chen et al.’s scheme¹⁹, we separately calculated the storage and communication overhead for user devices and sensors during registration. The total verification overhead is 3200 bits. In Mahmood et al.’s scheme²², we separately calculated the storage and communication overhead for user devices and sensors during registration. The total verification overhead is 1568 bits.

In the proposed scheme, the server (service provider) does not store additional user information for authentication during registration. The devices used by doctors and patients store 1032 bits and 800 bits of data, respectively. The communication overhead for registration is 1792 bits for doctors and 2368 bits for patients. The total communication overhead during the verification phase is approximately 5288 bits.

In terms of storage overhead, our scheme reduces the overhead by 2392 bits (a 13.3% reduction) compared to scheme⁸, and 3288 bits (a 64.2% reduction) compared to scheme¹⁸. It increases the overhead by 168 bits (a 10.1% increase) compared to scheme¹⁹, and 824 bits (a 31.0% reduction) compared to scheme²². The proposed scheme has 864 and 1216 more bits of communication overhead than schemes⁸ and²² respectively, and 5088 and 416 fewer bits than Schemes¹⁸ and¹⁹ respectively. To enhance communication security, our scheme additionally uses a key to encrypt the transmission content during the transmission process. Therefore, the communication overhead is slightly higher than that of schemes in⁸ and²².

Figure 7 comprehensively shows the advantages and disadvantages of six schemes. Therefore, our authentication protocol has higher security, efficiency, and privacy. Besides, it meets the needs of decentralization, scalability, and cross-cluster of medical scenarios.

Fig. 7.

Comprehensive performance comparison.

The proposed system supports secure communication between doctors and patients across different hospitals, enabling integrated healthcare. Patient devices connected to sensors provide continuous health monitoring, with immediate alerts if critical thresholds are exceeded. Smart contracts ensure that only authorized entities access sensitive patient data, maintaining privacy and confidentiality. Implementation steps include setting up hospital nodes with independent registration centers and smart contracts. Doctors and patients register with their respective hospital nodes, verified by the registration center. Doctors send authentication requests to smart contracts, which are verified and processed in real-time, enabling secure communication with patients.

The proposed scheme demonstrates several practical advantages: (1) Efficiency: Low computational overhead and high TPS ensure the system can handle high volumes of authentication requests efficiently. (2) Scalability: The system can scale to accommodate additional hospital nodes without performance loss. (3) Security: Robust cryptographic mechanisms and consensus protocols ensure secure and reliable operations.

The proposed authentication and key agreement scheme, leveraging the alliance blockchain and RPBFT consensus mechanism, demonstrates high feasibility and operability for real-world medical applications. Its computational efficiency, scalability, security, and real-time operability make it a practical solution for secure and efficient healthcare communication. The system meets the demands of decentralized, scalable, and cross-cluster communication, ensuring robust and reliable operations in integrated healthcare networks.

Conclusion

In this paper, we proposed a novel blockchain-based cross-hospital authentication scheme for IoMT-based healthcare. We realize efficient automatic authentication based on smart contracts and blockchain instead of relying on TTP. A novel DAS is proposed, and pseudo-identity is used to realize the anonymity of doctors and patients respectively. Based on these two strategies, we realize the privacy protection of doctors and patients meanwhile keep the records traceable. Based on the alliance blockchain and RPBFT consensus mechanism, we have realized a secure and efficient dynamic expansion of hospital nodes. Doctors and patients in different hospital nodes can communicate across clusters. We present formal security proof in the random oracle model to prove the semantic security of the proposed scheme, as well as security analysis of many other desirable properties. In addition, we conduct a simulation test on the scheme and compare it with two related schemes. The results and security analysis show that our scheme can achieve identity authentication, node expansion, and cross-hospital communication with lower computation overhead while ensuring security and privacy. Compared to most related schemes, our approach achieves a reduction of approximately 23% to 87% in computational overhead and a reduction of about 13% to 64% in storage overhead. The limitation of our scheme is that it increases the transmission volume due to the need for interaction with smart contracts in the blockchain, resulting in a transmission volume that is only at a moderate level compared to existing solutions. Future research can focus on the design of smart contracts specifically designed for secure and efficient cross hospital communication protocols.

Author contributions

Z.D, designing, experimentation, writing, and security proof; Q.X., conceptualization, methodology, review, editing, revise, funding. All authors reviewed the manuscript.

Funding

This research was supported by the Hangzhou Joint Fund of the Zhejiang Provincial Natural Science Foundation of China under Grant LHZSZ24F020002 and the National Natural Science Foundation of China under Grant U21A20466.

Data availability

Data is provided within the manuscript.

Declarations

Competing interests

The authors declare no competing interests.