Startseite PLASMA-Privacy-Preserved Lightweight and Secure Multi-level Authentication scheme for IoMT-based smart healthcare
Artikel Open Access

PLASMA-Privacy-Preserved Lightweight and Secure Multi-level Authentication scheme for IoMT-based smart healthcare

  • Manjunath Hegde , Karthik M. , Varun Hegde , Rohini R. Rao , Vinayak M. Mantoor und Radhakrishna Bhat EMAIL logo
Veröffentlicht/Copyright: 7. April 2025
Veröffentlichen auch Sie bei De Gruyter Brill

Abstract

The Internet of Medical Things has enabled the development of smart healthcare systems, allowing users to collect, process, and transmit patient health data to cloud servers for further analysis. Internet of Things devices and cloud servers’ physical distance raise network latency and jitter even with ample storage and processing capability. Additionally, this connectivity raises serious challenges about security and privacy in smart healthcare environments. In this article, we focused on addressing those security concerns in a hierarchical smart healthcare system involving devices, gateway, and medical servers. To show the security issues in the existing solution, we reviewed the Das and Namasudra authentication scheme, identifying vulnerabilities such as replay attacks, device impersonation, and denial of service attacks. This article proposes a Privacy-Preserved Lightweight and Secure Multi-level Authentication (PLASMA) scheme to mitigate these vulnerabilities. PLASMA’s security and key privacy are validated through the Real-Or-Random (ROR) model and simulated using the widely accepted Scyther tool. PLASMA’s performance was evaluated by comparing its computational and communication costs with related schemes, and functional analysis was demonstrated to show the security and efficiency of the scheme. The results prove that PLASMA offers a secure, scalable solution for smart healthcare systems.

1 Introduction

Advancements in the Internet of Things (IoT) are moving toward creating more and more connected systems. More than 75 billion devices are expected to be connected by 2025 [1]. Nowadays, IoT-enabled healthcare, widely known as smart healthcare, has gained popularity in the field of health technology. In smart healthcare systems, many IoT devices are interconnected, creating a healthcare system for exchanging information between the user and the server, which helps with better decision-making. Integrating the IoT into the medical field is known as the Internet of Medical Things (IoMT). The IoMT enables the connected network of smart devices, such as wearable sensors, medical instruments, and hospital assets, to establish an integrated information platform for healthcare [2,3].

In modern healthcare systems, IoMT is crucial in collecting patient health data and transmitting it to servers for analysis. Medical professionals can use cloud computing and machine learning algorithms to analyze these data and diagnose patient health conditions locally or remotely. IoMT enables the remote patient monitoring and also contributes diagnosis and treatment based on the analyzed results. In the IoMT, devices are equipped with sensors to collect data that are transmitted to the cloud server for processing. However, due to the physical distance between the cloud infrastructure and IoMT devices, there is a significant increase in network latency and jitter despite the cloud’s unlimited storage and processing capabilities. Increasing latency is a bottleneck for real-time applications requiring high bandwidth, mobility support, fast response time, and geo-distribution. To overcome the challenge, deploying Fog servers as a gateway can create a lightweight layer between IoMT devices and the cloud server. Also, establishing an extra gateway layer improves scalability and ensures efficiency in processing big data from numerous devices.

Integrating the IoMT with cloud computing improves connectivity and communication but raises concerns about security threats. The sensitive data of IoMT devices transmitted through insecure channels can be intercepted or modified. System administrators may need more time to assess all security threats on the network. Inadequate security mechanisms, lack of cyber intelligence, and insecure communication networks in the healthcare sector have resulted in numerous cyber attacks. To mitigate these risks, it is essential to establish secure communication channels over insecure networks.

Authentication is a first-level and significant cryptographic solution to preserve the device’s privacy and establish a secure communication channel. Authenticated key agreement (AKA) protocols enable two or more parties to share a common session key to secure the communication channel over an insecure public network [4]. When the gateway nodes are involved in the IoMT-based healthcare system, they are responsible for preprocessing the healthcare data obtained from the devices and sending it to the cloud server in a structured manner. Therefore, the gateway must receive the instructions from both the server and the device. In this system architecture, traditional two-party authentication schemes are not adaptive [5]. Also, the existing protocols are vulnerable to attacks and only fulfill some security requirements. Possible vulnerabilities are discussed in Section 1.1. Therefore, it is required to propose an enhanced authentication scheme that suits the smart healthcare environment. In this article, the authors proposed an authentication scheme called PLASMA, a Privacy-Preserved Lightweight and Secure Multilevel Authentication Scheme for IoMT-based Smart Healthcare. As a demonstration, the authors cryptanalyzed the Das and Namasudra authentication scheme and illustrated possible vulnerabilities. Also, the proposed PLASMA’s security analysis was carried out, and it proved that the scheme is secure against various attacks.

1.1 Literature review

In 2019, Ostad-Sharif et al. [6] thoroughly analyzed three authentication schemes previously proposed by Giri et al. [7], Amin and Biswas [8], and Hamed and Abbas [9]. They identified vulnerabilities to key compromise impersonation attacks within these schemes. To address this issue, Sharif et al. developed an enhanced elliptic curve cryptography (ECC)-based mutual authentication and session key generation scheme for healthcare applications. Jia et al. [5] proposed a key agreement protocol for three parties that relies on bilinear pairings to ensure authentication. Following this, Khatoon et al. [10] proposed an authentication and key agreement scheme, which mainly adopts bilinear pairing centered on privacy and designed for telecare medical information system, incorporating a fuzzy extractor to identify patients securely using biometric data.

In 2020, Masud et al. [11] proposed a mutual authentication and secret key establishment protocol that uses physical unclonable functions (PUFs) to enable network devices to verify the doctor’s legitimacy and sensor node before establishing a session key. In the same year, Wong et al. [12] analyzed the authentication scheme proposed by Zhang et al. [13] and identified that the scheme suffers from denial of service (DoS) attack. Also, Masud et al. identified that the scheme lacks time-bound-based access control and multi-server environment. The authors develop a three-factor authentication scheme for multiserver e-health systems to address the identified issue. Later, in 2020, Fotouhi et al. [14] identified that related schemes cannot simultaneously address security and privacy problems such as perfect forward secrecy and untraceability and resistance against the key compromise impersonation attack in wireless body area networks-based healthcare. To address the identified issues, the authors proposed hash-chain-based and forward secure authentication scheme for wireless body area networks in healthcare IoT.

In 2021, Li et al. [15] highlighted the limitations of existing schemes, ranging from performance to security concerns, and introduced a lightweight, provably secure scheme named provably secure and lightweight mutual authentication and key agreement for use in fully public IoMT channels. Masud et al. [16] proposed a user authentication scheme that preserves anonymity and is tailored for IoT-based healthcare services. Wang et al. [17] raised concerns about the neglect of physical-layer security by most schemes and the issue of overcentralization in wireless medical sensor networks (WMSNs), proposing a solution through a lightweight authentication protocol that leverages blockchain technology and PUFs. Additionally, Wu et al. [18] critically analyzed Jia et al.’s [5] scheme, pointing out its vulnerability to known session-specific temporary information attacks and a lack of per-verification, leading to the development of an improved authentication for Fog-Driven IoT healthcare systems. Sowjanya et al. [19] reviewed He et al.’s [20] scheme, identifying vulnerabilities to known session-specific temporary information attacks, insider attacks, and clock desynchronization attacks, and proposed an ECC-based anonymous authentication protocol for IoMT to address these issues.

In 2022, Yu and Park [21] critically analyzed the scheme proposed by Wang et al. [17], highlighting its vulnerabilities to man-in-the-middle and session key disclosure attacks, while also pointing out its failure to ensure mutual authentication. To address the identified issues, the authors proposed an authentication scheme for WMSNs that involves blockchain technology and PUF. Gupta et al. [22] pointed out that existing schemes aimed at securing the IoMT come with high computational and communication costs. They also noted the scarcity of schemes that maintain user anonymity within wireless sensor networks. To overcome these challenges, they proposed an anonymous mutual authentication scheme specifically designed for wearable devices within the IoMT system. Sumithra et al. [23], in their 2022 study, identified various vulnerabilities in existing mutual authentication and key agreement protocols, such as susceptibility to replay, insider, impersonation attacks, and password guessing. They also highlighted the lack of guarantees for user privacy and key agreements between patients and medical servers. To address these shortcomings, they proposed a new authentication scheme tailored to healthcare information systems. Finally, in 2022, Chen et al. [24] introduced a novel three-factor internet of health things-based protocol named lightweight authentication protocol for the internet of health things, which integrates authentication and key negotiation strategies. This scheme is distinctive for using biometric characteristics, XOR operations, and one-way hashing, to provide secure authentication.

In 2023, Ma et al. [25] analyzed Wang et al.’s [26] certificateless AKA scheme designed for smart healthcare systems, revealing that the protocol lacked forward security. To address this security flaw, the authors introduced an enhanced certificateless AKA scheme, building upon Wang et al.’s initial proposal. Concurrently, Kim et al. [27] evaluated Masud et al.’s [16] scheme, initially presented in 2021, and found it susceptible to offline password guessing, impersonation, and privileged insider attacks. In response, they developed a more secure user authentication scheme tailored for the IoMT. Moving forward to 2024, Saini et al. [28] reviewed Soni et al.’s [29] scheme, pinpointing its vulnerabilities to user impersonation and offline password-guessing attacks. To mitigate these issues, they proposed a robust user authentication scheme for wireless healthcare sensor networks. Finally, in the same year, Aldosary and Tanveer [30] highlighted that many existing authentication schemes, reliant on computationally intensive symmetric and asymmetric encryption methods, were prone to attacks such as privileged insiders and compromise of key from the medical server. To address these challenges, they introduced a novel authentication scheme, PUF and authenticated encryption based authentication framework for the IoT-enabled smart healthcare system (PAAF-SHS). Using PUFs, the GIFT-COFB authenticated encryption algorithm is included, as are fuzzy extractors, one-way hash functions, and straightforward XOR operations.

1.2 Motivation and contribution

We have summarized important authentication schemes and presented in Table 1 to provide a comprehensive overview. From Table 1, we observed three significant issues in the IoMT-based healthcare framework.

  • When fog servers act as gateway nodes, they usually carry out initial preprocessing of healthcare data gathered from IoMT devices. Following this, the preprocessed sensor data are forwarded to the medical server. As a result, the gateway servers need to receive directions from both the cloud server and the users. In this context, conventional two-party authentication schemes are inadequate for the computing environment.

  • Some of the schemes focus exclusively on two-party, which authenticates only the device and the gateway, neglecting the server’s involvement. Neglecting the authentication between the gateway and cloud servers may lead to vulnerabilities, such as servers masquerading.

  • A few schemes create multiparty authentication whereby all entities, including the server, participate in the communication process. However, the devices in these systems do not interact directly with the server. In existing multiparty authentication schemes, the server must authenticate both the device and the gateway. When servers communicate with many devices, these multiparty authentication approaches can reduce the gateway’s role within the communication network. As a result, it is more practical for the server to focus on authenticating only the gateways rather than both the gateways and the devices.

Table 1

Literature review summary

Author Year Attack addressed Cryptographic techniques applied
Ostad-Sharif et al. [6] 2019 Key compromise attack ECC
Impersonation attack Symmetric encryption/decryption
One-way hash function
Jia et al. [5] 2019 User anonymity and untraceability Bilinear pairing and ECC
Perfect forward privacy One-way hash function
Offline dictionary attack
Man-in-the-middle attack
Khatoon et al. [10] 2019 Anonymity and unlinkability Bilinear pairing and ECC
Offline guessing attack Fuzzy extractor
Server impersonation attacks One-way hash function
Masud et al. [11] 2020 Man-in-the-middle attack Symmetric encryption/decryption
Impersonation attacks One-way hash function
Anonymity and untraceability
Wong et al. [12] 2020 DoS attack One-way hash function
Biometric storage Symmetric and asymmetric encryption/decryption
Time-bound-based access control
Li et al. [15] 2021 Anonymity and untraceability One-way hash function
Replay attack
Impersonation attacks
Man-in-the-middle attack
Wu et al. [18] 2021 Impersonation attacks Bilinear pairing and ECC
Man-in-the-middle attack Fuzzy extractor
Replay attack One-way hash function
DoS attack
Sowjanya et al. [19] 2021 Session-specific temporary information ECC
Insider attack One-way hash function
Yu and Park [21] 2022 Man-in-the-middle attack ECC
Session key disclosure attack One-way hash function
Gupta et al. [22] 2022 Man-in-the-middle attack One-way hash function
Impersonation attacks
Anonymity and untraceability
Chen et al. [24] 2022 Insider attack Hash function
User impersonation Fuzzy extractor/reproduction function
Replay attacks Asymmetric encryption/decryption
Ma et al. [25] 2023 Forward security ECC
One-way hash function
Symmetric encryption/decryption
Kim et al. [27] 2023 Password guessing attack Hash function
Privileged insider attack Fuzzy extractor/reproduction function
Replay attack
Saini et al. [28] 2024 Offline password guessing ECC
User impersonation Hash function
Aldosary and Tanveer [30] 2024 Untraceability/anonymity Fuzzy extractor/reproduction function
DoS attack Hash function
Replay attacks Symmetric encryption/decryption
Man-in-the-middle attack

We reviewed many authentication schemes developed for smart healthcare systems and noted shortcomings in these solutions. As a demonstration, we show the review and cryptanalysis of the Das and Namasudra authentication scheme, revealing their susceptibility to replay attacks, impersonation attacks, and DoS attacks. Then, we proposed a robust authentication scheme in response to these identified vulnerabilities. The key contributions of this article include the following:

  • The development of a novel, authentication scheme, called PLASMA, for IoMT-based smart healthcare environments. This scheme is suitable for a hierarchical authentication process in which the server authenticates the gateways, and the gateway authenticates the devices. This hierarchical framework significantly boosts the system’s efficiency, even as the number of devices scales up. The authentication process leverages symmetric trivariate polynomial, ECC, and cryptographic hash functions, ensuring robust security.

  • A detailed cryptanalysis of PLASMA demonstrates its resilience against replay attacks, impersonation attacks, and DoS attacks. Furthermore, the scheme proves its security against many other potential threats, including insider attacks and man-in-the-middle attacks, ensuring forward secrecy and device anonymity. The scheme’s security against an adversarial model is presented through the real-or-random (ROR) model. The security verification process also uses the Scyther tool simulation to support the scheme’s robustness.

  • An evaluation of the proposed scheme’s performance, focusing on computational and communication overheads, showcases its efficiency when compared against existing schemes. The functional analysis proves that PLASMA successfully addresses security and efficiency, minimizing the typical trade-offs between these aspects.

This article is organized as follows: Section 2 describes the system models for the IoMT-based healthcare network, covering both the network model (2.1) and the threat model (2.2). Section 3 introduces the cryptographic foundations required for developing the authentication scheme. Section 4 provides a detailed review of the Das and Namasudra authentication scheme, explaining its various phases. Section 5 performs a cryptanalysis of the Das and Namasudra scheme, highlighting its potential weaknesses. Section 6 illustrates the proposed authentication scheme, PLASMA. Section 7 provides a security analysis of PLASMA, with an informal analysis (7.1) and a formal analysis using the ROR model (7.2) and the formal security verification results from the Scyther tool (7.3). Section 8 assesses the efficiency of PLASMA by comparing computation and communication costs (8.1) and conducting a functional analysis (8.2). Finally, Section 9 provides the conclusion of this article.

2 System model

In this section, we present the system model, which encompasses the authentication network architecture as well as the attacker’s capability to execute various attacks.

2.1 Network model

In the proposed system, we recommended, three-layer architecture: (1) the device layer ( D i ), (2) the gateway layer ( GW i ), and (3) the medical server layer ( MS i ). The network model connects IoMT devices, gateway nodes, and medical servers in a hierarchical framework.

  • Device layer: The layer contains IoMT devices. For example, smart bands are equipped with sensors that capture health data such as heart rate and blood pressure.

  • Gateway layer: This layer comprises fog servers and networking tools in charge of first-level data collection and processing, as well as data cleaning and organization for subsequent analysis.

  • Medical server layer: This layer is necessary to store the data collected from the gateway nodes and perform the analysis.

Figure 1 illustrates the suggested system architecture together with the authentication technique. Under the proposed system concept, medical servers do not need to gather the raw data from the sensor node, since the gateway layer will handle the preprocessing. Therefore, the medical server does not need to authenticate the sensor where it must authenticate the gateway layer. Likewise, the gateway layer is responsible for authenticating the IoMT devices. Thus, authentication between a device, a gateway, and a medical server does not have to be parallel.

Figure 1 
                  Proposed network model and authentication framework.
Figure 1

Proposed network model and authentication framework.

2.2 Attacker model

The widely accepted Dolev–Yao (DY) model, as described in the study by Dolev and Yao [31], explains the capabilities of an adversary ( A ) to execute any form of attack. The model assumes that the attacker has full control when the communication channel is insecure. Therefore, attacker can intercept, disrupt, forge, and eavesdrop the communication messages.

In this model, IoMT devices and gateway nodes are considered untrustworthy, as they are susceptible to various attacks, including compromise or theft by the adversary.

  • An attacker can eavesdrop on the exchanged messages. In addition, A can delete or modify communication messages during transmission.

  • An attacker with access to all the data stored on various devices could conduct a collusion attack. Using these devices’ data, the attacker could bypass the cryptographic protections by calculating additional temporal decryption keys.

  • An attacker with physical access to IoMT sensors could steal credentials and private data from the devices’ memory. The attacker can perform unauthorized activities from the extracted data, such as calculating session keys or performing impersonation attacks. Furthermore, the adversary may perform side-channel attacks or power analysis to get the session keys and secret credentials. However, attacks against devices resistant to tampering need expensive and specialized equipment, which may reduce the attacker’s incentive.

Besides the DY model, we have also taken into account of the ROR model. According to the ROR-adversary model, an attacker can access confidential credentials, session keys, and states within sessions. Furthermore, the attacker can capture IoT devices and perform a power analysis attack to retrieve stored information.

3 Cryptographic preliminaries

This section presents the key cryptographic fundamentals used to analyze existing authentication schemes and propose new ones. We have not included illustrations for minor operations such as XOR and concatenation.

3.1 Cryptographic hash function

A cryptographic hash function is a deterministic function that takes the input string of variable lengths and produces a fixed-length output. The function can be expressed as y = h ( x ) , with x being the input and y being the output. The output preserves a uniform length regardless of the input size. Hash functions are irreversible, which means computing the hash is possible, but reversing it is nearly unachievable. Furthermore, no two different inputs contain the same hash value; each input results in a unique and non-reversible hash.

3.2 Symmetric trivariate polynomial

A trivariate polynomial defined in the finite field G F ( p ) , of degree t , can be represented as follows: f ( x 1 , x 2 , x 3 ) = i 1 , i 2 , i 3 = 0 t a i 1 , i 2 , i 3 ( x 1 ) i 1 ( x 2 ) i 2 ( x 3 ) i 3 , where the coefficients a i 1 , i 2 , i 3 are randomly selected from the finite field G F ( p ) , where p is a large prime to accommodate the cryptographic key. Furthermore, for a trivariate polynomial to be classified as symmetric, it must adhere to the condition f ( x 1 , x 2 , x 3 ) = f ( x σ ( 1 ) , x σ ( 2 ) , x σ ( 3 ) ) for every permutation σ : 1, 2, 3 1, 2, 3 [32,33].

4 Review of the Das and Namasudra scheme

The Das and Namasudra scheme has four phases: (1) offline registration, (2) mutual authentication phase, (3) recovery from gateway failure, and (4) device mobility. In this framework, D i represents the devices; G j indicates the IoT gateway, where i = { 1 , 2 , , I } ; and j = { 1 , 2 , , J } , with the condition that I > J , and CA represents the central administrator.

4.1 Offline registration phase

In this phase, D i registers with G j before the authentication process. First, D i sends a registration request R Req to G j , where R Req is the identity of D i . On the other side, G j receives the request, selects a random number x, and computes AID = DID x and adds AID to its registered device list R Device . Furthermore, G j sends registration confirmation and a pre-shared key PK i with D i . Finally, G j periodically shares its updated list of registered devices R Update with the CA.

4.2 Mutual authentication phase

In the mutual authentication phase, first, D i selects a random nonce n 1 and computes S Req = AID PK i n 1 and S Hash = AID PK i sends an authentication request { S Req , S Req } to G j .

Gateway G j receives { S Req , S Req } and retrieves AID and searches in registration list ( R Device ). If AID exists, then gateway computes n 1 = S Req AID PK i . Furthermore, G j selects a random nonce g 1 , computes G c h = n 1 g 1 PK i , and sends G c h to the device.

D i receives G c h and retrieves g 1 by computing g 1 = G c h n 1 PK i . Furthermore, D i computes D Res = ( g 1 n 1 ) and sends D Res to the G j . Gateway receives D Res , computes g = D Res n 1 , and verifies g = g 1 . If both are equal, then accept S Req ; else, drop the session.

4.3 Recovery from gateway failure

In this phase, when the gateway G j is unavailable, the CA shares R Update with the gateway G j + 1 . Furthermore, device D i sends S Req to G j + 1 . When G j + 1 receives S Req , it retrieves AID from S Req and searches AID in R Device . If the AID is found, G j + 1 proceeds with the same steps followed during the mutual authentication phase; else, drops the session.

4.4 Mobility of any device from one gateway to another

This phase performed when a registered D i moved from G j to G j + 1 . Consider a device D i attached to the patient and registered with G j . When D i moves from G j to G j + 1 , it notifies G j of its mobility. As a result, G j cancels the device’s registration and authentication by removing its entry from the R Update list and updating it accordingly. Next, D i sends a S R e g message to G j + 1 to authenticate itself. Importantly, D i does not need to go through the registration process again. When G j + 1 receives S R e g , it uses the same procedure to authenticate D i after retrieving all the information about it from the CA’s R Update list.

5 Cryptanalysis of the Das and Namasudra scheme

In this section, we performed the cryptanalysis of the Das and Namasudra scheme. We have demonstrated that the scheme is vulnerable to device impersonation attacks, DoS attacks, and replay attacks. A comprehensive proof of these vulnerabilities is provided in the following.

5.1 Vulnerable to replay attack

The authors of the Das and Namasudra scheme, claim that it uses timestamps. Despite this, the login request parameters S Req = AID PK i n 1 and S Hash = AID PK i do not rely on the timestamp. This creates a security vulnerability in the timeliness of messages received. The adversary A can perform the attack by resending a successfully authenticated message. When a gateway receives such messages, it accepts the received message and retrieves the random number n 1 . It then generates a new random nonce g 1 , calculates G c h , and sends it back to A . Now possessing g 1 , the attacker can compute D Res and send it back to the gateway. The gateway authenticates the attacker as a legitimate device when it checks D Res . Hence, the scheme is susceptible to replay attacks.

5.2 Susceptible to device impersonation attack

Suppose an attacker A gains control of an IoT device and manages to extract the stored parameters { AID , PK i } , as well as intercept the communication parameters { S req , S hash } . Now, A can impersonate by choosing a random number n 1 and creating a new request signature S req by performing S req = AID PK i n 1 . Furthermore, A computes S = h ( AID PK i ) , and forwards to the gateway. Gateway receives { S req , S } , extracts n 1 , and generates a random nonce g 1 , calculates G , and sends it back to the attacker. Then, A deciphers g 1 , calculates D Res , and sends it to the gateway. Upon verifying D Res , the gateway mistakenly authenticates A as the legitimate device. As a result, A successfully impersonated the device.

5.3 Susceptibility to DoS attack

In Sections 5.1 and 5.2, we proved that the scheme is vulnerable to replay and impersonation attacks. When an attacker performs a replay attack or impersonates a device, they can gain access to the gateway by posing as a legitimate device. In this scenario, an attacker can transmit the device from its original gateway to a new one without undergoing any registration process. If an attacker sets up a malicious gateway and transfers a legitimate user’s device to this compromised gateway, the user will be unable to connect to the legitimate gateway. Consequently, this scenario shows susceptibility to DoS attacks.

6 Proposed authentication scheme – PLASMA

To address the identified security vulnerabilities in the reviewed scheme, we proposed PLASMA, specifically designed for use in IoMT-enabled smart healthcare environments. The PLASMA scheme consists of three phases: (1) system initialization, (2) registration, and (3) login and authentication. The registration phase is divided into gateway registration and device registration, with the same distinction made in the login and mutual authentication phase. The authentication process for both gateway and device is clearly separated, and the detailed steps of each phase are outlined in the following.

6.1 System initialization phase

Medical server is responsible to initialize the entire system. The server generates few parameters such as selection of elliptic curve E p over a finite field F p , where p represents a large prime. Additionally, the server picks a point G on the chosen elliptic curve. Furthermore, server chooses the private key x and calculates the public key K pub = x G . Later, the server chooses the hash functions H 1 ( ) Z * , H 2 ( ) Z * , H 3 ( ) Z * , and H 4 ( ) Z * . Finally, server publishes the parameters { E p , F p , G , K pub , H 1 ( ) , H 2 ( ) , H 3 ( ) , H 4 ( ) }

6.2 Registration phase

6.2.1 Gateway registration phase

Gateway registration will be made with the server as follows:

  1. Gateway chooses the identity GID i and sends it to the server.

  2. Server receives the request message and generates e g and the registration timestamp RT g .

  3. Furthermore, the server computes M g w = H 1 ( x e g ) , and also computes two public keys

  4. GW master = e g K pub ,

  5. GW pub = e g G ,

  6. V g w = H 1 ( M g w RT g ) ,

  7. H g w = H 1 ( V g w M g w GID i ) .

  8. Server sends the parameters { M g w , H g w , GW master , GW pub , V g w , g ( x , y , z ) , H 1 ( ) , H 2 ( ) } .

  9. Gateway receives the parameters sent by the server and stores into the memory.

Table 2 outlines the overview of the gateway registration process.

Table 2

Gateway registration phase

Gateway Server
Choose GID i
{ GID i }
Generates e g and RT g
Computes
M g w = H 1 ( x e g )
Public Keys = GW master = e g K pub ,
GW pub = e g G
Computes
V g w = H 1 ( M g w RT g ) ,
H g w = H 1 ( V g w M g w GID i )
{ M g w , H g w , GW master , GW pub , V g w }

6.2.2 Device registration phase

The overview of the initial gateway registration stage is given in Table 3. Device registration will be carried out with the gateway as follows:

  1. Generates DID i and b i and sends them to the gateway.

  2. Gateway receives the request message and generates e d and registration timestamp RT d .

  3. Furthermore, gateway computes the following:

  4. M d = H 3 ( b i e 2 ) ,

  5. Also, computes two public keys:

  6. GWD pub = b i G ,

  7. GWD master = e d GWD pub ,

  8. Furthermore, it computes

  9. V d = H 3 ( M d RT g ) ,

  10. H d = H 3 ( V d M d DID i ) ,

  11. D sec = e d H 3 ( H 3 ( b i DID i ) RT g ) .

  12. Gateway sends { M d , H d , GWD master , GWD pub , V d , f ( x , y , z ) , H 3 ( ) , H 4 ( ) } to the device. Also, it stores D sec in to its database.

  13. Device receives the parameters sent by the gateway and stores in to its database.

Table 3

Device to gateway registration phase

Device Gateway
Generates DID i and b i
{ DID i , b i }
Generates e d and RT d
M d = H 3 ( b i e 2 )
Public Keys GWD pub = b i G
GWD master = e d GWD pub
V d = H 3 ( M d RT g ) ,
H d = H 3 ( V d M d DID i )
D sec = e d H 3 ( H 3 ( b i DID i ) RT g )
{ M d , H d , GWD master , GWD pub , V d }

6.3 Login and authentication phase

6.3.1 Gateway – Server login and authentication phase

  1. Gateway generates a random number r 1 and the current timestamp TS 1 and computes

  2. RG 1 = r 1 GW master ,

  3. RG 2 = r 1 GW pub ,

  4. C 1 = H 1 ( RG 1 TS 1 V g w ) GID i ,

  5. C 2 = H 1 ( C 1 M g w RG 1 H g w ) .

  6. Gateway sends the parameters { C 1 , C 2 , TS 1 , RG 2 } to the server

  7. The server receives the parameters { C 1 , C 2 , TS 1 , RG 2 } , generates a new timestamp TS 1 * , and verifies the validity of the received parameters. This is carried out by checking whether the condition TS 1 TS 1 * Δ T holds. If this condition is not satisfied, the server drops the session; else, it proceeds to compute

  8. M g w = H 1 ( x e g ) ,

  9. RG 1 = RG 2 x ,

  10. V g w = H 1 ( M g w RT g ) ,

  11. GID i = H 1 ( RG 1 TS 1 V g w ) C 1 ,

  12. H g w = H 1 ( V g w M g w GID i ) ,

  13. C 2 = H 1 ( C 1 M g w RG 1 H g w ) .

  14. Furthermore, the server verifies the condition C 2 1 C 2 .

  15. If the condition holds, the server generates r 2 and TS 2 and computes,

  16. RG 3 = r 2 . e g K pub ,

  17. RG 4 = r 2 e g x .

  18. Server also computes g ( GID i , RG 1 , RG 3 ) and g ( GID i , M g w , 1 ) ,

  19. K m s = H 2 ( g ( GID i , RG 1 , RG 3 ) M g w RG 1 RG 3 ) ,

  20. C 3 = H 2 ( g ( GID i , M g w , 1 ) RG 3 K m s RG 1 TS 2 ) .

  21. The server sends the mutual authentication parameters { C 3 , TS 2 , RG 4 } to the gateway.

  22. The gateway receives the message { C 3 , TS 2 , RG 4 } and verifies the validity of the parameter received by generating TS 2 * and verifying the condition TS 2 TS 2 * Δ T . Once the condition is met, the gateway computes

  23. RG 3 = R 4 G ,

  24. g ( GID i , RG 1 , RG 3 ) and g ( GID i , M g w , 1 ) ,

  25. K g w = H 2 ( g ( GID i , RG 1 , RG 3 ) M g w RG 1 RG 3 ) ,

  26. C 3 = H 2 ( g ( GID i , RG 1 , M g w , 1 ) RG 3 K g w R 1 TS 2 ) .

  27. At last, gateway verifies the condition C 3 = C 3 .

  28. Furthermore, communication will be made using the shared keys K g w and K m s .

The overview of the gateway-server login and authentication phase is presented in Table 4.

Table 4

Gateway-to-server login phase

Gateway Server
Generates random numbers r 1 and TS 1 ,
Computes
RG 1 = r 1 . GW master ,
RG 2 = r 1 GW pub ,
C 1 = H 1 ( RG 1 TS 1 V g w ) GID i ,
C 2 = H 1 ( C 1 M g w RG 1 H g w ) ,
{ C 1 , C 2 , TS 1 , RG 2 } .
Verifies TS 1 TS 1 * Δ T
Computes M g w = H 1 ( x e g ) , RG 1 = RG 2 x ,
V g w = H 1 ( M g w RT g ) , GID i = H 1 ( RG 1 TS 1 V g w ) C 1 ,
H g w = H 1 ( V g w M g w GID i ) ,
C 2 = H 1 ( C 1 M g w RG 1 H g w ) ,
Verify C 2 1 = C 2 ,
Generates r 2 and TS 2 ,
RG 3 = r 2 . e g K pub , RG 4 = r 2 e g . x ,
g ( GID i , RG 1 , RG 3 ) , g ( GID i , M g w , 1 ) ,
{ C 3 , TS 2 , RG 4 } .
Verifies TS 2 TS 2 * Δ T .
Computes RG 3 = R 4 G ,
g ( GID i , RG 1 , RG 3 ) and g ( GID i , M g w , 1 ) ,
K g w = H 2 ( g ( GID i , RG 1 , RG 3 ) M g w RG 1 RG 3 ) ,
C 3 = H 2 ( g ( GID i , RG 1 , M g w , 1 ) RG 3 K g w R 1 TS 2 ) .
Verifies C 3 = C 3 .

6.3.2 Device – Gateway login and authentication phase

  1. Device generates a random number r d 1 and the current timestamp TD 1 and computes

  2. RD 1 = r d 1 G D master , RD 2 = r d 1 G D pub ,

  3. CD 1 = H 3 ( RD 1 TD 1 V d ) DID i ,

  4. CD 2 = H 3 ( V d M d RD 1 H d ) ,

  5. CD 3 = H 3 ( RD 1 TD 1 ) b i ,

  6. CD 4 = H 3 ( b i DID i ) CD 3 ,

  7. The device sends { CD 1 , CD 2 , CD 3 , CD 4 , TD 1 , RD 2 } to the gateway

  8. The gateway receives the request parameters { CD 1 , CD 2 , CD 3 , CD 4 , TD 1 , RD 2 } and verifies the message validity by generating TD 1 * and checking the condition TD 1 TD 1 * Δ T . Once the condition is true, the gateway computes

  9. H 3 ( b i DID i ) = CD 4 CD 3 ,

  10. e d = D sec H 3 ( H 3 ( b i DID i ) RT g ) ,

  11. RD 1 = RD 2 e d ,

  12. b i = CD 3 H 3 ( RD 1 TD 1 ) ,

  13. M d = H 3 ( b i e d ) ,

  14. V d = H 3 ( M d RT g )

  15. DID i = CD 1 H 3 ( RD 1 TD 1 V d ) ,

  16. H d = H 3 ( V d M d DID i ) ,

  17. CD 2 = H 3 ( V d M d RD 1 H d ) .

  18. The gateway verifies the parameters CD 2 = CD 2 .

  19. If the condition is true, the gateway generates r d 2 and TD 2 and computes

  20. RD 3 = r d 2 G D master , RD 4 = r 2 e d . G .

  21. The gateway also computes f ( DID i , RD 3 , RD 1 ) and f ( DID i , M d , 1 )

  22. K g w d = H 4 ( f ( DID i , RD 3 , RD 1 ) M d RD 1 RD 3 ) ,

  23. CD 5 = H 4 ( f ( DID i , M d , 1 ) RD 3 K g w d RD 1 TD 2 ) .

  24. The gateway sends the parameters { CD 5 , TS 2 , RD 4 } to the device.

  25. The device receives the parameter { CD 5 , TS 2 , RD 4 } and verifies the message validity TD 2 * and the condition TD 2 TD 2 * Δ T . If the condition is not satisfied, the device drops the session; else, proceeds further.

  26. Furthermore, the device computes

  27. RD 3 = RD 4 b i ,

  28. f ( DID i , RD 3 1 , RD 1 ) and f ( DID i , M d , 1 ) ,

  29. K d i = H 4 ( f ( DID i , RD 3 , RD 1 ) M 2 RD 1 RD 3 ) ,

  30. CD 5 = H 4 ( f ( DID i , M 2 , 1 ) RD 3 K D i RD 1 TD 2 ) .

  31. At last, the device verifies the condition CD 3 = CD 3

  32. All future communication will occur using the shared session keys, i.e., K d i and K g w d .

Table 5 presents a summary of the device-gateway login and authentication phase.

Table 5

Device and gateway login phase

Device Gateway
Generates random number r d 1 and TD 1
RD 1 = r d 1 G D master , RD 2 = r d 1 G D pub ,
CD 1 = H 3 ( RD 1 TD 1 V d ) DID i ,
CD 2 = H 3 ( V d M d RD 1 H d ) ,
CD 3 = H 3 ( RD 1 T 1 ) b i ,
CD 4 = H 3 ( b i DID i ) CD 3 ,
{ CD 1 , CD 2 , CD 3 , CD 4 , TD 1 , RD 2 } .
Verify timestamp
H 3 ( b i DID i ) = CD 4 CD 3 ,
e d = D sec H 3 ( H 3 ( b i DID i ) RT g ) ,
RD 1 = RD 2 e d ,
b i = CD 3 H 3 ( RD 1 TD 1 ) , M d = H 3 ( b i e d ) , V d = H 3 ( M d RT g ) ,
DID i = CD 1 H 3 ( RD 1 TD 1 V d ) , H d = H 3 ( V d M d DID i ) ,
CD 2 = H 3 ( V d M d RD 1 H d ) ,
Verify CD 2 and CD 2 ,
Generate r d 2 and TD 2 ,
RD 3 = r d 2 G D master , RD 4 = r 2 e d . G ,
f ( DID i , RD 3 , RD 1 ) and f ( DID i , M d , 1 ) ,
K g w d = H 4 ( f ( DID i , RD 3 , RD 1 ) M d RD 1 RD 3 ) ,
CD 5 = H 4 ( f ( DID i , M d , 1 ) RD 3 K g w d RD 1 TD 2 ) ,
{ CD 5 , TD 2 , RD 4 } .
Verify the timestamp and compute
RD 3 = RD 4 b i ,
f ( DID i , RD 3 1 , RD 1 ) and f ( DID i , M d , 1 ) ,
K d i = H 4 ( f ( DID i , RD 3 , RD 1 ) M 2 RD 1 RD 3 ) ,
CD 5 = H 4 ( f ( DID i , M 2 , 1 ) RD 3 K D i RD 1 TD 2 ) .
Verify CD 3 = CD 3

7 Security analysis of PLASMA

This section provides a cryptanalysis of PLASMA. First, an informal security analysis demonstrates how PLASMA is secure against active and passive attacks. Next, a formal security analysis is performed using the ROR model and computational problems. Through this model, we are proving the security and privacy of the long-term and session keys. Finally, the security is validated through formal verification using the Scyther simulation.

7.1 Informal security analysis

An informal security analysis was performed to check for the security requirements identified for the proposed authentication scheme.

7.1.1 Security against replay attack

Replay attack protection is ensured when the medical server or gateway confirms the freshness of the login message before initiating the authentication process. In the proposed scheme, a timestamp is employed to validate the login request message’s legitimacy. Let us consider a scenario where an attacker A steals the login request message from a previous successful authentication sent by D i or GW i , which is represented as { CD 1 , CD 2 , CD 3 , CD 4 , TD 1 , RD 2 } or { C 1 , C 2 , TS 1 , RG 2 } . In PLASMA, when GW i receives login requests from D i and MS i receives a request from GW i , the receiver first verifies the validity of the message using the timestamp. Once MS i or GW i receives the message, the receiver generates a new timestamp TS i * / TD i * , where i = 1, 2, 3, 4, and checks the condition TS i TS i * Δ T / TD i TD i * Δ T . Since the intercepted message belongs to a previous session, the condition fails, and the session is dropped. Therefore, the proposed scheme is secured against replay attacks.

7.1.2 Resiliency against insider attack

In PLASMA, devices do not directly communicate with the medical server. Instead, device authentication to a gateway node and the gateway node’s authentication to the medical server occur independently. This procedure distributes necessary credentials among D i (device), GW i (gateway), and MS i (medical server), ensuring that not all information is stored on a single system/server. For an insider attack to be successful, an attacker must possess knowledge of all credentials involved in the communication process, which is highly improbable in PLASMA. Therefore, PLASMA provides robust resiliency against insider attacks.

7.1.3 Resiliency against impersonation attack

Communication parameters are transmitted over an open channel in the login and authentication phase. According to the threat model, an attacker can intercept and modify these communication parameters. However, in the proposed scheme, should an adversary intercept the login and authentication parameters { CD 1 , CD 2 , CD 3 , CD 4 , TD 1 , RD 2 } , { CD 5 , TS 2 , RD 4 } , or { C 1 , C 2 , TS 1 , RG 2 } , { C 3 , TS 2 , RG 4 } to carry out an impersonation attack, knowledge of the random noise variables r d 1 and r 1 is essential. Furthermore, the parameters needed to execute an impersonation attack are scattered and not stored within a single system. For an adversary to successfully conduct an impersonation attack, they would need access to all parameters within the D i , GW i , and MS i , which is highly impossible. Hence, PLASMA is secure against impersonation attacks.

7.1.4 Secure against man-in-the-middle attack

In PLASMA, two defense mechanisms have been implemented. These attacks are typically executed by an adversary who manages to authenticate with a server or figure out the session key by intercepting messages. The first line of defense involves computing the parameters of the communication messages using random nonces r d 1 and r 1 . This approach not only discourages impersonation attempts but also helps in keeping the session key confidential. Additionally, we have incorporated the use of a timestamp to ensure the authenticity of login request messages in each session. As highlighted in Section 7.1.1, PLASMA prevents replay attacks, thereby blocking attackers from gaining unauthorized access by merely capturing the communication messages.

7.1.5 Ensures perfect forward secrecy

PLASMA derives the session key shared between device and gateway using the formula K d i = H 4 ( f ( DID i , RD 3 , RD 1 ) M 2 RD 1 RD 3 ) , while the session key for gateway-to-server communication is obtained via K g w = H 2 ( g ( GID i , RG 1 , RG 3 ) M g w RG 1 RG 3 ) . It is impossible for an adversary A , to determine the session key by intercepting the mutual authentication messages { CD 3 , TS 2 , RD 4 } or { C 3 , TS 2 , RG 4 } . An attacker needs to possess explicit knowledge of r d 1 and r 1 to proceed. Given that in PLASMA, random nonces are not transmitted as plain text over public channels, an adversary must correctly guess all involved nonces simultaneously to compute K g w or K d i , which is not feasible. Therefore, PLASMA assures perfect forward secrecy.

7.1.6 Resiliency against DoS attack

An attacker must first login to the gateway or server to execute a DoS attack. This requires carrying out a replay attack, a man-in-the-middle attack, or an impersonation attack by intercepting the communicated messages { CD 1 , CD 2 , CD 3 , CD 4 , TD 1 , RD 2 } , { CD 5 , TS 2 , RD 4 } , or { C 1 , C 2 , TS 1 , RG 2 } , { C 3 , TS 2 , RG 4 } . However, it has been demonstrated that PLASMA is secure against replay attacks, man-in-the-middle attacks, and impersonation attacks. As a result, it is also protected from DoS attacks.

7.2 Formal security using the ROR model

The authors perform a formal security analysis in this section to show that PLASMA is secure against A , as described in the study by Odelu et al. [34] and built on the model suggested by Canetti and Krawczyk [35]. In this model, A tries to eavesdrop, intercept communication messages, and modify the same by completely controlling the communication channel. In addition, A is assumed to have all knowledge of the public parameters but lacks direct access to the secret parameter. However, A can generate queries to extract information.

7.2.1 Participants

In the proposed scheme, authentication involves three distinct entities called participants. These participants include the smart device ( D i ), the gateway ( GW i ), and the medical server ( MS i ). Each participant can have multiple instances of the scheme in parallel denoted as D i , G W i , and M S i , where “ i ” denotes the i th participant instance [36]. In Table 6, the authors present the queries that attackers can create, and their importance is also outlined.

Table 6

ROR model symbols and description

Query Description
E x e c u t e ( D i , G W i , M S i ) The eavesdropping attack is a query that enables A to simulate the login and authentication and retrieve the communication transcript in the i th instance of participants.
S e n d ( D i G W i M S i , M ) To perform the active attacks, A uses this query. The message M communicated between D i , GW i , and MS i can be intercepted by A using this query. Furthermore, A attempts to alter the intercepted message.
R e v e a l ( D i G W i M S i ) Using this query, an adversary can retrieve the ephemeral secret key information of the instance D i GW i MS i .
C o r r u p t ( D i G W i M S i ) Using the oracle, adversary A can obtain the session key even after the long-term secret key is compromised.
T e s t ( D i G W i M S i ) A can make this query only once, and it models the session’s semantic security. When issued, A is given either the session key from D i GW i MS i or a random string of the same length, based on a coin toss. If b = 1 , the adversary receives the actual session key; if not, it receives a random string.

7.2.2 Security proof

Theorem 1

Assume that an adversary A operates within polynomial time t against the proposed scheme PLASMA. Let HASH , q h , and Adv ECDHP PLASMA ( t ) represent the range of h ( ) , the number of hash queries, and A s advantage in breaking elliptic curve Diffie-Hellman protocol (ECDHP), respectively. Then, the advantage of ECDHP in compromising the semantic security of the PLASMA scheme, specifically in deriving the session key SK shared between device and gateway or gateway and server, can be approximated by

Adv A PLASMA ( q s + q h ) 2 n + q h 2 HASH + 2 Adv A ECDH ( t ) .

Proof of Theorem 1

The proof consists of a sequence of experiments denoted as Exp i , where i = 0, 1, 2, 3, 4, which are based on queries generated by the adversary A . Tables 5 and 6 display the queries generated by A . Consider A d v n to denote the event where A successfully predicts the bit b following the execution of a T e s t query.

Exp 0 : In this experiment, the adversary A builds the attacks in the ROR model. According to the definition, we have

(1) Adv A PLASMA 2 Adv A , Exp 0 PLASMA 1 .

Exp 1 : This experiment illustrates an eavesdropping attack. In this scenario, an entity A captures all messages exchanged during the authentication process between D i , and GW i , specifically { C 1 , C 2 , TS 1 , RG 2 } and { C 3 , TS 2 , RG 4 } , or between GW i , and MS i , notably { CD 1 , CD 2 , CD 3 , CD 4 , TD 1 , RD 2 } and { CD 5 , TS 2 , RD 4 } . To achieve this, A creates an E x e c u t e query. Eventually, A will conduct R e v e a l and T e s t queries to get the session key K d i / K g w d shared between D i and GW i , or K g w / K m s shared between GW i and MS i . The session key K d i / K g w d is calculated as K d i K g w d = H 4 ( f ( DID i , RD 3 , RD 1 ) M d RD 1 RD 3 ) , and K g w / K m s is computed as K g w K m s = H 2 ( g ( GID i , RG 1 , RG 3 ) M g w RG 1 RG 3 ) . A utilizes e g and e d to calculate K d i / K g w d or K g w / K m s . It is important to note that just intercepting the communicated messages does not increase A ’s chances of successfully breaching the experiment. Thus, the scenarios Exp 0 and Exp 1 are considered equivalent regarding security implications. As a result, we obtain the following:

(2) Adv A , Exp 1 PLASMA = Adv A , Exp 0 PLASMA ,

Exp 2 : In this experiment, A constructs s e n d query with E x e c u t e query. A attempts to alter intercepted messages, which include { C 1 , C 2 , TS 1 , RG 2 } and { C 3 , TS 2 , RG 4 } or { CD 1 , CD 2 , CD 3 , CD 4 , TD 1 , RD 2 } and { CD 5 , TS 2 , RD 4 } , before forwarding them to one of the involved parties. For message modification to be possible, A must have knowledge of both e g and e d . Consequently, Exp 1 and Exp 2 are indistinguishable from each other, except for the queries s e n d and the E x e c u t e in Exp 2 . Therefore, we obtain the following:

(3) Adv A , Exp 2 PLASMA Adv A , Exp 1 PLASMA ( q s + q e ) 2 2 n ,

where n is the number of queries generated by A .

Exp 3 : This game emulates a hash query by depicting an active attack. Within PLASMA, the authentication process from the gateway to the server involves protecting { C 1 , C 2 } and C 3 with a hash function denoted by h ( ) . Similarly, the authentication from device to gateway for CD 1 , CD 2 , CD 3 , CD 4 , and { CD 5 } uses the same hash function for protection. Following the application of the hash function, the resulting values for these parameters are randomized. As a result, when the hash query is executed, no collisions are observed. Thus, except for the hash inclusion, Exp 2 and Exp 3 are indistinguishable. Therefore, we obtain the following:

(4) Adv A , Exp 3 PLASMA Adv A , Exp 2 PLASMA q h 2 2 HASH .

Exp 4 : This experiment focuses primarily on the security evaluation of session keys. Consider a scenario in which A successfully intercepts all messages exchanged among { C 1 , C 2 , TS 1 , RG 2 } and { C 3 , TS 2 , RG 4 } during the authentication process between D i and GW i , or { CD 1 , CD 2 , CD 3 , CD 4 , TD 1 , RD 2 } and { CD 5 , TS 2 , RD 4 } during the authentication process between GW i and MS i . To obtain the session key K d i K g w d = H 4 ( f ( DID i , RD 3 , RD 1 ) M d RD 1 RD 3 ) or K g w K m s = H 2 ( g ( GID i , RG 1 , RG 3 ) M g w RG 1 RG 3 ) , the adversary A needs to acquire long-term and short-term keys. Through intercepted communications, A can access RG 2 and RG 4 or RD 2 and RD 4 . However, to extract a key using these parameters, A must undertake the challenge of solving the ECDH problem, which is computationally hard. Therefore, as long as the ECDH assumption is satisfied, Exp 2 and Exp 3 remain indistinguishable. Hence, we obtain the following:

(5) Adv A , Exp 4 PLASMA Adv A , Exp 3 PLASMA = Adv A ECDH ( t ) .

At this stage, to complete the experiment with the T e s t query, A must guess for b . Clearly,

(6) Adv A , Exp 4 PLASMA = 1 2 .

Based on equations (1)–(6), we can obtain

1 2 Adv A PLASMA ( q s + q h ) 2 2 n + q h 2 2 HASH + Adv A ECDH ( t ) .

Therefore, we obtain

Adv A PLASMA ( q s + q h ) 2 n + q h 2 HASH + 2 Adv A ECDH ( t ) .

7.3 Scyther simulation

The Scyther tool is designed for the purpose of security protocol evaluation, focusing on identifying vulnerabilities and ensuring the fulfillment of security requirements. This automated tool scrutinizes how protocols behave under potential attack scenarios and provides findings that detail critical security prerequisites, including, but not limited to, Alive, Nisynch, weak agreement, and confidentiality. These criteria are fundamental for the secure and accurate operation of protocols, ensuring timely and synchronized communication, the protection of confidential data, and the defense against identity fraud.

To articulate particular security goals, the tool introduces the concept of “Claim”. Through claims such as Niagree and Nisynch, it is asserted that message exchanges between all parties have been successfully completed. The claims regarding secrecy confirm that the sensitive information covered in these claims remains concealed from adversaries. The effectiveness of this security scheme is verified in Figures 2 and 3, where it is shown to effectively meet all the security objectives outlined, preventing any attempted breaches.

Figure 2 
                  Simulation result: device-to-gateway authentication.
Figure 2

Simulation result: device-to-gateway authentication.

Figure 3 
                  Simulation result: gateway-to-server authentication.
Figure 3

Simulation result: gateway-to-server authentication.

8 Efficiency analysis

In this section, the computation and communication costs of PLASMA are calculated to assess its performance, and the results are compared with those of other related schemes. Additionally, a functional analysis is presented, followed by a detailed discussion.

8.1 Computation and communication cost analysis

To start with, we present both the computational cost and the estimated duration required for the execution of PLASMA. The essential computational parameters for determining the cost are detailed in Table 6. Throughout our analysis, we consider the overall computational expense and the expected time it takes for the scheme to execute. To estimate the expected execution time, we rely on existing evaluation results of various cryptographic operations, as presented by previous studies [30,37]. The estimated execution time for each cryptographic function is presented in Table 6. To calculate the computation cost of the proposed scheme PLASMA, we have considered one complete round of login and authentication between the entities. We have separately considered the authentication between device to gateway and gateway-to-server because they performed independently. XOR and concatenation operations are excluded from the estimation since the time is very minimal.

In the PLASMA device-to-gateway authentication, we have used 3 T ecmul and 4 T hash operations device side for construction of the login request, mutual authentication verification, and the session key. Also, 4 T ecmul and 7 T hash are used in the gateway side for authenticating the login request parameter, mutual authentication request parameter, and the session key. The total computation cost of the proposed PLASMA is 7 T ecmul + 11 T hash in the device-to-gateway side and 6 T ecmul + 15 T hash in the gateway-to-server authentication side. The total expected execution time for device-to-gateway authentication is 17.31 ms and for gateway-to-server authentication 19.35 ms. Table 8 presents the computation result of PLASMA.

Table 8

Computation and communication cost analysis

Schemes Total computations Estimated time Communication cost
Khatoon et al. [10] 12 T hash + 5 T ecmul + 2 T sym + 2 T f e + 2 T BPA 37.94 ms 960 bits
Nikooghadam et al. [38] 4 T sym + 20 T hash 19 ms 2400 bits
Wong et al. [12] 3 T sym + 14 T hash 13.3 ms 832 bits
Das & Namasudra [39] 2 T hash 1.62 ms 512 bits
Qiao et al. [4] 8 T c h + 24 T hash + 4 T sym 22.968 ms 5280 bits
Amintoosi et al. [1] 19 T hash 15.39 ms 2848 bits
Saini et al. [28] 5 T ecmul + 1 T BPA + 36 T hash 43.36 ms 3584 bits
Aldosary and Tanveer [30] 3 T PUF + 4 T f e + 9 T A E + 6 T hash 20.091 ms 1344 bits
Proposed scheme (device-to-gateway) 7 T ecmul + 11 T hash 17.31 ms 1632 bits
Proposed scheme (gateway-to-server) 6 T ecmul + 15 T hash 19.35 ms 1120 bits

The computation cost of PLASMA was compared with relevant schemes such as those mentioned in previous studies [1,4,10,12,28,30,38,39]. When PLASMA compared with the related schemes, it is observed that the computation cost of the PLASMA is less compared to that in the previous studies [4,10,28,30]. Also the scheme takes more slightly more computation cost compared to that in previous studies [1,12,38]. Finally, we can observe a big difference when compared to the study by Das and Namasudra [39]. But we already proved in Section 5 that the scheme mentioned in the study by Das and Namasudra [39] has the vulnerability to replay attack, device impersonation attack, and DoS attack. The authentication schemes that takes less computation cost compared to PLASMA such as that in previous studies [1,38] are also vulnerable to various attacks as discussed in Section 8.2. Finally, the PLASMA is still justifiable when compared to the study by Wong et al. [12] because it does not have fog node between user and server. This creates bottleneck while scaling the system.

The communication cost of PLASMA is calculated and compared with relevant schemes. The comparison result is presented in Table 7. For consistency in comparison, we assume the following: length of the random nonce, ID, password, and timestamp is 32bit. For the elliptic curve point, the bit length is 160, while the hash function uses 256 bits. Symmetric encryption and chaotic maps both use a 128-bit size. Additionally, the elliptic curve encryption is 256 bits, the fuzzy extractor operates at 128 bits, and modular computations are carried out with a 256-bit size. During the device-to-gateway login and authentication phase of PLASMA communicated messages are { CD 1 , CD 2 , CD 3 , CD 4 , TD 1 , RD 2 } and { CD 5 , TS 2 , RD 4 } , which requires 256 + 256 + 32 + 256 + 256 + 32 + 128 = 1,216 bits and 256 + 32 + 128 = 416 bits. The total communication cost of PLASMA device-to-gateway authentication is 1,632 bits. In the gateway-to-server login and authentication phase system communicates the messages { C 1 , C 2 , TS 1 , RG 2 } and { C 3 , TS 2 , RG 4 } , which is 256 + 32 + 256 + 32 + 128 = 704 bits and 256 + 32 + 128 = 416 bits. The total communication cost of PLASMA gateway-to-server authentication is 1,120 bits.

Table 7

Notations and execution time of cryptographic operations

Notation Description Estimated time
T hash One-way hash operation 0.81 ms
T ecpa Elliptic curve point addition 0.12 ms
T ecmul Elliptic curve point multiplication 1.2 ms
T BPA Bilinear pairing 8.2 ms
T c h Chaotic map 0.091 ms
T sym Symmetric encryption 0.7 ms
T f e Fuzzy extractor Gen(.) or Rep(.) function 2.21 ms
T f e Authenticated encryption 0.7 ms
T PUF PUF operation 0.00054 ms

The obtained communication cost of PLASMA is compared with relevant schemes and presented the result in Table 7. From the table, we can observe that the PLASMA takes less bits compared to that in previous studies [1,4,28, 38] and takes more bits compared to previous studies [10,12,39]. Still, we can accept PLASMA because the proposed scheme achieves all observed gaps and addresses all vulnerabilities. But the schemes that takes less bits are vulnerable to active attacks mainly uses the intercepted communication messages exchanged during the login and authentication phase. Finally, the PLASMA is still justifiable when compared to previous studies [30] because it does not have fog node between the user and the server. As mentioned earlier, the system loses efficiency when the number of users is very large.

8.2 Functional analysis

The security functionalities of PLASMA are compared with related schemes and presented in Table 9. To perform the functional analysis, we have considered the following parameters: F1 – security against replay attack, F2 – resiliency against insider attack, F3 – resiliency against impersonation attack, F4 – resiliency against man-in-the-middle attack, F5 – provides perfect forward secrecy, F6 – resiliency against DoS attack, and F7 – secure mutual authentication. Table 9 clearly proves that the proposed scheme PLASMA achieves all the security requirements. Other relevant authentication schemes are unable to address all the security issues mainly impersonation attack and insider attack, which are very crucial in the given system framework.

Table 9

Comparison of different schemes security functions

Schemes F1 F2 F3 F4 F5 F6 F7
Khatoon et al. [10] × × ×
Nikooghadam et al. [38] ×
Das & Namasudra [39] × × ×
Qiao et al. [4] ×
Amintoosi et al. [1] × × ×
Saini et al. [28] ×
PLASMA (device-to-gateway)
PLASMA (gateway-to-server)

F1 – security against replay attack, F2 – resiliency against insider attack, F3 – resiliency against impersonation attack, F4 – resiliency against man-in-the-middle attack, F5 – provides perfect forward secrecy, F6 – resiliency against DoS attack, F7 – secure mutual authentication.

9 Conclusion and future work

In this article, the authors proposed a privacy preserved lightweight and secure multi-level authentication scheme for IoMT-based smart healthcare framework called PLASMA. The PLASMA recommends a method to enhance the security of IoMT-driven smart healthcare systems by addressing the weaknesses found in existing authentication schemes. To show that we reviewed the Das and Namasudra authentication scheme and identified that the scheme is vulnerable to replay attacks, device impersonation, and DoS attacks. The PLASMA utilizes a hierarchical framework and ensures security, lightweight, and privacy-preserved authentication between devices, gateways, and medical servers. Rigorous cryptanalysis was performed on PLASMA to prove its security. First, an informal security analysis proves that the scheme is secure against active and passive attacks. A formal analysis using the ROR model proves that the scheme is provably secure against various attacks and preserves security and session key privacy during the authentication. The scheme is also simulated through the scyther, a well-known simulation tool that simulates active and passive attacks. Its computational and communication overheads are significantly lower than similar existing schemes, as presented through a comprehensive performance evaluation. The functional assessment highlights that the scheme also meets all critical requirements for a robust authentication mechanism.

In the future, we can explore the enhancement of PLASMA by reducing the computational and communicational overhead specifically for large, extensive IoT networks and resource-limited environments. Incorporating blockchain for decentralized data handling and using artificial intelligence for anomaly detection in healthcare data can enhance the security and operational effectiveness of IoT-based healthcare infrastructures. Adapting PLASMA to support multilevel authentication beyond the current three-tier system by preserving its efficiency could significantly advance the authentication framework for such architectures.

  1. Funding information: The authors state no funding involved.

  2. Author contributions: Manjunath Hegde conducted the experiments, analyzed the data, performed the computations, prepared the figures and/or tables, and approved the final draft.; Karthik M carried out the experiments and prepared the figures and/or tables.; Varun Hegde also conducted the experiments and prepared the figures and/or tables.; Rohini R. Rao authored or reviewed the drafts of the paper and approved the final draft.; Vinayak M. Mantoor authored or reviewed the drafts of the paper and approved the final draft.; Radhakrishna Bhat conducted the experiments, analyzed the data, prepared the figures and/or tables, and approved the final draft.

  3. Conflict of interest: The authors state no conflict of interest.

  4. Ethical approval: This article does not contain any studies with human participants or animals performed by any of the authors.

  5. Data availability statement: The data that support the findings of this study are available from the corresponding author upon reasonable request.

Appendix

Scyther employs the Security Protocol Descriptive Language for input, which is utilized to outline the details of security protocols. This encompasses the establishment of various roles such as device, gateway, and server. The initial configurations are illustrated in Figure A1, while Figures A2, A3, and A4 highlight the specific roles of these entities.

Figure A1 
                  Role server implementation.
Figure A1

Role server implementation.

Figure A2 
                  Role device implementation.
Figure A2

Role device implementation.

Figure A3 
                  Role gateway implementation.
Figure A3

Role gateway implementation.

Figure A4 
                  Role gateway communicating with server implementation.
Figure A4

Role gateway communicating with server implementation.

References

[1] H. Amintoosi, M. Nikooghadam, M. Shojafar, S. Kumari, and M. Alazab, “Slight: A lightweight authentication scheme for smart healthcare services,” Comput. Electr. Eng., vol. 99, p. 107803, 2022. 10.1016/j.compeleceng.2022.107803Suche in Google Scholar

[2] C. Huang, J. Wang, S. Wang, and Y. Zhang, “Internet of medical things: A systematic review,” Neurocomputing, p. 126719, 2023. 10.1016/j.neucom.2023.126719Suche in Google Scholar

[3] M. A. Khan, I. U. Din, T. Majali, and B.-S. Kim, “A survey of authentication in internet of things-enabled healthcare systems,” Sensors, vol. 22, no. 23, p. 9089, 2022. 10.3390/s22239089Suche in Google Scholar PubMed PubMed Central

[4] H. Qiao, X. Dong, Q. Jiang, S. Ma, C. Liu, N. Xi, and Y. Shen, “Anonymous lightweight authenticated key agreement protocol for fog-assisted healthcare iot system,” IEEE Internet Things J., 2023, vol. 10, pp. 16715–16726. 10.1109/JIOT.2023.3270300Suche in Google Scholar

[5] X. Jia, D. He, N. Kumar, and K.-K. R. Choo, “Authenticated key agreement scheme for fog-driven iot healthcare system,” Wireless Networks, vol. 25, no. 8, pp. 4737–4750, 2019. 10.1007/s11276-018-1759-3Suche in Google Scholar

[6] A. Ostad-Sharif, D. Abbasinezhad-Mood, and M. Nikooghadam, “A robust and efficient ECC-based mutual authentication and session key generation scheme for healthcare applications,” J. Med. Syst., vol. 43, no. 1, p. 10, 2019. 10.1007/s10916-018-1120-5Suche in Google Scholar PubMed

[7] D. Giri, T. Maitra, R. Amin, and P. Srivastava, “An efficient and robust rsa-based remote user authentication for telecare medical information systems,” J. Med. Syst., vol. 39, pp. 1–9, 2015. 10.1007/s10916-014-0145-7Suche in Google Scholar PubMed

[8] R. Amin and G. Biswas, “An improved rsa based user authentication and session key agreement protocol usable in TMIS,” J. Med. Syst., vol. 39, no. 8, p. 79, 2015. 10.1007/s10916-015-0262-ySuche in Google Scholar PubMed

[9] H. Arshad and A. Rasoolzadegan, “Design of a secure authentication and key agreement scheme preserving user privacy usable in telecare medicine information systems,” J. Med. Syst., vol. 40, pp. 1–19, 2016. 10.1007/s10916-016-0585-3Suche in Google Scholar PubMed

[10] S. Khatoon, S. M. M. Rahman, M. Alrubaian, and A. Alamri, “Privacy-preserved, provable secure, mutually authenticated key agreement protocol for healthcare in a smart city environment,” IEEE Acc., vol. 7, pp. 47962–47971, 2019. 10.1109/ACCESS.2019.2909556Suche in Google Scholar

[11] M. Masud, G. S. Gaba, S. Alqahtani, G. Muhammad, B. B. Gupta, P. Kumar, and A. Ghoneim, “A lightweight and robust secure key establishment protocol for internet of medical things in covid-19 patients care,” IEEE Internet Things J., vol. 8, no. 21, pp. 15694–15703, 2020. 10.1109/JIOT.2020.3047662Suche in Google Scholar PubMed PubMed Central

[12] A. M.-K. Wong, C.-L. Hsu, T.-V. Le, M.-C. Hsieh, and T.-W. Lin, “Three-factor fast authentication scheme with time bound and user anonymity for multi-server e-health systems in 5g-based wireless sensor networks,” Sensors, vol. 20, no. 9, p. 2511, 2020. 10.3390/s20092511Suche in Google Scholar PubMed PubMed Central

[13] L. Zhang, Y. Zhang, S. Tang, and H. Luo, “Privacy protection for e-health systems by means of dynamic authentication and three-factor key agreement,” IEEE Trans. Ind. Electron., vol. 65, no. 3, pp. 2795–2805, 2017. 10.1109/TIE.2017.2739683Suche in Google Scholar

[14] M. Fotouhi, M. Bayat, A. K. Das, H. A. N. Far, S. M. Pournaghi, and M.-A. Doostari, “A lightweight and secure two-factor authentication scheme for wireless body area networks in health-care IoT,” Computer Networks, vol. 177, p. 107333, 2020. 10.1016/j.comnet.2020.107333Suche in Google Scholar

[15] J. Li, Z. Su, D. Guo, K.-K. R. Choo, and Y. Ji, “Psl-maaka: Provably secure and lightweight mutual authentication and key agreement protocol for fully public channels in internet of medical things,” IEEE Internet Things J., vol. 8, no. 17, pp. 13183–13195, 2021. 10.1109/JIOT.2021.3055827Suche in Google Scholar

[16] M. Masud, G. S. Gaba, K. Choudhary, M. S. Hossain, M. F. Alhamid, and G. Muhammad, “Lightweight and anonymity-preserving user authentication scheme for IoT-based healthcare,” IEEE Internet Things J., vol. 9, no. 4, pp. 2649–2656, 2021. 10.1109/JIOT.2021.3080461Suche in Google Scholar

[17] W. Wang, Q. Chen, Z. Yin, G. Srivastava, T. R. Gadekallu, F. Alsolami, and C. Su, “Blockchain and puf-based lightweight authentication protocol for wireless medical sensor networks,” IEEE Internet Things J., vol. 9, no. 11, pp. 8883–8891, 2021. 10.1109/JIOT.2021.3117762Suche in Google Scholar

[18] T.-Y. Wu, T. Wang, Y.-Q. Lee, W. Zheng, S. Kumari, and S. Kumar, “Improved authenticated key agreement scheme for fog-driven iot healthcare system,” Security and Communication Networks, vol. 2021, pp. 1–16, 2021. 10.1155/2021/6658041Suche in Google Scholar

[19] K. Sowjanya, M. Dasgupta, and S. Ray, “Elliptic curve cryptography based authentication scheme for internet of medical things,” J. Inf. Secur., vol. 58, p. 102761, 2021. 10.1016/j.jisa.2021.102761Suche in Google Scholar

[20] D. He, S. Zeadally, N. Kumar, and J.-H. Lee, “Anonymous authentication for wireless body area networks with provable security,” IEEE Systems Journal, vol. 11, no. 4, pp. 2590–2601, 2016. 10.1109/JSYST.2016.2544805Suche in Google Scholar

[21] S. Yu and Y. Park, “A robust authentication protocol for wireless medical sensor networks using blockchain and physically unclonable functions,” IEEE Internet Things J., vol. 9, no. 20, pp. 20214–20228, 2022. 10.1109/JIOT.2022.3171791Suche in Google Scholar

[22] A. Gupta, M. Tripathi, S. Muhuri, G. Singal, and N. Kumar, “A secure and lightweight anonymous mutual authentication scheme for wearable devices in medical internet of things,” J. Inf. Secur., vol. 68, p. 103259, 2022. 10.1016/j.jisa.2022.103259Suche in Google Scholar

[23] V. Sumithra, R. Shashidhara, and D. Mukhopadhyay, “Design of a secure and privacy preserving authentication protocol for telecare medical information systems,” Security and Privacy, vol. 5, no. 4, p. 222228, 2022. 10.1002/spy2.228Suche in Google Scholar

[24] C.-M. Chen, Z. Chen, S. Kumari, and M.-C. Lin, “Lap-IoHT: A lightweight authentication protocol for the internet of health things,” Sensors, vol. 22, no. 14, p. 5401, 2022. 10.3390/s22145401Suche in Google Scholar PubMed PubMed Central

[25] Y. Ma, Y. Ma, Y. Liu, and Q. Cheng, “A secure and efficient certificateless authenticated key agreement protocol for smart healthcare,” Comput. Stand. Inter., vol. 86, p. 103735, 2023. 10.1016/j.csi.2023.103735Suche in Google Scholar

[26] W. Wang, H. Huang, F. Xiao, Q. Li, L. Xue, and J. Jiang, “Computation-transferable authenticated key agreement protocol for smart healthcare,” J. Syst. Archit., vol. 118, p. 102215, 2021. 10.1016/j.sysarc.2021.102215Suche in Google Scholar

[27] K. Kim, J. Ryu, Y. Lee, and D. Won, “An improved lightweight user authentication scheme for the internet of medical things,” Sensors, vol. 23, no. 3, p. 1122, 2023. 10.3390/s23031122Suche in Google Scholar PubMed PubMed Central

[28] K. K. Saini, D. Kaur, D. Kumar, and B. Kumar, “An efficient three-factor authentication protocol for wireless healthcare sensor networks,” Multimedia Tools and Applications, vol., 83, pp. 1–23, 2024. 10.1007/s11042-024-18114-1Suche in Google Scholar

[29] P. Soni, A. K. Pal, and S. H. Islam, “An improved three-factor authentication scheme for patient monitoring using WSN in remote health-care system,” Computer methods and programs in biomedicine, vol. 182, p. 105054, 2019. 10.1016/j.cmpb.2019.105054Suche in Google Scholar PubMed

[30] A. Aldosary and M. Tanveer, “Paaf-shs: Puf and authenticated encryption based authentication framework for the IoT-enabled smart healthcare system,” Internet of Things, vol. 26, p. 101159, 2024. 10.1016/j.iot.2024.101159Suche in Google Scholar

[31] D. Dolev and A. Yao, “On the security of public key protocols,” IEEE Trans. Inf. Theory, vol. 29, no. 2, pp. 198–208, 1983. 10.1109/TIT.1983.1056650Suche in Google Scholar

[32] C. Blundo, A. De Santis, A. Herzberg, S. Kutten, U. Vaccaro, and M. Yung, “Perfectly secure key distribution for dynamic conferences,” Information and Computation, vol. 146, no. 1, pp. 1–23, 1998. 10.1006/inco.1998.2717Suche in Google Scholar

[33] Y. Zhou and Y. Fang, “A two-layer key establishment scheme for wireless sensor networks,” IEEE Trans Mob Comput., vol. 6, no. 9, pp. 1009–1020, 2007. 10.1109/TMC.2007.1008Suche in Google Scholar

[34] V. Odelu, A. K. Das, M. Wazid, M. Conti, “Provably secure authenticated key agreement scheme for smart grid,” IEEE Transactions on Smart Grid, vol. 9, no. 3, pp. 1900–1910, 2016. 10.1109/TSG.2016.2602282Suche in Google Scholar

[35] R. Canetti and H. Krawczyk, “Analysis of key-exchange protocols and their use for building secure channels,” in International conference on the theory and applications of cryptographic techniques, Springer, 2001, pp. 453–474. 10.1007/3-540-44987-6_28Suche in Google Scholar

[36] J.-L. Tsai and N.-W. Lo, “Secure anonymous key distribution scheme for smart grid,” IEEE Transactions on Smart Grid, vol. 7, no. 2, pp. 906–914, 2015. 10.1109/TSG.2015.2440658Suche in Google Scholar

[37] X. Jin, N. Lin, Z. Li, W. Jiang, Y. Jia, and Q. Li, “A lightweight authentication scheme for power IoT based on PUF and Chebyshev chaotic map,” IEEE Acc., vol. 12, 83692–83706, 2024. 10.1109/ACCESS.2024.3413853Suche in Google Scholar

[38] M. Nikooghadam, H. Amintoosi, and N. Bagheri, “Lightweight authentication for remote healthcare systems in cloud-IoT,” in: 2020 10th International Conference on Computer and Knowledge Engineering (ICCKE), IEEE, 2020, pp. 636–643. 10.1109/ICCKE50421.2020.9303671Suche in Google Scholar

[39] S. Das and S. Namasudra, “Lightweight and efficient privacy-preserving mutual authentication scheme to secure internet of things-based smart healthcare,” Trans. Emerg. Telecommun. Technol., vol. 34, no. 11, p. e4716, 2023. 10.1002/ett.4716Suche in Google Scholar

Received: 2024-11-24
Revised: 2025-01-25
Accepted: 2025-02-08
Published Online: 2025-04-07

© 2025 the author(s), published by De Gruyter

This work is licensed under the Creative Commons Attribution 4.0 International License.

Artikel in diesem Heft

  1. Research Articles
  2. Intelligent data collection algorithm research for WSNs
  3. A novel behavioral health care dataset creation from multiple drug review datasets and drugs prescription using EDA
  4. Speech emotion recognition using long-term average spectrum
  5. PLASMA-Privacy-Preserved Lightweight and Secure Multi-level Authentication scheme for IoMT-based smart healthcare
  6. Basketball action recognition by fusing video recognition techniques with an SSD target detection algorithm
  7. Evaluating impact of different factors on electric vehicle charging demand
  8. An in-depth exploration of supervised and semi-supervised learning on face recognition
  9. The reform of the teaching mode of aesthetic education for university students based on digital media technology
  10. QCI-WSC: Estimation and prediction of QoS confidence interval for web service composition based on Bootstrap
  11. Line segment using displacement prior
  12. 3D reconstruction study of motion blur non-coded targets based on the iterative relaxation method
  13. Overcoming the cold-start challenge in recommender systems: A novel two-stage framework
  14. Optimization of multi-objective recognition based on video tracking technology
  15. An ADMM-based heuristic algorithm for optimization problems over nonconvex second-order cone
  16. Special Issue on AI based Techniques in Wireless Sensor Networks
  17. Blended teaching design of UMU interactive learning platform for cultivating students’ cultural literacy
  18. Special Issue on Informatics 2024
  19. Analysis of different IDS-based machine learning models for secure data transmission in IoT networks
  20. Using artificial intelligence tools for level of service classifications within the smart city concept
  21. Applying metaheuristic methods for staffing in railway depots
  22. Interacting with vector databases by means of domain-specific language
  23. Data analysis for efficient dynamic IoT task scheduling in a simulated edge cloud environment
  24. Analysis of the resilience of open source smart home platforms to DDoS attacks
Heruntergeladen am 30.9.2025 von https://www.degruyterbrill.com/document/doi/10.1515/comp-2025-0024/html?licenseType=open-access
Button zum nach oben scrollen