Secure and Efficient WBAN Authentication Protocols for Intra-BAN Tier

Abstract

Telecare medical information system (TMIS) is a technology used in a wireless body area network (WBAN), which has a crucial role in healthcare services. TMIS uses wearable devices with sensors to collect patients’ data and transmit the data to the controller node via a public channel. Then, the medical server obtains the data from the controller node and stores it in the database to be analyzed. Unfortunately, an attacker can try to perform attacks via a public channel. Thus, establishing a secure mutual authentication protocol is essential for secure data transfer. Several authentication schemes have been presented to achieve mutual authentication, but there are performance limitations and security problems. Therefore, this study aimed to propose two secure and efficient WBAN authentication protocols between sensors and a mobile device/controller: authentication protocol-I for emergency medical reports and authentication protocol-II for periodic medical reports. To analyze the proposed authentication protocols, we conducted an informal security analysis, implemented BAN logic analysis, validated our proposed authentication protocol using the AVISPA simulation tool, and conducted a performance analysis. Consequently, we showed that our proposed protocols satisfy all security requirements in this study, attain mutual authentication, resist active and passive attacks, and have suitable computation and communication costs for a WBAN.

1. Introduction

A WBAN is being utilized effectively in healthcare services remotely because of the fast progress of wireless communication technology. TMIS is one of the WBAN technologies that can provide a variety of healthcare services to patients remotely through telecare servers [1,2,3].

In the TMIS environment, patients can wear wearable devices with many sensors to continuously monitor patients’ physical conditions and collect sensitive health data, such as the temperature of the body, heart rate, pressure, sugar of the blood, and other data [4,5]. The health data are transmitted to patients’ mobile devices and then transferred to medical servers at any time and from any location. Thus, patients can save time and cost by utilizing numerous healthcare services remotely. Due to these advantages, TMIS offers better healthcare services compared to traditional healthcare services [6]. However, despite the advantages of TMIS, sensitive medical data concerning patients must be protected from malicious attacks as they are transmitted through unsecured channels. Thus, secure mutual authentication is essential for secure data transmission [7].

The transmitted messages include emergency medical reports and periodic medical reports. The emergency medical report occurs when a sensor detects an emergency in the body of a patient, which is needed to be sent as soon as the emergency is detected. The periodic medical report occurs when the sensor nodes are requested to collect the patient’s health data and send them to take an appropriate diagnosis at a specific time.

In this paper, we propose two WBAN authentication protocols for the intra-BAN tier: authentication protocol-I for emergency medical reports and authentication protocol-II for periodic medical reports. We conducted an informal security analysis to show that the proposed authentication protocols satisfy all security requirements in this study. Moreover, we implemented BAN logic to evaluate our proposed authentication protocols and ensure they attain mutual authentication. In addition, the AVISPA simulation tool was used to demonstrate that our proposed protocols resist active and passive attacks. Moreover, we conducted a performance analysis by comparing our proposed authentication protocols’ computation and communication costs with related protocols.

The rest of the paper is organized as follows. Section 2 presents the related work, and Section 3 presents the problem statement and the proposed scheme, whereas Section 4 outlines the security analysis of the proposed authentication protocols. In Section 5, a performance analysis of the proposed protocols and related protocols is demonstrated. Finally, Section 6 presents the conclusion.

2. Related Works

WBANs deal with patients’ sensitive health data, which must be safeguarded against cyberattacks. Many researchers have been interested in proposing WBAN authentication protocols to protect patients’ sensitive data transmitted over insecure channels.

2.1. Overview of The System Model

The WBAN includes three tiers [8], as shown in Figure 1:

• The first tier is “Intra-BAN“ The communication in this tier is between sensor nodes and a controller node. Sensors monitor and collect the patient’s data, which are then transmitted via a public channel to the controller node/local server/mobile device.
• The second tier is “Inter-BAN“. The communication in this tier is between a controller node/mobile device and a remote medical server. The controller node gathers data from sensor nodes and then sends them to the medical server via a public channel. The medical server stores the data in the database for later analysis.
• The third tier is “Beyond-BAN“. The communication in this tier is between a medical server and a medical service provider (i.e., a doctor). The medical server can be over the cloud, and the doctor can access the server’s data.

Figure 1. Overview of the WBAN system model.

Figure 1. Overview of the WBAN system model.

2.2. Requirements of Authentication Schemes in WBAN

The authentication schemes in the WBAN must satisfy the following requirements:

• Emergency and periodic authentication protocols: The emergency authentication occurs when a sensor detects an emergency in the patient’s body, and it needs to initiate the authentication request for sending the emergency report securely. Periodic authentication occurs when the controller node requests to collect the patient’s data from a sensor node at a specific time, and the controller initiates the periodic authentication request to the sensor node for transmitting the data securely.
• Replay attack: An attacker can obtain messages when transmissions occur via unsecured channels. However, the attacker is unable to perform a replay attack if the message contains a timestamp.
• Session key disclosure attack: If an attacker tries to obtain the session key, the attacker cannot obtain secret values using messages sent via a public channel. Thus, the session key cannot be calculated by the attacker.
• Impersonation attack: An attacker cannot produce an authentication message to impersonate the legitimate entity.
• Controller node/mobile device stolen attack: If an attacker obtains a legitimate patient’s mobile device, the attacker is unable to extract any information stored on it and is unable to generate a legitimate message.
• Off-line guessing attack: An attacker has the ability to guess either identity or a password, but not both at the same time.
• Perfect forward/backward secrecy: Future keys will not be attacked, and previous keys will not be misused (future/past key secrecy).
• Known session-specific temporary information attack: In case an attacker gets the secret values that are created randomly through the session, the session key cannot be calculated.
• Anonymity and unlinkability: This refers to an attacker being unable to obtain the identity of a legitimate entity through message eavesdropping and being unable to trace a legitimate entity using messages sent during previous sessions.
• Desynchronization attack: The solution should prevent the risk of a desynchronization attack that blocks communication between two parties and render them unable to proceed with authentication.
• Secure password change: This refers to an attacker being unable to arbitrarily change the password of a legitimate mobile device because the identity and password of the legitimate entity are unknown to the attacker.
• Performance: Authentication protocols must be cost-effective in terms of computation and communication.

2.3. Adversary Model

An adversary model’s capabilities are as follows:

• The attacker has total control over all messages sent through unsecured channels. Thus, the attacker has the ability to eavesdrop, manipulate, insert, and remove messages [9].
• An attacker can steal a patient’s mobile device/controller and access the data stored on it [10].
• An attacker could guess either a patient’s identity (ID_i) or password (PW_i), but not both at the same time [2].
• An attacker can perform desynchronization, man-in-the-middle (MITM) attacks, impersonation attacks, replay attacks, and other possible attacks over public channels [11].
• An attacker is unable to compromise the trusted authority’s private key [12].

2.4. The Existing Authentication Schemes in WBAN

The authors of [13] suggested a WBAN authentication protocol for the intra-BAN tier. Their scheme provides a group key generated by a controller node to many sensor nodes. The authentication protocol ensures forward secrecy only in the case of adding or deleting at least one sensor node where the group key is changed. However, it does not ensure forward secrecy when the sensor nodes are constant.

The scheme in [14] presented a WBAN authentication protocol for the interaction among sensor nodes and a controller device. It creates a group key between the controller device and many sensor nodes. The scheme ensures perfect forward secrecy where a new group key is generated for each session even if the sensor nodes are unchanged. However, the scheme has high communication and computation costs do not support node anonymity/unlinkability and are vulnerable to desynchronization attacks, stolen mobile device attacks, and a replay attack [15].

The authors of [16,17] suggested a lightweight WBAN authentication protocol to transmit data on a public channel securely. It relies on XOR operation and hash function to achieve low computation and communication costs. However, it presents security weaknesses such as a stolen mobile device/controller node attack, where an attacker can obtain the sensitive data within the controller device if the attacker can steal it. This allows for establishing the session key between the attacker and the sensor node.

The scheme in [18] presented an authentication protocol for the intra-BAN tier. It prevents node impersonation, MITM, and session key disclosure attacks, and it ensures forward secrecy, node anonymity, and node unlinkability. However, it has high computation and communication costs and does not prevent the risk of a desynchronization attack. The scheme adopts elliptic curve cryptography (ECC) with a point multiplication operation on the sensors and controller side, along with a hash function and XOR operation. However, the point multiplication operation is considered complex for the first tier given the resource constraints of the sensor nodes.

The authors of [19] suggested a lightweight WBAN authentication scheme to transmit sensitive data on a public channel securely. It relies on XOR operation and hash function to enhance performance. In addition, it creates biometric keys by extracting features from physiological signals, such as ECG signals. However, it presents security weaknesses such as a stolen controller device attack. If an attacker steals the controller device, the attacker can extract the secret key of the controller node, the secret key of the sensor node, and the identity of the sensor node, which represents the secret information. Thus, the session key between the attacker and a sensor node may be established.

The authors of [20] suggested a WBAN authentication protocol for the intra-BAN tier. The scheme has suitable computation and communication costs for a WBAN. Moreover, it provides some security features, such as protection from replay attacks, session key disclosure attacks, impersonation attacks, and desynchronization attacks and it ensures perfect forward/backward secrecy and node anonymity/unlinkability. However, it is prone to a stolen mobile device/controller node attack. If an attacker steals the controller device, the attacker can obtain the secret key of the controller device and the sensor node’s identity and then compute the sensor node’s secret key.

Ding et al. [15] and Abiramy and Sudha [21] (pp. 287–296) proposed a WBAN authentication protocol for interaction between sensor nodes and a controller node. The controller node can create a session key and distribute it to the sensor nodes in a group, which means all sensor nodes in the same group can use the same session key with the controller node. In addition, the schemes ensure perfect forward secrecy.

The scheme in [22] worked on establishing mutual authentication for the intra-BAN tier. The scheme prevents node impersonation, man-in-the-middle, and desynchronization attacks and it ensures forward/backward secrecy, node anonymity, and node unlinkability.

The authors of [23] suggested an authentication protocol for the intra-BAN tier. The scheme ensures forward/backward secrecy, node anonymity, and node unlinkability.

The scheme in [24] proposed an authentication protocol for the intra-BAN tier. Their scheme achieves integrity, confidentiality, authentication, and access control over sensitive data.

In summary, we concluded that the existing schemes did not satisfy all the solution requirements in this study, where most schemes focus on proposing secure authentication protocols but still present performance limitations or vice versa. Moreover, all existing schemes do not consider two types of authentication protocols. The first one occurs when a sensor detects an emergency in the patient’s body and needs to initiate an authentication to send the emergency medical report as soon as the emergency is detected. In contrast, the second one occurs when the controller node needs to initiate an authentication to collect the patient’s data from sensor nodes at specific times. Furthermore, most schemes were designed with the assumption that a patient’s mobile device/controller is trusted, but in reality, an attacker can steal the patient’s mobile device and extract the sensitive information stored on it. As a result, they did not protect against the risk of a stolen mobile device/controller attack. Based on analyzing the previous WBAN authentication protocols, it was found that working on improving the existing schemes may lead to secure and efficient authentication protocols in a WBAN.

3. Problem Statement and Proposed Scheme

The public wireless network environment of a WBAN provides a significant security concern in terms of ensuring that only permitted entities have access to patients’ sensitive health data. Unauthorized access may result in interception, interruption, or modification of sensitive data that may threaten a patient’s life [25]. Several authentication schemes have been presented to achieve secure authentication and establish a session key, where the session key is utilized to encrypt the sensitive data transmitted through the insecure channel. Nonetheless, there are still performance limitations and security problems, such as impersonation attacks, desynchronization attacks, and other possible attacks over unsecured channels [26]. Our study will answer the following question:

• How can we achieve secure and efficient WBAN authentication protocols for the intra-BAN tier?

Therefore, we proposed WBAN authentication protocols for securing the communication between sensor nodes and a controller node. The sensor nodes (SN) work as data collectors for the patient body, and the controller node (CN) works as a local server for data collection from sensor nodes. The proposed scheme includes an initialization phase, registration phase, authentication protocol-I, authentication protocol-II, and changing password protocol.

Table 1. Notations that are used in the proposed protocols.

Notation	Description
Pi	i-th patient
CN	Controller node of Pi
SN	Sensor node-i of Pi
TA	Trusted authority
IDi, PWi	Identity and password of Pi
IDSN	Identity of SN
HIDi	Masked identity of Pi
SIDi	Secret identity of Pi
SSN	Secret key of SN
STA, PKTA	Secret key and public key of TA
ai, bi, uSN+, ri	CN-generated random numbers
xSN	SN-generated random number
uSN	TA-generated random number
VSN, WSN, VSN+, WSN+	Data to check message synchronization
RESN	Data used in protocol-II for IDSN retrieval and SN authentication
HPWi, APi, BPi, CPi, DPi	Data used by CN to authenticate Pi
Tn	Timestamp n
Tn*	The time of message receipt
ΔT	The maximum transmission delay
XSN	Data used to retrieve xSN in protocol-I
LSN1	Data used by CN to authenticate SN in protocol-I
Ui	Data used to retrieve uSN+ in protocol-I
C	Data used to retrieve VSN+ in protocol-I
Li1	Data used by SN to authenticate CN in protocol-I
Ri	Data used to retrieve ri in protocol-II
Li2	Data used by SN to authenticate CN in protocol-II
SK-I	Session key for protocol-I
SK-II	Session key for protocol-II
q	Large prime number
G1	An additive group of order q
P	A generator of the group G1
h	Hash function
Zq*	The nonzero positive integers’ modulus q
||	Concatenation operation
*	Scalar multiplication operation
⊕	XOR operation
	Secure communication channel
	Public communication channel

presents the notations that are used in our proposed protocols.

3.1. Initialization Phase

During this phase, TA creates the system’s parameters as well as its private and public keys:

• TA chooses an additive group G₁ of prime order q and a generator P of the group G₁.
• TA selects a secure hash function h:{0,1} → Z_q.
• TA generates a secret random number S_TA ∈ Z_q* as its private key and calculates its public key PK_TA = S_TA * P where S_TA * P denotes the scalar multiplication operation of the point P in G₁.
• TA publishes the system’s parameters (G₁, PK_TA, P, q, h) and keeps S_TA as a private key.

3.2. Registration Phase

As shown in Figure 2, the CN and SN register with TA as follows:

• P_i chooses ID_i and PW_i and then creates a number a_i ∈ Z_q*. P_i calculates HID_i = h (ID_i || a_i) and sends (HID_i) to TA securely. TA calculates SID_i = (HID_i * S_TA) * PK_TA and then stores HID_i in secure memory.
• TA assigns a unique ID_SN for each SN and then creates a number u_SN ∈ Z_q*. TA calculates S_SN = h(ID_SN || SID_i), V_SN = u_SN ⊕ h(SID_i), W_SN = ID_SN ⊕ h(u_SN), and RE_SN = ID_SN ⊕ h(SID_i). TA sends (ID_SN, S_SN, V_SN) to the SN securely to store them in the SN’s memory.
• TA sends (SID_i, V_SN, W_SN, RE_SN) to the CN securely. The CN generates a random number b_i ∈ Z_q* and then calculates HPW_i = h(ID_i PW_i || a_i), AP_i = h(ID_i || PW_i) ⊕ a_i, BP_i = HPW_i ⊕ b_i, CP_i = SID_i ⊕ b_i * P, and DP_i = h(a_i || b_i || HPW_i || SID_i). The CN stores (AP_i, BP_i, CP_i, DP_i, V_SN, W_SN, RE_SN) in its memory.

Figure 2. Registration phase.

Figure 2. Registration phase.

3.3. Authentication Protocol-I

This authentication protocol is for emergency medical reports. When a sensor detects an emergency in the patient’s body, the sensor node initiates the emergency authentication request to the controller node for sending the report securely. Figure 3 shows the authentication protocol between the SN and CN and contains the following steps:

• SN creates a secret number x_SN ∈ Zq* and a current timestamp T₁. The SN computes X_SN = h(S_SN) ⊕ x_SN and L_SN1 = h(ID_SN || x_SN || S_SN || V_SN || T₁). Afterwards, the SN transmits the message (V_SN, L_SN1, X_SN, T₁) to the CN via an unsecured channel.
• When (V_SN, L_SN1, X_SN, T₁) is received, P_i enters ID_i and PW_i to the CN. Then, the CN computes a_i = AP_i ⊕ h(ID_i || PW_i), HPW_i = h(ID_i || PW_i || a_i), b_i = HPW_i ⊕ BP_i, and SID_i = CP_i ⊕ b_i * P. Next, the CN checks to see if DP_i ≟ h(a_i || b_i || HPW_i || SID_i). If so, P_i is logged into the CN successfully.
• The CN checks the validity of the timestamp, i.e., if |T₁ − T₁*| < ΔT, where T₁* denotes the time of message receipt and ΔT denotes the longest possible transmission delay, then the CN retrieves W_SN of V_SN from its memory and then computes u_SN = V_SN ⊕ h(SID_i), ID_SN = W_SN ⊕ h(u_SN), S_SN = h(ID_SN || SID_i), x_SN = h(S_SN) ⊕ X_SN, and L_SN1* = h(ID_SN || x_SN || S_SN || V_SN || T₁). The CN checks whether L_SN1* ≟ L_SN1. If so, then the SN is authenticated. Next, the CN creates a secret random number u_SN⁺ ∈ Z_q* and the current timestamp T₂. Afterwards, the CN computes V_SN⁺ = u_SN⁺ ⊕ h(SID_i), W_SN⁺ = ID_SN ⊕ h(u_SN⁺), U_i = h(S_SN) ⊕ u_SN⁺, SK-I = h(ID_SN || S_SN || x_SN || u_SN⁺ || V_SN), and C = V_SN⁺ ⊕ u_SN⁺. The CN replaces (V_SN, W_SN) with (V_SN, W_SN, V_SN⁺, W_SN⁺) and then computes L_i1 = h(S_SN || SK-I || ID_SN || V_SN⁺ || T₂). The CN transmits the message (U_i, L_i1, C, T₂) to the SN through an unsecured channel.
• When the SN received (U_i, L_i1, C, T₂), the SN checks the validity of the timestamps. If |T₂ − T₂*| < ΔT, where T₂* denotes the time of message receipt, then the SN computes u_SN⁺ = U_i ⊕ h(S_SN), SK-I = h(ID_SN || S_SN || x_SN || u_SN⁺ || V_SN), and V_SN⁺ = C ⊕ u_SN⁺. The SN checks to see if L_i1 ≟ h(S_SN || SK-I || ID_SN || V_SN⁺ || T₂). If so, it replaces (V_SN) with (V_SN⁺) in its memory, and the session key is established between the SN and CN.

Figure 3. Authentication protocol-I.

Figure 3. Authentication protocol-I.

3.4. Authentication Protocol-II

This authentication protocol is for periodic medical reports. When the controller node requests to collect the patient’s data from a sensor node at a specific time, the controller initiates the periodic authentication request to the sensor node for transmitting the data securely, as shown in Figure 4, and contains the following steps:

• P_i inputs ID_i and PW_i to the CN. Then, the CN computes a_i = AP_i ⊕ h(ID_i || PW_i), HPW_i = h(ID_i || PW_i || a_i), b_i = HPW_i ⊕ BP_i, and SID_i = CP_i ⊕ b_i * P. Next, the CN checks to see if DP_i ≟ h(a_i || b_i || HPW_i || SID_i). If so, P_i is logged into the CN successfully.
• The CN retrieves ID_SN from its secure memory, where ID_SN = RE_SN ⊕ h(SID_i), and computes S_SN = h(ID_SN || SID_i). The CN creates a secret number r_i ∈ Zq* and current timestamp T₁ and then computes R_i = h(S_SN) ⊕ r_i, SK-II = h(ID_SN || S_SN || r_i), and L_i2 = h(S_SN || SK-II || ID_SN || T₁). Afterwards, the CN transmits the message (R_i, L_i2, T₁) to the SN via a public channel.
• When (R_i, L_i2, T₁) is received from the CN, the SN checks the validity of the timestamps. If |T₁ − T₁*| < ΔT, where T₁* denotes the time of message receipt, then the SN computes r_i = h(S_SN) ⊕ R_i and SK-II = h(ID_SN || S_SN || r_i). The SN checks to see if L_i2 ≟ h(S_SN || SK-II || ID_SN || T₁). If so, the session key is established between the CN and SN.

Figure 4. Authentication protocol-II.

Figure 4. Authentication protocol-II.

3.5. Password Change Protocol

This protocol provides a secure changing of the password when P_i wants to change the old password of the CN, as shown in Figure 5, and contains the following steps:

• P_i inputs ID_i and PW_i in the CN.
• The CN computes a_i = AP_i ⊕ h(ID_i || PW_i), HPW_i = h(ID_i || PW_i || a_i), b_i = HPW_i ⊕ BP_i, and SID_i = CP_i ⊕ b_i * P. Next, the CN checks to see if DP_i ≟ h(a_i || b_i || HPW_i || SID_i). If so, the CN asks P_i for a new password.
• P_i inputs a new password PW_i⁺.
• The CN calculates HPW_i⁺ = h(ID_i || PW_i⁺ || a_i), AP_i⁺ = h(ID_i || PW_i⁺) ⊕ a_i, BP_i⁺ = HPW_i⁺ ⊕ b_i, CP_i = SID_i ⊕ b_i * P, and DP_i⁺ = h(a_i || b_i || HPW_i⁺ || SID_i). Finally, the CN replaces (AP_i, BP_i, CP_i, DP_i, V_SN, W_SN, RE_SN) with (AP_i⁺, BP_i⁺, CP_i, DP_i⁺, V_SN, W_SN, RE_SN) in the CN.

Figure 5. Change password protocol.

Figure 5. Change password protocol.

4. Security Analysis

Both informal and formal security analyses were conducted to show that our authentication protocols satisfy security requirements.

4.1. Informal Security Analysis

This section discusses the proposed protocols in connection to the aforementioned solution requirements in Section 2.2.

4.1.1. Emergency and Periodic Authentication Protocols

• There are two proposed authentication protocols: the first protocol is for emergency reports, and the second protocol is for periodic reports. According to protocol-I, when a sensor detects an emergency in the patient’s body, the sensor node initiates the emergency authentication request by sending the message M1 = (V_SN, L_SN1, X_SN, T₁) to the CN. An attacker cannot generate a legal L_SN1 because it is computed using the secret key S_SN. Thus, the CN authenticates the SN by checking L_SN1 ≟ h(ID_SN || x_SN || S_SN || V_SN || T₁). Then, the CN responds to the authentication by sending the message M2 = (U_i, L_i1, C, T₂) to the SN. An attacker is unable to generate a valid L_i1, so the SN authenticates the CN by checking L_i1 ≟ h(S_SN || SK-I || ID_SN || V_SN⁺ || T₂). Therefore, the SN and CN can authenticate each other.
• The authentication protocol-Ⅱ occurs when the controller node requests to collect the patient’s data from a sensor node at a specific time. Thus, there is no need to initiate the authentication by the SN, reducing costs and enhancing performance. In this case, the CN requests authentication periodically from the SN, whose identity ID_SN is stored in the CN. The CN initiates the authentication by sending the message M1 = (R_i, L_i2, T₁) to the SN. An attacker cannot generate a legal L_i2 because it is computed using the secret key S_SN. Thus, the SN authenticates the CN by checking L_i2 ≟ h(S_SN || SK-II || ID_SN || T₁). Therefore, the CN and SN can authenticate each other.

4.1.2. Replay and MITM Attacks

We presupposed in the model of the adversary that an attacker could obtain messages when transmissions occurred via unsecured channels. However, the attacker is unable to perform replay and MITM attacks on our protocols because each message sent through a public channel contains a timestamp. For protocol-I, timestamp 1 is created by the SN and contained in the hash value L_SN1 = h(ID_SN || x_SN || S_SN || V_SN || T₁). Timestamp 2 is generated by the CN and contained in the hash value L_i1 = h(S_SN || SK-I || ID_SN || V_SN⁺ || T₂). An attacker is unable to forge the values ID_SN, x_SN, and S_SN for L_SN1 and S_SN, ID_SN, and V_SN⁺ for L_i1.

For protocol-Ⅱ, timestamp 1 is generated by the CN and included in the hash value L_i2 = h(S_SN || SK-II || ID_SN || T₁). An attacker cannot tamper with the values S_SN and ID_SN for L_i2. Therefore, the proposed protocols are resistant to such attacks.

4.1.3. Session Key Disclosure Attack

This security requirement is intended to ensure that if an attacker attempts to obtain the session key, the attacker cannot obtain secret values using messages sent via a public channel. For protocol-I, if an attacker wants to obtain the session key SK-I, the attacker must first obtain ID_SN, S_SN, x_SN, and u_SN⁺. However, the attacker cannot obtain these values through messages sent over a public channel to compute SK-I.

For protocol-Ⅱ, if an attacker tries to obtain the session key SK-II, the attacker must first obtain ID_SN, S_SN, and r_i. However, the attacker cannot obtain these values through the message sent via a public channel. Thus, the attacker cannot obtain the session keys.

4.1.4. Impersonation Attack

This security requirement aims to ensure that an attacker cannot produce an authentication message to impersonate a legitimate entity. For protocol-I, an attacker must generate an authentication message (V_SN, L_SN1, X_SN, T₁) to impersonate the genuine SN. However, the attacker is unable to calculate a legal L_SN1 because it is computed using the secret key S_SN = h(ID_SN || SID_i), and the attacker cannot compute a legal S_SN because it is computed using the secret identity SID_i = (HID_i * S_TA) * PK_TA, where we assumed in the adversary model that an attacker cannot compromise the TA’s private key. Thus, the CN checks L_SN1 ≟ h(ID_SN || x_SN || S_SN || V_SN || T₁). If they do not match, then the attacker is locked out by the CN. Moreover, the attacker must generate an authentication message (U_i, L_i1, C, T₂) to impersonate the genuine CN. However, the attacker is unable to calculate a legal L_i1. Thus, the SN checks L_i1 ≟ h(S_SN || SK-I || ID_SN || V_SN⁺ || T₂). If they do not match, then the attacker is locked out by the SN.

For protocol-Ⅱ, an attacker must generate an authentication message (R_i, L_i2, T₁) to impersonate the legitimate CN. However, the attacker cannot calculate a legal L_i2 because it is calculated using the secret key S_SN, and the secret key is computed using the secret identity SID_i. Thus, the SN checks L_i2 ≟ h(S_SN || SK-II || ID_SN || T₁). If they do not match, then the attacker is locked out by the SN. Therefore, our protocols are resistant to such attacks.

4.1.5. Mobile Device Stolen Attack

We assumed in the model of adversary that the mobile device/controller of the genuine P_i can be stolen by an attacker. However, for protocol-I, when the attacker receives an authentication message from the SN, the session key cannot be established between the SN and the attacker because the attacker cannot extract P_i’s ID_i and PW_i and cannot compute SID_i.

For protocol-II, the attacker cannot create a valid authentication message because the attacker cannot extract P_i’s ID_i and PW_i and cannot compute SID_i. As a result, the proposed protocols are resistant to such attacks.

4.1.6. Off-Line Guessing Attack

We presupposed in the model of the adversary that an attacker could guess either P_i’s ID_i or PW_i but not both at the same time. For protocol-I and protocol-II, the attacker cannot compute a_i = AP_i ⊕ h(ID_i || PW_i) without correctly guessing both ID_i and PW_i at the same time. Thus, the attacker cannot compute HPW_i, b_i, and SID_i. Therefore, the proposed protocols are resistant to such attacks.

4.1.7. Perfect Forward/Backward Secrecy

This security service aims to guarantee that if an attacker obtains any session key, this should not impact the secrecy of future/past session keys. For authentication protocol-I, the session key cannot be calculated by the attacker SK-I = h(ID_SN || S_SN || x_SN || u_SN⁺ || V_SN) because the attacker cannot obtain x_SN and u_SN⁺, which are secret random numbers.

For authentication protocol-II, the session key cannot be calculated by the attacker SK-II = h(ID_SN || S_SN || r_i) because it is a dynamic that involves a secret random number r_i. Thus, our protocols guarantee forward/backward secrecy, as a new session key is created for each session.

4.1.8. Known Session-Specific Temporary Information Attack

This security requirement aims to ensure that if an attacker gets the secret values that are created randomly through the session, the session key cannot be calculated. For protocol-I, if an attacker obtains the secret values x_SN and u_SN⁺, which are created randomly during the session between the SN and CN, the attacker still cannot compute S_SN = h(ID_SN || SID_i) without obtaining SID_i = (HID_i * S_TA) * PK_TA. Thus, the session key cannot be calculated by the attacker SK-I = h(ID_SN || S_SN || x_SN || u_SN⁺ || V_SN).

For protocol-Ⅱ, if an attacker obtains the random number r_i generated during the session between the CN and SN, the attacker still cannot compute S_SN without obtaining SID_i. Thus, the session key cannot be calculated by the attacker SK-II = h(ID_SN || S_SN || r_i). Therefore, the proposed protocols are resistant to such attacks.

4.1.9. Node Anonymity and Untraceability

For protocol-I, the messages transmitted in the authentication, i.e., M1 = (V_SN, L_SN1, X_SN, T₁) and M2 = (U_i, L_i1, C, T₂), are updated during each session because the authentication depends on secret random numbers x_SN and u_SN⁺. Likewise, for protocol-Ⅱ, the messages transmitted by the CN, i.e., M3 = (R_i, L_i2, T₁), depend on a secret random number r_i, making the messages transmitted during the session independently. Thus, the attacker cannot obtain ID_i and ID_SN through eavesdropping on these messages and the attacker is unable to track a node using the messages sent during previous sessions. As a result, our protocols preserve these security features.

4.1.10. Desynchronization Attack

A desynchronization attack blocks communication between parties at a particular stage during the authentication, rendering both parties unable to update some data synchronously and proceed with authentication. The proposed authentication protocol-I prevents desynchronization attacks by updating the data (V_SN, W_SN) stored by the CN and (V_SN) stored by the SN during the authentication. If the attacker blocks the communication from the SN to CN, the SN needs to restart a new authentication round. If the attacker blocks the communication from the CN to SN, there are data stored in the CN (V_SN, W_SN, V_SN⁺, W_SN⁺) indicated as the nonupdated and updated data. When the SN sends a new authentication request to the CN using the nonupdated data (V_SN), the CN can still use the nonupdated data (V_SN, W_SN).

In other words, the CN and SN, respectively, can verify that the received message is synchronized by checking the equality of L_SN1* ≟ h(ID_SN || x_SN || S_SN || V_SN || T₁) and L_i1 ≟ h(S_SN || SK-I || ID_SN || V_SN⁺ || T₂) [27].

For protocol-II, if the attacker blocks the communication from the CN to SN, the CN only needs to restart a new authentication round [28,29]. Therefore, our protocols prevent the risk of a desynchronization attack.

4.1.11. Secure Password Change

Our protocols provide a secure password change when a P_i wants to change the old password. First, the P_i must input the current ID_i and PW_i in the CN to ensure that the user is the legitimate owner of the CN, where the CN checks whether DP_i ≟ h(a_i || b_i || HPW_i || SID_i). If so, the CN requests a new password from the P_i and then computes HPW_i⁺, AP_i⁺, BP_i⁺, and DP_i⁺. After that, the CN replaces (AP_i, BP_i, CP_i, DP_i, V_SN, W_SN, RE_SN) with (AP_i⁺, BP_i⁺, CP_i, DP_i⁺, V_SN, W_SN, RE_SN) in the CN for future purposes. Thus, an attacker cannot arbitrarily change the password because the attacker does not know ID_i and PW_i. Therefore, our protocols provide a secure password change.

In summary,

Table 2. Security features comparison.

Feature	[13]	[14]	[16]	[17]	[18]	[19]	[20]	Proposed
Emergency and periodic authentication protocols	×	×	×	×	×	×	×	✓
Replay and MITM attacks	N/A	N/A	✓	✓	✓	✓	✓	✓
Session key disclosure attack	✓	✓	N/A	N/A	✓	N/A	✓	✓
Impersonation attack	N/A	N/A	✓	✓	✓	✓	✓	✓
Mobile device stolen attack	×	×	×	×	×	×	×	✓
Off-line guessing attack	N/A	N/A	N/A	✓	N/A	N/A	N/A	✓
Perfect forward/backward secrecy	×	✓	✓	✓	✓	✓	✓	✓
Known session-specific temporary information	N/A	N/A	N/A	N/A	✓	N/A	✓	✓
Node anonymity and unlinkability	×	×	✓	✓	✓	✓	✓	✓
Desynchronization attacks	×	×	✓	✓	×	✓	✓	✓
Secure password change	×	×	×	×	×	×	×	✓

N/A = Information not available.

shows the security features’ comparison of our authentication protocols with related protocols [13,14,16,17,18,19,20]. As shown in Table 2, our protocols met all security requirements.

4.2. BAN Logic Proof

We implemented BAN logic to evaluate our proposed authentication protocols and ensure they attain mutual authentication [30].

4.2.1. Basic Notation

We used the following fundamental notation in both authentication protocol-I and protocol-II:

• P, Q: two principals.
• X₁, X₂: two statements.
• SK: the session key.
• P|≡ X₁: P believes X₁, if X₁ is true.
• P⊲ X₁: P sees X₁, i.e., P receives X₁ contained within a message, but P does not necessarily believe X₁.
• P|∼X₁: P once says X₁, i.e., P transmits a message including X₁. It is unclear if P sent the message lately or a long time ago, but P believes X₁ when P sent it.
• P|⇒ X₁: P controls X₁, and P should trust X₁.
• #(X₁): X₁ is fresh, i.e., X₁ has never been sent before.
• (X₁) _K: X₁ is combined with K.
• P $\stackrel{K}{\leftrightarrow }$ Q: P and Q have the same key K.
• $\frac{P}{Q}$: if P is true, then Q is also true.

4.2.2. Inference Rules

Rule 1 (Message meaning rule)

$$MMR=\frac{P | \equiv P \stackrel{K}{\leftrightarrow } Q, P ⊲{(X_1)}_K}{P | \equiv Q | \sim X_1}$$

Rule 2 (Nonce verification rule)

$$NVR=\frac{P |\equiv \#(X_1),P |\equiv Q |\sim X_1 }{P |\equiv Q |\equiv X_1}$$

Rule 3 (Jurisdiction rule)

$$JR=\frac{P |\equiv Q|\Rightarrow X_1,P |\equiv Q |\equiv X_1}{P |\equiv X_1}$$

Rule 4 (Belief rule)

$$BR=\frac{P |\equiv (X_1,X_2) }{P |\equiv X_1}$$

Rule 5 (Freshness rule)

$$FR=\frac{P |\equiv \#(X_1)}{P |\equiv \#(X_1,X_2)}$$

Rule 6 (Session key rule)

$$SKR=\frac{P |\equiv \#(X_1),P |\equiv Q |\equiv X_1}{P | \equiv P \stackrel{K}{\leftrightarrow } Q}$$

4.2.3. Protocol-I Goals

• G1: SN | ≡ (SN $\stackrel{SK-I}{\leftrightarrow }$ CN)
• G2: SN | ≡ CN | ≡ (SN $\stackrel{SK-I}{\leftrightarrow }$ CN)
• G3: CN | ≡ (SN $\stackrel{SK-I}{\leftrightarrow }$ CN)
• G4: CN | ≡ SN | ≡ (SN $\stackrel{SK-I}{\leftrightarrow }$ CN)

4.2.4. Protocol-I Assumptions

• A₁: CN | ≡ #(T₁)
• A₂: SN | ≡ #(T₂)
• A₃: SN | ≡ CN ⇒ (SN $\stackrel{SK-I}{\leftrightarrow }$ CN)
• A₄: CN | ≡ SN ⇒ (SN $\stackrel{SK-I}{\leftrightarrow }$ CN)
• A₅: SN | ≡ SN $\stackrel{S_{SN}}{\leftrightarrow }$ CN
• A₆: CN| ≡ SN $\stackrel{S_{SN}}{\leftrightarrow }$ CN

4.2.5. Protocol Idealized Forms

• Msg₁: $SN\to \mathit{CN}:{(V_{SN},x_{SN},I{D}_{SN},T_1)}_{S_{SN}}$
• Msg₂: $CN\to SN:{(V_{SN}^{+},u_{SN}^{+},I{D}_{SN},T_2)}_{S_{SN}}$

4.2.6. Protocol-I Formal Analysis

We implemented the BAN logic analysis of the proposed authentication protocol-I as below:

Step 1: D₁ is obtained from Msg₁.

$$D_1:CN⊲{(V_{SN},x_{SN}, I{D}_{SN}, T_1)}_{S_{SN}}$$

Step 2: $CN$ verifies the transmitted message is from $SN$. Applying MMR with D₁ and A₆ yields D₂.

$$\frac{CN | \equiv SN \stackrel{S_{SN}}{\leftrightarrow }CN, CN⊲{(V_{SN},x_{SN}, I{D}_{SN}, T_1)}_{S_{SN}}}{CN| \equiv SN | \sim (V_{SN},x_{SN}, I{D}_{SN}, T_1)}$$

$$D_2:CN| \equiv SN | \sim (V_{SN},x_{SN}, I{D}_{SN}, T_1)$$

Step 3: $CN$ checks whether the $SN$ request is fresh. Applying FR with A₁ and D₂ yields D₃.

$$\frac{CN|\equiv \#({\mathrm{T}}_1)}{CN|\equiv \#(V_{SN},x_{SN}, I{D}_{SN}, T_1)}$$

$$D_3: CN|\equiv \#(V_{SN},x_{SN}, I{D}_{SN}, T_1)$$

Step 4: $CN$ checks whether the $SN$ request is valid. Applying NVR with D₂ and D₃ yields D₄.

$$\frac{CN|\equiv \#(V_{SN},x_{SN}, I{D}_{SN}, T_1),CN| \equiv SN | \sim (V_{SN},x_{SN}, I{D}_{SN}, T_1) }{CN |\equiv SN |\equiv (V_{SN},x_{SN}, I{D}_{SN}, T_1)}$$

$$D_4: CN |\equiv SN |\equiv (V_{SN},x_{SN}, I{D}_{SN}, T_1)$$

Step 5: The $\mathrm{CN}$ now trusts the SN and all its transmitted parameters. D₅ is obtained by applying BR using D₄.

$$\frac{CN |\equiv SN |\equiv (V_{SN},x_{SN}, I{D}_{SN}, T_1)}{CN |\equiv SN |\equiv (V_{SN},x_{SN}, I{D}_{SN})}$$

$$D_5: CN |\equiv SN |\equiv (V_{SN},x_{SN}, I{D}_{SN})$$

Step 6: D₆ is obtained by applying SKR using D₃ and D₅ to accomplish G4.

$$\frac{CN|\equiv \#(V_{SN},x_{SN}, I{D}_{SN}, T_1),CN |\equiv SN |\equiv \left(V_{SN},x_{SN}, I{D}_{SN}\right)}{CN|\equiv SN|\equiv \left(SN \stackrel{SK-I}{\leftrightarrow } CN\right)}$$

$$D_6:CN|\equiv SN|\equiv \left(SN \stackrel{SK-I}{\leftrightarrow } CN\right)$$

Step 7: $CN$ has full control over the transmitted SN parameters. D₇ is obtained by applying JR using A₄ and D₆ to accomplish G3

$$\frac{CN|\equiv SN\Rightarrow (SN\stackrel{SK-I}{\leftrightarrow }CN),CN|\equiv SN|\equiv (SN\stackrel{SK-I}{\leftrightarrow }CN)}{CN | \equiv (SN\stackrel{SK-I}{\leftrightarrow }CN)}$$

$$D_7:CN | \equiv (SN\stackrel{SK-I}{\leftrightarrow }CN)$$

Step 8: D₈ is obtained from Msg₂

$$D_8: SN⊲{(V_{SN}^{+},u_{SN}^{+},I{D}_{SN},T_2)}_{S_{SN}}$$

Step 9: $SN$ verifies the transmitted message is from $CN$. Applying MMR with D₈ and A₅ yields D₉.

$$\frac{SN | \equiv SN\stackrel{S_{SN}}{\leftrightarrow }CN , SN⊲{(V_{SN}^{+},u_{SN}^{+},I{D}_{SN},T_2)}_{S_{SN}}}{SN | \equiv CN | \sim (V_{SN}^{+},u_{SN}^{+},I{D}_{SN},T_2)}$$

$$D_9:SN | \equiv CN | \sim (V_{SN}^{+},u_{SN}^{+},I{D}_{SN},T_2)$$

Step 10: $SN$ checks whether $CN$ request is fresh. Applying FR with A₂ and D₉ yields D₁₀.

$$\frac{SN |\equiv \#(T_2)}{SN |\equiv \#(V_{SN}^{+},u_{SN}^{+},I{D}_{SN},T_2)}$$

$$D_{10}: SN |\equiv \#(V_{SN}^{+},u_{SN}^{+},I{D}_{SN},T_2)$$

Step 11: $SN$ checks whether $CN$ request is valid. Applying NVR with D₉ and D₁₀ yields D₁₁.

$$\frac{SN |\equiv \#(V_{SN}^{+},u_{SN}^{+},I{D}_{SN},T_2), SN | \equiv CN | \sim (V_{SN}^{+},u_{SN}^{+},I{D}_{SN},T_2)}{SN | \equiv CN |\equiv (V_{SN}^{+},u_{SN}^{+},I{D}_{SN},T_2)}$$

$$D_{11}: SN | \equiv CN |\equiv (V_{SN}^{+},u_{SN}^{+},I{D}_{SN},T_2)$$

Step 12: $SN$ now trusts $CN$ and all its transmitted parameters. Applying BR with D₁₁ yields D₁₂.

$$\frac{SN | \equiv CN |\equiv (V_{SN}^{+},u_{SN}^{+},I{D}_{SN},T_2)}{SN | \equiv CN |\equiv (V_{SN}^{+},u_{SN}^{+},I{D}_{SN})}$$

$$D_{12}: SN | \equiv CN |\equiv (V_{SN}^{+},u_{SN}^{+},I{D}_{SN})$$

Step 13: D₁₃ is obtained by applying SKR using D₁₀ and D₁₂ to accomplish G2.

$$\frac{SN |\equiv \#(V_{SN}^{+},u_{SN}^{+},I{D}_{SN},T_2), SN | \equiv CN |\equiv (V_{SN}^{+},u_{SN}^{+},I{D}_{SN})}{SN | \equiv CN| \equiv (SN\stackrel{SK-I}{\leftrightarrow }CN)}$$

$$D_{13}: SN | \equiv CN| \equiv (SN\stackrel{SK-I}{\leftrightarrow }CN)$$

Step 14: $SN$ has the new session key’s parameters from transmitted $CN$ parameters. D₁₄ is obtained by applying JR to A₃ and D₁₃ to accomplish G₁.

$$\frac{SN |\equiv CN\Rightarrow (SN\stackrel{SK-I}{\leftrightarrow }CN),SN | \equiv CN| \equiv (SN\stackrel{SK-I}{\leftrightarrow }CN) }{SN | \equiv (SN\stackrel{SK-I}{\leftrightarrow }CN)}$$

$$D_{14}: SN | \equiv (SN\stackrel{SK-I}{\leftrightarrow }CN)$$

In summary of protocol-I, the $SN$ and CN attained mutual authentication. Furthermore, the session key SK-I was established in a secure manner based on G1, G2, G3, and G4. In the following, we analyze the authentication protocol-II.

4.2.7. Protocol-II Goals

• G1: $SN$ | ≡ ($CN$ $\stackrel{SK-II}{\leftrightarrow }$ $SN)$
• G2: $SN$ | ≡ $CN$| ≡ ($CN$ $\stackrel{SK-II}{\leftrightarrow }$ $SN)$
• G3: $CN$| ≡ ($CN$ $\stackrel{SK-II}{\leftrightarrow }$ $SN)$
• G4: $CN$| ≡ $SN$ | ≡ ($CN$ $\stackrel{SK-II}{\leftrightarrow }$ $SN)$

4.2.8. Protocol-II Assumptions

• A₁: $SN$ | ≡ #(T₁)
• A₂: $SN$ | ≡ $CN$⇒ ($CN$ $\stackrel{SK-II}{\leftrightarrow }$ $SN$)
• A₃: $CN$| ≡ $SN$ ⇒ ($CN$ $\stackrel{SK-II}{\leftrightarrow }$ $SN$)
• A₄: $SN$ | ≡ $CN$ $\stackrel{S_{SN}}{\leftrightarrow }$ $SN$
• A₅: $CN$| ≡ $SN$| ≡ ($I{D}_{SN}$)

4.2.9. Protocol-II Idealized Forms

• Msg₁: $T\mathrm{A}\to CN:(I{D}_{SN})$
• Msg₂: $CN\to SN:{(r_i,I{D}_{SN},T_1)}_{S_{SN}}$

4.2.10. Protocol-II Formal Analysis

We implemented the BAN logic to analyze our proposed authentication protocol-Ⅱ, as below:

Step 1: D₁ is obtained from Msg₁.

$$D_1:CN⊲(I{D}_{SN})$$

Step 2: $CN$ trusts the transmitted parameters from TA and trusts the $SN$ is legitimate. D₂ is obtained from A₅, S_SN = h (ID_SN || SID_i), r_i = h (S_SN) ⊕ R_i, and the session key SK-II = h (ID_SN || S_SN || r_i) to accomplish G4.

$$D_2:CN| \equiv SN| \equiv (CN \stackrel{SK-II}{\leftrightarrow } SN)$$

Step 3: D₃ is obtained by applying JR using A₃ and D₂ to accomplish G3.

$$\frac{CN|\equiv SN\Rightarrow (CN \stackrel{SK-II}{\leftrightarrow } SN),CN| \equiv SN| \equiv (CN \stackrel{SK-II}{\leftrightarrow } SN)}{CN|\equiv (CN \stackrel{SK-II}{\leftrightarrow } SN)}$$

$$D_3: CN|\equiv (CN \stackrel{SK-II}{\leftrightarrow } SN)$$

Step 4: D₄ is obtained from Msg₂

$$D_4: SN⊲{(r_i,I{D}_{SN},T_1)}_{S_{SN}}$$

Step 5: $SN$ verifies the transmitted message is from $CN$. Applying MMR with D₄ and A₄ yields D₅.

$$\frac{SN | \equiv CN \stackrel{S_{SN}}{\leftrightarrow } SN, SN⊲{(r_i,I{D}_{SN},T_1)}_{S_{SN}}}{SN | \equiv CN| \sim (r_i,I{D}_{SN},T_1)}$$

$$D_5: SN | \equiv CN| \sim (r_i,I{D}_{SN},T_1)$$

Step 6: $SN$ checks whether the $CN$ request is fresh. Applying FR with A₁ and D₅ yields D₆.

$$\frac{SN |\equiv \#(T_1)}{SN |\equiv \#(r_i,I{D}_{SN},T_1)}$$

$$D_6: SN |\equiv \#(r_i,I{D}_{SN},T_1)$$

Step 7: $SN$ checks whether the $CN$ request is valid. Applying NVR with D₅ and D₆ yields D₇.

$$\frac{SN |\equiv \#(r_i,I{D}_{SN},T_1),SN | \equiv CN| \sim (r_i,I{D}_{SN},T_1)}{SN | \equiv CN|\equiv (r_i,I{D}_{SN},T_1)}$$

$$D_7: SN | \equiv CN|\equiv (r_i,I{D}_{SN},T_1)$$

Step 8: $SN$ now trusts $CN$ and all its transmitted parameters. Applying BR with D₇ yields D_8.

$$\frac{SN | \equiv CN|\equiv (r_i,I{D}_{SN},T_1)}{SN | \equiv CN|\equiv (r_i,I{D}_{SN})}$$

$$D_8: SN | \equiv CN|\equiv (r_i,I{D}_{SN})$$

Step 9: D₉ is obtained by applying SKR, using D₆ and D₈ to accomplish G2.

$$\frac{SN |\equiv \#(r_i,I{D}_{SN},T_1), SN | \equiv CN|\equiv (r_i,I{D}_{SN})}{SN |\equiv CN|\equiv (CN\stackrel{SK-II}{\leftrightarrow }SN)}$$

$$D_9: SN |\equiv CN|\equiv (CN\stackrel{SK-II}{\leftrightarrow }SN)$$

Step 10: $SN$ has the new session key’s parameters from transmitted $CN$ parameters. D₁₀ is obtained by applying JR, using A₂ and D₉ to accomplish G1.

$$\frac{SN |\equiv CN\Rightarrow (CN\stackrel{SK-II}{\leftrightarrow }SN),SN | \equiv CN| \equiv (CN\stackrel{SK-II}{\leftrightarrow }SN) }{SN | \equiv (CN\stackrel{SK-II}{\leftrightarrow }SN)}$$

$$D_{10}: SN | \equiv (CN\stackrel{SK-II}{\leftrightarrow }SN)$$

In summary of protocol-Ⅱ, the $CN$ and SN attained mutual authentication. Furthermore, the session key SK-II was established in a secure manner based on G1, G2, G3, and G4.

4.3. AVISPA Simulation Tool

We used the Automated Validation of Internet Security Protocols and Applications (AVISPA) simulation tool and the Security Protocol ANimator for AVISPA (SPAN) to analyze the security of the proposed authentication protocols. We showed that the simulator executed our authentication protocols entirely, proving the validity of the authentication and privacy reports generated by AVISPA’s security checker module. First, we wrote the protocol-I and protocol-II codes in High-Level Protocol Specification Language (HLPSL). After that, we ran the SPAN animator to confirm that protocol-I and protocol-II were entirely executable. Finally, we ran the On-the-Fly Model Checker (OFMC) and the Constraint Logic-Based Attack Searcher (CL-AtSe) to determine whether our protocols’ security goals were SAFE or UNSAFE. If the results of the OFMC and CL-AtSe models were SAFE, it meant that the protocols were secure.

Figure 6 and Figure 7 show the HLPSL code for authentication protocol-I. Figure 8 and Figure 9 show the HLPSL code for protocol-II. We had three agents’ roles, a session role, and an environment role. The role controller was played by agent CN, the role sensor was played by agent SN, and the role trustedauthority was played by agent TA. The role controller header contained SN, CN, and TA as agents, hash function, SKcnta as the symmetric key used to create a secure channel, and SND/RCV channels of type Dolev–Yao (dy). The role sensor header contained SN, CN, and TA as agents, hash function, SKsnta as the symmetric key to generate a secure channel, and SND/RCV channels. The role trustedauthority header contained SN, CN, and TA as agents, hash function, SKsnta/SKcnta as the symmetric keys, and SND/RCV channels. The SN was not permitted to know SKcnta, and the CN did not know SKsnta.

Figure 6. HLPSL code for protocol-I.

Figure 6. HLPSL code for protocol-I.

Figure 7. HLPSL code for protocol-I.

Figure 7. HLPSL code for protocol-I.

Figure 8. HLPSL code for protocol-II.

Figure 8. HLPSL code for protocol-II.

Figure 9. HLPSL code for protocol-II.

Figure 9. HLPSL code for protocol-II.

Moreover, HLPSL should specify the session and environment roles. The role session defines the interactions between the three agents’ roles, which describes a protocol session. The role environment includes the intruder knowledge, specifies the goal, and expresses a composition of one or more sessions. The parameters (sp1, sp2, sp3, sp4, sp5, sn_cn_xsn, sn_cn_t1, cn_sn_usn, cn_sn_t2) of protocol-I and parameters (sp1, sp2, sp3, sp4, sp5, sn_cn_idsn, cn_sn_ri, cn_sn_t1) of protocol-II are declared as protocol_id and are used as privacy and authentication checkers. In the goal section, the goal secrecy_of sp1, sp2, sp3, sp4, sp5 indicates that the values of specific variables are kept secret to the specific agents. The goals authentication_on sn_cn_xsn and authentication_on sn_cn_idsn express that the CN authenticates the SN after receiving messages containing these values. The goal authentication_on sn_cn_t1 means that the SN selects a timestamp t1 and the CN authenticates the SN after receiving a message from the SN containing t1. The goals authentication_on cn_sn_usn and authentication_on cn_sn_ri mean that the CN generates random values and the SN checks that CN is the emitter of these values and authenticates CN after receiving messages from CN containing these values. The goals authentication_on cn_sn_t1 and authentication_on cn_sn_t2 indicate that the CN selects timestamps and the SN authenticates the CN after receiving the timestamps from the messages of the CN.

We used the SPAN animator to demonstrate the correct execution of our proposed protocols. Figure 10 and Figure 11 show snapshots of the SPAN animator of protocol-I and protocol-II, respectively. As shown in Figure 10 and Figure 11, all messages were executed and exchanged by the simulator. No message was left unexecuted.

The simulation results of our protocols using AVISPA with OFMC and CL-AtSe are shown in Figure 12. The summary reports demonstrate that the proposed protocol-I and protocol-II were SAFE and met all the security goals stated in the role environment.

Figure 10. SPAN animator of protocol-I.

Figure 10. SPAN animator of protocol-I.

Figure 11. SPAN animator of protocol-II.

Figure 11. SPAN animator of protocol-II.

Figure 12. AVISPA with OFMC and CL-AtSe summary reports: (a) protocol-I OFMC report; (b) protocol-I CL-AtSe report; (c) protocol-II OFMC report; (d) protocol-II CL-AtSe report.

Figure 12. AVISPA with OFMC and CL-AtSe summary reports: (a) protocol-I OFMC report; (b) protocol-I CL-AtSe report; (c) protocol-II OFMC report; (d) protocol-II CL-AtSe report.

5. Performance Analysis

In this section, we compare the computation and communication costs of our proposed authentication protocols with those of related protocols [13,14,16,17,18,19,20].

5.1. Computation Costs

To calculate the computation costs, we considered the time complexity of each operation based on the experiments conducted in [2] and [31], where the time needed for scalar multiplication (T_mul) was 2.226 ms, the time needed for random number generation (T_rng) was 0.539 ms, the time needed for symmetric encryption and decryption (T_ed) was 0.0046 ms, the time needed for point addition (T_add) was 0.0288 ms, and the time needed for the one-way hash function (T_h) was 0.0023 ms.

The computation cost for Shen et al.’s scheme in [13] amounted to 6 T_mul + 2 T_ed + 2 T_add + 1, T_h ≈ 13.4251 ms. The computation cost of Liu et al. [14] was 4 T_mul + 2 T_ed + 2 T_h ≈ 8.9178 ms. The computation cost of Ur Rehman et al.’s scheme in [16] was 3 T_rng + 6 T_h ≈1.6308 ms. Chen et al.’s scheme in [17] had a cost of 3 T_rng+ 7 T_h ≈1.6331 ms. Wan et al.’s scheme in [18] required 2 T_rng+ 11 T_h + 6 T_mul ≈ 14.4593 ms. Moreover, the computation cost of Rehman et al.’s scheme in [19] was 1 T_rng+ 5 T_h ≈ 0.5505 ms. The computation cost for Li et al [20] was 2 T_rng+ 8 T_h ≈ 1.0964 ms. Our authentication protocol-I required 1 T_mul + 2 T_rng + 11, T_h ≈ 3.3293 ms. The cost of our authentication protocol-II was 1 T_mul + 1 T_rng + 8 T_h ≈ 2.7834 ms.

As shown in

Table 3. Computation cost comparison.

Scheme	Computation Cost (ms)
[18]	14.4593
[13]	13.4251
[14]	8.9178
[17]	1.6331
[16]	1.6308
[20]	1.0964
[19]	0.5505
Proposed Protocol-I	3.3293
Proposed Protocol-II	2.7834

, the proposed authentication protocols had a better computation cost compared to the computation costs in [13,14,18] and had a higher computation cost than the computation costs in [16,17,19,20]. However, the existing schemes presented security concerns, where they did not satisfy all security requirements in this study. Thus, our proposed authentication protocols achieved better security than other schemes and had acceptable computation costs. Therefore, the proposed authentication protocols were suitable for the WBAN.

5.2. Communication Costs

To calculate the communication costs, we considered the bit sizes and communication overhead. Bit sizes were calculated based on the schemes in [31] and [32], where the one-way hash function had 160 bits, the group element G1 had 1024 bits, the identity had 128 bits, and the timestamp required 32 bits.

In Shen et al.’s [13] scheme, the first authentication message (Q_i) required 1024 bits, the second authentication message (MAC_PDA, Q_PDA) needed 1184 bits, and the third message (M) needed 1024 bits. Therefore, the total cost was 3232 bits. In Liu et al. [14], the first message (MAC_C) needed 160 bits, the second message (MAC_i⁺) required 160 bits, and the third message (M) needed 1024 bits. Thus, the total cost was 1344 bits. In Ur Rehman et al. [16], the first message (tid_N, a_N, b_N, t_N) needed 192 bits and the second message (β, µ, η) required 160 bits. Thus, the total cost was 352 bits. In Chen et al. [17], the first message (tid_N,y_N,a_N,b_N,t_N) needed 352 bits and the second message (α, β, η, µ) required 480 bits. Thus, the total cost was 832 bits. In Wan et al. [18], the first message (D₁, G_SN, Z_SN, W₁, T₁) needed 1536 bits, the second message (M₁, W₂, T₂) needed 1216 bits, and the third message (W₃, T₃) needed 192 bits. Thus, the total cost was 2944 bits. In Rehman et al. [19], the first message (tid_N,a_N,b_N,t_N) needed 192 bits, whereas the second message (β, µ, η) required 160 bits. Therefore, the total cost was 352 bits. In Li et al. [20], the first message (tid_SN, H_SN, x) needed 448 bits and the second message (tid_SN, z, H_CN) required 448 bits. Thus, the total cost was 896 bits. In our proposed authentication protocol-I, the first message (V_SN, L_SN1, X_SN, T₁) needed 512 bits and the second message (U_i, L_i1, C, T₂) needed 352 bits. Therefore, the total cost was 864 bits. In our proposed authentication protocol-II, the message (R_i, L_i2, T₁) needed 352 bits.

The result of the communication cost comparison is shown in

Table 4. Communication cost comparison.

Scheme	Communication Cost (bits)	Communication Overhead
[13]	3232	3
[18]	2944	3
[14]	1344	3
[20]	896	2
[17]	832	2
[16]	352	2
[19]	352	2
Proposed Protocol-I	864	2
Proposed Protocol-II	352	1

. In terms of communication costs in bits, authentication protocol-I had a better communication cost than the communication costs in [13,14,18,20] and had a higher communication cost than the communication costs in [16,17,19]. However, protocol-I achieved better security than these other schemes. Thus, protocol-I had an acceptable communication cost. On the other hand, authentication protocol-II had a better communication cost than the communication costs in [13,14,17,18,20] and had the same communication cost as [16,19]. Regarding communication overhead, the schemes in [13,14,18] needed three messages, which added overhead to the communication channel. On the other hand, the authentication protocol-II required one message. Therefore, the proposed authentication protocols are suitable for the WBAN.

6. Conclusions

We proposed two secure and efficient WBAN authentication protocols between sensor nodes and a controller node: authentication protocol-I for emergency medical reports and authentication protocol-II for periodic medical reports. The proposed scheme included an initialization phase, registration phase, authentication protocol-I, authentication protocol-II, and password change protocol. We conducted an informal security analysis and found that our proposed authentication protocols enhanced the security of the existing schemes and satisfied all security requirements in this study. We also implemented the BAN logic and found that our proposed authentication protocols attained mutual authentication. We also utilized the AVISPA simulation tool and found that our proposed protocols were secure against active and passive attacks. Moreover, we conducted a performance analysis and found that the proposed authentication protocols had suitable computation and communication costs for a WBAN.