Ensuring end-to-end privacy in IoT-based healthcare systems through hyperledger fabric and identity mixer

TL;DR

This paper proposes a blockchain-based system using Hyperledger Fabric and Idemix to ensure patient privacy and data security in IoT healthcare systems.

Contribution

The novel integration of Hyperledger Fabric and Idemix ensures end-to-end privacy and resilience against security threats in IoT healthcare systems.

Findings

The proposed system ensures data integrity, confidentiality, and mutual authentication in IoT healthcare.

It provides patient anonymity and untraceability while resisting collusion among internal entities.

Blockchain introduces computational overhead but significantly enhances security compared to centralized systems.

Abstract

Healthcare information is often sensitive and confidential, and any unauthorized disclosure can jeopardize patient privacy. Centralized approaches currently used to protect patient information are vulnerable to a single point of failure and the risk of data breaches from central servers. Conversely, distributed blockchain-based methods tend to focus only on safeguarding data privacy for certain segments of the communication path from sensors to end users. This leaves a gap in methodologies that ensure both location and data privacy throughout the entire communication from sensors to healthcare data users via blockchain technology. In this paper, we propose using Hyperledger Fabric to ensure the immutability of patient data and to address the single point of failure issue. Additionally, to maintain end-to-end data and location privacy, our proposed scheme integrates the Idemix protocol suit alongside Hyperledger Fabric and employs a lightweight communication protocol for interactions between healthcare sensors and gateways. Compared to previous methods, our approach not only facilitates privacy features such as patient anonymity and untraceability but also guarantees data integrity, confidentiality, mutual authentication, and resilience against a variety of security threats, including collusion among internal entities. While the implementation of blockchain may introduce additional computational overhead for service providers compared to centralized systems, this trade-off is outweighed by the significant enhancements in security as evidenced by our analyses and evaluations.

Figures

Modification attack in the Forth step of in the authentication protocol of the method of Ref. [51].

Modification attack in the second step of the authentication protocol of Ref. [51].

Identity Mixer implementation for Hyperledger Fabric [80].

The architecture of the proposed scheme, where (Reg.) indicates the registration steps and (Auth.) denotes the authentication and data exchange steps of the protocol.

Authentication and real-time data transmission (The small rectangles represent the operations performed by the entities at each step, which have been omitted for simplicity in the protocol description.The details of these operations are provided in Figs 6–15.).

Step 1 of the proposed protocol executed by the sensors.

Step 2 of the proposed scheme executed by GWs.

Step 3 of the proposed scheme executed by AP (Green texts indicate operations on the blockchain).

Step 4 of the proposed scheme executed by GWs.

Step 5 of the proposed scheme executed by sensors.

Step 6 of the proposed scheme executed by GWs.

Step 7 of the proposed scheme executed by Aps.

Step 8 of the proposed scheme executed by UAs.

Step 9 of the proposed scheme executed by Aps.

Step 10 of the proposed scheme executed by UAs.

Patient data retrieval by the UA.

Step 1 of data retrieval phase executed by UAs.

Step 2 of data retrieval phase executed by APs.

The computation overhead of sensors in the proposed scheme compared to the methods of Refs. [25,51] (for the setting with the number of shadow IDs = 100, the number of Aps = 10, and Seg-size = 10).

Communication overhead of the proposed scheme compared to the methods of Refs.[25,51,89].

Communication overhead of sensor in the proposed scheme compared to the methods of Refs. [25,51,89].

Communication delay and total end-to-end delay of the proposed scheme compared to the methods of Refs. [25,51,89].

Sensor energy consumption of the proposed scheme compared to the methods in Refs. [25,51,89].

Full text

Introduction

Due to the increasing costs of current healthcare services and the prevalence of chronic diseases [1], it has been predicted that healthcare systems change from hospital-centered to home-centered in 2030 [1]. Therefore, the need for remote monitoring of patients has led to using the Internet of Things (IoT) concept in healthcare systems. In such systems, bio-medical and context information are gathered through the sensors such as wearable ones and the information is processed at various levels to make prescriptions and possibly drug injections. These systems not only improve the quality of healthcare services but also reduce healthcare costs [2,3].

Continuous patient monitoring through Wireless Body Area Networks (WBAN) increases the early diagnosis of emergency conditions of patients and provides healthcare services for people with different degrees of disability [4]. These networks include a number of sensors on the surface of the body, inside the tissues, or on clothing. They should gather, process, and communicate healthcare information [5]. In these networks, some gateways receive sensor information and send it to remote servers [6,7]. Each sensor usually collects and processes some vital signs [5,8]. Those sensors have small batteries, low storage, and limited communication capabilities [5]. Due to resource constraints of sensors, conventional security protocols are not suitable [9,10] and lightweight solutions are necessary [10–12]. A solution is using smart gateways to collect data from WBANs and providing security services on behalf of the sensors [13–15].

Providing end-to-end data and location privacy of patients is an important issue in healthcare systems [9,11]. Many patients do not like to disclose their illness to others. Another concern of patients is revealing their location to others since their location should only be revealed to emergency centers. Privacy-preserving methods are divided into centralized and distributed ones. The centralized methods for protecting the data and location privacy of the patients (such as [16–23]) face the risk of a single point of failure problem and the possibility of privacy leakage from parts of the system. Privacy leakage is due to the fact that those studies assume some parts of the system as trusted while they may be curious despite following the protocol appropriately. For example, Ref. [2,10,16–18,23] just protect the privacy against external attackers and assume all entities as trusted ones.

Some studies place their trust in gateways or service providers [11,19,22,24], while others consider these gateways and healthcare service providers to be untrustworthy [20,21,25]. Only the study in [25] adopts the perspective that all system entities may be curious. Most of the studies mentioned in [16,17,21,22,26] primarily emphasize data privacy, while a few, such as [27], concentrate solely on location privacy. Some studies [10,11,18,20,24,25,28] address both data and location privacy. Our previous work [25] proposes a centralized scheme to preserve both data and location privacy, operating under the assumption that all system entities are untrusted. However, this approach is vulnerable to a single point of failure and is susceptible to collusion attacks, as noted in [25].

Blockchain (BC) is used as a distributed solution to preserve patients’ privacy in several studies [29–33]. Some others [34–41] utilize BC for access control in healthcare systems. Moreover, some studies [42–45] use BC with attribute-based encryption (ABE) methods to gain security features such as authentication, confidentiality, and integrity of healthcare data. Other studies [46–50] utilize patient-centric agents as well as BC to protect privacy.

However, the majority of earlier studies concentrate solely on safeguarding data privacy for specific segments of the end-to-end communication from sensors to the final users.

An end-to-end privacy-preserving method that maintains location and data privacy using blockchain has been proposed in previous work [51]. However, the approach presented in Ref. [51] is susceptible to several security vulnerabilities and attacks. In the initial stages of the authentication and data transmission algorithms, a modification attack occurs on critical parameters of the authentication process, leading to the misinterpretation of patient information in subsequent stages. This leads to compromising message integrity. Furthermore, message authentication is compromised due to another modification attack, although the end users finally recognize the modified information too late at the final stage, once it has already been entered into the healthcare information database. Additionally, some assumptions made in the aforementioned paper [51] have weakened the proposed solution.

Consequently, there is a notable absence of a comprehensive privacy-preserving approach that ensures both location and data privacy throughout the end-to-end communication from sensors to healthcare data users using blockchain technology. To address these vulnerabilities, we utilize the Hyperledger Fabric blockchain framework in conjunction with the Idemix protocol suite to establish end-to-end privacy in healthcare systems. Leveraging Hyperledger Fabric’s capabilities for immutable and secure data transaction storage, we incorporate this framework into our proposed method. Idemix facilitates anonymous authentication and privacy protection through a blind signature scheme and efficient zero-knowledge proofs. We assume that all system entities are semi-honest, meaning that they adhere to the protocol while remaining curious. The key contributions of our work are outlined as follows:

As mentioned previously, our earlier work [51] is vulnerable to modification attacks due to weak authentication in gateways. To address this issue highlighted in Ref. [51], we propose using Idemix for authentication. This new scheme aims to preserve the end-to-end privacy and anonymity of patients in a blockchain-based healthcare system, effectively resolving the problems identified in Ref. [51]. The proposed scheme safeguards patients’ privacy against violations from both external attackers and insider threats.A secure protocol is proposed to present the mentioned security features with the help of BC and Idemix.The proposed scheme provides both data privacy and location privacy of the patients, in contrast to most previous BC-based methods that are only preserving healthcare data’s privacy.A lightweight protocol is used to anonymously authenticate the sensor to the gateway and maintain its data privacy using light operations such as XOR and hash. Then, Idemix services are employed by the gateway to complete the procedure on behalf of the sensor.

This paper is organized as follows. First, we review recent literature on methods for protecting patient privacy. Next, we provide some preliminary background information before detailing the proposed scheme. We then cover the security analysis and performance evaluations. The paper concludes with a summary of our work and final remarks.

Related work

Numerous studies have applied blockchain (BC) to protect patient privacy in IoT-based healthcare environments [38,41,48,49,52–62]. Representative contributions include the two-layer blockchain framework S2HS for securing interactions among healthcare entities [55]; a blockchain-based electronic health record system that facilitates access to medical records and hospital resources [56]; and decentralized, privacy-preserving algorithms that enable distributed computation without revealing sensitive data while relying on blockchain for transparent record-keeping [57]. Reviews also document deployed healthcare applications such as MedRec, MeDShare, OmniPHR, Pervasive Social Network (PSN), and Healthcare Data Gateway [29–33,63].

Some approaches retain health records in local databases managed by healthcare providers and use blockchain primarily as an access-control layer, storing only hashed pointers and access policies on distributed ledgers to improve scalability, integrity, and availability [38,41]. Ref. [41] additionally proposes a patient-centric management platform that supports privacy-preserving storage. Other works concentrate explicitly on data confidentiality by encrypting information and storing it in distributed file systems such as IPFS [58], or by applying lightweight obfuscation techniques (e.g., interleaving encoders) to conceal raw data semantics [59].

Several efforts address resource constraints at sensing nodes. For example, lightweight security protocols, cluster-head-based aggregation, and ring signatures have been used to reduce sensor-side computation and to anonymize miners that verify data blocks prior to blockchain publication on cloud servers [62]. Similarly, Wang et al. propose an e-health architecture tailored for resource-constrained hardware in which WBAN gateways aggregate data and forward it to the blockchain over secure channels [61].

Authors’ prior work [51] presents a three-layer blockchain architecture employing zero-knowledge proofs and ring signatures to protect end-to-end data and location privacy, with computation of sensors being offloaded to gateways and access points. The protocol comprises entity registration, mutual authentication, information transfer, and information-access. However, there are vulnerabilities in that protocol. Modification attacks on sensitive early-stage parameters (e.g., $[eqn]$ or Beacon) can cause incorrect $[eqn]$ or Info values to be produced and recorded. Although the end user detects integrity or authenticity violations at the final verification step, erroneous data is stored in the provider’s database (see Figs 1 and 2). Fig 1 schematically depicts the authentication and information transmission algorithm outlined in Ref. [51]. This representation omits detailed per-step operations by each entity, focusing instead on sensitive parameters such as $[eqn]$ and $[eqn]$ . If an attacker alters the value of $[eqn]$ , then the sensor will incorrectly compute $[eqn]$ in Step 5. This $[eqn]$ parameter is subsequently used in Step 10 to verify the integrity and accuracy of the patient's information. Consequently, the end user fails to provide early validation, i.e., detects the mismatch in $[eqn]$ at the final verification step (Step 10).

Modification attack in the Forth step of in the authentication protocol of the method of Ref. [51].

Modification attack in the second step of the authentication protocol of Ref. [51].

Moreover, another modification undermines message authenticity, leading to a situation where end users only become aware of the incorrect information at the final stage, after it has already been recorded in the healthcare information database. Similar to Fig 1, Fig 2 illustrates a modification attack on the authentication and information transfer algorithm described in [51]. This figure specifically highlights sensitive parameters, such as Beacon. If an attacker modifies the Beacon parameter in Step 2, it causes subsequent entities to incorrectly compute several critical parameters across Steps 3–10. Among these, the Info parameter, containing the patient's healthcare information, is paramount. The Info is ultimately delivered to the end user via $[eqn]$ in Step 10. Consequently, the end user detects the compromised information too late, i.e., in the final step (Step 10), while the incorrect information has already been recorded in the database by the Application Provider (AP) in Step 7.

While frameworks such as PREHEALTH [64] and other Fabric/Idemix-based solutions leverage Hyperledger Fabric and identity-mixing techniques to provide anonymity and prevent traceability, they often neglect practical concerns such as latency or do not cover the entire communication path from sensors to end users [64–67]. In summary, existing blockchain-based solutions commonly protect portions of the communication chain, but simultaneous end-to-end protection of both patient’s data and location remains inadequately addressed.

Background

IoT-based healthcare systems architecture

IoT-based healthcare architectures commonly comprise three domains: (1) sensors and actuators that are typically lightweight devices which collect physiological and contextual data and communicate with gateways (patient mobile devices or public gateways in clinics/hospitals); (2) communication infrastructure, which consists of edge gateways that support WBAN protocols and mediate between sensors and backend services; and (3) healthcare service providers consisting applications and databases that receive sensor data and present it to end users (e.g., doctors).

Hyperledger fabric

Blockchain can preserve identity privacy (e.g., using distinct public keys per transaction to prevent tracking) [68–70]. Blockchains are categorized as public, private (permissioned), or consortium, with private/permissioned platforms often preferred for sensitive data [57,71,72]. We adopt Hyperledger Fabric for its privacy, modularity, and lower consensus cost relative to public platforms. Key Fabric concepts relevant to healthcare systems are as follows:

Channels: private subnets with separate ledgers for confidential communication among authorized members [73].Nodes: clients (submit transactions), peers (endorse/commit transactions), and ordering nodes (order transactions into blocks) [74,75]. Peers may assume roles such as endorsing, committing, leader, or anchor.Fabric CA and MSP: Fabric CA issues certificates; the Membership Service Provider (MSP) abstracts membership, certificate validation, and authentication, defining trusted CAs and domain roles [76].Ledger and world state: the ledger comprises an immutable blockchain plus a world state (key–value store via LevelDB or CouchDB) that reflects current state for efficient queries [77].Chaincode: smart contracts executed in containerized environments whose transactions are recorded in the ledger [78].

Transaction lifecycle in Hyperledger Fabric includes: (1) proposal and endorsement where client sends signed proposal and peers execute chaincode and endorse; (2) submission and ordering where client submits signed envelope to ordering service which creates blocks; and (3) validation and commitment where peers validate endorsements and read–write sets, commit blocks to the ledger, and emit commit events [79,80].

IDEMIX

Idemix provides cryptographic identity privacy (untraceability and selective disclosure) via blind signatures and zero-knowledge proofs [80,81]. Roles include issuer, user, and prover. Versions 1.2 and later of Fabric support Idemix, where Fabric CA issues Idemix credentials, the Fabric Java SDK acts as the user API, and the Idemix MSP verifies presentations [64,80]. Fabric’s Idemix implementation includes CA services, an Idemix MSP, and core cryptographic packages for key/credential issuance and presentation token generation (Fig 3).

Identity Mixer implementation for Hyperledger Fabric [80].

CA Service: It utilizes the Identity Mixer crypto package to issue ECert credentials. Idemix MSP implementation: it signs and verifies the transactions with the help of the Identity Mixer crypto package [80]. Core Identity Mixer crypto package: it creates the keys of the issuer, issues credentials, and generates and verifies presentation tokens.

In Hyperledger Fabric, certificate revocation is managed using Certificate Revocation Information (CRI). The issuer (Fabric CA) revokes credentials, and this revocation is recorded in the CRI [82]. The client (prover) uses the CRI to generate a non-revocation proof, which is verified by the Idemix MSP to ensure the credential is not revoked. The Gateway (GW) assists in generating this proof [83].

To update the ledger, the process involves three main steps [79]:

Transaction Proposal and Endorsement:

• Proposal: The client sends a signed transaction proposal to a peer via the gateway.
• Execution: The peer executes the chaincode, signs the response, and sends it back to the gateway.
• Endorsement: The gateway re-executes the transaction for endorsement, gathers signed responses, and returns a transaction envelope to the client for signing. Transaction Submission and Ordering:
• Submission: The client signs and submits the envelope to the gateway, which forwards it to an ordering node.
• Ordering: The ordering node validates the signature, orders the transaction into a block, and sends it to all peers in the channel. Transaction Validation and Commitment:
• Validation: Peers validate the transaction using Idemix MSP, compare read-write sets, and check endorsement policies [80].
• Commitment: Valid and invalid transactions are committed to the ledger, but only valid transactions update the world state.
• Commit Event: Peers notify the client of the ledger update with a commit event [79].

In Idemix, users generate secret keys and create multiple public keys (pseudonyms) for anonymity. The Fabric Idemix implementation uses a pairing-based signature scheme for cryptographic operations [84,85]. For further details, refer to Ref. [86] and Ref. [87].

Proposed scheme

This section provides a detailed illustration of the system architecture, the threat model, and our proposed privacy-preserving protocol.

System model

The system consists of patients accompanied by healthcare sensors, the users’ application (UA) which provides patient information to licensed data consumers (e.g., doctors or emergency centers), gateways (GWs) such as patients’ phones or hospital access points, the healthcare application providers (APs) such as hospitals, a private Fabric BC $[eqn]$ containing the sensor information shared between all APs, a private Fabric BC $[eqn]$ that reduces the possibility of a mining attack, a network of peers (APs) that each peer is serving some GWs and UAs, a Fabric CA, and the Idemix MSP. Sensors gather vital patient information and transmit it anonymously to the gateways (GWs). The GWs, through the access point (AP), verify the identity of these sensors while maintaining anonymity, and then forward the encrypted data to the APs. The AP serves as the leader of an overlay network, tasked with verifying the sensors of the patients it oversees, assisting the GWs in authenticating the sensors, and providing healthcare information to registered user agents (UAs). Additionally, APs are responsible for validating transactions as peers within the Fabric blockchain.

The overlay network i consists of several GWs, an AP, and a private blockchain $[eqn]$ . Each AP maintains a blockchain for every patient referred to it, designated as $[eqn]$ , where j represents the patient's anonymous ID. Once the AP stores the encrypted data of patient j in its local database, it records the hash of this information in the patient's dedicated blockchain ( $[eqn]$ . Subsequently, the AP adds the hashed pointer of the last block from $[eqn]$ into $[eqn]$ .

The APs and UAs register in X.509 MSP while patients and GWs register in Idemix MSP through Fabric CA (due to data and location privacy concerns related to these entities). Idemix MSP creates tokens for clients (here patients and GWs) and verifies the registered clients. The proposed system architecture is shown in Fig 4. The gateways only need to ensure the validity of the sensor without knowing the real identity of the patient. Also, the end user (for example, a doctor) does not need to know the real identity of the patient, and can make a medical diagnosis only by having the patient’s medical information. When a new health information is sent to an AP, the AP sends a notification to the end-user. Then the end-user authenticates to the AP and receives the patient’s information.

The architecture of the proposed scheme, where (Reg.) indicates the registration steps and (Auth.) denotes the authentication and data exchange steps of the protocol.

In order to adapt the Hyperledger Fabric to the context of our IoT-based healthcare system, we should attend to its scalability and high storage requirements [39,62]. Since a healthcare system contains many participants, we cluster the network to some overlay networks to improve BC scalability similar to [62]. Each overlay network uses a private BC to facilitate service provisioning to its owned nodes. The distributed nature of blockchain makes it impractical to store large volumes of data directly on it. Therefore, we store healthcare data in the database of the access points (APs) and keep only the hash of the data blocks in the private blockchain associated with the relevant overlay networks, ensuring data integrity and immutability. In our proposed scheme, to maintain patients’ anonymity and location privacy, sensors are authenticated anonymously to the gateways (GWs) via the APs, and GWs are authenticated to the APs anonymously using Idemix. Additionally, healthcare information is encrypted with the public key of the corresponding user.

To ensure distributed healthcare services and prevent single points of failure, a private blockchain (i.e., $[eqn]$ ) stores sensitive patient and sensor data, such as anonymized sensor identities, anonymized sensor secret keys, hashes of one-time sensor tokens, the identities of the access points (APs) serving the anonymized patient, and the identities of authorized user agents (UAs). Access to this blockchain is restricted to authorized APs. Each AP can serve a patient's sensors regardless of prior registration. After each session, the serving AP updates the hash of the one-time token and the list of authorized UAs in $[eqn]$ . Only authorized APs can access the anonymized sensor identities and secret keys. A main private blockchain ( $[eqn]$ ) is also used to mitigate 51% attacks by storing the hash of the last block from each overlay network's private blockchain (i.e., $[eqn]$ ).

Only selected and authenticated end users can access healthcare information. To facilitate this, one of the cluster heads (APs) anonymously authenticates the gateway (GW) using Idemix MSP. If the authentication is successful, the AP verifies the sensor by retrieving its anonymized identity and key based on the hash of the one-time token from $[eqn]$ . This allows the AP to authenticate both the sensor and the GW without knowing their true identities, ensuring that the actual identities of the sensors and their locations remain confidential.

The sensor authentication process in our scheme is based on a lightweight protocol inspired by Gope et al.’s approach [11]. In Gope et al.’s method, the sensor is authenticated to the GW via a local server (in this case, the AP), which prevents the GW from knowing the patient's real identity since the local server is aware of the patient's location through the serving GW. In our proposed method, the AP anonymously authenticates both GWs and sensors, and the healthcare information of patients is encrypted with the public key of the end users.

Threat model

In our proposed method, unlike much of the existing research, all system entities, including GWs, APs, and UAs, are considered semi-honest; this means they follow the protocol correctly but may be curious about the data. Additionally, the communication channels are assumed to be insecure. Only the certificate authority (CA) is regarded as a trusted entity. An attacker can impersonate an authorized entity to read, modify, delete, or forge messages, initiate a session, and execute replay attacks. However, the attacker cannot predict a random number, obtain the private key from public-key certificates, or decrypt a message without knowing the corresponding secret key.

Proposed protocol

This section outlines the proposed protocol, which consists of two main phases: 1) the registration phase and 2) the authentication and data exchange phase, as detailed in the following subsections.

Registration phase.

In this subsection, the initial registration of system entities such as patients’ sensors, UAs, APs, and GWs are presented. Two types of registration and enrollment are used in our method. One of them is the normal type where X.509 certificates are issued for UAs and APs, and the other is the anonymous type where Idemix certificates are issued for patients and GWs. Fabric CA generates its signing key pair ( $[eqn]$ ). UA and AP register in X.509 MSP while patients and GWs register in Idemix MSP through Fabric CA. Following, we present the registration phase of each entity in detail:

UA registration

The end user (e.g., physician) connects to the framework through a User Application (UA). Then the UA sends the registration request to the CA. In the registration process, a registration ID and a password, are assigned to the identity of the end user. Then, the registration ID and password along with other identity-related information are stored in the CA database. Then, UA sends an enrollment request to the Fabric CA. CA issues an X.509 certificate along with the public and private key pair. The membership service provider also contains the UA’s public key, which is used to verify the validity of the signature attached to the transactions.

AP registration

The AP registration process is similar to the end user registration process and APs do not need to be anonymous.

GW registration

In order to preserve location privacy, the GWs should anonymously authenticate to the APs. To do this, GWs receive a certificate from the Fabric CA during registration and prove to the verifier (MSP) that they have a valid certificate using the Idemix protocol without exposing any additional information. In more detail, the GW generates its unique secret key and sends a request to the Fabric CA (issuer) to get the credentials. Credential issuance is an interactive protocol between the GW and the CA. The issuer takes its private and public keys ( $[eqn]$ ) and user attributes as inputs. Also, the user takes a user secret and the issuer’s public key, $[eqn]$ as inputs [80]. First, the GW sends a request, i.e., GetCAInfo, with an empty body to the CA to get CA’s public key, $[eqn]$ . Also, the GW sends a NonceRequest with an empty body and an authentication header to the Fabric CA to get a nonce. The authentication header consists of an encoded username and password. Then, the CA authenticates the request, creates a random nonce, assigns an expiration time to it, stores the nonce in the database, and finally sends it to the GW. The GW generates credential requests using the CA public key ( $[eqn]$ ), user secret, and the nonce sent by the CA. The request consists of a Pedersen commitment to the user’s secret (commitment (userSecret)) and a zero-knowledge proof on knowledge of the user’s secret key (ZKProof ( $[eqn]$ )) [80]. This commitment to the user’s secret is used as a public key. Pedersen’s commitment and zero-knowledge proof are computed according to [87]. The body of the credential request is in the form of CredentialRequest (commitment (userSecret), ZKProof (( $[eqn]$ )), $[eqn]$ , nonce) and the basic authentication header is in the form of basic <base64 encoding of username: password > . The GW sends the credential request to the CA.

CA validates the credential request according to the zero-knowledge proof ZKProof ( $[eqn]$ ). If the validation is successful, CA issues a GW credential by signing the commitment to the secret key in the form of $[eqn]$ and stores it in the datastore [80]. Then it sends the $[eqn]$ and CRI back to the GW. Idemix MSP (Verifier) utilizes CRI to check whether the credentials used in a presentation token have expired or not. The GW verifies the Fabric CA's signature and stores it in his/her wallet [82]. Then GW generates a random number as $[eqn]$ and stores it.

Patient Registration

The patient registration process is similar to the GW registration process. The patient connects to the system through the client application and sends a registration request to the Fabric CA. The CA (issuer) issues a certificate (Idemix certificate) for the patient. The patient proves to the verifier (Idemix MSP) that he/she is the owner of a valid credential using a zero-knowledge proof protocol. Since zero-knowledge proof is used, no additional information is disclosed to the verifier, issuer, or anyone else. Here, no additional information is received from the patient and the patient only interacts with the system using his/her ambiguous ID ( $[eqn]$ ).

Sensor registration

Each patient has a number of sensors that must interact with the system. For this purpose, in an offline sensor registration process, the patient generates an ID ( $[eqn]$ ), a one-time token ( $[eqn]$ ), an array of shadow IDs ( $[eqn]$ ) which is long enough, and a key for each sensor, e.g., $[eqn]$ for sensor s where $[eqn]$ and $[eqn]$ are random numbers and $[eqn]$ is the patient ID (obtained during patient registration). The value of $[eqn]$ is $[eqn]$ [11]. Moreover, to verify the sensor authentication, the obfuscated ID of the sensor ( $[eqn]$ ), the obfuscated key of the sensor ( $[eqn]$ ), an array of the hash values of $[eqn]$ ( $[eqn]$ ), and the hash of one-time token of the sensor ( $[eqn]$ ) are stored in $[eqn]$ for each sensor. The values of $[eqn]$ and $[eqn]$ are according to the values of ( $[eqn]$ ) and ( $[eqn]$ ) respectively and random numbers ( $[eqn]$ , $[eqn]$ , $[eqn]$ , and $[eqn]$ ) are calculated according to $[eqn]$ and $[eqn]$ . The sensors store the values of $[eqn]$ , $[eqn]$ , $[eqn]$ , $[eqn]$ , and $[eqn]$ in non-volatile memory.

Authentication phase.

The authentication phase involves the anonymous authentication of sensors to the GWs via Idemix, the anonymous authentication of GWs to the APs using Idemix, and mutual authentication between the UAs and the APs. Our scheme is designed with consideration for the computational and energy limitations of the sensors. The AP initially authenticates the GWs through Idemix and subsequently assists the GWs in anonymously authenticating the sensors. This process ensures that the AP cannot link the sensors’ anonymized identities to their respective GWs, thus preserving the patients’ location privacy. When authentication was completed, the encrypted healthcare information is stored in the AP's local database. To safeguard this information from tampering, the AP adds the hash of the encrypted data to $[eqn]$ , and the hash of the latest block from $[eqn]$ , is recorded in $[eqn]$ . Fig 5 illustrates the authentication and data exchange phase of the proposed protocol. In this figure, operational details performed by the entities have been omitted and only transactions are shown, to facilitate understanding of the overall protocol. These details are described in below steps:

Authentication and real-time data transmission (The small rectangles represent the operations performed by the entities at each step, which have been omitted for simplicity in the protocol description.The details of these operations are provided in Figs 6–15.).

Step 1

In the first step, the sensor generates several random numbers: $[eqn]$ , $[eqn]$ , and $[eqn]$ . It then computes $[eqn]$ and $[eqn]$ using $[eqn]$ and $[eqn]$ with the following formulas: $[eqn]$ and $[eqn]$ . Additionally, the sensor calculates $[eqn]$ as $[eqn]$ using its key, $[eqn]$ . Next, it computes $[eqn]$ as $[eqn]$ , where $[eqn]$ , $[eqn]$ , and $[eqn]$ represent the original identity of the sensor, the one-time token of the sensor, and the identity of the UA receiving the healthcare information, respectively. Fig 6 shows the operation performed by the sensor in this step.

Step 1 of the proposed protocol executed by the sensors.

As seen in Fig 5, after the operation performed in Fig 6, the sensor sends the message $[eqn]$ including $[eqn]$ to the serving GW. Moreover, when the synchronization of the AP and the sensor is lost, the sensor should send the shadow ID ( $[eqn]$ ) instead of $[eqn]$ . Moreover, after each use, the values of $[eqn]$ are updated through the value of tr as will be discussed later in Step 5.

Step 2

As seen in Fig 5, this step consists of some exchanges as below:

iTransaction Signing and Verification

Whenever a GW wants to send a transaction, it needs to create a non-revocation proof, a pseudonym, and a presentation token to prove that it is a valid GW. To do this, the GW sends a SignRequest to the Idemix MSP. Idemix MSP sends the presentation policies to the GW. A presentation policy specifies the information that the GW has to expose to the Idemix MSP. This information can define which credentials from which trusted Fabric CAs are required. Moreover, it defines the public keys of credential issuing authorities which the Idemix MSP trusts [88]. Also, the GW should get new revocation information from the Revocation Authority [82]. The latest CRI can be requested by sending the GetLatestCRI request to relevant API endpoint (Fig 5).

After that, as shown in Fig 7, the GW generates a non-revocation proof that its credential has not been revoked according to the CRI [83]. After that, the GW generates a new scope-exclusive pseudonym, $[eqn]$ as follows.

Step 2 of the proposed scheme executed by GWs.

iiCreation of Scope-exclusive pseudonym (public key of GW)

A scope-exclusive pseudonym is unique for a secret key of the GW and a specified scope string. Moreover, scope-exclusive pseudonyms are unlinkable for different scope strings. Scope-exclusive pseudonym (public key of the GW) is the output of a verifiable random function. This function uses the scope string as input and the secret key as seed. The $[eqn]$ can be used as the scope string [88].

iiiCreation of presentation token

The GW generates a fresh presentation token from its credentials according to the presentation policy using the Idemix crypto library. The presentation token signs the content of the transaction, proof of having a valid credential issued by the CA, and defines the required attributes by the presentation policy.

By receiving the presentation policy, the GW invokes the Idemix crypto library. Then, the Idemix crypto library checks the GW for having required credentials and pseudonyms. This output specifies all the possible combinations of the GW’s credentials and pseudonyms that comply the policy. The GW selects an identity that lets the GW to select the preferred combination of credentials and pseudonyms (when there are several ways to satisfy the policy) and expresses its consent to the disclosure of its information. The GW’s selection options are stored in an object and forwarded to the Idemix crypto library. Idemix crypto library is responsible to create and return a presentation token, $[eqn]$ according to the GW’s selection [88]. $[eqn]$ contains the signature on the message, i.e., signatureOn(message), a zero-knowledge proof of the credential, i.e., ZKProof( $[eqn]$ ), the non-revocation proof, and the GW’s pseudonym, i.e., $[eqn]$ (Fig 7).

ivMutual Authentication with the AP

Then as shown in Fig 5, to perform mutual authentication with the AP, the GW generates a random number, $[eqn]$ , and sends it along with the message $[eqn]$ received from the sensor and the $[eqn]$ as a signed transaction proposal to the AP.

Step 3

Step 3 involves the anonymous authentication of the GW to the AP, the authentication of the sensor to the AP, updating the sensor’s token, encrypting the sensor's identity for the UA, and the authentication of the AP to the GW, as detailed below (Fig 8).

Step 3 of the proposed scheme executed by AP (Green texts indicate operations on the blockchain).

iAnonymous authentication of the GW to the AP (Verification of the presentation token)

When the AP receives the presentation token from the GW, the AP anonymously authenticates the GW through the Idemix MSP. The Idemix MSP forwards it to the Idemix crypto library to check whether the presentation token, $[eqn]$ , matches the corresponding presentation policy alternatives. The token validation is done in two phases. At the first, it checks if the statements of the presentation token ( $[eqn]$ ) provide the required statements of presentation policy. Second, it verifies the given token description [88]. $[eqn]$ is verified with the help of the CA’s public key that signed the credential [80]. Idemix MSP verifies the signature, the non-revocation proof, and zero-knowledge proof of the credentials, i.e., ZKProof ( $[eqn]$ ).

iiAuthentication of the sensor to the AP

The AP authenticates the sensor using the information stored in $[eqn]$ . To do this, the AP retrieves $[eqn]$ from $[eqn]$ by hashing the sensor's one-time token, specifically $[eqn]$ . The AP then computes the value of $[eqn]$ as $[eqn]$ , using the nonce $[eqn]$ received from the GW. The AP verifies the sensor by comparing the $[eqn]$ received from the GW with the $[eqn]$ it calculates as $[eqn]$ . If these values do not match, the AP terminates the session and notifies the GW that the sensor authentication has failed. If they match, the sensor is authenticated, and the AP proceeds to update the sensor's token.

iiiUpdating the sensor’s token

Once the AP authenticates the sensor, it generates a new one-time token, $[eqn]$ , and computes $[eqn]$ . This value is sent to the sensor via the GW, along with $[eqn]$ , which the sensor uses to verify the integrity of the new token. Additionally, the AP calculates $[eqn]$ and forwards it to the sensor through the GW, where $[eqn]$ is a random number used by the sensor to compute $[eqn]$ in step 5. The AP also updates $[eqn]$ to $[eqn]$ in $[eqn]$ , allowing other APs to access this value.

ivEncrypting the Sensor's Ambiguous Identity for the UA

In this step, the AP generates $[eqn]$ , which will be sent to the UA in step 9. This ensures that the ambiguous identity of the sensor ( $[eqn]$ and $[eqn]$ , used to verify the integrity of the patient’s information, are only exposed to the UA.

vAuthentication of the AP to the GW

In this step, the AP encrypts a nonce, $[eqn]$ , received from the GW using its private key, resulting in $[eqn]$ .

After the operation illustrated above (Fig 8), as shown in Fig 5, the AP sends $[eqn]$ , $[eqn]$ , $[eqn]$ , $[eqn]$ and $[eqn]$ to the GW, enabling the GW to verify the AP through its signature on the nonce

Step 4

In this step, the AP authenticates itself to the GW using the $[eqn]$ value received from the AP. As shown in Fig 9, the GW checks if decrypting $[eqn]$ yields $[eqn]$ , where $[eqn]$ was generated in step 2 and $[eqn]$ was received from the sensor in step 1. If the values do not match, the session is terminated otherwise the GW authenticates the AP and temporarily stores $[eqn]$ for later transmission to the AP. Then as shown in Fig 5, the GW sends $[eqn]$ , and $[eqn]$ to the sensor.

Step 4 of the proposed scheme executed by GWs.

Step 5

As shown in Fig 10, the sensor computes the new token value as $[eqn]$ . Next, the sensor calculates Ny using $[eqn]$ with the formula $[eqn]$ . The sensor then authenticates the GW by verifying $[eqn]$ ), which confirms the integrity of the new token and $[eqn]$ . After that, the sensor generates the authentication code $[eqn]$ to ensure the integrity of the healthcare information (Info) that will be sent to the UA.

Step 5 of the proposed scheme executed by sensors.

Then, as shown in Fig 5, the sensor transmits $[eqn]$ , and Info to the GW, updating the one-time token to $[eqn]$ .

Step 6

As shown in Fig 5, the GW performs the initial two phases of step 2 to authenticate itself anonymously to the AP.

Then, as shown in Fig 11, the GW encrypts its location (position), its identity ( $[eqn]$ ), and the healthcare information (Info) received from the sensor in step 5 using the UA's public key, resulting in $[eqn]$ . This $[eqn]$ allows the UA to locate the patient in emergencies. The GW then computes $[eqn]$ . Next, the $[eqn]$ , $[eqn]$ , ZKProof ( $[eqn]$ ), non-revocation proof) is generated in a manner similar to the third phase of step 2.

Step 6 of the proposed scheme executed by GWs.

Finally, as shown in Fig 5, the GW sends $[eqn]$ , $[eqn]$ , $[eqn]$ , $[eqn]$ , $[eqn]$ , and $[eqn]$ to the AP.

Step 7

In this step, as shown in Fig 12, the AP first anonymously authenticates the GW using Idemix MSP, similar to the first phase of step 3, by verifying the $[eqn]$ with the CA's public key. The AP then adds the patient’s information, specifically $[eqn]$ , to the blockchain for $[eqn]$ . This blockchain is established for $[eqn]$ after the AP receives the initial request from them. Additionally, the AP stores the patient’s details, including $[eqn]$ $[eqn]$ , in its local database. Following this, the index of the blockchain for $[eqn]$ and the hash of its most recent block are recorded in $[eqn]$ , while the hash of the last block from $[eqn]$ is saved in $[eqn]$ .

Step 7 of the proposed scheme executed by Aps.

To facilitate end-user authentication, the AP generates a random number, $[eqn]$ , signs the combination of $[eqn]$ and $[eqn]$ using its private key, and encrypts the result with the UA’s public key, resulting in $[eqn]$

Finally, as shown in Fig 5, the AP informs the UA by sending $[eqn]$ , $[eqn]$ and $[eqn]$ The values of $[eqn]$ and $[eqn]$ are encrypted using the UA’s public key to safeguard the privacy of healthcare information and the patient’s location, which could be compromised if the serving GW’s identity were disclosed.

Step 8

In this stage, as shown in Fig 13, the UA authenticates the AP by using the AP's certificate to decrypt the value of $[eqn]$ , which allows the UA to retrieve both the $[eqn]$ and $[eqn]$ .

Step 8 of the proposed scheme executed by UAs.

The UA then calculates the hash of $[eqn]$ , referred to as $[eqn]$ , and transmits it to the AP. Since only the UA can derive $[eqn]$ from $[eqn]$ , it sends $[eqn]$ to the AP to complete the authentication process (Fig 5).

Step 9

In this step, as shown in Fig 14, the AP verifies the UA by comparing $[eqn]$ to $[eqn]$ . If the authentication succeeds, the AP computes $[eqn]$ and as shown in Fig 5, sends the values of $[eqn]$ , $[eqn]$ $[eqn]$ , and $[eqn]$ to the UA.

Step 9 of the proposed scheme executed by Aps.

Then, as shown in Fig 15, initially, the UA authenticates the AP using the value of $[eqn]$ . It then retrieves sensor information through the following steps:

Step 10 of the proposed scheme executed by UAs.

The UA decrypts $[eqn]$ to obtain the ambiguous identity of the sensor ( $[eqn]$ ) and $[eqn]$ (i.e., $[eqn]$ ) which is used to verify the integrity of healthcare information.The UA decrypts $[eqn]$ to obtain the gateway's location (position), the gateway's identity ( $[eqn]$ ), the timestamp $[eqn]$ , and healthcare information (Info) (i.e., $[eqn]$ ).The UA ensures the integrity of the information by comparing the received $[eqn]$ to $[eqn]$ . Thus, the UA is the only entity with access to the healthcare information and location, while only the ambiguous identities of the sensors are accessible to it.

1)Patient data retrieval by the ENd users

Fig 16 shows the proposed protocol for UAs to access patients’ healthcare data in three steps:

Patient data retrieval by the UA.

Step1: A UA initiates access by sending a request to any AP that includes the UA’s identifier ( $[eqn]$ ), the patient’s identifier ( $[eqn]$ ) and $[eqn]$ (as described in step 7 of the authentication phase) (see Fig 17).

Step 1 of data retrieval phase executed by UAs.

Step 2: Upon receiving the request, the AP authenticates the UA by decrypting $[eqn]$ with the AP’s private key. If authentication succeeds, the AP obtains from $[eqn]$ the selected-AP list for the patient ( $[eqn]$ ), the list of authorized UAs ( $[eqn]$ ), and the patient’s private verification data ( $[eqn]$ ) to determine whether the UA is permitted to access the patient’s records via this AP. If the AP appears in $[eqn]$ , it uses the index from $[eqn]$ to retrieve the patient’s stored data (e.g., $[eqn]$ , $[eqn]$ , and $[eqn]$ ) from its local database. The AP computes $[eqn]$ ) and returns this value together with the selected-AP list to the UA (Fig 18).

Step 2 of data retrieval phase executed by APs.

Step3: On receipt, the UA verifies the AP by checking $[eqn]$ and then decrypts the patient data as described in Step 10 of previous section. The UA may repeat this process to request the patient’s information from other APs in the selected list. Patients may also access their own medical records using the UA role (like Fig 15).

Evaluation

The subsequent subsections discuss the security and performance attributes of the proposed method and compare it to traditional approaches.

Performance evaluation

This section presents a comparison of the proposed method's performance against the approaches outlined in Refs. [25,51,89]. Subsequently, the analysis focuses on computation and communication overhead, latency, and the energy consumption of sensors. These metrics are assessed based on the configurations specified in Table 1 for each system component. Computation overhead is determined by measuring the execution times of encryption processes on system entities such as GWs, APs, and sensors, as detailed in Table 2. Furthermore, the execution times for blockchain operations—reported in Table 3—are obtained from Hyperledger Fabric version 1.4.0, under the system setup described in [90]. The issuance and verification times are recorded as 1766 ms and 733 ms, respectively, utilizing the Idemix protocol set and assuming a single attribute, as noted in [91].

Table 1: System configurations considered for evaluating the proposed method.

Table 2: Execution time of security primitives on sensors, GWs, and servers.

Table 3: Execution time of blockchain operations on hyperledger (smart contract asset size = 100 bytes) [90].

Computation overhead evaluation.

The computational overhead for each system entity is detailed in Table 4 and compared to the overhead of the methods described in refs. [25,51,89]. Reference [25,51] are our previous work. Ref. [25] offers a centralized, end-to-end privacy-preserving solution. In contrast, Ref. [51] presents a blockchain-based end-to-end privacy method. In addition, Ref. [89] presents a blockchain-based distributed privacy-preserving method for healthcare systems, which includes (1) sensors and the patient's smartphone, (2) an IoT health manager (IHM) that receives data from the smartphone and stores the hash of that information in the blockchain, (3) the blockchain and miners, (4) healthcare servers that initiate the primary blockchain, manage clusters, and register other entities, and (5) a healthcare wallet. Ref. [89] uses two separate chains—one for access policies and another for data—and assumes all entities are trusted while considering a secure channel between the sensors and the patient's smartphone. In this setup, the smartphone gathers information from the sensors, encrypts it with a symmetric key, and sends the encrypted data to the IHM. The IHM then analyzes the data and sends its hash to one of the miners, who checks the transaction cluster and forwards it to all miners in that cluster. Each miner verifies the transaction and adds it to the blockchain. Additionally, the IHM calculates and stores the access policy transaction in the policy chain for healthcare staff access control.

Table 4: Comparing the computation overhead of the proposed scheme with the approaches in refs. [25,51,89] (n: the number of shadow ids = 100, n: the number of aps = 10, and s: seg-size = 10).

In our scheme, considering the computational and power limitations of sensors, we use only lightweight operations such as hashing and XOR in sensors, shifting the computational burden to the gateways. While the computation overhead imposed to sensors is near to or even lower than that of some previous studies (see Fig 19), the computation time for GWs and APs is increased due to the overhead associated with blockchain operations. However, this trade-off results in enhanced privacy and security for the blockchain-based systems, effectively addressing the single point of failure issue. During the authentication and data transmission phases, the computational overhead of our proposed method is slightly higher than that of Ref. [89].

The computation overhead of sensors in the proposed scheme compared to the methods of Refs. [25,51] (for the setting with the number of shadow IDs = 100, the number of Aps = 10, and Seg-size = 10).

Communication overhead evaluation.

Table 5 presents the communication overheads of the protocol, which are calculated based on the number of transactions and the volume of messages exchanged by each entity. To determine the communication overhead, the sizes of an identity, a nonce, and a one-time token are assumed to be 4 bytes each, while the sizes of healthcare information and hash values are assumed to be 20 bytes and 16 bytes, respectively. Additionally, the size of the credential is considered to be 86 bytes like Ref. [97]. Our method employs 160-bit ECDSA, AES-128 CBC (16 bytes), and SHA1 (16 bytes) for ECC encryption and decryption, AES encryption, and hashing, respectively. Given the limited bandwidth of communication channels and the energy constraints of sensors, the communication overhead for sensors is more critical than for other entities. As shown in Fig 20, the total transaction volume in our proposed method is lower than that of Refs. [51,25,89]. Furthermore, as shown in Fig 21, the communication overhead for the sensor is less than that of Ref. [25,51] but slightly higher than that of Ref. [89]. The approach in Ref. [89] only ensures privacy for part of the end-to-end communication path and assumes that all system entities are trusted, failing to adequately address issues like anonymity against internal entities, untraceability, and resilience against attacks such as collusion, mining, replay, and impersonation. Therefore, the higher communication overhead of our proposed method is justified compared to Ref. [89], given its enhanced security capabilities for patients (see Table 8).

Table 5: Comparison of communication overhead in the proposed scheme with the methods in refs. [25,89].

Table 8: Comparing the proposed method to top-related work in terms of security features and resistance to attacks.

Communication overhead of the proposed scheme compared to the methods of Refs.[25,51,89].

Communication overhead of sensor in the proposed scheme compared to the methods of Refs. [25,51,89].

Latency evaluation.

Latency refers to the time it takes to transfer a healthcare data packet from a sensor to a UA [1]. This end-to-end latency encompasses both computing delay and communication delay. The computing delay is the total time taken for operations performed by each system entity according to the proposed protocol (as shown in Table 4). For communication delay, we assume a 250 kbps wireless link for connections between sensors and gateways (GWs), and a 20 Mbps broadband WAN link for connections among other entities. Additionally, queuing and routing delays are considered negligible. The communication delay is analyzed during the authentication and data transmission phases in comparison to Refs. [25,51,89]. Table 6 presents a comparison of the computation delay, communication delay, and total end-to-end delay of our proposed scheme with those of Refs. [25,51,89]. As shown in Fig 22, the results indicate that the communication delay of our protocol is lower than that of Ref. [25,51] but slightly higher than that of Ref. [89]. Regarding total end-to-end latency, our method results in greater latency than the others; however, this increase is deemed acceptable given the enhanced security features achieved.

Table 6: Comparison of computation overhead between the proposed scheme and the methods in refs. [25,89].

Communication delay and total end-to-end delay of the proposed scheme compared to the methods of Refs. [25,51,89].

Energy consumption.

Given that sensors have limited energy resources and their energy consumption is a critical factor, we will focus solely on the energy usage of the sensors. The energy consumption for a MICA2 sensor is calculated using the formula E = U × I × t [94], where the values for current (I) and voltage (U) are assumed to be 8 mA and 3.0 Volts, respectively. The time (t) is derived from the execution times of operations listed in Table 2. Additionally, the energy consumption for receiving and transmitting a bit on the MICA2 sensor is 2.36 μJ/bit and 4.28 μJ/bit, respectively [98]. Table 7 presents the energy consumption for sensors using our proposed method compared to the methods in Refs. [25,51,89]. As shown in Fig 23, the energy consumption for sensors in our scheme is less than Refs. [25,51], while Ref. [89] results in lower energy consumption. However, the approach in Ref. [89] assumes a secure channel between the sensors and the patient's cellphone, focusing only on the energy needed to transmit raw data to the cellphone. The energy required to establish and maintain a secure channel between the sensors and the gateway is not accounted for, as its specifics are not provided. If this energy were included, the sensor's energy consumption in Ref. [89] could be higher.

Table 7: Comparison of sensor energy consumption in the proposed scheme with the methods in refs. [25,89].

Sensor energy consumption of the proposed scheme compared to the methods in Refs. [25,51,89].

Security analysis

In this section, the security features of the proposed scheme are intuitively assessed. These security features include confidentiality, integrity, availability, privacy, anonymity, authentication, authorization, and scalability as discussed below:

Confidentiality

Confidentiality ensures that only authorized users have access to sensitive data [62]. In step 3, critical information such as $[eqn]$ are encrypted as $[eqn]$ which are accessed only by end users. Moreover, in step 6, healthcare data ( $[eqn]$ ), the location of GW ( $[eqn]$ ), and the identity of GW ( $[eqn]$ ) are encrypted as $[eqn]$ . In steps 8 and 9, the UA should authenticate itself to access patients’ information. Using private BCs such as $[eqn]$ $[eqn]$ $[eqn]$ , unauthorized access is prevented. In addition, in steps one, three, and five of Fig 3, the critical information is hashed as $[eqn]$ , $[eqn]$ .

Integrity

Data integrity refers to the assurance that data is received at its destination exactly as it was sent, without any alterations, and that it cannot be modified without authorization [38,62]. In step 6, healthcare information is encrypted as $[eqn]$ . Thanks to the immutability of blockchain technology, the integrity of this information is maintained. In step 7, the integrity of healthcare data is further secured by incorporating the hash of the data block for $[eqn]$ and $[eqn]$ into both $[eqn]$ and $[eqn]$ , respectively. The sensor computes $[eqn]$ in step 5 to confirm the integrity of the healthcare data to the UA in step 9. Additionally, the AP calculates $[eqn]$ to verify the integrity of $[eqn]$ to the sensor.

Availability

Patients and end users can access the healthcare system even if their previous AP is unavailable, as all APs can assist them by utilizing $[eqn]$

Privacy

In the proposed method, unauthorized adversaries cannot access sensitive information or location data. The healthcare information is encrypted and stored in the local database of the APs, with its hash saved in $[eqn]$ to prevent any modifications. Additionally, the AP records the hash of the data block from $[eqn]$ in both $[eqn]$ and $[eqn]$ . The GW authenticates itself to the AP using Idemix, which employs ZKP authentication, ensuring that the true identity of the GW supporting the user is not disclosed to the AP. Consequently, the user's location remains concealed even if the GW is known. Furthermore, the sensor utilizes a one-time token, and the AP encrypts the ambiguous identities of patients’ sensors, their locations, and healthcare data using the UA public key through $[eqn]$ and $[eqn]$ , respectively.

Anonymity

In this paper, the true identities of sensors and GWs are protected from both unauthorized entities and external attackers. By utilizing one-time tokens and shadow identities, the anonymity of the sensors is maintained against GWs and external threats. Patients store $[eqn]$ , $[eqn]$ and $[eqn]$ in the private blockchain*,* $[eqn]$ , which is only accessible to authorized APs. Both GWs and patients employ Idemix for anonymous authentication to the AP using the ZKP technique.

Authentication

The sensor employs a one-time token and shadow identities, specifically $[eqn]$ and $[eqn]$ , for anonymous authentication to the GWs with assistance from the APs. Additionally, the private blockchain ( $[eqn]$ ) is utilized to store critical sensor information, such as $[eqn]$ $[eqn]$ , $[eqn]$ , and $[eqn]$ GWs use Idemix for anonymous authentication to the APs, while UAs and APs rely on public keys and certificates for mutual authentication.

Authorization

In this context, authorization refers to the fact that only designated UAs are permitted to access patients’ information. The ambiguous identities of patients’ sensors, their locations, and healthcare data are encrypted using the UA’s public key as $[eqn]$ and $[eqn]$ ensuring that only authorized users can access sensitive patient information.

Scalability

Scalability refers to the ability to manage a growing volume of data and an increasing number of users within the system [99]. Our protocol achieves scalability by utilizing network clustering and storing only the hash of the healthcare data in $[eqn]$

Additionally, we address the security of the proposed scheme against various attacks, including Denial of Service (DoS), modification, mining, storage, replay, impersonation, man-in-the-middle attacks, and collusion, which are discussed in detail below.

Denial of Service (DoS)

This attack occurs when numerous transactions are directed to a destination in an attempt to disrupt its availability [47]. By employing network clustering, we reduce both the impact and likelihood of a Denial of Service (DoS) attack. This means that if an attack does occur, only a portion of the nodes will be affected, rather than all of them. Moreover, using private BC ( $[eqn]$ ) helps all application providers to serve the patients. Therefore, if one AP goes out of reach, the others can still serve its users. In addition, our scheme checks the UA authentication and has limitations in the number of acceptable unsuccessful access requests.

Modification

Attackers may modify or delete patients’ data [47], which includes healthcare information, $[eqn]$ , $[eqn]$ and $[eqn]$ during a modification attack. In step 3, the patient's critical information, $[eqn]$ and $[eqn]$ are encrypted as $[eqn]$ . In step 6, the gateway's ID ( $[eqn]$ ), the location of the GW, and healthcare information are encrypted as $[eqn]$ . Additionally, in step 7, healthcare data is encrypted and stored in the local database of the APs. The hash of the healthcare data is also saved in $[eqn]$ . Furthermore, the hash values of the data blocks from $[eqn]$ and $[eqn]$ are stored in $[eqn]$ and $[eqn]$ , respectively. Finally, the end user can verify the integrity of the healthcare information through the message authentication code ( $[eqn]$ ) calculated by the sensor in step 5.

Mining

In a mining attack, a group of nodes, constituting 51% of the system, collaborates to introduce a fraudulent chain into the blockchain [39]. To mitigate the risk of such an attack, our scheme employs a private blockchain ( $[eqn]$ ) that stores the hash of the last block from each private blockchain in the overlay network (i.e., $[eqn]$ ).

Storage

A storage attack involves attackers deleting, modifying, or adding data within the database [62]. In step 7, the hash values of healthcare information are recorded in $[eqn]$ . Additionally, the hash values of the data blocks from $[eqn]$ are stored in $[eqn]$ . Furthermore, the hash values of the data blocks from $[eqn]$ are stored in $[eqn]$ to help detect any modifications.

Replay

In a replay attack, attackers resend intercepted messages from previous sessions to gain access to information without proper authentication [100]. Our scheme is resistant to replay attacks because it employs a one-time token and shadow identity in step 1, along with a timestamp in the calculation of $[eqn]$ .

Impersonation

In this attack, an attacker forges the identity of one of the real system entities and acts instead of that entity for malicious purposes. During sensor authentication, a one-time token, $[eqn]$ , and an identifier, $[eqn]$ , are used by sensors. Moreover, these two values and the shadow identifiers are only available to the sensors. Therefore, an attacker cannot impersonate the sensors. Besides, at the end of each session, the value of $[eqn]$ is updated. Moreover, in step 2, the GW is anonymously authenticated to the AP using Idemix. Since the GWs utilize a zero-knowledge proof scheme, an attacker is not able to forge herself/himself as a trusted GW. In the case of APs, they utilize their private keys to sign a random variable and authenticate themselves to the GWs. As a result, the attacker is not successful to act as a valid AP. Similarly, for UA authentication to the APs, the UAs utilize their private keys. Therefore, attackers are not able to impersonate themselves as valid application users.

Man-in-the-Middle

As previously mentioned, our scheme ensures mutual authentication between system entities, which helps prevent man-in-the-middle attacks, making our proposed solution resilient to this threat. Additionally, by incorporating a random variable, a one-time token, and an ambiguous key for sensor authentication, the protocol further defends against man-in-the-middle attacks. The gateway also authenticates itself anonymously as a valid gateway using Idemix. Furthermore, the use of private keys and timestamps in the authentication process for APs and UAs enhances the protocol's resistance to this type of attack. Consequently, it is not possible to use messages from previous sessions in the current session.

Collusion

Since the real identity of patients and their sensors are not revealed to other entities, the collusion between them cannot expose the real identity of patients. Also, the AP only accesses to the ambiguous identities of sensors and encrypted healthcare information. Therefore, the proposed scheme is safe against the collusion of system entities.

As shown in Table 8, we compare the proposed method to previous researches (both the ones that use centralized infrastructure and those which exploit blockchain) in terms of security features and resistance against attacks. As seen, compared to related work, the proposed method provides more security features. Considering the selected centralized method presented in Ref. [25], it is obvious that the scheme faces a single point of failure problem. Therefore, in case of any problem for the network management (NM) entity, it is not possible to serve patients, and therefore the availability and scalability of the system are highly dependent on the availability of NM. Also, the data is sent without encryption, which endangers the confidentiality of the data.

In comparison to the most similar blockchain-based method presented in Ref. [89], it is important to note that their scheme primarily addresses privacy preservation for only a portion of the end-to-end communication path. They rely on trusted entities and assume a secure connection between the sensors and gateways. Additionally, they do not account for issues such as collusion, patient anonymity, and untraceability. In contrast, our proposed method leverages the distributed nature of blockchain and utilizes clustering to ensure availability and scalability, while also avoiding a single point of failure. We maintain end-to-end privacy and assume the presence of semi-honest entities. Our approach is resilient to collusion among internal entities, and patient anonymity is ensured through the anonymous authentication of sensors and gateways.

Conclusion

This paper presents an end-to-end privacy-preserving protocol that utilizes Idemix with Hyperledger Fabric to safeguard patient privacy. The proposed scheme ensures the anonymity of patients against both internal and external threats. Idemix achieves identity privacy through a blind signature scheme and efficient zero-knowledge proofs. Given the resource constraints of sensors, it employs lightweight operations such as XOR and hashing for securing sensor communications. Importantly, the real identities of sensors and gateways (GWs) remain concealed from APs, preventing them from linking healthcare information, location data, and patient identities. This effectively protects both location privacy and data privacy from inquisitive APs. Additionally, patients’ identities are not exposed to the GWs, ensuring that privacy is maintained against these entities as well. Only authorized user applications (UAs) can access patients’ healthcare information and locations. Consequently, each intermediary entity possesses only a fragment of patient information, preventing them from connecting identity, location, and healthcare data. The GWs can access only location and healthcare information without knowing the patients’ true identities, while the APs can only see the obfuscated identities of patients and their sensors.

A comprehensive security analysis indicates that our protocol ensures confidentiality, integrity, availability, authentication, authorization, anonymity, and scalability, thus providing end-to-end privacy in healthcare systems. It further demonstrates resilience against various attacks, including DoS, modification, mining, storage, and replay attacks. In contrast to traditional centralized methods, our approach is also resistant to collusion attacks. Moving forward, we suggest implementing flexible privacy levels tailored to individual patient preferences as an extension of the proposed method.

Supporting information

S1 FileAll generated data from analysis of compared protocols.(XLSX)