1 Introduction

Technological advancements have brought about positive changes in all aspects of modern life, particularly in the field of Internet of Things (IoT)-enabled medical or healthcare systems. The benefits of it are being utilized through the use of wearables like smartwatches and wristbands, smartphones, and many more. Nowadays, people are using wearable gadgets to connect with online medical systems. It has provided convenience to the users, who can now receive medical advice without having to physically visit a medical facility or hospital (Sowjanya et al. 2021). However, it is crucial to protect users’ information from illegitimate access and keep all exchanged messages between the user and server confidential. In any application, it is necessary to ensure the authenticity of user and server to provide security and privacy for both parties. Therefore, the reliability of these applications depends on authentication.

In a typical IoT-based network, user authentication involves three entities: gateway, smart device, and user. Based on the message exchange patterns among these actors, the existing authentication mechanisms in the literature can be categorize into many different categories (Krishnasrija et al. 2023). Out of those, one approach involves the gateway directly authenticating the user device, while the second approach involves the gateway authenticating the user device via a smart device. In this approach, the user communicates with the devices directly. For example, Farash et al. (2016) proposed a user authentication and key establishment model for an IoT environment. In this technique, a user connects with a specific sensor device and reads its specific data without having to establish a connection with the gateway first and simply receive aggregated information. In another approach, the user authentication protocol does not allow the user direct access to the device. Instead, the device undergoes authentication by directly interacting with the gateway. For example, Shuai et al. (2019) proposed an authentication mechanism for smart homes. This system permits three different mutual authentications. The first is between the user and the gateway, the second is between the gateway and the smart device, and the third is between the user and the smart device. The majority of protocols in the above two categories focus only on user authentication. However, for large-scale IoT applications, there is a need for mechanisms that enable device-to-device (i.e. between the gateway and smart device) and device-to-gateway authentications (Zhou et al. 2019). These mechanisms facilitate mutual authentication between devices within an IoT network and enable the formation of an IoT device group with other devices.

Consider a IoT-based healthcare scenario, where multiple gateways and devices are interconnected. The gateway can authenticate the registered device directly, as shown in connection (A) of Fig. 1, or using another device that is directly linked to and authenticated by the gateway as shown in connection (B) of Fig. 1. Here, devices are divided into two categories: already authenticated devices and new devices trying to connect. This requires handling two types of requests for connection: device to gateway and device to device. To address this, the authentication process must support two separate schemes. The first scheme involves authentication for devices directly connecting to gateways. The second scheme enables authentication for devices connecting to trusted devices already authenticated by the gateway, ensuring secure and trusted communication.

Fig. 1
figure 1

Different types of devices in an IoT network

By implementing these authentication schemes, the IoT network can effectively manage connections from both already authenticated devices and new devices, maintaining security and integrity within the network. The proposed mechanism, enabling mutual and transitive authentication in IoT networks, emphasizes the use of lightweight techniques to establish secure communication between IoT devices due to the computational limitations of these devices. The term "mutual" implies that both parties involved in the authentication process authenticate each other, ensuring trust and integrity. The term "transitive" suggests that the authentication mechanism extends beyond individual device-to-device authentication, allowing authentication to propagate across multiple devices or nodes in the network. Overall, the scheme focuses on lightweight and efficient authentication for IoT networks. During the registration phase, the necessary parameters and credentials for authentication are shared with the devices. These shared credentials are used for both authentication processes. The key contributions of this work are outlined as follows:

  1. 1)

    Development of two lightweight mutual authentication schemes: The work proposes novel authentication schemes for both device-to-gateway and device-to-device communication in IoT networks. These schemes are designed to be lightweight, ensuring efficient authentication while maintaining security.

  2. 2)

    Secure session establishment: The proposed schemes enable secure session establishment for registered devices. Successful authentication is a prerequisite for initiating a secure session, and each session utilizes a unique session key for data communication. This enhances the overall security and confidentiality of the communication.

  3. 3)

    Efficient credential management: The work introduces a credential updating process, ensuring the regular update of session IDs and parameters at the end of each session. This contributes to better credential management and helps maintain the integrity and freshness of authentication credentials.

  4. 4)

    Resistance to security threats: The proposed work is designed to withstand various security threats, including man-in-the-middle attacks, replay attacks, capturing, and eavesdropping. By incorporating security features, such as privacy preservation, untraceability, forward secrecy, credential updates, and session key secrecy, the proposed schemes enhance the overall security posture of the IoT-based smart healthcare system.

The remainder of the article is arranged in the following sections. Section 2 discusses some existing works that are related to the proposed scheme. In Sect. 3, the proposed authentication mechanism is introduced, by giving an overview of the design goals and system model of the proposed work. The construction of the proposed authentication mechanism is discussed in detail in Sect. 4. A detailed security analysis is carried out in Sect. 5, whereas in Sect. 6, the performance of the proposed scheme is compared with similar existing schemes. Finally, in Sect. 7, the work is concluded with future goals.

2 Related work

In literature, a few articles have recently covered the authentication and key agreement process because it is still a relatively new concept. In this section, some authentication and key agreement techniques which are presented in the past to ensure secure communication are discussed in brief.

Shuai et al. (2019) proposed an authentication mechanism based on Elliptic Curve Cryptography (ECC) for smart homes. This system permits three different mutual authentications. The first is between the user and the gateway, the second is between the gateway and the smart device, and the third is between the user and the smart device. Lastly, to facilitate secure interaction, a symmetric session key is also established between the user and the smart device. However, the performance of this approach is not satisfactory in terms of computational cost and communication expenses. In addition, several vulnerabilities, such as susceptibility to session key disclosure, replay attacks, and privileged insider attacks are also present in this scheme.

A user authentication scheme for a heterogeneous wireless sensor network was proposed by Turkanovic et al. (2014). This scheme offers secure authentication and generates a secure session key through the use of simple XOR and hash computation. However, this authentication model cannot provide mutual authentication between remote users and the gateway and cannot fulfill the requirements like anonymity and privacy in the network. Additionally, several security flaws were later revealed by Chang et al. (2016), including user impersonation and stolen smart card attacks.

Gope et al. (2016) proposed another lightweight authentication protocol to transfer real-time data in a wireless sensor network. This approach, however, asks for the gateway to save additional user data, which is impractical and often leads to failed authentication. This method does not support anonymity and untraceability because the sensor node’s identity is revealed during data transmission over a public channel. Jolfaie et al. (2017) also revealed some security weaknesses in this protocol, specifically regarding the disclosure of the session key.

Li et al. (2017) designed another lightweight protocol for anonymous mutual authentication in WBAN. This protocol offers perfect backward and forward secrecy and is resilient to several attacks. However, upon further analysis, it is discovered that this protocol is also susceptible to intermediate node capture, sensor node impersonation, and hub node impersonation attacks. This protocol also suffers from a key-escrow problem.

Wazid et al. (2020) suggested a novel lightweight authentication approach for a cloud-based IoT system. The authors asserted that the scheme is effective, scalable, and capable of giving IoT sensors real-time data access via corresponding gateways which are placed in various clusters. However, while more gateway nodes are added, the system becomes unstable, thus, arises scalability issues. In this regard, Chaudhry et al. (2021) have found that the scheme cannot achieve mutual authentication between system entities in the situation of numerous registered users.

Jan et al. (2021) put forward a proposal for a lightweight mutual authentication and secure session generation scheme that relies on a client–server model. The IoT device acts as a client system and registers with the server anonymously in this scheme. Following this, both the server and client authenticate each other to establish a secure session for data transmission. During the registration and authentication phases, this scheme employs a lightweight symmetric encryption technique to exchange messages. However, the scheme is unable to handle the issue of server failure.

Izza et al. (2021) have proposed another user authentication scheme, where by using a trusted gateway device, the authentication starts between a user and a device. This technique makes advantage of straightforward symmetric cryptography to make the whole process lightweight. However, there are still potential vulnerabilities that could be exploited by an attacker. For example, the use of a single trusted gateway device to facilitate the authentication process introduces a potential single point of failure, and if the gateway device is compromised, an attacker could potentially impersonate the sensor device and gain unauthorized access to the network.

Banerjee et al. (2019) proposed a user authentication scheme suitable for symmetric key cryptosystem, where a user can connect to its preferred IoT sensor node. In this scheme, the gateway node serves as a third party and does not play any role once the user is connected to a sensor node. The key agreement protocol effectively negotiates a session key for authentication with the user’s preferred sensor node, thus establishing a secure connection.

Masud et al. (2022) introduced an authentication scheme designed for IoT-enabled healthcare systems, featuring four distinct phases: device registration, user registration, mutual authentication between device and user, and key generation. This lightweight scheme is adept at establishing a secure session between the user and the device, thereby thwarting unauthorized access to data or resources. Nevertheless, it exhibits vulnerability to several types of attacks, including stolen verification attacks, privilege escalation attacks, and sensor node capture attacks.

Kumar et al. (2023) suggested a robust authentication mechanism that merges a password-protected biometric with physically unclonable functions (PUF). PUF device generates a distinct cryptographic key, which serves as the basis for authenticating the device, facilitating access to protected resources. This work addresses shortcomings observed in existing systems, particularly mitigating concerns related to key compromise impersonation attacks, wrong login, and server registration complexity.

Besides the above-discussed approaches, a variety of other approaches are proposed by many researchers in the literature for a wide range of application sectors, including mobile cloud environment (Gomaa et al. 2016; Gutub 2022), fog computing (Wang et al. 2022), healthcare sector (Khasim and Basha 2022), and vehicular technology (Namasudra and Sharma 2022; Wang et al. 2016). Yet, most of those techniques do not focus on the processing capability of resource-constraint devices (Moqurrab et al. 2022). Hence, novel schemes need to be designed that can match the characteristics of IoT and yet, offer a robust security mechanism (Khasim and Basha 2022; Das and Namasudra 2023; Chen 2022; Huang 2023; Kumar and Priyanka 2023; Ali et al. 2022; Gaur et al. 2023).

3 Overview of the proposed scheme

This study proposes a novel lightweight IoT device authentication approach for smart healthcare system. This section provides an overview of the proposed scheme, including design goals, system model, and network model of the proposed scheme.

3.1 System model

An IoT network can consist of several gateway devices, and there may be some IoT devices connected to it either directly or indirectly. The proposed approach involves two entities, namely the IoT devices and gateway devices that are defined below:

  1. 1)

    IoT Device: An IoTD is a limited-resourced device that gathers and sends a patient’s health data to a gateway with which it is associated.

  2. 2)

    Gateway: A gateway is a device that connects various sensors, IoTD, and users to the internet and serves as a bridge between them. It acts as an intermediary between IoTD and the user, allowing them to communicate with each other. The gateway is not a resource-constraint device.

As shown in Fig. 1, IoT devices can be divided into two categories: devices directly connected to the gateway and device connected to the gateway via another device. The network needs to provide two different authentication and network connections; one is to connect a device directly to the gateway and the other is to connect a device to another device already authenticated by the gateway. A few assumptions that are considered in this work are mentioned below:

  • It is assumed that the gateway is not a resource-constraint device while IoT device (IoTD) is a limited-resourced device.

  • The IoT device gets registered with the system in an offline mode before the network gets operational.

3.2 Design goals

The objective of this study is to develop a new method for authenticating devices in smart healthcare environments with limited resources to access medical equipment. Therefore, the proposed authentication method for medical devices should ensure the following design goals:

  1. 1)

    Secure device authentication and session key establishment

  2. 2)

    Resistance to various cryptographic attacks

  3. 3)

    Minimizing storage, number of messages exchanged, and execution time.

  4. 4)

    Use of lightweight or simple cryptographic operations.

4 Construction of the proposed scheme

In this section, the major phases of the proposed scheme, namely registration, authentication, and credential update phase, are presented. Here, \({G}_{j}\) and \({D}_{i}\) represent gateway and IoT device, respectively, where \(j=\{\mathrm{1,2},\dots,J\}\), \(i=\{\mathrm{1,2},\dots,I\}\), and \(I>J\). All the symbols used in this paper are described in Table 1.

Table 1 Descriptions of symbols

4.1 Registration process

During the registration process, a secure channel is utilized for communication between the device and gateway. The steps of this procedure are sequentially discussed below:

Step 1: Each device \({D}_{i}\) in the network contains a unique \({D}_{i}\)’s identity \({D}_{ID}\). The \({D}_{i}\) generates a fresh Registration Request (\({R}_{Req}\)) and sends it to a gateway \({G}_{j}\).

Step 2: After receiving the request, \({G}_{j}\) retrieves \({D}_{ID}\) from \({R}_{Req}\) and selects a random x and a pre-shared key \(({PK}_{i})\) for \({D}_{i}\). Then, the \({G}_{j}\) computes \({D}_{i}\)’s anonymous identity \(AID={D}_{ID}\oplus x\) and \({S}_{Hash}=h(AID||{PK}_{i})\). After completing the registration process, the \({G}_{i}\) stores \({D}_{i}\)’s \(AID\) and \({PK}_{i}\) in its registered device list \(({R}_{Device})\) and also sends these parameters to the \({D}_{i}\).

Step 3: After receiving \(AID\) and \({PK}_{i}\) from \({G}_{i}\), \({D}_{i}\) stores them in its secure memory.

4.2 Authentication process between a gateway and an immediate IoT device

The gateway can authenticate a registered device by utilizing its unique anonymous identity and pre-shared key. The first mutual authentication process is initiated by a device \({D}_{i}\) which is directly connected to a \({G}_{j}\). The authentication procedure, outlined in Fig. 1, includes the following sequential steps:

Step 1: Initially, the \({D}_{i}\) generates a number n1 randomly, and using n1, it calculates \({S}_{Req}\) =\(AID\oplus {PK}_{i}\oplus {n}_{1}\) and \({S}_{Hash} =H(AID||{PK}_{i})\). Then, \({D}_{i}\) sends the authentication request {\({S}_{Req}\),\({S}_{Hash}\), \({T}_{1}\)} at time \({T}_{1}\) to \({G}_{j}\) through a public channel.

Step 2: The \({G}_{j}\) searches for \(AID\) using \({S}_{Hash}\) in its \({R}_{Device}\) list. If the \(AID\) is not recorded in this \({R}_{Device}\) list, then, the \({S}_{Req}\) is declined by the \({G}_{j}\). Otherwise, \({G}_{j}\) continues the authentication process. The \({G}_{j}\) retrieves n1 from \({S}_{Req}\) as it contains \({D}_{i}\)’s \(AID\), \({PK}_{i}\), and n1. Further, \({G}_{j}\) chooses a random nonce g1 and calculates a challenge \({G}_{ch}={n}_{1}\oplus {g}_{1}\oplus {PK}_{i}\). Finally, the \({G}_{j}\) sends the \(\{{G}_{ch}\),\({T}_{2}\)} to the \({D}_{i}\) at time \({T}_{2}\).

Step 3: On receiving \(\{{G}_{ch}\),\({T}_{2}\)}, the \({D}_{i}\), at first, checks the validity of \({T}_{2}\) as \({T}_{c}-{T}_{2}\)< = \({T}_{\Delta }\). Then, the \({D}_{i}\) generates g1 from \({G}_{ch}\) by computing \({g}_{1}={G}_{ch}\oplus {n}_{1}\oplus {PK}_{i}\) and calculates response \({D}_{res}={g}_{1}\oplus {n}_{1}\oplus {g}_{2}\) after choosing a random nonce g1. The \({D}_{i}\) sends {\({D}_{res}\),\({T}_{3}\)} to the \({G}_{j}\) at time \({T}_{3}\). The \({D}_{i}\) also computes the session key \(SK=H({g}_{1}||{g}_{2})\).

Step 4: After receiving {\({D}_{res}\),\({T}_{3}\)} the \({G}_{j}\) checks the validity of \({T}_{3}\) as \({T}_{c}-{T}_{3}\)< = \({T}_{\Delta }\). Then, the \({G}_{j}\) computes \({g}_{2}={D}_{res}\oplus {n}_{1}\oplus {g}_{1}\) to generate the session key \(SK=H({g}_{1}||{g}_{2})\).

Thus, the mutual authentication of the device and the concerned gateway completes. Both the \({D}_{i}\) and \({G}_{j}\) can exchange data through a secure session using \(SK\). Once data transmission completes, the session is terminated by discarding the current session key. At this stage, the anonymous identity and pre-shared key can be securely updated as \(AID\_new\) and \({PK}_{i}\_new\) before terminating the ongoing session. The complete process is defined in the below subsection. Figure 2 shows the entire authentication technique discussed above along with the credential update phase.

Fig. 2
figure 2

The authentication between a gateway and directly connected IoT device and credential update phase

4.3 Credential update phase

This section provides a process to update IoT device’s credentials, such as anonymous identity and pre-shared key at the end of each session.

Step 1: The \({G}_{j}\) selects fresh random nonce \(x\_new\) and pre-shared key \({PK}_{i}\_new\) for \({D}_{i}\) and computes \(AID\_new=H(AID\oplus x\_new)\) and \({S}_{Hash}=H(AID\_new||{PK}_{i}\_new)\). Then, the \({G}_{j}\) stores \({S}_{Hash}\) and \({PK}_{i}\_new\) in its \({R}_{Device}\) list and sends \(AID\_new\) and \({PK}_{i}\_new\) to the device through the secure channel.

Step 2: On receiving \(\{AID\_new\), \({PK}_{i}\_new\}\), the \({D}_{i}\) updates its \(AID\_new\) and \({PK}_{i}\_new\). Then, the \({D}_{i}\) ends the ongoing session by discarding the session key.

4.4 Authentication between a gateway and a new device through an intermediate device

As previously discussed, a new device can be connected to another authenticated device in addition to the gateway device. This authenticated device serves as an authentication facilitator for the new device. This authentication procedure is shown in Fig. 3 and also described using the below-mentioned steps:

Fig. 3
figure 3

Authentication of a new device with a gateway through another authenticated device

Step 1: Initially, the new device \({D}_{new}\) generates a number \({m}_{1}\) randomly. By using \({m}_{1}\), it calculates \({S}_{Req}\) =\(AID\oplus {PK}_{j}\oplus {m}_{1}\) and \({S}_{Hash} =h(AID||{PK}_{j})\). Then, \({D}_{new}\) sends the authentication request {\({S}_{Req}\), \({S}_{Hash}\), \({T}_{1}\)} at time \({T}_{1}\) to the authenticated device \({D}_{i}\) through a public channel.

Step 2: After \({D}_{i}\) receives {\({S}_{Req}\), \({S}_{Hash}\)}, it adds its \({AID}_{Di}\) and sends the message \({\{S}_{Req}\), \({S}_{Hash}\), \({AID}_{Di}\)} to the concerned gateway device \({G}_{j}.\) \({D}_{i}\) sends the message through the secure channel that was established during the direct authentication process performed between \({D}_{i}\) and \({G}_{j}.\)

Step 3: Once the gateway receives \({D}_{new}\)’s authentication request message from \({D}_{i}\), at first, it verifies the authenticated device identity \({AID}_{Di}\). Then, by following the same procedure as in the direct mutual authentication process the \({G}_{j}\) computes challenge \({G}_{ch}={m}_{1}\oplus {g}_{1}\oplus {PK}_{j}\) for \({D}_{new}\). The \({G}_{j}\) also computes \({D}_{ch}={m}_{1}\oplus x\oplus {n}_{1}\) for \({D}_{i}\) where x is a random nonce. Finally, the \({G}_{j}\) sends the \(\{{G}_{ch}\),\({D}_{ch}\)} to the \({D}_{i}\) through the same secure channel.

Step 4: Authenticated device \({D}_{i}\) receives\(\{{G}_{ch}\),\({D}_{ch}\)} from \({G}_{j}\) at time \({T}_{4}\) and checks if \(\left( {T_{c} - T_{4} } \right) \le T_{\Delta }.\) \({D}_{i}\) computes \({D}_{ch}{\prime}\)=\({D}_{ch}\oplus {n}_{1}\), which provides\({D}_{ch}{\prime}={m}_{1}\oplus x\). Here, n1 is known to the\({D}_{i}\). Then, the \({D}_{i}\) selects another random nonce \({d}^{old}\) to compute\({D}_{ch}^{new}={m}_{1}\oplus x\oplus {d}^{old}\). The \({D}_{i}\) sends the message containing two challenges to generate secret session keys\(\{{G}_{ch}\),\({D}_{ch}^{new}\)} to the \({D}_{new}\) through the public channel.

Step 5: At this stage, the \({D}_{new}\) retrieves g1 from \({G}_{ch}\) by computing \({g}_{1}={G}_{ch}\oplus {m}_{1}\oplus {PK}_{j}\). Once \({g}_{1}\) is retrieved, then, the \({D}_{new}\) selects random nonce g2 and calculates the session key \(SKgd\) between \({G}_{j}\) and \({D}_{new}\) as \(H({g}_{1}|\left|{g}_{2}\right)\) and a response \({D}_{res}={g}_{1}\oplus {m}_{1}\oplus {g}_{2}\) for \({G}_{j}\). The \({D}_{new}\) again selects random parameter \({d}^{new}\) and calculates the session key \({SK}_{dd}\) =\(H({D}_{ch}^{new}\oplus {m}_{1}\oplus {d}^{new})\)=\(H(x\oplus {d}^{old}\oplus {d}^{new})\) between \({D}_{i}\) and \({D}_{new}\), and response for \({D}_{i}{D}_{res}^{new}={m}_{1}\oplus {d}^{new}\). Finally, \({D}_{new}\) sends both \({D}_{res}\) and \({D}_{res}^{new}\) to the \({D}_{i}.\)

Step 6: On receiving the response messages the \({D}_{i}\) combines the \({D}_{ch}^{new}\) and \({D}_{res}^{new}\) to get the session key between \({D}_{i}\) and \({D}_{new}\) as \({SK}_{dd}=H({D}_{ch}^{new}\oplus {D}_{res}^{new})=H(x\oplus {d}^{old}\oplus {d}^{new})\) and the authentication ends. Next, the \({D}_{i}\) sends {Dres}SK to the gateway.

Step 7: After the gateway \({G}_{j}\) receives the response message \({D}_{res}\) from \({D}_{i}\), it computes \({g}_{2}= {D}_{res}\oplus {m}_{1}\oplus {g}_{1}\). Then, it computes the session key \(SKgd=H({g}_{1}||{g}_{2})\) between the \({D}_{i}\) and \({G}_{j}\) and the authentication ends here. Both the \({D}_{i}\) and \({G}_{j}\) can communicate with each other by using this key \(SKgd.\)

5 Security analysis

This section presents a security analysis of the proposed scheme to demonstrate its resilience and effectiveness. Initially, several potential threat scenarios are examined, and it is demonstrated that the proposed scheme is capable of withstanding these scenarios.

Theorem 1

A session can only be initiated by a registered device \({D}_{i}\) with a concerned gateway \({G}_{j}\) by sending a valid request \({S}_{Req}.\)

Proof

During the device registration phase, each valid device \({D}_{i}\) is assigned an anonymous identity \(AID\) and a pre-shared key \({PK}_{i}\) by the corresponding gateway \({G}_{j}.\) \({G}_{j}\) maintains a record of device identity (\({D}_{ID})\), \(AID\), \({PK}_{i}\), and \({S}_{Hash}\) in its \({R}_{Device}\) list for every registered device. Suppose an intruder \({I}_{k}\) tries to start a session by sending a \({S}_{Req}\) to the \({G}_{j}\). \({G}_{j}\) checks the sender’s authenticity by checking \({S}_{Hash}\) in its \({R}_{Device}\) and also in \({R}_{Update}\) list. If \({S}_{Hash}\) is not found, it implies that \(AID\) is not registered with \({G}_{j}\), i.e., \(AID\notin \{{AID}_{1},{AID}_{2},\dots,{AID}_{I}\}\). In such a case, \({G}_{j}\) rejects the \({S}_{Req}\) and marks it as an intruder. Conversely, if a registered device \({D}_{i}\) initiates a session by sending \({S}_{Req}\), the \({G}_{j}\) verifies \({D}_{i}\)’s authenticity by checking \({S}_{Hash}\) in \({R}_{Device}\) and \({R}_{Update}\) list. Therefore, a secure sessions with the gateway \({G}_{j}\) can be initiated only by a registered device \({D}_{i}\). This completes the proof.

Theorem 2

Only the intended gateway \({G}_{j}\), and not any intruder \({I}_{k}\), can process device \({D}_{i}\)’s session initiation request \({S}_{Req}.\)

Proof

During the registration phase,\({D}_{i}\)’s registration details, including \({D}_{ID}\), \(AID\), \({PK}_{i}\), and \({S}_{Hash}\) are stored in \({G}_{j}\)’s \({R}_{Device}\) list. Only \({D}_{i}\) and the concerned \({G}_{j}\) know these details. Suppose \({I}_{k}\) receives the \({S}_{Req}\) sent by the \({D}_{i}\). Since \({I}_{k}\) does not know \(AID\) and \({PK}_{i}\), it is unable to get \({n}_{1}\) from \({S}_{Req}\). Hence, \({I}_{k}\) cannot calculate a valid \({G}_{ch}\) as \(\{{n}_{1}\oplus {g}_{1}\oplus {PK}_{i}\}\) for \({D}_{i}\). Even if \({I}_{k}\) manages to send \({G}_{ch}\) to \({D}_{i}\), \({D}_{i}\) can identify it due to the presence of the incorrect n1 value. However, by using correct \(AID\) and \({PK}_{i}\) the intended \({G}_{j}\) can retrieve n1 from \({S}_{Req}\). Therefore, only the correct \({G}_{j}\) is able to process \({S}_{Req}\) by calculating a valid \({G}_{ch}.\) This concludes the proof.

Theorem 3

Only the designated entities \({D}_{i}\) and \({G}_{j}\) have the ability to decrypt the encrypted \({G}_{ch}\) and \({D}_{Res}\), not any intruder \({I}_{k}.\)

Proof

To decrypt \({G}_{ch}\) sent by \({G}_{j}\), any device \({D}_{i}\) or intruder \({I}_{k}\) needs to have correct \({PK}_{i}\) and n1. Since \({I}_{k}\) does not know \({PK}_{i}\), it cannot get g1 from \({G}_{ch}\). Therefore, \({I}_{k}\) cannot compute the response message (\({D}_{Res})\) using the correct n1 and g1. Even if \({I}_{k}\) attempts to guess the \({PK}_{i}\) value, the probability of success is \(\frac{1}{{2}^{128}}\). In contrast, \({D}_{i}\) can decrypt \({G}_{ch}\) with the correct \({PK}_{i}\) and n1 value. In the same way, \({I}_{k}\) cannot decrypt \({D}_{Res}\) sent by \({D}_{i}\). Therefore, only the designated \({D}_{i}\) and \({G}_{j}\) can decrypt the \({G}_{ch}\) and \({D}_{Res}\). This concludes the proof.

5.1 Formal security analysis based on ROR model

In subsection, the security analysis of the proposed scheme is explained by employing the ROR model (Abdalla et al. 2005). The ROR model, recognized for its probabilistic nature, serves as a tool to validate the security of the session key implemented in the proposed scheme. Initially, the fundamentals of the ROR model, encompassing its definition and operational principles, are explored. Subsequently, the presentation explores the mathematical proofs in detail. The ROR model incorporates the following components.

The network involves three key entities: (1) new IoTD device, (2) intermediate node or device, and (3) gateway. It is assumed that \({D}_{new}\), \({D}_{i}\), and \({G}_{j}\), represent instances of new IoTD, intermediate node or device, and gateway, respectively, with the parameter ξ denoting the tuple \(\{{D}_{new}\), \({D}_{i}\), \({G}_{j}\)}. These instances are referred to as oracles. As per the threat model, the adversary \(\mathcal{A}\) holds complete control over the communication network. \(\mathcal{A}\) is empowered to capture, eavesdrop, modify, delete, or reconstruct new messages within the network where legitimate devices communicate with each other. The adversary \(\mathcal{A}\) can ascertain various queries to gain insight into the security of the protocol. Additionally, \(\mathcal{A}\) can execute the following queries:

Exec (ξ): Through this query, \(\mathcal{A}\) can conduct an eavesdropping attack, acquiring all the messages exchanged among the legitimate entities.

Send (ξ,M): \(\mathcal{A}\) has the capability to send a message \(\mathcal{m}\) to ξ and receive a reply message \({\mathcal{m}}^{\mathrm{^{\prime}}}\) from ξ.

Capt (ξ): \(\mathcal{A}\) can perform a capture attack by executing this query and capture all the parameters stored in the memories of the IoT device and gateway. Notably, \(\mathcal{A}\) is constrained to a limited number of Capt() queries.

Hash (S): By executing this query, the adversary can obtain a fixed-length hash value from an input string S.

Tst (ξ): This query is designed to assess the semantic security of the session key. Before the experiment’s commencement, adversary \(\mathcal{A}\) tosses an unbiased coin c and only \(\mathcal{A}\) is aware of the result, which dictates the outcome of the test query. If c = 1 and SK is fresh, the adversary obtains the correct SK from ξ. The adversary receives a random number if c = 0; otherwise, it returns a null value (⊥). Importantly, \(\mathcal{A}\) can execute an unlimited number of Tst() queries.

Here, the event for \(\mathcal{A}\) to win a game is considered as \(Scc\), and the advantage of \({\mathbb{A}}\) to break the proposed scheme is denoted as \({Adv}_{\mathcal{A}}^{\xi }=\left|2Prob\left(Scc\right)-1\right|\). The proposed scheme is secured if \({Adv}_{\mathcal{A}}^{\xi }\le \varepsilon \) for sufficiently small ε > 0.

Semantic security of the session-key: Ensuring the semantic security of the session key within the ROR model entails the requirement that adversary \(\mathcal{A}\) should be incapable of distinguishing between the genuine session key of an instance and a randomly generated key. \(\mathcal{A}\) can conduct multiple Tst(​) queries to either IoT device, Intermediate Node, or gateway​​, and the output must consistently align with or be uniformly distributed for the random bit c. After the process, \(\mathcal{A}\) provides a guessed bit c′ and succeeds if c′ = c. Denoting the event for \(\mathcal{A}\) winning a game as Scc, the advantage of adversary \(\mathcal{A}\) attempting to compromise the semantic security of the protocol is defined as \({Adv}_{\mathcal{A}}^{\xi }=\left|2Prob\left(Scc\right)-1\right|.\) The protocol is considered secure if \({Adv}_{\mathcal{A}}^{\xi }\le \varepsilon \) where \(\varepsilon >0\) is a sufficiently small positive value, for the runtime t.

Theorem

Let \(\mathcal{A}\) be an adversary operating within polynomial time t against the proposed scheme in the random oracle model. The variables qsnd​, ∣Hash∣, qsnd​, ∣PD∣, and \({Adv}_{\mathcal{A}}^{\xi }\) represent the number of hash queries, the range space of hash, the number of send queries, the size of the uniformly distributed password dictionary, and \(\mathcal{A}\)’s advantage in breaking the proposed scheme in time t, respectively. The estimated advantage of A in deriving the session key between the IoTD Node and gateway is expressed as follows:

$$ Adv_{{\mathcal{A}}}^{\xi } \le \frac{{q_{snd} }}{{\left| {PD} \right|}} + \frac{{q_{hash}^{2} }}{{\left| {Hash} \right|}} $$

Proof

\({G}_{i}\) is a sequence of four games, where \(i\) ranges from 0 to 3. The success of each game \({G}_{i}\)​ is denoted as \(Scc({G}_{i})\) under the rules defined for each game.

\({G}_{0}\): \(\mathcal{A}\) does not execute any query. Thus, the probability of \(\mathcal{A}\) breaking the proposed scheme is \({Adv}_{\mathcal{A}}^{\xi }\left(n\right)=|2prob\left[{Scc}_{\mathcal{A}}^{\xi }(n)-1\right]|\).

\({G}_{1}\): The game \({G}_{1}\) introduces \(Exec(\xi )\) query to the first game \({G}_{0}\) to perform an eavesdropping attack. In this scenario, \(\mathcal{A}\) can send all messages through the common channel and attempt to obtain the session key by executing \(Tst\left(\xi \right)\) query. The adversary remains incapable of accessing the random secret values used in the session key. Consequently, the probability of success for \({G}_{1}\) is equivalent to that \({G}_{0}\), denoted as \(Prob\left[{Scc}_{\mathcal{A}}^{{G}_{1}}\right]=Prob\left[{Scc}_{\mathcal{A}}^{{G}_{0}}\right]\).

\({G}_{2}\): \(\mathcal{A}\) performs this game by sending \(Send(\xi,\mathcal{M})\) and \(Hash(S)\) queries over \({G}_{1}\) to mislead a legitimate device into accepting an illicit message. However, all messages incorporate current timestamps and random secret numbers, making it impractical to achieve hash collisions within polynomial time through the execution of send and hash queries. According birthday paradox, the following outcome is derived:

$$ Prob\left[ {Scc_{{\mathcal{A}}}^{{G_{2} }} } \right] - Prob\left[ {Scc_{{\mathcal{A}}}^{{G_{1} }} } \right]| \le \frac{{q_{hash}^{2} }}{{2.\left| {Hash} \right|}} $$

\({G}_{3}\): The adversary executes \(Capt(\xi )\) query to gain access to all the confidential parameters stored in the memory of each node. \(\mathcal{A}\) captures an intermediate node and gets all the information from it. However, since the intermediate node doesn’t store any parameters of either the new IoTD device or gateway, no additional information is acquired. \(\mathcal{A}\) captures new IoTD to get the parameters stored in it. \({D}_{ID}\), not being stored in the device’s memory, \(\mathcal{A}\) cannot use a node capture attack to obtain the true identity. Even if \(\mathcal{A}\) has the parameter \(AID\), the secret key value \(x\) prevents it from tracking the device. Therefore, the following can be derived

$$ Prob\left[ {Scc_{{\mathcal{A}}}^{{G_{3} }} } \right] - Prob\left[ {Scc_{{\mathcal{A}}}^{{G_{2} }} } \right]| \le \frac{{q_{snd} }}{{2.\left| {PD} \right|}} $$

\(\mathcal{A}\) executes all the oracle queries to break the semantic security of the proposed protocol. A can win the game only after accurately guessing the c bit after executing \(Tst()\) query. This gives \(Prob\left[{Scc}_{\mathcal{A}}^{{G}_{3}}\right]=1/2\) and from the above equations, it can be noted that

$$ \begin{aligned} Adv_{{\mathcal{A}}}^{\xi } = & \left| {2.Prob\left[ {Scc_{{\mathcal{A}}}^{{G_{0} }} } \right] - 1} \right| \\ = & \left| {2.Prob\left[ {Scc_{{\mathcal{A}}}^{{G_{1} }} } \right] - 1} \right| \\ = & \left| {2.Prob\left[ {Scc_{{\mathcal{A}}}^{{G_{1} }} } \right] - 1/2} \right| \\ = & 2.\left| {Prob\left[ {Scc_{{\mathcal{A}}}^{{G_{1} }} } \right] - Prob\left[ {Scc_{{\mathcal{A}}}^{{G_{3} }} } \right]} \right| \\ \end{aligned} $$

By using triangular inequality, it can be derived

$$ \begin{aligned} \left| {Prob\left[ {Scc_{{\mathcal{A}}}^{{G_{1} }} } \right] - Prob\left[ {Scc_{{\mathcal{A}}}^{{G_{3} }} } \right]} \right| \le & \sum\limits_{{i = 0}}^{3} {\left| {Prob\left[ {Scc_{{\mathcal{A}}}^{{G_{{i + 1}} }} } \right]} \right.} \\ - & \left. {Prob\left[ {Scc_{{\mathcal{A}}}^{{G_{i} }} } \right]} \right| \\ \end{aligned} $$
$$\frac{1}{2}Adv_{{\mathcal{A}}}^{\xi } \le \frac{{q_{{hash}}^{2} }}{{2.\left| {Hash} \right|}} + \frac{{q_{{snd}} }}{{2.\left| {PD} \right|}} $$
$$Adv_{{\mathcal{A}}}^{\xi } \le \frac{{q_{{snd}} }}{{\left| {PD} \right|}} + \frac{{q_{{hash}}^{2} }}{{\left| {Hash} \right|}}\left( {{\text{multiplied}}\,{\text{by}}\,2} \right) $$

5.2 Informal analysis

In this section, various potential security attacks, such as MITM, replay, eavesdropping, and impersonation against the proposed protocol are examined. The aim is to demonstrate that the devised scheme is resistant to such attacks, as described in the following subsections. In addition, this scheme also provides untraceability and anonymity features. A security feature comparison is given in Table 2.

  1. 1)

    MITM Attack: During a MITM attack, messages exchanged between two parties are intercepted by intruders who may modify them as they require. If the alterations are performed flawlessly, the parties communicating are not alerted to the changes. However, the proposed scheme requires the attacker to be aware of all secret parameters and pre-shared keys of the device to alter original messages sent from gateway or device. As attackers don’t possess this knowledge, a MITM attack can be thwarted.

  2. 2)

    Replay Attack: In a replay attack, an unauthorized user resends previously captured secure information in an attempt to deceive the recipient. In a mutual authentication scheme, the gateway ignores a message if |\({T}_{c}-{T}_{s}\)|> \({T}_{\Delta }\), where \({T}_{\Delta }\) is the maximum transmission delay, preventing an attacker from intercepting and replaying communications. Similar to the first mutual authentication, if |\({T}_{c}-{T}_{s}\)|> \({T}_{\Delta }\)is true, the already authenticated device and gateway device also ignore the message. Assuming the adversary captured the messages and tried to impersonate a legitimate new device by replaying them, Dt would reject the request because of the invalid nonce in the replayed messages. In the same way, if the adversary impersonates valid Dt and replays the messages, the gateway would reject the request as it notices the invalid random numbers. Similarly, during all phases of authentication, additional checks are made to ensure the freshness of messages that contain the random nonce.

  3. 3)

    Identity Anonymity and Untraceability: An adversary shouldn’t learn the device \({D}_{i}\)’s true identity, \({D}_{ID}\), or be able to track \({D}_{i}\) by eavesdropping on any communication channel. The \({D}_{ID}\) in the proposed approach is concealed by utilizing a secret key value x, and each device is given an associated \(AID\). \({D}_{ID}\) not being stored in the device’s memory the adversary cannot use a node capture attack to obtain the true identity. Even if the attacker has the parameter \(AID\), the secret key value x prevents it from tracking the device. Thus, the proposed technique maintains the features of anonymity and untraceability.

  4. 4)

    Eavesdropping Attack: Assuming that an adversary can access all the messages exchanged among the different entities. This means that adversary may have access to \({S}_{Req},\)\({S}_{Hash},\)\({G}_{ch},\) and \({D}_{res}.\) However, adversary cannot get the session key or any other confidential information because the \({PK}_{i}\) is not available to the adversary. As a result, the session key is protected against eavesdropping attack.

  5. 5)

    Known Session Key Secrecy: This security guarantee ensures that even if an attacker possesses knowledge of the session key used for message exchange, the communication remains secure. The proposed scheme utilizes a randomly generated session key \(SKgd=H({g}_{1}||{g}_{2})\), where g1 and g2 are freshly generated at each new session. This approach ensures that the session key cannot be successfully predicted by an attacker, even if they have compromised a previous session key. Similarly, the session key between two devices is calculated as \({SK}_{dd}=H({D}_{ch}^{new}\oplus {D}_{res}^{new})=H(x\oplus {d}^{old}\oplus {d}^{new})\), where \({d}^{old}\) and \({d}^{new}\) are freshly generated for each new session. As a result, an attacker cannot access any sensitive data by predicting future session keys. Thus, the proposed scheme securely establishes the session keys with known session key secrecy.

Table 2 Comparison of security features

5.3 Formal security analysis using AVISPA tool

This subsection provides a brief introduction to AVISPA, a widely used tool that evaluates the security of cryptographic protocols against known attacks and determines their safety status. AVISPA utilizes high-level protocol specification language (HLPSL) codes to specify any security model. The HLPSL2IF translator is employed to convert the HLPSL code into an intermediary form (IF), which is then processed by one of the four back-ends of the AVISPA tool. These back-ends include TA4SP, CL-AtSe, SATMC, and OFMC for security analysis. Overall, AVISPA is a powerful tool that can help researchers and practitioners evaluate the security of cryptographic protocols and identify potential vulnerabilities in their designs.

To analyze the HLPSL specification of the proposed protocol, the Security Protocol Animator (SPAN) of AVISPA simulation tool is utilized on an Ubuntu 10.10 (32-bit) operating system. The HLPSL specification of the proposed scheme outlines the roles of two entities, namely the device and gateway. The SUMMARY of both back-ends (CL-AtSe and OFMC) are obtained as output and shown in Fig. 4. The results demonstrate that this protocol is SAFE against a number of well-known attack, including impersonation, replay, and MITM attacks.

Fig. 4
figure 4

Output summary produced by the AVISPA tool’s two back ends (OFMC and CL_AtSe)

6 Performance analysis

The experimental evaluation of the proposed authentication methodology is presented in this section. The proposed methodology is implemented in Java1.8 on a Windows 11 computer with an 8th generation Intel Core i7 processor and 16 GB of RAM, along with analogous methods that have been identified in the literature. Memory utilization (storage cost), communication costs, and computation cost are some key IoT authentication metrics used in the analysis of experimental outcomes.

6.1 Storage requirement comparison

Table 3 compares the storage requirement of proposed scheme to that of the existing schemes (Li et al. 2017; Jan et al. 2021). \(AID\) and \({PK}_{i}\) are stored in the memory of each device while a few parameters are stored in gateway and CA’s memory in a similar manner. However, the storage requirement of the gateway and CA rises with the number of registered devices in the system. The size of the output of the hash function, identity parameters, and secret key values are 160, 128, and 128 bits, respectively. The overall storage cost of each entity in the suggested scheme is determined based on the size of these parameters.

Table 3 Storage requirement of the proposed scheme in bits

6.2 Communication cost

Table 4 compares the communication cost of the proposed scheme with the existing schemes in terms of the number of messages and bits sent and received by the communicating entities. The proposed authentication process exchanges three messages which takes a total of 544 bits for these messages. As compared to other existing methods, the proposed scheme transfers noticeably less messages and bits.

Table 4 Communicational cost of the authentication process between gateway and device

6.3 Computation cost

To assess the computational cost of all existing authentication schemes, including the proposed one, XOR, concatenation (||), and hash operations are computed. Table 5 shows the number of operations used by both IoT device and the gateway in the authentication phase. \({H}_{T}\) and \({X}_{T}\) represent the time it takes to execute hash and XOR operations, respectively. It should be noted that the computational cost of a scheme is mostly caused by the cryptographic operations used. Therefore, for simplicity, it is possible to approximate the efficiency of a scheme by examining the execution time of these operations. Here, the execution time of hash operation, i.e., \({H}_{T}\) is 32 ms and \({X}_{T}\) is negligible as compared to \({H}_{T}\). As depicted in Table 5 the computation time for each protocol is calculated by considering the cryptographic operations and their execution time. Figure 5 illustrates the corresponding graphical representation.

Table 5 Computation cost of the authentication process between gateway and device
Fig. 5
figure 5

Execution time taken by each scheme

Again the proposed indirect mutual authentication protocol is compared to other similar authentication protocols that are detailed in the literature to evaluate its effectiveness. From the perspective of message exchange, all the existing methods (Farash et al. 2016; Turkanović et al. 2014; Banerjee et al. 2019) are comparable to the proposed protocol because they use an IoT device linked to the gateway to authenticate the new device. To evaluate the proposed protocol, the methods discussed in Farash et al. (2016); Turkanović et al. 2014; Banerjee et al. 2019), are also implemented in this context. The experimental findings show that the proposed protocol significantly reduces computation time at the new IoT device. The experimental results are shown in Table 6 and Fig. 6.

Table 6 Computation cost of the authentication process between new device and gateway through already authenticated device
Fig. 6
figure 6

Execution time taken by each scheme

7 Conclusion and future work

In any IoT-enabled healthcare system, and it is crucial to authenticate each entity before beginning a secure session. The anonymity and untraceability of each device must also be maintained. This article proposes an IoT-enabled healthcare system with a simple anonymous device authentication method. The existing session key established during authentication between the gateway and the immediate device is utilized by the authentication protocol for new devices. This means that the intermediate device simply facilitates the establishment of the session and securely transfers messages to the gateway. This method uses lightweight symmetric cryptographic operations, such as XOR, concatenation, and hashing, to perform mutual authentication between the device and gateway. Furthermore, the proposed authentication process exhibits a smaller message size compared to existing approaches, resulting in lower energy consumption. This makes it well-suited for IoT devices with limited resources. The lightweight nature of the process ensures efficient utilization of device capabilities, making it energy-efficient and suitable for resource-constrained IoT environments.