Blockchain-Based Privacy-Preserving Authentication and Access Control Model for E-Health Users

Abstract

The advancement of e-health systems has resulted in substantial enhancements in healthcare delivery via effective data management and accessibility. The use of digital health solutions presents dangers to sensitive health information, including unauthorised access, privacy violations, and security weaknesses. This research presents a blockchain-based paradigm for privacy-preserving authentication and access control specifically designed for e-health systems. The architecture utilises the Ethereum blockchain, smart contracts, blind signatures, Proof of Authority (PoA) consensus, and one-way hash functions to improve data integrity, security, and privacy in a decentralised framework. The proposed methodology addresses computational efficiency and scalability issues via the implementation of lightweight cryptographic techniques, achieving an average authentication delay of 0.059 milliseconds, which represents a 4000-fold improvement compared to current approaches. The model exhibits a significant decrease in memory use, requiring just 0.0198 MB in contrast to the 96.98 MB required by benchmark models, and attains an average signature verification duration of 0.00092 milliseconds. The findings demonstrate the model’s capability for safe, efficient, and scalable applications in e-health, which guarantees privacy and adherence to regulatory norms.

1. Introduction

The swift integration of e-health systems and digital health applications has notably altered healthcare delivery through the facilitation of remote patient monitoring, telemedicine, and efficient electronic health records (EHRs) [1,2]. The increasing reliance on digital platforms has resulted in significant security and privacy concerns, including unauthorised access, data breaches, and identity theft [3]. Traditional authentication methods, including password-based systems and two-factor authentication (2FA), do not sufficiently resolve these challenges because they are vulnerable to cyberattacks, have limited scalability, and do not provide adequate trust assurance [4,5]. A secure, scalable, and resilient authentication mechanism is essential for safeguarding patient data and ensuring controlled access to healthcare resources.

Blockchain technology features a decentralised, immutable, and cryptographically secure architecture, which presents a viable solution for addressing these challenges [6]. Utilising a tamper-resistant ledger and distributed consensus mechanisms, blockchain facilitates secure authentication, access control, and  data integrity protection within e-health systems [7]. Previous research has shown the capabilities of blockchain-based authentication models, which utilise Practical Byzantine Fault Tolerance (PBFT) and Elliptic Curve Cryptography (ECC) to improve privacy-preserving authentication while also tackling computational and storage limitations [8]. Blockchain-driven privacy-preserving access control models employ techniques like Geometric Data Perturbation (GDP) and K-means clustering to enhance security; however, scalability challenges remain in IoMT-based healthcare environments [9]. In addition to authentication, blockchain enhances the confidentiality of medical data and facilitates secure data sharing. Advanced solutions, including Searchable Attribute-Based Encryption (SABE), offer fine-grained access control and maintain data confidentiality through decentralised governance [10]. These systems frequently encounter significant computational expenses during the decryption process and may experience delays attributed to consensus mechanisms [10]. Furthermore, frameworks designed to preserve privacy for electronic health records (EHR) and biometric data protection utilise zero-knowledge proofs (ZKP) and privacy coins, thereby ensuring adherence to General Data Protection Regulation (GDPR) standards [11]. Although these techniques improve security, they frequently face limitations due to elevated transaction fees, computational overhead, and scalability issues [12,13,14].

Blockchain integration in e-health presents several advantages; however, it is impeded by computational inefficiencies, latency in data processing, and storage constraints [15]. The IoMT-based e-health monitoring systems that employ blockchain often experience synchronisation delays between on-chain and off-chain storage, which affect the accessibility of real-time data [16]. AI-driven blockchain-enabled e-health data sharing frameworks exhibit scalability limitations when deployed in resource-intensive environments [17]. To address these challenges, it is essential to implement optimised blockchain-based authentication architectures, which improve security while maintaining efficiency and scalability.

This study introduces an innovative framework for authentication and access control, utilising blockchain technology specifically designed for e-health environments. The proposed solution incorporates the Ethereum blockchain, utilises smart contracts, implements blind signatures, employs Proof of Authority (PoA) consensus, and applies one-way hash functions to ensure secure, privacy-preserving, and efficient authentication. The framework is designed to address current authentication vulnerabilities, improve patient data confidentiality, and provide a scalable, low-latency blockchain solution suitable for practical healthcare applications.

This study presents several significant contributions:

• The proposed model presents a decentralised, blockchain-based framework for securely authenticating e-health users while maintaining privacy. It integrates blind signatures with Proof of Authority consensus on the Ethereum blockchain.
• Lightweight cryptographic techniques are utilised in the model to meet the scalability and efficiency requirements of e-health systems. Specifically, one-way hash functions and blind signatures are implemented to reduce computational load and memory consumption.
• The model enhances privacy and regulatory compliance by storing only hashed identifiers and metadata on-chain, thereby ensuring adherence to privacy regulations like GDPR and facilitating secure access to patient data while preserving privacy.
• A thorough performance analysis reveals that the model exhibits efficiency improvements in authentication speed, memory utilisation, and signature verification time when compared to established frameworks, indicating its suitability for real-time, large-scale healthcare settings.

The remaining parts of the paper include the following: literature review (Section 2), system model (Section 3), proposed model (Section 4), security analysis of the proposed model (Section 5), and performance evaluation of the proposed model (Section 6). Section 7 concludes the paper.

2. Literature Review

The growing dependence on digital health systems has created a need for advanced security solutions to safeguard patient data, maintain authentication integrity, and manage access control mechanisms. Blockchain technology has emerged as a viable solution, providing decentralised security, privacy preservation, and immutability for applications in the healthcare sector. This section organises the existing research on privacy-preserving authentication and access control in Blockchain-Based Systems, exploring its methodologies, advantages, and constraints in the context of e-health security.

2.1. Privacy-Preserving Authentication

Blockchain technology is becoming acknowledged for its ability to improve authentication processes in e-health systems via its decentralised and irreversible ledger features. Numerous research has investigated several strategies to overcome the shortcomings of conventional authentication techniques, emphasising improvements in security, privacy, and access control within e-health settings.

Numerous research has suggested decentralised authentication procedures and access control techniques to safeguard medical data. One research used Practical Byzantine Fault Tolerance (PBFT) consensus and elliptic curve cryptography (ECC) to guarantee data privacy and integrity; however, it encountered significant computational expenses and synchronisation difficulties between on-chain and off-chain storage [6]. Likewise, a privacy-preserving control technique that used K-means clustering, Geometric Data Perturbation (GDP), and ECC enhanced data security but faced considerable computational complexity and scalability challenges in IoT systems [8].

Blockchain-assisted searchable attribute-based encryption (SABE) systems have been developed to improve safe data exchange, integrating blockchain for decentralised access management with searchable encryption methods to preserve privacy. These solutions, however, encountered difficulties such as significant computing costs during decryption and delays resulting from blockchain consensus procedures [9]. Moreover, a blockchain-based privacy-preserving system for managing electronic health records (EHRs) used pairing-based encryption and secure key exchange protocols, however it had elevated computing costs and possible delays attributable to consensus procedures [11].

Additionally, privacy-preserving biometric authentication (PPBA) protocols were developed to safeguard biometric data via the utilisation of blockchain, zero-knowledge proofs (ZKP), and privacy coins, hence assuring adherence to GDPR and resilience against attacks [12]. The system had limitations due to processing complexity from cryptographic procedures, elevated transaction fees on public blockchains, and the risk of attacks if secret parameters or user devices were compromised. A blockchain-enabled IoMT security solution used smart contracts and decentralised storage, enhancing data privacy but encountering significant computational expenses and synchronisation difficulties [15].

Ultimately, the blockchain-based authentication architecture was proposed to utilised multi-factor authentication (MFA), the RSA cryptosystem, and smart contracts within a decentralised network to enhance security and privacy in e-health systems [18]. The system faced limitations owing to elevated computational expenses from cryptographic operations, scalability issues in managing extensive EHRs, possible delays in real-time data processing, and dependence on reliable network access for authentication procedures.

A blockchain-based user authentication system using modified RSA encryption and smart contracts for secure access management was proposed. The system uses blockchain for decentralised storage and multi-channel data transmission to augment security and privacy [19]. The concept aims to provide access across various healthcare applications but faces significant computing costs for encryption and blockchain operations, possible delays in real-time authentication procedures, and difficulties in safely and effectively handling large-scale healthcare data.

2.2. Access Control in Blockchain-Based Systems

Initiatives to strengthen access control and key management include an innovative protocol (BACKM-EHA) for IoMT applications, using ECC and smart contracts to enhance security, however encountering real-time processing latency and computational overhead [16]. Provenance-aware blockchain systems, using Directed Acyclic Graph (DAG) architectures, sought to enhance transparency but faced challenges related to computational expenses and delays in auditing procedures [17]. AI-driven secure data dissemination frameworks employing a deep learning-based intrusion detection system (IDS) that integrates stacked contractive sparse denoising auto-encoder (SCSDAE), long short-term memory (LSTM), multi-layer perceptron (MLP), and a blockchain-enabled Proof-of-Authority consensus mechanism was proposed. The main objective of the model is to safeguard patient data; however, it encounters significant computational costs and latency in real-time data processing, scalability challenges due to resource-intensive blockchain operations, and possible synchronisation issues between blockchain and IoT devices [20].

Smart contract-enabled frameworks for electronic health record (EHR) sharing in mobile cloud-based systems were proposed to utilise smart contracts and proof-of-work consensus. The framework employed blockchain for decentralised management, InterPlanetary File System (IPFS) for distributed storage, and cryptographic techniques for secure data sharing to ensure data integrity. However, they faced significant computational overhead from proof-of-work consensus, scalability challenges in managing extensive datasets, and potential latency issues in real-time data processing [21]. A hybrid blockchain framework that combines private and consortium blockchains, using optimised encryption methods such as cryptographic hashing (SHA-256) to ensure data integrity, improve privacy, and minimise overhead, was presented [22]. Nonetheless, the approach faced scalability issues resulting from the hybrid blockchain architecture and significant delays in data retrieval caused by many layers of encryption and blockchain processes. Simultaneously, multi-level security frameworks integrating lattice-based access control (LBAC) for hierarchical access management and smart contracts on the Ethereum platform were proposed. The framework also uses the elliptic curve digital signature algorithm (ECDSA) for secure transactions and Keccak-256 hashing for data integrity, thus collectively enhancing data privacy [23]. Nevertheless, the architecture necessitated substantial computing resources for transaction validation and smart contract execution, posed possible scalability issues, and relied on uninterrupted network connection for real-time access control.

In a nutshell, the analysed papers illustrate several blockchain-based methodologies for improving security, privacy, and data management in e-health systems. Notwithstanding their contributions, persistent challenges such as increased computing expenses, scalability constraints, and latency problems underscore the need for more study and optimisation of these frameworks to fully harness their potential in safe e-health settings.

Table 1. Summary of the related works.

Approach	Techniques Used	Challenges Identified	References
Decentralised Authentication Protocols	PBFT consensus, Elliptic Curve Cryptography (ECC)	High computational costs, synchronisation challenges between on-chain and off-chain storage	[6]
Privacy-Preserving Control Mechanisms	K-means clustering, Geometric Data Perturbation (GDP), ECC	High computational overhead, scalability issues in IoT environments	[8]
Blockchain-Assisted Secure Data Sharing	Searchable Attribute-Based Encryption (SABE), blockchain for decentralised access management	High computational overhead during decryption, latency from blockchain consensus mechanisms	[9]
Privacy-Preserving EHR Management	Pairing-based cryptography, secure key exchange protocols	High computational costs, potential delays due to consensus mechanisms	[11]
Biometric Authentication Protocols (PPBA)	Zero-Knowledge Proofs (ZKP), privacy coins, blockchain	High transaction fees, potential vulnerabilities	[12]
Blockchain-Enabled IoMT Security Systems	Smart contracts, decentralised storage	High computational costs, synchronisation challenges	[15]
Access Control and Key Management Protocols	ECC, smart contracts	Real-time processing delays, computational overhead	[16]
Provenance-Aware Blockchain Systems	Directed Acyclic Graph (DAG) structures	High computational costs, latency in auditing processes	[17]
AI-Based Secure Data Dissemination	Deep learning techniques combined with blockchain	High computational cost and latency, scalability issues, synchronisation issues	[20]
Smart Contract-Enabled EHR Sharing Frameworks	Blockchain, smart contracts	Computational overhead, scalability concerns	[21]
Hybrid Blockchain Models	Private and consortium blockchains, optimised encryption techniques	Latency, scalability challenges	[22]
Multi-Level Security Frameworks	Lattice-Based Access Control (LBAC), blockchain smart contracts	High computational resources required	[23]
Blockchain-Assisted Authentication Frameworks	Multi-Factor Authentication (MFA), smart contracts	Computational costs, scalability limitations	[18]
User Authentication Schemes	Modified RSA encryption, blockchain	High computational overhead, latency issues	[19]
Common Challenges Across Approaches	Various cryptographic and blockchain-based techniques	High computational costs, scalability limitations, latency issues	[6,8,9,11,12,15,16,17,18,19,20,21,22,23]

provides an overview of the relevant papers based on their approach, techniques used and challenges identified.

3. System Model

Leveraging the Ethereum blockchain, smart contracts, blind signatures, PoA consensus, and one-way hash functions, the system model offers strong security, privacy, and regulatory standard compliance. The approach guarantees that different users—doctors, labs, IoMT devices, and third-party companies—may securely identify themselves while preserving patient privacy and controlling access to sensitive health data, as shown in Figure 1.

The system model has the following parts:

• User Layer:
  • Patients: Create original, anonymised passwords for data access requests and authentication. Their identities are kept private by the use of blind signatures, thus shielding them.
  • Doctors, Laboratories, IoMT Devices, Third-Party Users: Generate their own unique identifiers and employ the same blind signature procedure to authenticate themselves with the e-health system.
  • Admin: This is a trusted entity that operates on the Ethereum blockchain and requests a blind signature. This includes such as a healthcare provider, a certifying authority, or a regulatory body. The blinding aspect causes the administrator to be unaware of the specific component of the unique identities.
• Authentication Layer:
  • Blind Signatures: Is used to provide a privacy-preserving authentication procedure. Each user will anonymise their identity prior to submitting it to the admin for endorsement. The signed message is then unblinded and sent to the Ethereum smart contract for verification.
  • Smart Contract-Based Authentication: Is implemented in the Ethereum blockchain. It can be used to check the validity of the signatures of the users using the admin public key. Only authenticated users can proceed to request access to patient data.
• Access Control Layer:
  • AccessControlContract: Is the smart contract controlling access in line with set rules. It generates access tokens using lightweight cryptographic methods like SHA-256 and then checks permissions to let users access data securely.
  • Proof of Authority (PoA): Guarantees that only the admin node validates and confirms transactions on the Ethereum blockchain. This consensus technique minimises computing expenses and improves scalability.
• Blockchain Layer
  • Ethereum Blockchain: Functions as a decentralised ledger that permanently documents all authentication events, access requests, and authorised permissions. Only hashed values and limited information are retained on-chain to safeguard privacy.
  • Transaction Logging: This records access requests, permissions, and token issuance in an auditable and immutable manner.
• Data Storage Layer:
  • Off-Chain Storage (e.g., IPFS): It securely stores real patient data, including electronic health records (EHRs), off-chain to reduce blockchain storage demands and adhere to data privacy standards. On-chain storage contains hash references that reference off-chain data. This layer’s application is beyond the purview of this research.
• Healthcare Application Layer:
  • E-Health Applications: This combines with the levels of authentication and access control to provide a safe interface for many stakeholders—doctors, laboratories, patients—to access or modify health data.

Adversary Model

In this study, the adversaries are considered to possess the following characteristics and capabilities:

• External Adversaries: Attempt to obtain unauthorised access to the e-health system by exploiting weaknesses in authentication protocols or intercepting communications. They may execute attacks such as man-in-the-middle (MITM), replay attacks, phishing, or Denial-of-Service (DoS) attacks in order to compromise the system or acquire credentials.
• Insider Adversaries: Authorised users, including healthcare professionals or administrators, may use their lawful access privileges to alter patient data, manipulate smart contracts, or execute unauthorised transactions. Malicious insiders, who deliberately exploit their access, and inquisitive insiders, who inadvertently jeopardise security via carelessness, are both seen as threats.
• Smart Contract Exploiters: Adversaries seeking to exploit vulnerabilities in smart contracts implemented on the Ethereum platform. Potential vulnerabilities include re-entrancy attacks (where attackers repeatedly activate routines), integer overflow/underflow attacks, and other code deficiencies that may modify authentication or access control protocols.
• Data Privacy Adversaries: Aim to undermine patient privacy by linking publicly accessible blockchain data with external information or trying to deanonymise anonymised data. They may evaluate trends in transactional data or attempt to deanonymise obscured identifiers.
• Regulatory Compliance Adversaries: Leverage discrepancies between blockchain immutability and regulatory requirements (e.g., GDPR’s “right to be forgotten”). The system mitigates these issues by retaining just hashes and minimum metadata on-chain, while sensitive information is stored off-chain using adaptable compliance alternatives.

In summary, the study categorises adversaries into five primary types: external adversaries, insider threats, smart contract exploiters, data privacy attackers, and regulatory compliance adversaries. These threats underscore weaknesses in authentication, data integrity, and privacy. Addressing these factors facilitates the implementation of robust cryptographic mechanisms, thereby improving system security and ensuring compliance.

4. Proposed Model

This section presents a proposed method for privacy-preserving authentication and access control for e-health users, including physicians, labs, IoMT devices, and third-party organisations, as seen in Figure 1. The architecture consists of multiple layers, including the User Layer (patients, doctors, labs, IoMT devices, and third parties), Authentication Layer (blind signatures and smart contract-based authentication), Access Control Layer (smart contracts and Proof of Authority consensus), Blockchain Layer (Ethereum blockchain storing hashed identifiers), and Data Storage Layer (off-chain storage for EHRs using IPFS). The diagram highlights the interaction between entities, showcasing the secure authentication process and decentralised access control enforcement. The system uses the Ethereum blockchain, smart contracts, blind signatures, Proof of Authority consensus, and one-way hash functions to guarantee safe and efficient operations. The model comprises three principal components: a privacy-preserving authentication system for e-health users with Enhanced Patient Privacy, Secure and Lightweight Access Control through smart contracts, and Secure Access Execution for e-health data. Each will be elaborated upon in the following subsections.

4.1. Privacy-Preserving Authentication System for E-Health Users with Enhanced Patient Privacy

This section delineates the proposed model for a privacy-preserving authentication system tailored for e-health users, encompassing healthcare professionals, laboratories, Internet of Medical Things (IoMT) devices (such as medical sensors and monitors), and third-party entities (including insurance companies and research institutions) while prioritising augmented privacy for patients. The system utilises the Ethereum blockchain, smart contracts, blind signatures, the PoA consensus process, and one-way hash functions to provide safe, efficient, and privacy-preserving authentication. The technique addresses regulatory compliance concerns by protecting patient identities and reducing data exposure.

Step-by-Step Methodology Flow

• Registration Phase
  Step 1.1: Patient Generates Unique Identifier and Blinding Factor: At the beginning, the patient generates a unique identifier $M_p$ (such as a pseudonymous patient ID) that will be used for authentication and data access requests. To ensure privacy, the patient applies a random blinding factor r to their identifier, creating a blinded message ${M_p}^{\prime }$:

  $${M_p}^{\prime }=M_p·r\left(modn\right)$$

  where n is a modulus agreed upon with the admin. This blinded message ensures that the patient’s actual identity remains concealed.
  Step 1.2: Submission of Blinded Message for Signing: Then, the patient submits the blinded message ${M_p}^{\prime }$ to the admin operating on the Ethereum blockchain, requesting a blind signature. The admin does not know the actual content of $M_p$ due to the blinding factor.
  Step 1.3: Blind Signing by the Admin: Then, the admin, which is a trusted node on the Ethereum blockchain (using the PoA consensus), signs the blinded message using its private key d:

  $$S\left({M_p}^{\prime }\right)={\left({M_p}^{\prime }\right)}^d\left(modn\right)$$
  The signed blinded message $S\left({M_p}^{\prime }\right)$ is returned to the patient.
  Step 1.4: Patient Unblinds the Signature: The patient then unblinds the signature to obtain a valid signature on their original identifier $M_p$:

  $$S\left(M_p\right)=S\left({M_p}^{\prime }\right)·r^{-1}\left(modn\right)$$

  where $r^{-1}$ is the modular multiplicative inverse of r. With this, the patient now holds a valid signature that proves their identity without revealing any personal information.
• Authentication Phase for E-Health Users
  Step 2.1: User-Specific Unique Identifier Generation: Here, each user type (e.g., doctors, laboratories, IoMT devices, and third-party entities) generates its own unique identifier $M_u$ and applies a blinding factor $r_u$ to create a blinded message ${M_u}^{\prime }$:

  $${M_u}^{\prime }=M_u·r_u\left(modn\right)$$

  where n is a common modulus for the system.
  Step 2.2: Authentication Request Submission: When a user needs to access patient data or interact with the e-health system, they send their blinded identifier ${M_u}^{\prime }$ to the admin for signing, similar to the patient registration process. Then, the admin signs the blinded identifier and returns the signed blinded message $S\left({M_u}^{\prime }\right)$ to the user.
  Step 2.3: Unblinding and Verification: On reception, the user then unblinds the signed message:

  $$S\left(M_u\right)=S\left({M_u}^{\prime }\right)·{r_u}^{-1}\left(modn\right)$$
  This signed identifier $\left(M_u\right)$ is then sent to the smart contract on the Ethereum blockchain for verification alongside the user’s unique identifier $M_u$.
• Patient Privacy-Preserving Authentication and Data Access
  Step 3.1: Privacy-Preserving Authentication by the Smart Contract: On reception, the smart contract will then verify the signatures $S\left(M_p\right)$ and $S\left(M_u\right)$ of both patients and other users (e.g., doctors and labs) against the admin’s public key e:

  $$M_p\equiv {\left(S\left(M_p\right)\right)}^e\left(modn\right)$$

  $$M_u\equiv {\left(S\left(M_u\right)\right)}^e\left(modn\right)$$
  If both signatures are valid, the smart contract confirms that both the patient and the user have been authenticated without revealing their identities.
  Step 3.2: One-Way Hash Function for Data Integrity: A one-way hash $H\left(M_p\right)$ of the patient’s identifier and a hash $H\left(M_u\right)$ of the user’s identifier are computed:

  $$H\left(M_p\right)=SHA\_256\left(M_p\right)$$

  $$H\left(M_u\right)=SHA\_256\left(M_u\right)$$
  These hashes are recorded on the blockchain to ensure data integrity and serve as a verifiable proof of successful authentication while protecting patient privacy.

4.2. Secure and Lightweight Access Control via Smart Contracts in an E-Health System

This section demonstrates the safe and efficient access control method for an e-health system using smart contracts on the Ethereum blockchain. The system employs cryptographic methods like blind signatures, one-way hash functions, and smart contracts, adhering to the PoA consensus to provide a scalable and efficient approach for controlling access to sensitive health data while ensuring patient privacy and regulatory compliance.

Step-by-Step Methodology for Access Control

• Registration Phase
  Step 1.1: Initialisation of Smart Contracts for Access Control: Initially, the admin deploys a smart contract on the Ethereum blockchain to handle access control. This smart contract, referred here to as the AccessControlContract, maintains a list of authorised entities (doctors, labs, IoMT devices, and third-party users) and their respective permissions. Each entity is associated with a unique hashed identifier $H\left(M_u\right)$ and a corresponding set of access rights.
  Step 1.2: Define Access Policies: The smart contract contains predefined access policies based on user roles and access levels (e.g., read, write, and modify). For example:
  • Doctors: Read and write access to patient records.
  • Laboratories: Write access for uploading test results, read access to relevant records.
  • IoMT Devices: Write access for data transmission.
  • Third-party Users (e.g., insurers): Limited read access with explicit patient consent.
  Step 1.3: Secure Storage of Access Data: In this work, the AccessControlContract stores only minimal metadata and hashed identifiers on-chain. While the actual patient data remain off-chain in secure, decentralised storage solutions (IPFS). The smart contract includes a reference to the off-chain storage location, represented as a hash pointer.
• Access Request Phase
  Step 2.1: Secure Storage of Access Data: In this phase, a user (e.g., a doctor) who wishes to access patient data first authenticates using the previously described blind signature process. Upon successful authentication, the user sends an access request to the AccessControlContract, including their unique identifier $M_u$, the patient’s anonymised identifier $M_p$, and the requested access type (e.g., read and write).
  Step 2.2: Compute and Verify Hashes: Upon receiving the request, the smart contract computes the one-way hash values for both the user’s identifier and the patient’s identifier to confirm their validity:

  $$H\left(M_p\right)=SHA\_256\left(M_p\right)$$

  $$H\left(M_u\right)=SHA\_256\left(M_u\right)$$
  These hashes are compared against the records stored on-chain to ensure the identifiers correspond to valid, authenticated entities.
• Lightweight Access Control Enforcement
  Step 3.1: Verify User Permissions: Here, the smart contract checks the user’s permissions against the predefined access control policies. If the user $H\left(M_u\right)$ has the required access rights for the requested operation (e.g., a doctor requesting read access to a patient’s EHR), the smart contract proceeds to the next step.
  Step 3.2: Verify User Permissions: Upon successful verification of permissions, the smart contract generates a secure access token T using a lightweight cryptographic hash function:

  $$T=SHA\_256(H\left(M_u\right)\Vert H\left(M_p\right)\Vert Timestamp\Vert Nonce)$$

  where
  • $Timestamp$ is the current time, ensuring token validity is time-bound.
  • $Nonce$ is a random value to prevent token replay attacks.
  The access token T is time-limited and unique to prevent unauthorised reuse.
  Step 3.3: Store Access Record on the Blockchain: Then, the smart contract logs the access request, the type of access granted, and the expiration time of the access token on the blockchain, ensuring an immutable record for auditing purposes. The log entry includes the following:

  $$Log=H\left(M_u\right),H\left(M_p\right),Access\_Type,Expiratio{n}_{Time},T$$

4.3. Secure Access Execution for E-Health Data

This section defines the Access Execution phase within an e-health system using the Ethereum blockchain, smart contracts, access tokens, and one-way hash functions. During this phase, authorised users (e.g., doctors, labs, IoMT devices, or third-party users) submit their access tokens to securely view or modify patient data kept off-chain in a decentralised storage system, such as IPFS (InterPlanetary File System).

The objective is to guarantee that only authorised individuals may access confidential patient information while preserving privacy and data integrity. The system employs cryptographic methods to authenticate access requests and guarantee safe data retrieval.

Step-by-Step Methodology for Access Execution

• Access Token Presentation to Off-Chain Storage
  Step 1.1: Requesting Data from Off-Chain Storage: Here, the user presents the access token T to the off-chain storage system to retrieve or modify the requested patient data. The data are stored off-chain for scalability and efficiency, but only hash pointers (links to the actual data) are recorded on the blockchain.
  The request includes the following:
  • The access token T;
  • The user identifier $M_u$;
  • The patient identifier $M_p$;
  • The data request (e.g., retrieve EHRs and modify test results).
  Step 1.2: Data Integrity Verification via Hashes:
  • Upon receiving the request, the off-chain storage system verifies the validity of the access token by recalculating the hash:

    $$T^{\prime }=SHA\_256(H\left(M_u\right)\Vert H\left(M_p\right)\Vert Timestamp\Vert Nonce)$$
  • If $T^{\prime }$ matches the presented access token T, the token is considered valid, and the request is granted. This ensures that only authorised users with the correct token can access the data.
  Step 1.3: Data Integrity Verification via Hashes:
  • In this system, the system will now check the timestamp to ensure the token is still within its valid time period. If the token has expired, the request is denied.
  • The system also verifies the nonce to ensure that the token is unique and has not been reused in a replay attack. If the nonce is valid, the request proceeds.
• Secure Data Access and Retrieval
  Step 2.1: Granting Access to Data:
  • If the access token T is valid and all conditions (timestamp, nonce, and permissions) are met, the off-chain storage system grants access to the requested data.
  • The data (e.g., a patient’s electronic health record or lab results) are then retrieved and securely transmitted to the authorised user.
  Step 2.2: Data Integrity Check:
  • The retrieved data include a hash value that was stored on-chain at the time of data creation or modification. The user can verify the data’s integrity by recalculating the hash:

    $$H\left(Data\right)=SHA\_256\left(Data\right)$$
  • The recalculated hash is compared with the hash stored on-chain. If the hashes match, the data are confirmed to be unaltered and authentic.
• Logging and Auditing
  Step 3.1: Logging the Data Access Event:
  • Once the data are retrieved or modified, the access event is logged on the blockchain, recording details such as the user identifier $H\left(M_u\right)$, patient identifier $H\left(M_p\right)$, access token T, and the type of data operation (read, write, modify).
    The log entry on the blockchain contains the following:

    $$Log=H\left(M_u\right),H\left(M_p\right),Access\_Type,Timestamp,T$$
    This log provides an immutable and auditable trail of all access attempts, ensuring transparency and accountability.
  Step 3.2: Audit and Compliance:
  • Admin can audit the access logs on the Ethereum blockchain to verify that only authorised users have accessed patient data and that no unauthorised modifications were made.
  • The system’s use of hashed identifiers and access tokens ensures that patient privacy is preserved during audits, in compliance with regulations such as GDPR and HIPAA.
• Handling Invalid or Expired Tokens
  Step 4.1: Token Expiry:
  • If the access token’s timestamp indicates that it has expired, the off-chain storage system denies the request and logs the failed attempt on the blockchain. The user must re-authenticate and obtain a new token from the smart contract.
  Step 4.2: Invalid Token or Replay Attack:
  • If the access token T does not match the recalculated hash $T^{\prime }$, or if the nonce has already been used, the off-chain storage system denies the request and logs the suspicious attempt.
  • This ensures the system remains resilient to replay attacks and other token forgery attempts.
  In summary, the proposed blockchain-based authentication and access control solution improves patient privacy and guarantees regulatory compliance via the utilisation of blind signatures, the Ethereum blockchain, smart contracts, Proof of Authority, and one-way hash functions. This system offers resilient, scalable, and privacy-preserving authentication for diverse e-health users, including doctors, labs, IoMT devices, and third-party entities. The system utilises time-bound access tokens and streamlined access control methods to provide efficient and secure data access while preserving the integrity, transparency, and availability of critical health information. Algorithm 1 highlights the comprehensive technique, including privacy-preserving authentication, Secure Access Control, and Secure Access Execution for e-health systems.

Algorithm 1: Complete Methodology
1	Start
2	// Privacy-Preserving Authentication for E-Health Users
3	For each user (Patient, Doctor, Laboratory, IoMT Device, or Third Party): a. Generate a unique identifier $M_u$ b. Generate a random blinding factor $r_u$ c. Create a blinded identifier: $M_u^{\prime }=M_u\ast r_u\left(modn\right)$ d. Submit the blinded identifier $M_u^{\prime }$ to the admin (PoA node) for blind signing
4	// Blind Signing by the Admin
5	Admin signs the blinded message: $S\left(M_u^{\prime }\right)={\left(M_u^{\prime }\right)}^d\left(modn\right)$
6	Admin returns the signed blinded message $S\left(M_u^{\prime }\right)$ to the user
7	// Unblinding the Signature
8	User unblinds the signature: $S\left(M_u\right)=S\left(M_u^{\prime }\right)\ast r_u^{-1}\left(modn\right)$
9	User submits $(M_u,S\left(M_u\right))$ to the smart contract for verification
10	// Smart Contract Verification
11	Smart contract verifies the signature: a. If $M_u\equiv {\left(S\left(M_u\right)\right)}^e\left(modn\right)$: i. Authentication successful b. Else: i. Authentication fails, reject request
12	// Secure and Lightweight Access Control via Smart Contracts
13	If authentication is successful, user sends an access request to the
	AccessControlContract: a. Include user identifier $M_u$, patient identifier $M_p$, and requested access type
14	Smart contract computes hash values: a. $H\left(M_u\right)=SHA\_256\left(M_u\right)$ b. $H\left(M_p\right)=SHA\_256\left(M_p\right)$ c. Compare with stored records to ensure validity
15	Smart contract verifies user permissions: a. If valid, generate access token: i. $T=SHA\_256\left(H\left(M_u\right)\right|\left|H\left(M_p\right)\right|\left|Timestamp\right|\left|Nonce\right)$ b. Else, deny access and log attempt
16	Log the access request on the blockchain with: a. User identifier $H\left(M_u\right)$, patient identifier $H\left(M_p\right)$, access type, expiration time, and access token T
17	// Secure Access Execution for E-Health Data
18	User presents the access token T to the off-chain storage system to retrieve or modify patient data
19	Off-chain storage system verifies the token by recalculating: a. $T^{\prime }=SHA-256(H\left(M_u\right)\left|\right|H\left(M_p\right)\left|\right|Timestamp\left|\right|Nonce)$ b. If $T^{\prime }=T$, the token is valid, proceed with request
20	Validate the token’s timestamp and nonce to prevent replay attacks and ensure token freshness: a. If valid, grant access to data b. Else, deny access and log the attempt
21	User retrieves or modifies patient data: a. Verify data integrity using the on-chain hash: i. H(Data) = SHA_256(Data) ii. Compare with the stored hash value to confirm authenticity
22	Logging and Auditing
23	Log the access event on the blockchain: a. User identifier H(M_u), patient identifier H(M_p), access token T, access type, and timestamp
24	Admin or auditors can audit the blockchain logs to verify: a. Compliance with access policies b. Regulatory compliance (e.g., GDPR, HIPAA)
25	End

5. Security Analysis of the Proposed Model

The Real-Or-Random (ROR) model is used to evaluate the security of the proposed blockchain-based authentication and access control framework for e-health. This model is often used to assess the security attributes of authentication systems, especially in contexts where attackers want to differentiate between a genuine and a random session key [24,25]. The ROR model offers a systematic method to demonstrate the security of an authentication mechanism against diverse attack vectors [26].

The proposed model aims to achieve the following security goals:

• Privacy-Preserving Authentication: Ensure that users (e.g., doctors, laboratories, IoMT devices, and third parties) can authenticate themselves without revealing their real identities or sensitive information.
• Data Integrity: Ensure that data remain unchanged during transmission and storage, maintaining its integrity.
• Access Control: Ensure that only authorised entities can access or modify sensitive health data.
• Confidentiality: Protect sensitive health information from unauthorised access.
• Anonymity: Ensure that patient identities remain anonymous and protected against unauthorised deanonymisation attacks.
• Resistance to Replay Attacks: Prevent adversaries from reusing previously intercepted messages to impersonate legitimate users.
• Resistance to Insider Attacks: Prevent trusted users or nodes from misusing their access privileges to tamper with data or perform unauthorised actions.

5.1. Security Analysis Using the Real-Or-Random (ROR) Model

The ROR model evaluates an adversary’s ability to differentiate between an authentic protocol session and a random session [27]. The model’s security is assessed by the adversary’s ability to differentiate between these two circumstances [28]. This study will conduct an ROR analysis with many phases in order to assess its resilience against several attack vectors, including replay attacks, man-in-the-middle (MITM) attacks, and insider threats.

5.1.1. ROR Analysis Framework and Setup

Step 1.1: Logging the Data Access Event: In the ROR model, a security game is defined between an adversary A and a challenger X, representing the proposed model. The security game consists of the following steps:

• The challenger C sets up the system parameters, including the public and private keys for blind signatures, and initializes the smart contract on the Ethereum blockchain.
• The adversary A is allowed to interact with the system and make various queries such as the following:
  • Authentication Queries: To test the authenticity of different users (doctors, labs, devices, third parties).
  • Access Control Queries: To attempt to access specific data or resources.
  • Challenge Queries: To challenge the system and receive a token that could either be real or random.
• The adversary A tries to distinguish whether the token received is from a real session or a random one.

Step 1.2: Logging the Data Access Event:

• Real World: In the real-world scenario, it is presumed that the system operates normally, generating valid access tokens using the following formula:

  $$T=SHA\_256(H\left(M_u\right)\Vert H\left(M_p\right)\Vert Timestamp\Vert Nonce)$$
• Random World: In the random-world scenario, it is presumed that the system generates a completely random token $T^{\ast }$ that does not correspond to any valid access control logic.

5.1.2. Detailed Steps and Mathematics for the ROR Analysis

Step 2.1: Resistance to Replay Attacks:

• Goal: Is to ensure that the adversary A cannot use a previously intercepted access token to gain unauthorised access.
• Proof:
  • Assuming that the adversary intercepts a valid access token T during a legitimate session.
  • The token T is given by the following:

    $$T=SHA\_256(H\left(M_u\right)\Vert H\left(M_p\right)\Vert Timestamp\Vert Nonce)$$
  • If A reuses T in a different session, the following would occur:

    -

    The $Timestamp$ will differ, making the new token $T^{\prime }\ne T$.

    -

    The $Nonce$ ensures that even if all other values are the same, $T^{\prime }\ne T$.

ROR Analysis: In the security game, A cannot distinguish whether they are receiving a real token or a random one because of the following:

• The hash function $SHA256$ is collision-resistant.
• Any change in the input (Timestamp or Nonce) results in a completely different output, ensuring that replaying T fails with overwhelming probability.

Result: The model is secure against replay attacks in the ROR game as A cannot reuse a valid token or distinguish it from a random token.

Step 2.2: Resistance to Man-in-the-Middle (MITM) Attacks:

• Goal: Is to ensure that an adversary A cannot intercept or alter messages between users and the e-health system to impersonate legitimate users.
• Proof:
  • In an MITM attack, we assume that A intercepts communication between a user and the smart contract on the blockchain.
  • The user submits the blinded identifier ${M_u}^{\prime }=M_u·r_u\left(modn\right)$ for signing.
  • The admin signs the blinded identifier: $\left({M_u}^{\prime }\right)={\left({M_u}^{\prime }\right)}^d\left(modn\right)$ and returns it to the user.
  • The adversary cannot modify ${M_u}^{\prime }$ without invalidating the blind signature, as any alteration would require knowledge of $r_u$, which is unknown to A.
  • If A tries to forge a signature $S\left({M_u}^{\prime }\right)$, it would require solving the discrete logarithm problem or breaking the RSA assumption, both of which are computationally infeasible.

ROR Analysis: In the security game, A cannot distinguish whether they are interacting with a real session or a random session because of the following:

• Any tampering with ${M_u}^{\prime }$ or the signature $S\left({M_u}^{\prime }\right)$ will be detected by the smart contract’s verification checks.
• Blind signatures ensure that only valid messages are accepted, and any modification will be rejected.

Result: The model is secure against MITM attacks in the ROR game, as A cannot forge or modify valid messages.

Step 2.3: Anonymity and Privacy Preservation:

• Goal: Is to ensure that an adversary A cannot deanonymise patient identities or link their actions to specific individuals.
• Proof:
  • User identifiers $M_u$ and patient identifiers $M_p$ are blinded before submission and signed using blind signatures.
  • Only the blinded messages ${M_u}^{\prime }$ and ${M_p}^{\prime }$ are submitted to the admin, ensuring the admin does not know the original identifiers.
  • On the blockchain, only hashed values $H\left(M_u\right)$ and $H\left(M_p\right)$ are stored:

    $$H\left(M_u\right)=SHA\_256\left(M_u\right)$$

    $$H\left(M_p\right)=SHA\_256\left(M_p\right)$$
  • The hash function $SHA256$ is pre-image resistant, meaning A cannot find the original identifier from the hash.

ROR Analysis: In the security game, the adversary cannot distinguish a real session from a random session because of the following:

• The blinded identifiers and hash values do not reveal any identifiable information.
• The adversary cannot link the hashed identifiers to specific users or patients.

Result: The model preserves anonymity and privacy in the ROR game as A cannot deanonymise or identify users.

Step 2.4: Resistance to Insider Attacks:

• Goal: Is to ensure that trusted insiders cannot misuse their access privileges to perform unauthorised actions or tamper with data.
• Proof:
  • The system uses the PoA consensus mechanism, which requires less computational power compared to Proof of Work (PoW), reducing vulnerability to DoS attacks.
  • The smart contracts implement rate-limiting to prevent excessive requests from a single user.

Result: The model is secure against DoS attacks in the ROR game, as A cannot exhaust system resources or disrupt service availability.

In conclusion, the comprehensive procedures and proofs show that the proposed model is safe within the ROR framework against several attack vectors, including replay attacks, MITM attacks, insider threats, DoS attacks, and efforts to compromise privacy and anonymity. The integration of cryptographic methods, including blind signatures, one-way hash functions, and smart contracts on the Ethereum blockchain, establishes a secure and privacy-enhancing authentication and access control framework for e-health systems.

5.2. Security Goals and Their Implementation in the Proposed Model

The proposed model’s security mechanisms improve privacy protection by facilitating user authentication without disclosing identities, ensuring data integrity via hash-based verification, and implementing stringent access control through role-based and attribute-based policies. Furthermore, it addresses prevalent attack vectors, including replay and insider attacks, through the implementation of nonces, Proof of Authority consensus, and immutable access logs. The security enhancements render the model robust and appropriate for deployment in real-world e-health environments, ensuring adherence to privacy regulations such as GDPR. The following

Table 2. Security goals and their implementation in the proposed model.

Security Goal 7	How It Is Achieved in the Proposed Model
Privacy-Preserving	Utilizes blind signatures to ensure that users authenticate without revealing their real identities.
Authentication	Hash-based pseudonymous identifiers prevent unauthorised user tracking.
Data Integrity	One-way hash functions (SHA-256) ensure that data remain immutable during transmission and storage. Any modification results in a verifiable hash mismatch.
Access Control	Smart contracts enforce role-based and attribute-based access control (RBAC/ABAC), ensuring only authorised entities can access or modify sensitive health data.
Confidentiality	End-to-end encryption ensures that sensitive health information remains protected from unauthorised access. Only encrypted references (hash pointers) are stored on-chain.
Anonymity	Patient data are stored off-chain, with only hashed identifiers referenced on the blockchain, ensuring that patient identities remain anonymous.
Resistance to Replay Attacks	Time-based nonces and PoA consensus ensure that authentication tokens are unique and cannot be reused, preventing replay attacks.
Resistance to Insider Attacks	Decentralised transaction logging prevents unauthorised modifications by insiders, ensuring auditability. Access logs are immutable and verifiable via blockchain.

provides an overview of the essential security objectives achieved in the proposed model.

6. Performance Evaluation

This section provides an overview of the simulation configuration and a careful analysis of the performance of the proposed model with respect to two current benchmark models: Haritha et al. [23] and Kumar et al. [18]. The benchmark models were chosen for their relevance in systems of blockchain-based authentication. Both techniques use advanced cryptographic techniques and consensus processes meant to increase security and efficiency in distributed networks. These features make them suitable benchmarks for assessing the efficiency, scalability, and real-time capacity of the proposed model within a comparable technological context.

6.1. Simulation Setup

To evaluate the proposed access control system and privacy-preserving authentication for e-health users, a complete simulation environment was developed. Important components such as the Ethereum blockchain, smart contracts, blind signatures, the PoA consensus approach, and one-way hash functions are included in the concept.

For back-end operations, including signature generation and verification, as well as Solidity for smart contract deployment, the simulation used Python (https://www.python.org/). The blockchain was interacted with using Web3.py; the Remix IDE allowed smart contract testing. Using the Oyente tool [29], the security of the smart contract was assessed and found to have $86\%$ coverage of the EVM code, therefore verifying the absence of typical security issues such re-entrancy and transaction dependence.

Using the Thread PoolExecutor library to imitate real-world events, the system tested with 100 concurrent user authentications. Every user generates unique identities, uses blinding, and interacts with the blockchain for signature confirmation. To emulate real-world operational dynamics, intentional insertion of successful and failed authentications was used.

To assess the performance of the proposed model, the following metrics were measured:

• Accuracy, Precision, and Recall: They are used to evaluate the system’s ability to correctly authenticate users.
• Average Memory Usage: It is used to measure memory overhead during operations.
• Average Authentication Latency: It is used to capture the time taken for user authentication.
• Signature Verification Time: It is the time required to verify blind signatures.
• Throughput: It is the transactions per second to assess scalability.

6.2. Authentication Latency Analysis

Authentication latency quantifies the duration needed to verify and authorise users, an important factor in real-time e-health settings. Figure 2 (left graph) indicates that the proposed model attains an average authentication latency of 0.059 milliseconds, markedly surpassing the performance of Kumar et al. (256.47 ms) and Haritha et al. 152.54 ms. This enhancement, exceeding 4000 times the speed of Kumar et al. and over 2500 times that of Haritha et al., highlights the model’s appropriateness for e-health settings where rapid and safe authentication is essential.

The improved efficiency arises from critical optimisations in the proposed model. The model uses PoA as its consensus mechanism, therefore limiting communication to a trusted subset of nodes and so lowering validation time and avoiding the latency problems connected with Kumar et al.’s PBFT approach. Unlike more complex cryptographic procedures of other models, the model minimises computation needs by using lightweight cryptographic functions such as one-way hash functions and blind signatures, therefore balancing security with speed.

Decentralised verification using Ethereum-based smart contracts enhances authentication efficiency. The solution utilises blockchain for event recording and employs smart contracts for access regulation, hence removing the need for central verification authority and facilitating rapid and dependable verification in decentralised e-health environments where data privacy is paramount. To minimise latency, the model uses off-chain storage (IPFS) for primary data, referencing only critical information on-chain, in contrast to Kumar et al.’s direct on-chain data method, which results in increased delay.

6.3. Average Memory Utilisation Analysis

The evaluation of average memory usage (in MB) reveals a significant advantage of the proposed model compared to the existing benchmark models by Kumar et al. and Haritha et al. Figure 2 (right graph) illustrates the memory utilisation for each model. The proposed model has a consumption of only 0.0198 MB, which is significantly lower than that of Kumar et al. (96.98 MB) and Haritha et al. (119.27 MB). This signifies a 4000-fold and 6000-fold reduction in memory utilisation, which highlights the superior efficiency of the proposed approach. Previous approaches require solving the discrete logarithm problem or breaking the RSA assumption, both of which are computationally infeasible.

The memory efficiency of the proposed method stems from a combination of lightweight cryptographic functions, data minimisation, and a modular architecture that assigns non-essential actions to separate components. The technique reduces memory demands for complex cryptographic operations by using compact one-way hash functions and blind signatures. Data minimisation techniques enhance memory efficiency by preserving just essential information on-chain, while more comprehensive data are stored off-chain. The PoA consensus mechanism reduces memory use by limiting the number of participating nodes, unlike more resource-demanding options. Smart contracts decentralise verification and reduce data storage, while the model’s modular design enables precise memory allocation for each function. These techniques together provide a memory-efficient solution appropriate for real-time e-health applications.

The memory economy is crucial in e-health environments, where resource constraints and the need for fast processing make lightweight models especially beneficial. The proposed model’s reduced memory use enhances system performance and complies with scalability and resource optimisation principles, making it an ideal option for real-time applications in healthcare settings.

6.4. Signature Verification Time Analysis

The duration of signature verification is a critical element in evaluating the efficiency of blockchain-based authentication systems. Efficient signature verification is crucial for maintaining low-latency authentication processes. In time-sensitive applications such as e-health, where fast data access is critical, minimising verification delays is vital. Figure 3 (left graph) demonstrates that the proposed model achieves an average signature verification time of 0.00092 milliseconds, which is nearly 50,000 times faster than Kumar et al. (46.16 ms) and Haritha et al. (50.01 ms).

The main cause of this enhancement is the proposed model’s use of lightweight cryptographic functions, including one-way hash functions and efficient signature techniques such as blind signatures, which reduce computational complexity. In contrast to Kumar et al. and Haritha et al., which may use more resource-demanding cryptographic techniques, the proposed model’s efficient methodology guarantees expedited signature validation. The reduced verification time advantages healthcare environments by facilitating real-time processing, which is essential for situations such as patient data retrieval and secure communication across healthcare organisations.

The proposed model demonstrates the capability to manage many verification requests without system overload, making it suitable for high-transaction situations. The extended verification durations in the models of Kumar et al. and Haritha et al. can result in delays that impact total throughput, especially in settings characterised by the continuous processing of substantial transaction quantities. The verification efficiency of the proposed approach meets the twin requirements of speed and scalability in blockchain-based healthcare applications.

6.5. Throughput Analysis

Throughput, quantified as transactions per second (TPS), reflects a blockchain model’s capacity to manage simultaneous transactions efficiently. Figure 3 (right graph) indicates that the proposed model achieves 43.01 TPS, closely aligning with Kumar et al. 56.61 TPS while ensuring stable transaction rates under peak loads. Although Haritha et al. achieve a higher throughput of 298.23 TPS, its elevated processing power requirements and transaction validation delays make it less suitable for privacy-focused healthcare systems. Thus, elevated throughput levels may not be as essential in healthcare, where stability and precision sometimes take precedence over maximum transaction speeds.

The proposed model’s modest throughput is beneficial in healthcare settings as it mitigates the danger of network congestion, ensuring stable transaction rates even during peak times. The model attains this by harmonising processing speed with transaction flow regulation, minimising the probability of bottlenecks and guaranteeing seamless system functionality. This factor is especially significant in contexts where transaction integrity and patient confidentiality are paramount since overly elevated throughput rates can, at times, jeopardise data security for the sake of expediency.

In contrast to Kumar et al.’s approach, which provides marginally superior throughput, the proposed model guarantees reliable transaction management without exerting extra resource pressure. The design decision demonstrates an awareness that healthcare systems value stability and dependability more than maximum throughput. Conversely, the elevated throughput in Haritha et al.’s model, while commendable, may result in augmented gas consumption and, consequently, escalated transaction costs, rendering it less suitable for cost-sensitive applications.

6.6. Gas Consumption Analysis

Gas consumption directly influences the operating expenses of blockchain systems since gas units denote the computing resources necessary to perform tasks on the blockchain. Figure 4 compares the gas consumption of the proposed model against benchmark models. The analysis indicates that the proposed model’s average gas consumption was 25,438.87 gas units, while Kumar et al. recorded 11,835.87 gas units and Haritha et al. recorded 61,735.24 gas units, as presented in Figure 4. These numbers underscore the proposed model’s equilibrium between computing requirements and cost efficiency.

Kumar et al.’s model attains reduced gas usage by emphasising a minimalist operational framework; however, this decrease may result in performance compromises, evident in latency and verification time. Conversely, Haritha et al.’s markedly increased gas consumption suggests a more resource-intensive methodology, which is perhaps attributable to intricate cryptographic functions and consensus procedures. This technique may improve security in some circumstances; nevertheless, its substantial gas needs render it impractical in scenarios with limited processing resources and transaction costs.

The gas consumption of the proposed model exemplifies an ideal equilibrium between the minimalist methodology of Kumar et al. and the resource-heavy framework of Haritha et al. By using lightweight cryptographic operations and a selective consensus procedure, the model maintains gas consumption at acceptable levels while ensuring security and efficiency are not compromised. This equilibrium is essential in blockchain applications in healthcare, as transaction costs must be reduced without compromising security or efficiency.

6.7. Comparison of Accuracy, Precision, and Recall Metrics Across Datasets

The comparison of accuracy, precision, and recall metrics for the proposed model versus the benchmark models by Kumar et al. and Haritha et al. demonstrates clear performance variations shaped by the design and approach of each model, and it is presented in Figure 5.

6.7.1. Accuracy Trends

Accuracy, indicative of overall predictive correctness, reveals that Haritha et al.’s model attains the maximum accuracy at 82.23%, followed by Kumar et al. at 79.33%, while the proposed model obtains 70.27%. Although the proposed model exhibits reduced accuracy, this trade-off corresponds with its emphasis on computing efficiency and resource optimisation. The elevated accuracy of the benchmark models can be ascribed to their resource-demanding methodologies, which emphasise overall accuracy but can result in computational inefficiencies, as seen by their increased gas consumption and latency measurements.

6.7.2. Precision Trends

The proposed model excels in precision, demonstrating a capacity to minimise false positives. It attains an average precision of 82.48%, above both Kumar et al. (76.83%) and Haritha et al. (81.30%). This trend demonstrates the proposed model’s efficacy in precisely forecasting positive events, rendering it especially appropriate for applications such as healthcare, where the avoidance of false alarms is essential. This corresponds with its implementation of lightweight cryptographic functions and Proof of Authority consensus, which decrease computing costs while maintaining prediction accuracy.

6.7.3. Recall Trends

Recall assesses the models’ sensitivity in identifying genuine positives. The proposed model attains a recall of 82.63%, somewhat exceeding Haritha et al. (80.58%) and markedly surpassing Kumar et al. (74.26%). The elevated recall guarantees that the proposed model consistently identifies relevant occurrences, minimising the likelihood of overlooking essential data. The decreased recall of the benchmark models indicates a heightened emphasis on avoiding false positives, sometimes compromising the identification of all actual positives.

6.7.4. Combined Metric Analysis

The proposed model exhibits a robust equilibrium between precision and recall, rendering it especially appropriate for real-time applications such as healthcare, where sensitivity and dependability are critical. The lowered accuracy, relative to benchmark models, underscores a calculated trade-off aimed at enhancing computational efficiency and minimising latency, which is shown by its exceptional performance in authentication latency and memory utilisation.

The comparative results illustrated in Figure 2, Figure 3 and Figure 4 demonstrate that the proposed model markedly improves authentication performance while also ensuring security and cost efficiency. The enhancements in latency, memory efficiency, and verification speed render it particularly appropriate for e-health applications, facilitating rapid, scalable, and secure user authentication and access control.

Kumar et al. and Haritha et al. emphasise accuracy, as shown by their high precision, although with heightened latency and computation demands. The proposed model’s equitable performance, together with its lightweight and efficient architecture, presents a persuasive option for situations requiring swift and dependable decision-making, such as e-health systems.

6.7.5. Comparison of Benchmark Models

The benchmark models were chosen for their applicability to blockchain-based authentication within e-health systems.

Table 3. Comparison of benchmark models.

Model	Authentication Method	Security Features	Consensus Mechanism	Key Limitations
Kumar et al. [18]	Multi-factor authentication with cryptographic hashing	Secure key exchange, role-based access control (RBAC)	Proof of Work (PoW)	High computational cost, slow transaction processing
Haritha et al. [23]	Smart contract-based authentication with biometric encryption	Privacypreserving biometric authentication, Zero-Knowledge Proofs (ZKP)	Proof of Stake (PoS)	Susceptibility to Sybil attacks, validation delays
Proposed Model	Smart contract-based authentication with blind signatures	Enhanced privacy, resistance to replay and insider attacks	Proof of Authority (PoA)	Optimised for regulatory compliance, but depends on trusted validators

presents a comparative analysis of these models alongside the proposed approach.

The proposed model enhances benchmark models by utilising blind signatures to improve privacy, employing PoA consensus for expedited transaction validation, and implementing smart contract-driven access control to address security risks linked to centralised authentication methods. The enhancements lead to reduced computational costs, increased scalability, and enhanced security guarantees relative to the benchmark models.

6.7.6. Privacy Protection and Regulatory Compliance in the Proposed Model

The proposed blockchain-based authentication and access control framework is designed to comply with stringent privacy regulations, ensuring patient confidentiality and secure data access. Below are key aspects of privacy protection and compliance:

• Patient Anonymity through Blind Signatures
  Blind signatures ensure that user authentication is conducted without revealing personal identifiers. This aligns with Article 5 of the GDPR, which mandates data minimisation and pseudonymisation to enhance privacy. The proposed system allows users to authenticate and request access without exposing their identities, which reduces the risk of unauthorised tracking.
• Smart Contract-Based Fine-Grained Access Control
  The implementation of smart contracts ensures that access control policies are enforced transparently and automatically. The AccessControlContract only permits authorised entities (e.g., doctors and laboratories) to retrieve specific data based on predefined access permissions. This supports HIPAA’s “Minimum Necessary Standard”, which limits access to only essential information.
• Off-Chain Storage for GDPR Compliance
  Blockchain’s immutability poses challenges in meeting the GDPR’s “Right to be Forgotten” (Article 17), which requires data deletion upon user request. Our approach addresses this issue by storing only hashed references on-chain while actual health data remain off-chain in the InterPlanetary File System (IPFS). Users can revoke access and request data deletion from the off-chain repository, ensuring regulatory adherence.
• Auditable and Tamper-Resistant Logging
  The Ethereum-based blockchain ledger records access requests and permissions in an immutable manner, ensuring auditability for compliance verification. This aligns with HIPAA’s “Security Rule”, which requires healthcare organisations to maintain detailed audit trails of data access and modifications.

By integrating these security measures, the proposed model ensures compliance with major privacy regulations while maintaining efficiency and scalability in e-health applications.

7. Why Proof of Authority (PoA) for E-Health Authentication?

The choice of PoA as the consensus mechanism for the proposed e-health authentication system is based on its superior efficiency, scalability, and security compared to other blockchain consensus mechanisms like Proof of Work (PoW) and Proof of Stake (PoS).

In distinction to Proof of Work, which necessitates significant computational resources for mining, Proof of Authority does not depend on energy-intensive cryptographic challenges. This enhances its suitability for resource-constrained environments, such as e-health systems, where rapid authentication is critical.

PoA facilitates rapid transaction processing through low-latency authentication and near-instant block finality, in contrast to PoS, which necessitates multiple validations prior to transaction finalisation. This guarantees that patient authentication and access control processes take place in real time, eliminating unnecessary delays.

In a PoA model, trusted validators, or authorised nodes, are responsible for transaction approval, which mitigates the risk of Sybil attacks and fraudulent transactions compared to systems reliant on anonymous miners. Within the e-health framework, hospitals, regulatory agencies, and accredited health providers function as validators, guaranteeing secure and auditable access.

Regulatory compliance in healthcare is critical due to stringent privacy laws such as GDPR and HIPAA. The use of permissioned blockchains through PoA facilitates controlled access and adherence to regulations by restricting validation rights to authorised healthcare entities.

In terms of scalability for e-health networks, PoA facilitates greater transaction throughput while minimising energy consumption, rendering it suitable for extensive healthcare applications that engage various stakeholders, including hospitals, laboratories, and insurers, which is in contrast to PoW and PoS.

The proposed model, through the adoption of PoA, establishes a secure, efficient, and scalable authentication system specifically designed for e-health environments, effectively addressing issues of latency, computational cost, and regulatory compliance.

Limitations and Future Work

The proposed blockchain-based authentication and access control model provides significant advantages in privacy preservation, efficiency, and scalability for e-health applications; however, it also reveals specific limitations in practical healthcare implementation.

The PoA consensus technique improves computing efficiency and decreases latency in blockchain authentication. Similarly, PoA facilitates low-latency authentication and adheres to regulatory standards, yet its dependence on a restricted number of trustworthy validators poses significant centralisation problems. In contrast to PoW or PoS, which incentivise consensus players via computing power or staking, PoA functions with pre-approved validators, usually chosen from reputable companies. This structure presents certain vulnerabilities:

• Collusion Risk: A limited number of validators may collaborate to distort transactions, alter access privileges, or exclude certain parties.
• Censorship Potential: In contrast to completely decentralised networks, Proof of Authority (PoA) networks enable validators to selectively authorise or deny transactions, which may result in censorship over data access situations.
• Single Point of Failure: Should many validators be compromised, the whole system may be jeopardised, undermining trust in authentication and access control systems.

To alleviate these problems, future works will investigate hybrid consensus techniques that include aspects of Delegated Proof of Stake (DPoS) or Byzantine Fault Tolerant (BFT) consensus, which provide enhanced decentralisation while preserving efficiency. Furthermore, the use of periodic validator rotation and decentralised governance frameworks might provide a more equitable distribution of validation power.

The current study evaluates the proposed model through simulation-based analysis, focusing on authentication speed, memory utilisation, and scalability in a controlled testing environment. The model effectively minimises computational and memory overhead; however, its performance may be compromised in extensive IoMT networks that manage millions of real-time transactions, where high throughput is essential. Subsequent research will investigate alternative consensus mechanisms, including PoS and Delegated Proof of Stake (DPoS), which may improve decentralisation and lessen dependence on a fixed group of validators. While the results demonstrate significant improvements over existing blockchain-based authentication models, real-world deployment in hospital networks and IoMT-enabled healthcare systems remains an essential next step. Future work will involve collaborating with healthcare institutions to integrate the proposed model into operational e-health infrastructures. This will enable testing in dynamic and complex scenarios, assessing real-time authentication under varying network conditions and user loads. Additionally, integration with electronic health record (EHR) systems will facilitate end-to-end validation of regulatory compliance and user acceptance. Evaluations in practical settings will yield insights into the management of extensive datasets, latency reduction, and the assurance of interoperability across diverse healthcare systems.

Additionally, hybrid blockchain architectures that integrate public and private blockchains will be examined to enhance scalability and reduce dependence on a singular blockchain network. The study will also examine the incorporation of AI-driven access control mechanisms to improve real-time security threat detection, dynamic authorisation policies, and adaptive authentication protocols. The proposed enhancements seek to establish a more flexible, scalable, and robust blockchain-based authentication framework to facilitate the adoption of e-health in real-world applications.

8. Conclusions

This paper presents a blockchain-based framework for authentication and access control, which is designed for the safe and efficient administration of sensitive health information in e-health systems. The amalgamation of lightweight cryptographic methods with blockchain technology improves privacy and scalability, successfully mitigating the issues of computational expense and latency. The findings indicate superior performance relative to existing models in terms of memory utilisation, authentication speed, and transaction throughput, thus validating the model’s appropriateness for critical healthcare environments. Future studies can look into the augmentation of the system’s functionalities by integrating supplementary consensus methods and conducting tests in broader IoMT environments in order to promote scalability and integration into the healthcare ecosystem.