Design of Inter-BAN Authentication Protocols for WBAN in a Cloud-Assisted Environment

Abstract

The Telecare Medical Information System (TMIS) is a technology used in Wireless Body Area Networks (WBAN) that is used efficiently for remote healthcare services. TMIS services can be provided as cloud computing services for storage and processing purposes. TMIS uses wearable sensors to collect patient data and transmit it to the controller node over a public channel. The data is then obtained from the controller node by the medical server and stored in the database for analysis. However, an attacker can attempt to launch attacks on data transferred across an unsecured channel. Several schemes have therefore been proposed to provide mutual authentication however, there are security and performance problems. Therefore, the research aims to design two secure and efficient inter-BAN authentication protocols for WBAN: protocol-I (P-I) for emergency authentication and protocol-II (P-II) for periodic authentication. To analyze the proposed protocols, we conduct an informal security analysis, implement Burrows-Abadi-Needham (BAN) logic analysis, validate the proposed protocols using the Automated Validation of Internet Security Protocols and Applications (AVISPA) simulation tool, and conduct a performance analysis. Consequently, we show that the proposed protocols meet all the security requirements in this research, achieve mutual authentication, prevent passive and active attacks, and have suitable performance for WBAN.

1. Introduction

The Internet of Things (IoT) is a platform that integrates sensor devices with wireless networks and is applied in various environments and applications across businesses and industries. One such application is a WBAN, because of the rapid advancement of wireless communication technology, which is effectively used in remote healthcare services [1,2,3]. TMIS is a WBAN technology capable of remotely providing various healthcare services via telecare servers [4,5,6,7].

Patients in the TMIS use wearable sensors to continuously check their physical health condition and gather health data [8,9]. This health data is sent to the medical server anytime and from any location. TMIS is especially beneficial for those patients who are disabled, need to monitor their health status continuously, or are unable to attend the hospital for various reasons. Thus, TMIS gives better healthcare services in comparison to conventional healthcare delivery methods [10,11].

TMIS includes medical servers that store Electronic Medical Records (EMRs) of patients engaged in the system. The medical server can be in the cloud for storage and processing purposes, and patients and doctors can view the EMRs stored on the server via the Internet [12,13]. Medical messages transmitted to the medical server include emergency and periodic reports. An emergency report is one that must be sent to the medical server as soon as sensors detect an emergency in the body of the patient. The periodic reports are sent to the medical server at specific times to enable a medical service provider to access the patient’s data and provide an appropriate diagnosis.

Nevertheless, despite the benefits of TMIS, as patients’ health data is conveyed across unprotected channels, it needs to be safeguarded from malicious attacks. Accordingly, mutual authentication is necessary for transferring data securely [14]. Several authentication protocols have been proposed to securely perform mutual authentication; however, there are security and performance issues.

Therefore, the primary aim of this research is to design secure and efficient authentication protocols between a controller node and a cloud-based medical server for secure data transfer. To achieve this aim, this research proposes two WBAN authentication protocols for inter-body communication (Inter-BAN) in a cloud-assisted environment. P-I is for emergency authentication, which takes place whenever a sensor identifies an emergency in the body of the patient, requiring the controller node to begin an emergency authentication with the medical server, while P-II is for periodic authentication, which occurs when the cloud-based medical server needs to obtain the patient’s data from the controller node and store it in the database system at a specific time, requiring the medical server to initiate periodic authentication with the controller node.

1.1. Overview of WBAN

WBAN has three tiers [15], as illustrated in Figure 1:

• In the intra-BAN tier, communication takes place between sensor and controller nodes. The patient’s data is monitored and captured by sensors, and it is subsequently transmitted to the controller node through an unsecured channel.
• In the inter-BAN tier, communication takes place between a controller node and a medical server. Software is developed at the controller node/local server for gathering data from sensor nodes and then sending it to the medical server via unsecured channels. In addition, another software is developed at a remote medical server to obtain the data from the controller and store it in the database system for further analysis.
• In the beyond-BAN tier, communication takes place between a medical server and a doctor. The medical server can be in the cloud, and the doctor can view the data stored on the server.

WBAN in a cloud-assisted environment consists of four parties, as shown in Figure 2:

• The Trusted authority initializes the system and registers the system parties.
• The patient wears sensing devices to gather sensitive medical data, which is then transferred via public channels for medical purposes.
• The cloud-based medical server has sufficient storage and processing power to store the massive amount of medical data concerning patients [16,17].
• The doctor can request access to the patient’s data and provide appropriate treatment measures.

1.2. Problem Statement and Main Contributions

The environment of WBAN’s public wireless network presents a substantial security issue in terms of guaranteeing that only legitimate parties have access to patient data [18]. Unauthorized access can lead to the interruption, interception, or manipulation of data, putting patients’ lives in danger [19,20]. Several schemes have been proposed to securely perform authentication and create a session key, which is subsequently used to encrypt sensitive data delivered across an unsecured channel. However, there are still performance and security issues [21,22]. Our research will provide an answer to the following question:

• How do we achieve secure and efficient inter-BAN authentication protocols for WBAN in a cloud-assisted environment?

The contributions of this research are as follows:

• We design two inter-BAN authentication protocols for WBAN: P-I is for emergency authentication, and P-II is for periodic authentication.
• We conduct an informal security analysis to demonstrate that our protocols meet all of the security requirements in this research.
• We evaluate our proposed authentication protocols using BAN logic and the AVISPA simulation tool.
• We conduct a performance analysis in terms of computation and communication costs.

1.3. Research Scope

The research considers the inter-BAN authentication protocols. Thus, authentication protocols for the intra-BAN and beyond-BAN tiers are outside the scope of this research. Moreover, the research assumes the existence of hardware with integrated sensors that are working properly for manufacturers. The hardware specifications, development, and operation of the sensors are not in the scope of this research, but the use of such sensors to propose authentication protocols is.

The rest of the paper is organized as follows. Section 2 presents the literature review. Section 3 introduces the proposed scheme, whereas Section 4 demonstrates the security analyses of the proposed authentication protocols. In Section 5, performance analyses of the proposed protocols and related protocols are conducted. Finally, Section 6 presents the conclusion.

2. Literature Review

WBANs handle the health data of patients, which must be protected from cyber-attacks. Many researchers have expressed an interest in developing WBAN authentication protocols to safeguard sensitive patient data while it is sent via unsecured channels. This section provides preliminary information, clarifies the requirements of WBAN authentication schemes, reviews existing WBAN schemes, and discusses the findings.

2.1. Preliminary

2.1.1. Elliptic Curve Cryptography

Elliptic curve cryptography (ECC) is a popular kind of asymmetric key encryption. ECC is more secure and efficient than other asymmetric key cryptosystems with smaller key sizes [23,24]. Let q is a prime number, a,b ∈ F_q, and $4a^3+27b^2 \ne 0 \left(mod q\right).$ Then, an elliptic curve E_q(a, b) over a finite field F_q is defined by an equation as below:

$$E_q\left(a,b\right):y^2=x^3+ax+b \left(mod q\right)$$

ECC has two fundamental operations: scalar multiplication and point addition. The scalar multiplication operation is calculated by repeatedly adding as $n.P=P+\dots +P$ (n times), where P is a base point on the elliptic curve E_q(a, b) and n is a positive integer [25].

ECC security is based on the following problems [26]:

• Elliptic Curve Discrete Logarithm Problem (ECDLP): Given an elliptic curve E_q(a, b) and two points Q, P on E_q(a, b) such that $Q=n.P$, it is hard to determine an integer n.
• Elliptic Curve Diffie-Hellman Problem (ECDHP): Given an elliptic curve E_q(a, b) and three points P, x.P, y.P on E_q(a, b), it is hard to determine $x.y.P$.

2.1.2. Adversary Model

The capabilities of an adversary model are described as the following:

• All messages exchanged through public channels are completely under the control of the attacker [27].
• A patient’s controller node/mobile device can be stolen, and the attacker can access the data on it [28].
• A patient’s identity (ID_i) or password (PW_i) could be guessed by an attacker, but not both at the same time [29].
• An attacker has the ability to launch attacks through public channels [30].
• The private key of the trusted authority cannot be compromised by the attacker [31].

2.2. Requirements of WBAN Authentication Schemes

The following security and performance criteria for WBAN authentication schemes should be met:

• Emergency and periodic authentication protocols: Whenever a sensor identifies an emergency in the body of the patient, the patient’s controller device begins an emergency authentication with the medical server to send the emergency report in a secure manner. Likewise, when the patient’s data must be obtained from the controller node and stored on the server at a specific time, the cloud-based medical server begins a periodic authentication with the controller node to ensure secure data transmission.
• Perfect forward/backward secrecy: Future and past keys will not be compromised.
• Anonymity and Untraceability: This refers to an attacker’s inability to determine a patient’s identity via message eavesdropping and tracking a patient through messages transmitted during earlier sessions.
• Secure password change: A legitimate mobile device’s password cannot be changed at will by an attacker since the attacker is unaware of ID_i and PW_i.
• Controller node revocation: It is essential to include a revocation mechanism if a patient’s mobile device/controller node is lost or stolen.
• Replay attack: When messages are sent through insecure channels, an attacker can obtain them. However, if the message has a timestamp, the attacker cannot launch a replay attack.
• Session key disclosure attack: An attacker cannot extract secret values from messages transmitted over an unsecured channel. This prevents the attacker from computing the session key.
• Off-line guessing attack: A patient’s ID_i or PW_i could be guessed by an attacker, but not both at the same time.
• Impersonation attack: An attacker is unable to generate an authentication message to pretend to be a real entity.
• Controller node stolen attack: An attacker who gets a valid patient’s controller node cannot retrieve any information on it.
• Known session-specific temporary information attack: The session key cannot be computed even if an attacker has the random values produced securely throughout the session.
• Desynchronization attack: This attack, which corrupts the communication between two parties, should be prevented by updating the data kept on both parties during the authentication.
• Computation cost: This refers to the computational load on the involved parties. The computational cost should be minimized since it is critical for devices with constrained resources.
• Communication cost: This is the cost of exchanging messages in terms of bit sizes and communication overhead between the parties participating in the authentication. Regarding communication overhead, the authentication messages should require at most one round trip.

2.3. The Existing Authentication Schemes in WBAN

Authors in [29,32] presented authentication protocols for medical information assisted by cloud computing. They establish secure authentication between the patient and the cloud server (CS) to securely transmit health data to the CS. They also provide secure access to the CS for medical personnel. However, the schemes do not prevent desynchronization attacks.

Kumar & Chand [33] presented a scheme for authentication between a WBAN client and the CS. It resists session key disclosure and user impersonation attacks, and guarantees forward secrecy and user anonymity/ untraceability. However, it has security weaknesses, and it has more computation costs because it uses complex operations on the two sides.

Authors in [34] presented an authentication scheme for the WBAN client and the CS. The scheme resists user impersonation, replay, and session key disclosure attacks. However, client anonymity is not ensured by the scheme, where the client’s identity is transmitted without masking it over an unsecured channel.

Konan and Wang [35] proposed mutual batch authentication for the interaction between a WBAN client and a medical service provider. Batch authentication allows the medical service provider to handle multiple requests from patients at the same time to achieve lower computation costs. The scheme ensures anonymity to the WBAN client, but it does not resist the stolen mobile device and desynchronization attacks.

Almuhaideb and Alqudaihi [36] suggested an authentication scheme between a client’s controller device and a server. It is based on a three-factor mutual authentication, including biometrics, that worked on improving the scheme of Yu and Park [37] to overcome the security and efficiency problems that were encountered. The scheme ensures patient anonymity, perfect forward/backward secrecy, and resists guessing attacks. Moreover, it provides two protocols. The first one is for authentication between the controller node and the server. The second protocol is for reauthentication, which occurs after the successful initial authentication. Thus, there is no need to generate a new session key, saving considerable energy and time.

Zhou et al. [38] and Amin et al. [39] suggested authentication protocols between a client’s mobile device and a cloud-based server. The schemes are based on an architecture combining many cloud servers with various services distributed among them to distribute the computation burden and make the proposed schemes appropriate for resource-limited devices.

Authors in [40] suggested inter-BAN authentication. It resists replay and impersonation attacks, and it guarantees perfect forward/backward secrecy and anonymity/untraceability. Furthermore, the scheme avoids complex cryptographic operations and uses simple operations on elliptic curves and symmetric encryption. However, it does not resist a stolen controller node attack. If an attacker obtains a controller node, the attacker has the ability to extract the secret information shared between the client and the server.

Almuhaideb [41] proposed two WBAN authentication protocols. The first one is for authentication among a WBAN client and a service provider. The second protocol is for reauthentication, which occurs after the successful initial authentication. There is no need to generate a new session key, saving considerable energy and time since the second protocol helps to minimize communication and computation costs.

Authors in [42] suggested a WBAN protocol for authentication among a patient and a medical server for remote healthcare systems in 5G. It is based on a three-factor mutual authentication, including biometrics. The scheme is designed to provide fast authentication in multiserver environments.

Chen and Peng [43] suggested a WBAN authentication protocol between a client and a server. It worked to enhance the security of the scheme [44]. Also, authors in [45,46] suggested schemes for authentication among a user and a remote server in IoT environments. However, authors in [47] indicated that the scheme [45] does not prevent offline guessing, impersonation, and known session-specific temporary information attacks and does not offer user anonymity/untraceability. Although bilinear pairing and modular exponentiation are considered complex cryptographic operations, the schemes in [43,45] achieve low computation costs because they adopt these operations on only one side to minimize computation costs at the WBAN client.

Authors in [48] suggested a mutual authentication scheme for medical care in a TMIS environment. It has a high computation cost due to its use of complex cryptographic operations on both sides. Moreover, it does not prevent desynchronization and session-specific temporary information attacks.

Authors in [49] presented a mutual authentication protocol between a WBAN client and a medical service provider. The scheme prevents the session key from being disclosed even if the attacker obtains the random values that are produced securely by the client or service provider through the session. Moreover, it ensures client anonymity and untraceability. However, it does not prevent the desynchronization attack and stolen mobile device attacks.

Authors in [50] suggested a WBAN authentication protocol that achieves user anonymity and untraceability. However, it does not prevent the desynchronization attack and stolen mobile device attacks. Moreover, the scheme uses complex cryptographic operations, which create high computation costs.

Authors in [51] suggested an authentication protocol between the patient and a server. It is based on a three-factor mutual authentication, including biometrics, that worked to enhance the scheme of Sahoo et al. [52] and overcomes the security and efficiency problems that were encountered. The scheme ensures patient anonymity, resists the stolen mobile device attack, and provides a secure password change feature. Moreover, it avoids complex operations to achieve low computation costs by using ECC with scalar multiplication and hash functions.

Chen and Chen [53] presented a protocol for authentication between the WBAN client and a server. It is based on a three-factor mutual authentication, including biometrics. The scheme ensures patient anonymity, resists the stolen mobile device attack, and provides a secure password change feature. However, it is vulnerable to a desynchronization attack.

Karthigaiveni and Indrani [54] suggested a scheme for authentication between a patient and a remote server in an IoT-based E-healthcare environment. However, Alzahrani [55] indicated that this scheme does not resist stolen smart card and impersonation attacks, and does not offer patient anonymity/untraceability.

Authors in [56] suggested an authentication between a client and a server. It resists the stolen mobile device attack. However, it is vulnerable to a desynchronization attack.

Kumari and Renuka [57] worked on improving Qiu et al. scheme [58] to overcome the security and efficiency problems that were encountered. They suggested an authentication protocol between a client’s controller device and a server based on three-factor authentication: password, smartcard, and biometrics.

Authors in [59] suggested a WBAN authentication protocol between a client and a medical service provider. The scheme ensures client anonymity and resists desynchronization attacks. However, the scheme does not resist a stolen mobile device attack.

Alzahrani et al. [60,61], Khadem et al. [62], Chunka and Banerjee [63], and Narwal and Mohapatra [64] suggested authentication protocols among sensors and a hub node. In their scheme, the controller device works only to forward the messages between the sensor and the hub nodes. The schemes [60,61,62,63,64] do not ensure anonymity to a controller node and do not resist a stolen controller node attack.

Almuhaideb and Alqudaihi [21] suggested two WBAN authentication protocols. The first protocol is for authentication among a sensor node and a hub node. The second protocol is for reauthentication, which occurs after the successful initial authentication. Thus, there is no need to create a new session key, saving considerable energy and time. Therefore, the second protocol helps to minimize communication and computation costs. In their scheme, the controller node works only to forward the messages among the sensor and the hub nodes.

Narwal and Mohapatra [65] presented a scheme for authentication among a sensor node and a hub node. In their scheme, the controller node works only to forward the messages among the sensor and the hub nodes. It ensures anonymity to a controller node but is vulnerable to a stolen controller node attack.

Authors in [66,67,68] suggested authentication protocols between a patient and a server. The schemes ensure patient anonymity and prevent stolen mobile devices and desynchronization attacks. Moreover, they avoid complex operations to improve performance. However, the schemes do not consider an authentication protocol when the server requests to periodically get the patient’s data.

2.4. Findings

After highlighting the WBAN authentication requirements and reviewing the current authentication schemes, we discovered that the current schemes did not match all of the requirements in this research. Furthermore, none of the current schemes considered emergency and periodic authentication protocols. Moreover, most schemes assumed that the controller node of a patient could be trusted; nevertheless, an attacker can take the controller node and obtain the sensitive data contained in it. In addition, most schemes were vulnerable to a desynchronization attack, which would prohibit both parties from updating certain data synchronously and proceeding with authentication. Also, we discovered that using simple operations on ECC along with hash functions and XOR operations and avoiding complex operations results in a better trade-off between efficiency and security.

Based on the analysis of current inter-BAN authentication schemes, it was discovered that focusing on enhancing current schemes might result in secure and efficient inter-BAN authentication protocols. Therefore, we propose two inter-BAN authentication protocols for WBAN: P-I for emergency authentication and P-II for periodic authentication. Moreover, the proposed protocols meet all the highlighted WBAN authentication requirements to provide security features, prevent security attacks, and achieve the performance criteria.

3. Proposed Scheme

We design inter-BAN authentication protocols for securing the communication between a controller node and a cloud-based medical server. Our scheme consists of an initialization phase, registration phase, authentication P-I, authentication P-II, and changing password protocol.

Table 1. Symbols utilized in our scheme.

Symbol	Description
Pi	Patient-i
CN	Controller node of Pi
MSh	Cloud-based medical server-h
TA	Trusted authority
IDi, PWi	Pi’s identity and password
HIDi	Pi’s masked identity
SIDi	Pi’s secret identity
IDh	MSh’s identity
Si, PKi	CN’s secret and public keys
Sh, PKh	MSh’s secret and public keys
STA, PKTA	TA’s secret and public keys of
ai, bi, ri	CN-created random numbers
rh, ui+, fh, bh	MSh-created random numbers
ui	TA-created a random number
HPWi, APi, BPi, CPi, DPi	Data used by CN to authenticate Pi
Vi, Wi, Vi+, Wi+	Data to verify message synchronization
Tn	Timestamp n
ΔT	The maximum transmission delay
Tn*	The time of message receipt
XRi	Public data generated by CN and used by MSh to compute Xi
Xi	Elliptic Curve Diffie-Hellman Problem
Ji	Data utilized to retrieve Vi in P-I
PIDh-i	Data stored on MSh to check CN’s registration
Rh	Public data generated by MSh and used by CN to compute Vh
Vh	Elliptic Curve Diffie-Hellman Problem
C1	Data utilized to retrieve Vi+ in P-I
Li1	Data that MSh uses in P-I to authenticate CN
Li2	Data that CN uses in P-I to authenticate MSh
REi	Data that MSh uses in P-II to retrieve CIDi
CIDi	Data generated by TA and used by MSh to authenticate CN
XBh	Public data generated by MSh and used by CN to compute Bh
Bh	Elliptic Curve Diffie-Hellman Problem
Fh	Data utilized to retrieve fh in P-II
EPi	Data stored on CN and used to retrieve CIDi in P-II
Lk2	Data that CN uses in P-II to authenticate MSh
SKi-h	Session key between CN and MSh in P-I
SKh-i	Session key between MSh and CN in P-II
P	A base point on an elliptic curve
q	Large prime number
*	Scalar multiplication operation
Zq*	The nonzero positive integers modulus q
⊕	XOR operation
h	Hash function
||	Concatenation operation
→	Public channel
⇢	Secure channel

provides the fundamental symbols utilized in our scheme.

3.1. Initialization Phase

TA generates the parameters of the system and also its secret and public keys, during the system initialization phase.

• TA chooses an elliptic curve E_q(a, b) over a finite field F_q, and a base point P on E_q(a, b).
• TA chooses a hash function h:{0,1}* → Z_q*.
• TA creates a secret number S_TA ∈ Z_q* as its secret key and computes its public key PK_TA = S_TA * P.
• TA makes the parameters (E_q(a, b), PK_TA, P, q, h) public while keeping S_TA secret.

3.2. Registration Phase

Figure 3 demonstrates the registration of CN and MS_h with TA, and as the following:

• P_i selects ID_i and PW_i, then produces a number randomly a_i ∈ Z_q*, and calculates HID_i = h (ID_i || a_i). P_i transmits (ID_i, HID_i) to TA in a secure manner. Then TA calculates S_i = h (ID_i || S_TA) as CN secret key, PK_i = S_i*P, SID_i = (HID_i * S_TA)*PK_TA, and CID_i = h(HID_i || S_TA). TA stores HID_i and ID_i in secure memory and makes (PK_i) public.
• MS_h chooses ID_h and sends (ID_h) to the TA securely. Afterward, the TA produces u_i ∈ Z_q* and retrieves HID_i from secure memory. TA then calculates S_h = h (ID_h || S_TA) as MS_h secret key, PK_h = S_h*P, V_i = u_i ⊕ h (S_h), W_i = HID_i ⊕ h(u_i), and RE_i = CID_i ⊕ h(S_h). The TA makes (PK_h, ID_h) public.
• TA sends (S_h, HID_i, V_i, W_i, RE_i) to MS_h securely. MS_h defines S_h as its secret key and computes PID_h-i = HID_i ⊕ h(S_h). MS_h stores PID_h-i, V_i, W_i, and RE_i in its memory.
• TA sends (S_i, SID_i, CID_i, V_i) to CN securely. CN defines S_i as its secret key and creates a number b_i ∈ Z_q*. CN then computes 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, DP_i = h (a_i || b_i || HPW_i || SID_i), and EP_i = CID_i ⊕ SID_i. CN keeps (AP_i, BP_i, CP_i, DP_i, EP_i, V_i) in its memory.

3.3. Authentication P-I

Whenever a sensor identifies an emergency in the body of the patient, the patient’s controller device requests an emergency authentication with the medical server in order to send the report securely. Figure 4 demonstrates P-I, and as the following:

• P_i enters ID_i and PW_i to CN. Then CN calculates a_i = AP_i ⊕ h(ID_i || PW_i), HID_i = h(ID_i || a_i), HPW_i = h(ID_i || PW_i || a_i), b_i = HPW_i ⊕ BP_i, and SID_i = CP_i ⊕ b_i*P. Then, CN verifies if DP_i ≟ h(a_i || b_i || HPW_i || SID_i), P_i is logged into CN successfully.
• CN produces a number r_i ∈ Z_q* and a current timestamp T₁. CN calculates XR_i = r_i* P, X_i = r_i * PK_h, J_i = V_i ⊕ X_i, and L_i1 = h (X_i || HID_i || T₁ || ID_h || V_i). Afterward, CN transmits the message (XR_i, J_i, L_i1, T₁) to MS_h through an unsecured channel.
• When (XR_i, J_i, L_i1, T₁) is received, MS_h validates the timestamp, i.e., if |T₁ − T₁*| < ΔT, where T₁* denotes the time of message receipt, then MS_h calculates X_i = XR_i * S_h, V_i = J_i ⊕ X_i, then retrieves W_i of V_i from its memory and calculates u_i = V_i ⊕ h(S_h), and HID_i = W_i ⊕ h(u_i). MS_h checks whether HID_i ⊕ h(S_h) ≟ PID_h-i is in its memory. If this condition is met, CN of P_i is registered. MS_h then checks whether L_i1 ≟ h (X_i || HID_i || T₁ || ID_h || V_i). If so, then CN is authenticated.
• Next, MS_h creates random numbers r_h ∈ Z_q*, u_i⁺ ∈ Z_q*, and current timestamp T₂. Then, MS_h calculates R_h = r_h * P, V_h = r_h * PK_i, V_i⁺ = u_i⁺ ⊕ h(S_h), W_i⁺ = HID_i ⊕ h(u_i⁺), and SK_i-h = h(HID_i || V_h || X_i || V_i). MS_h replaces (V_i, W_i) with (V_i, W_i, V_i⁺, W_i⁺), then computes C1 = V_i⁺ ⊕ V_h, and L_i2 = h (V_h || SK_i-h || ID_h || HID_i || V_i⁺ || T₂). Then MS_h transmits the message (R_h, L_i2, C1, T₂) to CN through an insecure channel.
• When (R_h, L_i2, C1, T₂) is received from MS_h, CN checks the validity of the timestamps. If |T₂ − T₂*| < ΔT, where T₂* denotes the time of message receipt, then CN calculates V_h = S_i * R_h, SK_i-h = h(HID_i || V_h || X_i || V_i), and V_i⁺ = C1 ⊕ V_h. CN checks if L_i2 ≟ h (V_h || SK_i-h || ID_h || HID_i || V_i⁺ || T₂), CN replaces (V_i) with (V_i⁺) in its memory, MS_h is authenticated, and SK_i-h is created between CN and MS_h.

3.4. Authentication P-II

When the patient’s data must be obtained from the controller node and stored on the server at a specific time, the cloud-based medical server begins a periodic authentication with the controller node to ensure secure data transmission. Figure 5 demonstrates P-II, and as follows:

• MS_h generates secret numbers f_h ∈ Z_q*, b_h ∈ Z_q*, and current timestamp T₁. MS_h retrieves (CID_i) from the secure memory, where CID_i = RE_i ⊕ h(S_h), (i.e., retrieve the identity of the requested P_i). MS_h then computes XB_h = b_h * P, B_h = b_h * PK_i, F_h = h (CID_i) ⊕ f_h, SK_h-i = h (B_h || CID_i || f_h), and L_k2 = h (B_h || CID_i || ID_h || SK_h-i || T₁). Afterward, MS_h transmits the message (XB_h, F_h, L_k2, T₁) to CN through an unsecured channel.
• When (XB_h, F_h, L_k2, T₁) is received from MS_h, P_i enters ID_i and PW_i to CN. Then CN calculates a_i = AP_i ⊕ h(ID_i || PW_i), HID_i = h(ID_i || a_i), HPW_i = h(ID_i || PW_i || a_i), b_i = HPW_i ⊕ BP_i, and SID_i = CP_i ⊕ b_i*P. After that, CN verifies if DP_i ≟ h(a_i || b_i || HPW_i || SID_i), P_i is logged into CN successfully.
• CN validates the timestamps. If |T₁ − T₁*| < ΔT, where T₁* denotes the time of message receipt, then CN calculates CID_i = EP_i ⊕ SID_i, B_h = XB_h * S_i, f_h = F_h ⊕ h(CID_i), and SK_h-i = h (B_h || CID_i || f_h). Next, CN checks whether L_k2 ≟ h (B_h || CID_i || ID_h || SK_h-i || T₁). If so, MS_h is authenticated, and SK_h-i is created between MS_h and CN.

3.5. Password Change Protocol

The password can be changed securely whenever the P_i intends to replace the current password as follows:

• P_i enters ID_i and PW_i in CN.
• CN calculates a_i = AP_i ⊕ h(ID_i || PW_i), HID_i = h(ID_i || a_i), HPW_i = h(ID_i || PW_i || a_i), b_i = HPW_i ⊕ BP_i, and SID_i = CP_i ⊕ b_i * P. Then, CN verifies if DPi ≟ h(a_i || b_i || HPW_i || SID_i), CN prompts P_i to choose a new password.
• P_i chooses a new password PW_i⁺ and transmits it to CN.
• After getting PW_i⁺, 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, CN replaces (AP_i, BP_i, CP_i, DP_i, EP_i,V_i) with (AP_i⁺, BP_i⁺, CP_i, DP_i⁺, EP_i,V_i).

4. Security Analysis

Security evaluations are conducted informally and formally to demonstrate that P-I and P-II meet all of the security requirements.

4.1. Informal Security Analysis

In light of the requirements laid out in Section 2.2, P-I and P-II are discussed in this section.

4.1.1. Emergency and Periodic Authentication Protocols

According to the emergency authentication protocol, whenever a sensor identifies an emergency in the body of the patient, CN requests authentication by sending the message M = (XR_i, J_i, L_i1, T₁) to MS_h. An attacker AR cannot create a valid L_i1, so MS_h authenticates CN by checking L_i1 ≟ h(X_i || HID_i || T₁ || ID_h || V_i). Then, MS_h replies to the authentication by transmitting the message M = (R_h, L_i2, C1, T₂) to CN. AR cannot produce a legal L_i2, so CN authenticates MS_h by checking L_i2 ≟ h (V_h || SK_i-h || ID_h || HID_i || V_i⁺ || T₂). Therefore, CN and MS_h can authenticate one another.

The periodic authentication protocol occurs when the medical server requires a patient’s data from the controller node and stores it in the database system at specific times. As a result, there is no need for the controller node to start the authentication, which reduces the communication overhead. In this instance, MS_h asks CN, whose identity CID_i is kept on the MS_h’s secure memory, for authentication. The MS_h requests authentication by sending a message M = (XB_h, F_h, L_k2, T₁) to CN. AR cannot produce a legal L_k2, so CN authenticates MS_h by checking L_k2 ≟ h (B_h || CID_i || ID_h || SK_h-i || T₁). Therefore, CN and MS_h can authenticate each other.

4.1.2. Perfect Forward/Backward Secrecy

If AR acquires any session key, the secrecy of future or previous session keys should not be attacked. For P-I, the session key SK_i-h = h(HID_i || V_h || X_i || V_i) cannot be computed by AR, because AR cannot compute V_h and X_i without r_h and r_i, which are secret numbers generated at random.

For P-II, AR cannot compute the session key SK_h-i = h(B_h || CID_i || f_h) due to its dynamic nature and the usage of secret random numbers f_h and b_h. As a result, our protocols provide this feature since each session generates a fresh session key.

4.1.3. Patient Anonymity and Untraceability

For P-I, M = (XR_i, J_i, L_i1, T₁) and M = (R_h, L_i2, C1, T₂) are changed throughout each session since the authentication is based on random values r_i and r_h. Moreover, M = (XB_h, F_h, L_k2, T₁) for P-II depends on the random values f_h and b_h, making the messages transmitted throughout the sessions independently. As a result, AR cannot gain ID_i by eavesdropping on these messages, nor can AR trace a controller node utilizing messages transmitted throughout earlier sessions. Consequently, these features of our proposed protocols are preserved.

4.1.4. Secure Password Change

Our scheme allows for secure password changes whenever a P_i desires to replace the current PW_i. To begin, the P_i should enter the current ID_i and PW_i into CN to confirm that the user is the legal owner of CN. CN verifies if DP_i ≟ h (a_i || b_i || HPW_i || SID_i), CN asks that P_i chooses a new password. CN then computes HPW_i⁺, AP_i⁺, BP_i⁺, and DP_i⁺. After that, CN replaces (AP_i, BP_i, CP_i, DP_i, EP_i,V_i) with (AP_i⁺, BP_i⁺, CP_i, DP_i⁺, EP_i,V_i) for future purposes. As a result, AR cannot change the password at will since AR does not know the current ID_i and PW_i. Therefore, our scheme ensures a secure password change.

4.1.5. Controller Node Revocation

In the event that P_i’s controller node is lost or stolen, P_i can request that it be revoked. The identity-based revocation mechanism is adopted [34], in which P_i sends a revocation message containing ID_i to TA. Then, TA retrieves HID_i of ID_i from its memory and revokes the controller node from the system. Likewise, TA sends the revocation message containing HID_i to MS_h. As a result, if MS_h receives an authentication message from a controller node whose HID_i is in the revocation list, the authentication message is ignored.

4.1.6. Replay Attack

In the adversary model, we assumed that AR may get messages when transmissions happened across an unsecured channel. However, AR is unable to launch a replay attack since each message in our protocols has a timestamp. For P-I, CN creates a timestamp, which is included in the hash value L_i1 = h(X_i || HID_i || T₁ || ID_h || V_i). MS_h creates a timestamp, which is contained in the value L_i2 = h (V_h || SK_i-h || ID_h || HID_i || V_i⁺ || T₂). The values X_i, HID_i, and V_i for L_i1, and the values V_h, HID_i, and V_i⁺ for L_i2 cannot be forged by AR.

For P-II, MS_h creates a timestamp, which is included in the hash value L_k2 = h (B_h || CID_i || ID_h || SK_h-i || T₁). The values B_h and CID_i for L_k2 cannot be forged by AR. Therefore, our protocols resist such an attack.

4.1.7. Session Key Disclosure Attack

For P-I, if AR attempts to get SK_i-h, AR needs to compute HID_i, V_h, and X_i. However, AR is unable to obtain a_i or S_h, r_h or S_i, and r_i or S_h to compute HID_i, V_h, and X_i, respectively.

For P-II, if AR attempts to get SK_h-i, AR needs to obtain B_h and f_h. However, AR cannot obtain the values b_h or S_i, and f_h via an unsecured channel message. Moreover, AR is unable to obtain HID_i and S_TA, or S_h to calculate CID_i. Therefore, our protocols resist such an attack.

4.1.8. Off-Line Guessing Attack

In the adversarial model, we assumed that AR can only predict one of ID_i or PW_i at a time. For P-I and P-II, AR is unable to calculate a_i = AP_i ⊕ h(ID_i || PW_i) without simultaneously guessing both ID_i and PW_i correctly. Thus, AR is unable to calculate b_i, HID_i, HPW_i, and SID_i. Also for P-II, AR cannot compute CID_i = EP_i ⊕ SID_i, without simultaneously predicting both ID_i and PW_i correctly. Therefore, our protocols resist such an attack.

4.1.9. Impersonation Attack

For P-I, AR must produce the message (XR_i, J_i, L_i1, T₁) to pretend to be the legitimate CN. However, AR is unable to compute a legal L_i1 because it is calculated using X_i and HID_i. Thus, MS_h checks L_i1 ≟ h(X_i || HID_i || T₁ || ID_h || V_i). If the condition is not satisfied, MS_h locks out AR. Moreover, AR must produce the message (R_h, L_i2, C1, T₂) to impersonate the legitimate MS_h. However, AR is unable to calculate L_i2 since it is calculated using V_h and HID_i. Thus, CN checks L_i2 ≟ h(V_h || SK_i-h || ID_h || HID_i || V_i⁺ || T₂). If the condition is not satisfied, CN locks out AR.

For P-II, AR must produce the message (XB_h, F_h, L_k2, T₁) to pretend to be the legitimate MS_h. However, AR is unable to calculate L_k2 since it is calculated using B_h and CID_i. Thus, CN checks L_k2 ≟ h (B_h || CID_i || ID_h || SK_h-i || T₁). If the condition is not satisfied, CN locks out AR. Therefore, our protocols resist such an attack.

4.1.10. Controller Node Stolen Attack

In the adversary model, we considered that AR may steal the legitimate P_i’s mobile device/controller node. However, for P-I, AR is unable to produce a legal message because AR cannot retrieve ID_i and PW_i, and is unable to calculate HID_i.

For P-II, when AR gets an authentication message from MS_h, the creation of the session key among MS_h and AR is not able because AR cannot retrieve ID_i and PW_i, and cannot calculate CID_i. Therefore, our protocols resist such an attack.

Furthermore, P_i can request that the stolen controller node be revoked in order to prevent its misuse.

4.1.11. Known Session-Specific Temporary Information Attack

For P-I, if AR gets secret values r_i and r_h, which are generated randomly during the session, then AR has the ability to calculate X_i = r_i * PK_h and V_h = r_h * PK_i. However, AR still is unable to compute HID_i = h (ID_i || a_i) without S_h or a_i. Thus, SK_i-h = h(HID_i || V_h || X_i || V_i) cannot be calculated by AR.

For P-II, if AR gets secret values f_h and b_h, which are generated randomly during the session, then AR has the ability to calculate B_h = b_h * PK_i. However, AR still is unable to obtain CID_i = h (HID_i || S_TA) without a_i and S_TA, or S_h. Therefore, AR is not capable of computing SK_h-i = h (B_h || CID_i || f_h). Therefore, our protocols resist such an attack.

4.1.12. Desynchronization Attack

This attack corrupts the link between CN and MS_h at a certain point throughout the authentication, preventing CN and MS_h from updating some data synchronously and completing authentication. P-I resists this attack by updating the data (V_i, W_i) kept on MS_h, and (V_i) kept on CN. If AR corrupts the communication from CN to MS_h, CN requires to initiate a new authentication round. If AR corrupts the link from MS_h to CN, there is data stored in MS_h’s memory (V_i, W_i, V_i⁺, W_i⁺) indicating to the nonupdated and updated data. When CN transmits a new authentication request to MS_h using the nonupdated data (V_i), MS_h is still able to utilize the nonupdated data (V_i, W_i).

In other words, MS_h and CN, respectively, may confirm that the messages they have received are synchronous by examining the equality of L_i1 ≟ h(X_i || HID_i || T₁ || ID_h || V_i), and L_i2 ≟ h(V_h || SK_i-h || ID_h || HID_i || V_i⁺ || T₂) [69].

For P-II, if AR corrupts the link from MS_h to CN, the MS_h only requires to initiate a new authentication round [70,71]. Thus, our protocols resist such an attack.

In summary,

Table 2. A security requirements comparison.

Scheme	S01	S02	S03	S04	S05	S06	S07	S08	S09	S10	S11	S12
[29]	✘	✓	✓	~	✘	✓	✓	✓	✓	✓	✓	✘
[33]	✘	✓	✓	✘	✓	✓	✓	~	✓	✘	~	✘
[40]	✘	✓	~	✘	✘	✓	✓	~	✓	✘	~	✘
[43]	✘	✓	✓	✘	✘	✓	✓	~	✓	✘	~	✘
[45]	✘	~	✘	✓	✘	✓	✓	✘	✘	✓	✘	✘
[48]	✘	✘	✓	✓	✘	✓	✓	✓	✓	✓	✘	✘
[51]	✘	✓	✓	✓	✘	✓	✓	✓	✓	✓	✓	✘
Proposed	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓

S01 = Emergency and periodic authentication protocols, S02 = Perfect forward/backward secrecy, S03 = Patient anonymity and untraceability, S04 = Secure password change, S05 = Controller node revocation, S06 = Replay attack, S07 = Session key disclosure attack, S08 = Off-line guessing attack, S09 = Impersonation attack, S10 = Stolen controller node attack, S11 = Known session-specific temporary information attack, S12 = Desynchronization attack, ✓ = Could provide the requirement, ✘ = Could not provide the requirement, ~ = Information not available.

presents the security requirements comparison of P-I and P-II with those of related protocols [29,33,40,43,45,48,51]. As depicted in Table 2, our protocols meet all of the security requirements.

4.2. BAN Logic Proof

We implement BAN logic to show that P-I and P-II achieve mutual authentication [72,73].

Table 3. The notations of BAN logic.

Notation	Description
P, Q	Two principals
X1, X2	Two statements
SK	The session key
P|≡ X1	P believes X1, if X1 is true
P ⊲ X1	P sees X1, i.e., P receives X1 contained within a message, but P does not necessarily believe X1
P| ∼X1	P once says X1, i.e., P transmits a message including X1. It is unknown if P sent the message recently or a long time ago, but P believes X1 when P sends it
P| ⇒ X1	P controls X1, and P should trust X1
#(X1)	X1 is fresh, i.e., X1 has never been sent before
(X1) K	X1 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

shows the fundamental notations of BAN logic.

4.2.1. Inference Rules

We use the following inference rules in the proposed authentication protocols:

Rule 1 (Message Meaning Rule):

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

Rule 2 (Nonce Verification Rule):

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

Rule 3 (Jurisdiction Rule):

$$JR=\frac{P \left|\equiv Q\right|\Rightarrow X_1,P \left|\equiv Q \right|\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 \#\left(X_1\right)}{P |\equiv \#(X_1,X_2)}$$

Rule 6 (Session Key Rule):

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

4.2.2. P-I Goals

G1: $P_i| \equiv (P_i \stackrel{S{K}_{i-h}}{\leftrightarrow } M{S}_h)$

G2: $P_i \left| \equiv M{S}_h \right| \equiv (P_i \stackrel{S{K}_{i-h}}{\leftrightarrow } M{S}_h)$

G3: $M{S}_h | \equiv (P_i \stackrel{S{K}_{i-h}}{\leftrightarrow } M{S}_h)$

G4: $M{S}_h \left| \equiv P_i \right| \equiv (P_i \stackrel{S{K}_{i-h}}{\leftrightarrow }M{S}_h)$

4.2.3. P-I Assumptions

A₁: $M{S}_h | \equiv \#\left(T_1\right)$

A₂: $P_i | \equiv \#\left(T_2\right)$

A₃: $P_i | \equiv M{S}_h \Rightarrow (P_i\stackrel{S{K}_{i-h}}{\leftrightarrow } M{S}_h)$

A₄: $M{S}_h | \equiv P_i \Rightarrow (P_i\stackrel{S{K}_{i-h}}{\leftrightarrow } M{S}_h)$

A₅: $P_i | \equiv P_i \stackrel{V_h}{\leftrightarrow } M{S}_h$

A₆: $M{S}_h | \equiv P_i \stackrel{X_i}{\leftrightarrow } M{S}_h$

4.2.4. P-I Idealized Forms

Msg₁: $P_i\to M{S}_h:{\left(X{R}_i, HI{D}_i, V_i, T_1\right)}_{X_i}$

Msg₂: $M{S}_h\to P_i:{\left(R_h,HI{D}_i,V_i^{+},T_2\right)}_{V_h}$

4.2.5. P-I Formal Analysis

P-I uses BAN logic proof as shown below:

• Step 1: D₁ is obtained from Msg₁.

  $$D_1:M{S}_h⊲{\left(X{R}_i, HI{D}_i, V_i, T_1\right)}_{X_i}$$
• Step 2: $M{S}_h$ confirms that the message sent is from $P_i$. Applying MMR with D₁ and A₆ yields D₂.

  $$\frac{M{S}_h | \equiv P_i \stackrel{X_i}{\leftrightarrow }M{S}_h, M{S}_h⊲{\left(X{R}_i, HI{D}_i, V_i, T_1\right)}_{X_i}}{M{S}_h\left| \equiv P_i \right| \sim \left(X{R}_i, HI{D}_i, V_i, T_1\right)}$$

  $$D_2:M{S}_h \left| \equiv P_i \right|\sim \left(X{R}_i, HI{D}_i, V_i, T_1\right)$$
• Step 3: $M{S}_h$ checks whether $P_i$ request is fresh. D₃ is obtained by applying FR using A₁ and D₂.

  $$\frac{M{S}_h | \equiv \#\left(T1\right) }{M{S}_h | \equiv \#\left(X{R}_i, HI{D}_i, V_i, T_1\right) }$$

  $$D_3: M{S}_h | \equiv \#\left(X{R}_i, HI{D}_i, V_i, T_1\right)$$
• Step 4: $M{S}_h$ verifies whether $P_i$ request is legitimate. D₄ is obtained by applying NVR using D₂ and D₃.

  $$\frac{M{S}_h\left|\equiv \#\left(X{R}_i, HI{D}_i, V_i, T_1\right),M{S}_h\right|\equiv P_i|\sim \left(X{R}_i, HI{D}_i, V_i, T_1\right) }{M{S}_h \left|\equiv P_i \right|\equiv \left(X{R}_i, HI{D}_i, V_i, T_1\right)}$$

  $$D_4: M{S}_h \left|\equiv P_i \right|\equiv \left(X{R}_i, HI{D}_i, V_i, T_1\right)$$
• Step 5: $M{S}_h$ now trusts $P_i$ and all its sent parameters. D₅ is obtained by applying BR using D₄.

  $$\frac{M{S}_h \left|\equiv P_i \right|\equiv \left(X{R}_i, HI{D}_i, V_i, T_1\right)}{M{S}_h \left|\equiv P_i \right|\equiv \left(X{R}_i, HI{D}_i, V_i\right)}$$

  $$D_5: M{S}_h \left|\equiv P_i \right|\equiv \left(X{R}_i, HI{D}_i, V_i\right)$$
• Step 6: D₆ is obtained by using SKR with D₃ and D₅ to achieve G4.

  $$\frac{M{S}_h | \equiv \#\left(X{R}_i, HI{D}_i, V_i, T_1\right),M{S}_h \left|\equiv P_i \right|\equiv \left(X{R}_i, HI{D}_i, V_i\right)}{M{S}_h \left| \equiv P_i \right| \equiv \left(P_i \stackrel{S{K}_{i-h}}{\leftrightarrow } M{S}_h\right)}$$

  $$D_6: M{S}_h \left| \equiv P_i \right| \equiv \left(P_i \stackrel{S{K}_{i-h}}{\leftrightarrow } M{S}_h\right)$$
• Step 7: $M{S}_h$ has complete control over the sent $P_i$ parameters. D₇ is obtained by using JR with A₄ and D₆ to achieve G3

  $$\frac{ M{S}_h|\equiv P_i\Rightarrow \left(P_i\stackrel{S{K}_{i-h}}{\leftrightarrow }M{S}_h\right),M{S}_h\left|\equiv P_i\right|\equiv \left(P_i \stackrel{S{K}_{i-h}}{\leftrightarrow } M{S}_h\right) }{M{S}_h | \equiv \left(P_i \stackrel{S{K}_{i-h}}{\leftrightarrow } M{S}_h\right)}$$

  $$D_7: M{S}_h | \equiv \left(P_i\stackrel{S{K}_{i-h}}{\leftrightarrow } M{S}_h\right)$$
• Step 8: D₈ is obtained from Msg₂

  $$D_8: P_i⊲{\left(R_h,HI{D}_i,V_i^{+},T_2\right)}_{V_h}$$
• Step 9: $P_i$ confirms that the message sent is from $M{S}_h$. Applying MMR with D₈ and A₅ yields D₉.

  $$\frac{P_i | \equiv P_i\stackrel{V_h}{\leftrightarrow }M{S}_h, P_i⊲{\left(R_h,HI{D}_i,V_i^{+},T_2\right)}_{V_h}}{P_i \left| \equiv M{S}_h \right| \sim \left(R_h,HI{D}_i,V_i^{+},T_2\right)}$$

  $$D_9:P_i \left| \equiv M{S}_h \right| \sim \left(R_h,HI{D}_i,V_i^{+},T_2\right)$$
• Step 10: $P_i$ checks whether $M{S}_h$ request is fresh. Applying FR with D₉ and A₂ yields D₁₀.

  $$\frac{P_i |\equiv \#\left(T_2\right)}{P_i |\equiv \#\left(R_h,HI{D}_i,V_i^{+},T_2\right)}$$

  $$D_{10}: P_i |\equiv \#\left(R_h,HI{D}_i,V_i^{+},T_2\right)$$
• Step 11: $P_i$ verifies whether $M{S}_h$ request is legitimate. D₁₁ is obtained by applying NVR using D₉ and D₁₀.

  $$\frac{P_i |\equiv \#\left(R_h,HI{D}_i,V_i^{+},T_2\right), P_i \left| \equiv M{S}_h \right| \sim \left(R_h,HI{D}_i,V_i^{+},T_2\right) }{P_i \left| \equiv M{S}_h \right|\equiv \left(R_h,HI{D}_i,V_i^{+},T_2\right)}$$

  $$D_{11}: P_i \left| \equiv M{S}_h\right|\equiv \left(R_h,HI{D}_i,V_i^{+},T_2\right)$$
• Step 12: $P_{i }$ now trusts $M{S}_h$ and all of the parameters it has sent. D₁₂ is obtained by using BR with D_11.

  $$\frac{P_i \left| \equiv M{S}_h\right|\equiv \left(R_h,HI{D}_i,V_i^{+},T_2\right)}{P_i \left| \equiv M{S}_h\right|\equiv \left(R_h,HI{D}_i,V_i^{+}\right)}$$

  $$D_{12}: P_i \left| \equiv M{S}_h\right|\equiv \left(R_h,HI{D}_i,V_i^{+}\right)$$
• Step 13: D₁₃ is obtained by using SKR with D₁₀ and D₁₂ to achieve G2.

  $$\frac{P_i |\equiv \#\left(R_h,HI{D}_i,V_i^{+},T_2\right), P_i \left| \equiv M{S}_h\right|\equiv \left(R_h,HI{D}_i,V_i^{+}\right)}{P_i \left| \equiv M{S}_h\right| \equiv \left(P_i \stackrel{S{K}_{i-h}}{\leftrightarrow } M{S}_h\right)}$$

  $$D_{13}: P_i \left| \equiv M{S}_h\right| \equiv \left(P_i \stackrel{S{K}_{i-h}}{\leftrightarrow } M{S}_h\right)$$
• Step 14: $P_i$ obtains the parameters of the new session key from the sent $M{S}_h$ parameters. D₁₄ is obtained by using JR with A₃ and D₁₃ to achieve G1.

  $$\frac{P_i |\equiv M{S}_h\Rightarrow \left(P_i\stackrel{S{K}_{i-h}}{\leftrightarrow }M{S}_h\right),P_i\left|\equiv M{S}_h\right|\equiv \left(P_i\stackrel{S{K}_{i-h}}{\leftrightarrow }M{S}_h\right) }{P_i | \equiv \left(P_i \stackrel{S{K}_{i-h}}{\leftrightarrow } M{S}_h\right)}$$

  $$D_{14}: P_i | \equiv \left(P_i \stackrel{S{K}_{i-h}}{\leftrightarrow } M{S}_h\right)$$

In summary of P-I, $P_i$ and $M{S}_h$ attain mutual authentication. Furthermore, the session key $S{K}_{i-h}$ is created securely according to G1, G2, G3, and G4.

4.2.6. P-II Goals

G1: $P_i$ | ≡ ($M{S}_h$ $\stackrel{S{K}_{h-i}}{\leftrightarrow }$ $P_i$)

G2: $P_i$ | ≡ $M{S}_h$| ≡ ($M{S}_h$ $\stackrel{S{K}_{h-i}}{\leftrightarrow }$ $P_i$)

G3: $M{S}_h$ | ≡ ($M{S}_h$ $\stackrel{S{K}_{h-i}}{\leftrightarrow }$ $P_i$)

G4: $M{S}_h$ | ≡ $P_i$ | ≡ ($M{S}_h$ $\stackrel{S{K}_{h-i}}{\leftrightarrow }$ $P_i$)

4.2.7. P-II Assumptions

A₁: $P_{i }| \equiv \#\left(T_1\right)$

A₂: $P_i$ | ≡ $M{S}_h$⇒ ($M{S}_h$ $\stackrel{S{K}_{h-i}}{\leftrightarrow }$ $P_i$)

A₃: $M{S}_h$| ≡ $P_i$ ⇒ ($M{S}_h$ $\stackrel{S{K}_{h-i}}{\leftrightarrow }$ $P_i$)

A₄: $P_i$ | ≡ $M{S}_h \stackrel{B_h}{\leftrightarrow }{P}_i$

A₅: $M{S}_h$| ≡ $P_i$ | ≡ ($CI{D}_i$)

A₆: $P_i$ | ≡ $M{S}_h \stackrel{CI{D}_i}{\leftrightarrow }{P}_i$

4.2.8. P-II Idealized Forms

Msg₁: $T\mathrm{A}\to M{S}_h:\left(CI{D}_i\right)$

Msg₂: $M{S}_h\to P_i:{\left(X{B}_h,f_h,T_1\right)}_{B_h}$

4.2.9. P-II Formal Analysis

P-II uses BAN logic proof as shown below:

• Step 1: D₁ is obtained from Msg₁.

  $$D_1:M{S}_h⊲\left(CI{D}_i\right)$$
• Step 2: $M{S}_h$ trusts the $TA’s$ transmitted parameter and that $P_i$ is genuine. D₂ is obtained from D₁, A₅, f_h = h ($CI{D}_i$) ⊕ F_h, B_h = b_h * PK_i, and the session key SK_h-i = h ($B_h$ || CID_i || f_h) to accomplish G4.

  $$D_2:M{S}_h\left| \equiv P_i\right| \equiv \left(M{S}_h \stackrel{S{K}_{h-i}}{\leftrightarrow } P_i\right)$$
• Step 3: D₃ is obtained by using JR with A₃ and D₂ to achieve G3.

  $$\frac{M{S}_h|\equiv P_i\Rightarrow \left(M{S}_h\stackrel{S{K}_{h-i}}{\leftrightarrow }{P}_i\right),M{S}_h\left|\equiv P_i\right|\equiv \left(M{S}_h\stackrel{S{K}_{h-i}}{\leftrightarrow }{P}_i\right) }{M{S}_h| \equiv \left(M{S}_h \stackrel{S{K}_{h-i}}{\leftrightarrow } P_i\right)}$$

  $$D_3: M{S}_h| \equiv \left(M{S}_h \stackrel{S{K}_{h-i}}{\leftrightarrow } P_i\right)$$
• Step 4: D₄ is obtained from Msg₂

  $$D_4: P_i⊲{\left(X{B}_h,f_h,T_1\right)}_{B_h}$$
• Step 5: $P_i$ confirms that the message sent is from $M{S}_h$. D₅ is obtained by applying MMR using D₄ and A₄.

  $$\frac{P_i | \equiv M{S}_h \stackrel{B_h}{\leftrightarrow }{P}_i, P_i⊲{\left(X{B}_h,f_h,T_1\right)}_{B_h}}{P_i \left| \equiv M{S}_h\right| \sim \left(X{B}_h,f_h,T_1\right)}$$

  $$D_5: P_i \left| \equiv M{S}_h\right|\sim \left(X{B}_h,f_h,T_1\right)$$
• Step 6: $P_i$ checks whether $M{S}_h$ request is fresh. D₆ is obtained by using FR with A₁ and D₅.

  $$\frac{P_i |\equiv \#\left(T_1\right)}{P_i |\equiv \#\left(X{B}_h,f_h,T_1\right)}$$

  $$D_6: P_i |\equiv \#\left(X{B}_h,f_h,T_1\right)$$
• Step 7: $P_i$ verifies whether $M{S}_h$ request is legitimate. D₇ is obtained by applying NVR using D₅ and D₆.

  $$\frac{P_i \left|\equiv \#\left(X{B}_h,f_h,T_1\right),P_i \right| \equiv M{S}_h| \sim \left(X{B}_h,f_h,T_1\right) }{P_i \left| \equiv M{S}_h\right|\equiv \left(X{B}_h,f_h,T_1\right)}$$

  $$D_7: P_i \left| \equiv M{S}_h\right|\equiv \left(X{B}_h,f_h,T_1\right)$$
• Step 8: $P_i$ now trusts $M{S}_h$ and all of the parameters it has sent. D₈ is obtained by using BR with D_7.

  $$\frac{P_i \left| \equiv M{S}_h\right|\equiv \left(X{B}_h,f_h,T_1\right) }{P_i \left| \equiv M{S}_h\right|\equiv \left(X{B}_h,f_h\right)}$$

  $$D_8: P_i \left| \equiv M{S}_h\right|\equiv \left(X{B}_h,f_h\right)$$
• Step 9: D₉ is obtained from D₈, A₆, f_h = h ($CI{D}_i$) ⊕ F_h, B_h = XB_h * S_i, and the session key SK_h-i = h ($B_h$ || CID_i || f_h) to accomplish G2.

  $$D_9: P_i \left| \equiv M{S}_h\right| \equiv \left(M{S}_h \stackrel{S{K}_{h-i}}{\leftrightarrow } P_i\right)$$
• Step 10: $P_i$ obtains the parameters of the new session key from the sent $M{S}_h$ parameters. D₁₀ is obtained by using JR with A₂ and D₉ to achieve G1.

  $$\frac{P_i |\equiv M{S}_h\Rightarrow (M{S}_h\stackrel{S{K}_{h-i}}{\leftrightarrow }{P}_i),P_i\left|\equiv M{S}_h\right|\equiv (M{S}_h\stackrel{S{K}_{h-i}}{\leftrightarrow }{P}_i) }{P_i | \equiv (M{S}_h \stackrel{S{K}_{h-i}}{\leftrightarrow } P_i)}$$

  $$D_{10}: P_i | \equiv (M{S}_h \stackrel{S{K}_{h-i}}{\leftrightarrow } P_i)$$

In summary of P-II, $M{S}_h$ and $P_i$ attain mutual authentication. Furthermore, the session key $S{K}_{h-i}$ is created securely according to G1, G2, G3, and G4.

4.3. AVISPA Simulation Tool

The AVISPA simulation tool and the Security Protocol Animator (SPAN) are used to evaluate the security of P-I and P-II. We demonstrate that the simulator completely executes P-I and P-II, verifying the validity of the privacy and authentication reports issued by AVISPA’s checkers’ modules. First, High-Level Protocol Specification Language (HLPSL) is used to write P-I and P-II codes. Then, we evaluate whether the security goals of our protocols are SAFE or UNSAFE by running the On-the-fly Model-Checker (OFMC) and the Constraint-Logic-based Attack Searcher (CL-AtSe). If the outputs are SAFE, then the protocols are secure. Finally, we run the SPAN to ensure that all messages of P-I and P-II are exchanged.

Figure 6 and Figure 7 present the HLPSL code of P-I. Figure 8 and Figure 9 present the HLPSL code of P-II. We have three agents’ roles, a session role, and an environment role. The role controller is played by CN, the role medicalserver is played by MS, and the role trustedauthority is played by TA. The role controller header includes CN, MS, TA as agents, hash function, SKcnta as the symmetric key, and SND/RCV channels of type Dolev-Yao (dy). The role medicalserver header includes CN, MS, TA as agents, hash function, SKmsta as the symmetric key, and SND/RCV channels. The role trustedauthority header includes CN, MS, TA as agents, hash function, SKcnta/ SKmsta as the symmetric keys, and SND/RCV channels. CN is not allowed to be aware of SKmsta, and MS is not aware of SKcnta.

HLPSL specification also identifies the session and environment roles. A protocol session is described by the role session, which defines the interactions between the three agents’ roles. The role environment incorporates the intruder knowledge and the goal. The parameters (sp1, sp2, sp 3, sp4, sp5, sp6, vnew, wnew, cn_ms_ri, cn_ms_t1, ms_cn_rh, ms_cn_t2) of P-I, and parameters (sp1, sp2, sp3, sp4, sp5, sp6, ms_cn_bh, ms_cn_t1, cn_ms_cidi) of P-II, are declared as protocol_id and are used as privacy and authentication checkers. In the goal section, the goal secrecy_of sp1 indicates that CN keeps the variables PWi and Ai secret. The goal secrecy_of sp2 indicates that TA and MS keep the variable Sh secret. The goal secrecy_of sp3 indicates that CN and TA keep the variables SIDi and Si secret. The goal secrecy_of sp4 indicates that TA keeps the variable Sta secret. The goal secrecy_of sp5 indicates that CN and MS keep the session keys SKih and SKhi secret. The goal secrecy_of sp6 indicates that CN, TA, and MS keep the variable CIDi secret. The goal secrecy_of vnew indicates that CN and MS keep the variable Vinew secret. The goal secrecy_of wnew indicates that the variable Winew is kept secret to MS. The goals authentication_on cn_ms_ri and authentication_on cn_ms_cidi indicate that MS authenticates CN after getting messages including Ri and CIDi. The goal authentication_on cn_ms_t1 indicates that CN creates a timestamp T1, and MS authenticates CN after getting a message from CN including T1. The goals authentication_on ms_cn_rh and authentication_on ms_cn_bh indicate that MS creates values, and CN authenticates MS after getting messages from MS including Rrh and Bbh. Finally, the goals authentication_on ms_cn_t1 and authentication_on ms_cn_t2 mean that MS creates timestamps, and CN authenticates MS after getting the timestamps from the messages of MS.

Figure 10 depicts P-I and P-II simulation results utilizing AVISPA with OFMC and CL-AtSe. The summary reports show that P-I and P-II are SAFE and meet all of the security goals indicated in the role environment.

We use the SPAN to show the proper execution of P-I and P-II. Figure 11 and Figure 12 depict screenshots of the P-I and P-II SPAN animators, respectively. The simulator executes and exchanges all messages.

5. Performance Analysis

This section analyses P-I and P-II in connection to the performance requirements.

5.1. Computation Costs

We compute the computation costs by considering the time of the operations according to the studies [29,74]. Bilinear pairing (T_bp) takes 5.811 ms, map-to-point hash (T_hp) takes 12.418 ms, modular exponentiation (T_exp) requires 3.85 ms, scalar multiplication (T_mul) requires 2.226 ms, random number generation (T_rng) requires 0.539 ms, symmetric encryption and decryption (T_ed) takes 0.0046 ms, point addition (T_add) requires 0.0288 ms, and a one-way hash function (T_h) needs 0.0023 ms.

In Son et al. [29], the cost at the controller node side is 8 T_mul + 1T_rng + 8T_h ≈ 18.3654 ms, and the cost at the server side is 2T_bp + 5 T_mul + 1T_rng + 5T_h ≈ 23.3025 ms. In Chen and Peng scheme [43], the computation cost at the patient side is 1T_exp + 5T_mul + 1T_rng + 1T_ed + 1T_add + 4T_h ≈ 15.5616 ms, and the cost at the server side is 1T_bp + 4T_mul + 1T_rng + 1T_ed + 2T_add + 4T_h ≈ 15.3254 ms. In Khatoon et al. [48], the cost at the patient side is 1T_bp + 2T_hp + 3T_mul + 1T_rng + 1T_ed + 4T_h ≈ 37.8778 ms, and the cost at the server side is 1T_bp + 2T_hp + 4T_mul + 1T_rng + 1T_ed + 2T_h ≈ 40.0992 ms. In Rajaram et al. [45], the computation cost at the patient side is 5T_mul + 1T_rng + 1T_add + 7T_h ≈ 11.7139 ms, and the cost at the server side is 1T_bp + 1T_exp + 3T_mul + 1T_rng + 1T_add + 6T_h ≈ 16.9206 ms. In Kumar and Chand [33], the computation cost at the patient side is 1T_hp + 6T_mul + 1T_rng + 2T_add + 4T_h ≈ 26.3798 ms, and the cost at the cloud server side is 1T_hp + 6T_mul + 1T_rng + 2T_add + 4T_h ≈ 26.3798 ms. In Li et al. [40], the computation cost at the patient side is 2T_mul + 2T_rng + 3T_ed ≈ 5.5438 ms, and the cost at the server side is 1T_mul + 1T_rng + 3T_ed ≈ 2.7788 ms. In Ryu et al. [51], the cost at the patient side is 3T_mul + 1T_rng + 11T_h ≈ 7.2423 ms, and the cost at the server side is 3T_mul + 1T_rng + 7T_h ≈ 7.2331 ms.

In P-I, the cost at the patient side is 4T_mul + 1T_rng + 7T_h ≈ 9.4591 ms, and the cost at the server side is 3T_mul + 2T_rng + 6T_h ≈ 7.7698 ms. In P-II, the computation cost at the patient side is 2T_mul + 7T_h ≈ 4.4681 ms, and the cost at the server side is 2T_mul + 2T_rng + 4T_h ≈ 5.5392 ms.

The schemes in [33,48] use complex ECC operations on two sides, such as bilinear pairing and map-to-point hash operations, incurring more computation costs. The schemes in [29,43,45] adopt complex cryptographic ECC operations on only one side. The schemes in [40,51] use simple operations on ECC, such as scalar multiplication operations, to minimize the computation costs. P-I and P-II adopt simple ECC operations along with hash function and XOR operation and avoid complex operations, with P-II having fewer operations.

As shown in

Table 4. A computation costs comparison.

Scheme	Computation Cost
	CN	MSh	Total (ms)
[48]	1Tbp + 2Thp + 3Tmul + 1Trng + 1Ted + 4Th	1Tbp + 2Thp + 4Tmul + 1Trng + 1Ted + 2Th	77.977
[33]	1Thp + 6Tmul + 1Trng + 2Tadd + 4Th	1Thp + 6Tmul + 1Trng + 2Tadd + 4Th	52.7596
[29]	8 Tmul + 1Trng + 8Th	2Tbp + 5 Tmul + 1Trng + 5Th	41.6679
[43]	1Texp + 5Tmul + 1Trng + 1Ted + 1Tadd + 4Th	1Tbp + 4Tmul + 1Trng + 1Ted + 2Tadd + 4Th	30.887
[45]	5Tmul + 1Trng + 1Tadd + 7Th	1Tbp + 1Texp + 3Tmul + 1Trng + 1Tadd + 6Th	28.6345
[51]	3Tmul + 1Trng + 11Th	3Tmul + 1Trng + 7Th	14.4754
[40]	2Tmul + 2Trng + 3Ted	1Tmul + 1Trng + 3Ted	8.3226
P-I	4Tmul + 1Trng + 7Th	3Tmul + 2Trng + 6Th	17.2289
P-II	2Tmul + 7Th	2Tmul + 2Trng + 4Th	10.0073

, P-I has a lower computation than [29,33,43,45,48], but has a higher computation cost than [40,51]. P-II has a lower computation cost than [29,33,43,45,48,51], but has a higher computation cost then [40]. However, the current schemes had security problems, where they did not meet all of the security requirements in this research. Therefore, P-I and P-II achieve better security than these other schemes, yet they have acceptable computation costs.

5.2. Communication Costs

We compute the communication costs by considering the bit size and communication overhead. Bit sizes are computed according to the scheme [51], where ECC point has 320 bits, SHA-256 hash function has 256 bits, identity has 160 bits, the timestamp has 32 bits, symmetric encryption/decryption has 128 bits, and the random number has 160 bits.

In Son et al. [29], (PK_i, D_i, PSID_i, T₁) requires 928 bits, and (R_CS, L_i2, T₂) needs 608 bits. In Chen and Peng [43], the first message (V_C, Auth_C, T_C) needs 480 bits, and the second message (R_AP, Auth_AP) requires 576 bits. In Khatoon et al. [48], (R_i, T_i, Auth_i) needs 480 bits, and (R_S, T_S, Auth_S) needs 608 bits. In Rajaram et al. [45], the first message (id_x, R_x, L₃, L₄, T_x) needs 768 bits, whereas the second message (A₃, y_3, T_s) requires 352 bits. In Kumar and Chand [33], the first message (W, X) needs 640 bits, and the second message (t, T_CS, Y) requires 608 bits. In Li et al. [40], (ReqAuth, TID_N,E_kN (t_N, r), r_N, t_N) needs 480 bits, and (r_N,E_kN (r_N, r_HSP), E_kN (r_HSP, K)) requires 416 bits. In Ryu et al. [51], the message (PID_i, M_i, S₁, T₁) needs 864 bits, and the message (M_j, S₃, T₂) requires 608 bits.

In P-I, the first message (XR_i, J_i, L_i1, T₁) needs 608 bits, and the second message (R_h, L_i2, C1, T₂) needs 608 bits. In P-II, the message (XB_h, F_h, L_k2, T₁) needs 864 bits.

Table 5. A communication costs comparison.

Scheme	Communication Cost
	CN→MSh	MSh→CN	Total (bits)	Communication Overhead
[29]	928	608	1536	2
[51]	864	608	1472	2
[33]	640	608	1248	2
[45]	768	352	1120	2
[48]	480	608	1088	2
[43]	480	576	1056	2
[40]	480	416	896	2
P-I	608	608	1216	2
P-II	Not considered	864	864	1

shows the results of the communication cost comparison. In terms of communication costs in bits, P-I has a lower communication cost than [29,33,51] but has a higher communication cost than [40,43,45,48]. On the other hand, P-II has a better communication cost than other schemes. Furthermore, P-II achieves a lower communication overhead by requiring only one message.

6. Conclusions

TMIS is a WBAN technology that is capable of providing various healthcare services via telecare servers. TMIS uses wearable sensors to gather patient medical data and transmit it via a public channel for medical purposes. However, several cyber-attacks can be performed via such an unsecured channel. Therefore, the research aimed to design two inter-BAN authentication protocols for securing data transfer between a controller node and a cloud-based medical server: P-I for emergency authentication and P-II for periodic authentication. Our scheme consisted of an initialization phase, registration phase, authentication P-I, authentication P-II, and password change protocol. To analyze our protocols, we performed an informal security analysis and discovered that our protocols satisfied all of the security requirements in this research. Furthermore, we used the BAN logic and discovered that our protocols achieved mutual authentication. We also used the AVISPA simulation tool and discovered that our protocols were secure against passive and active attacks. Moreover, we conducted a performance analysis and discovered that our protocols had suitable computation and communication costs for WBAN, and P-II achieved a lower communication overhead than all other schemes due to the authentication message’s one-way communication. In future work, our goal is to conduct a performance analysis regarding the complexity of the proposed authentication protocols.