Analysis of the Desynchronization Attack Impact on the E2EA Scheme

The healthcare IoT system is considered to be a significant and modern medical system. There is broad consensus that these systems will play a vital role in the achievement of economic growth in numerous growth countries. Among the major challenges preventing the fast and widespread adoption of such systems is the failure to maintain the data privacy of patients and the integrity of remote clinical diagnostics. Recently, the author proposed an end-to-end authentication scheme for healthcare IoT systems (E2EA), to provide a mutual authentication with a high data rate between the communication nodes of the healthcare IoT systems. Although the E2EA authentication scheme supports numerous attractive security services to resist various types of attack, there is an ambiguous view of the impact of the desynchronization attack on the E2EA authentication scheme. In general, the performance of the authentication scheme is considered a critical issue when evaluating the applicability of such schemes, along with the security services that can be achieved. Therefore, this paper discusses how the E2EA authentication scheme can resist the desynchronization attack through all possible attack scenarios. Additionally, the effect of the desynchronization attack on the E2EA scheme performance is analyzed in terms of its computation and communication costs, based on a comparison with the recently related authentication schemes that can prevent such attack. Moreover, this research paper finds that the E2EA authentication scheme can not only prevent the desynchronization attack, but also offers a low cost in terms of computations and communications, and can maintain consistency and synchronization between the communication nodes of the healthcare IoT systems during the next authentication sessions.


Introduction
The healthcare IoT system is one of the most important medical systems. There is a broad consensus that these systems will play an essential function in achieving economic growth for several growth countries in terms of the health of their societies [1][2][3][4]. The core goal of the healthcare IoT system is to remotely monitor the medical state of the patients. Moreover, the healthcare IoT system can offer other benefits, such as reducing the number of healthcare centers and the expenditures they incur. It can cover also the shortfall in the number of health care centers located in distant areas, and patients can be easily treated by professional doctors and experts from around the world [5,6].
The fundamental process of the healthcare IoT systems can be summarized easily and simply. The patients' vital signs are collected through specific sensor devices, such as body temperature, blood sugar, blood pressure, pedometer, etc. Then, these collected data are sent to the healthcare service provider by wireless medical sensor network technology (WMSN), using internet communication channels [7]. After this, professional doctors monitor the patient's medical status using the physiological data of the patients that periodically arrive at the healthcare service provider [8][9][10].
Among the major challenges limiting the fast and widespread adoption of the healthcare IoT system are maintain patients' data privacy and the integrity of remote clinical diagnostics. Attackers can access and collect patients' vital signs data, and this issue can lead to passive consequences such as patients losing their jobs and their health insurance. Moreover, attackers also can tamper with communication between the patient and doctors, which could cause incorrect clinical diagnosis and lead to the wrong orders or advice being given to the patients [11].
With the growing demand for healthcare IoT systems, many healthcare IoT authentication schemes have been proposed to resolve the security weaknesses and to prevent different types of attack that target the patient's privacy and the integrity of remote clinical diagnostics [12][13][14][15][16][17][18][19][20]. These attacks can be summarized as the password table attack, man-in-the-middle attack, wrong login information attack, replay attack, impersonate attack, insider attack, smart card loss attack, and desynchronization attack [21][22][23][24][25]. Most healthcare IoT authentication schemes that have been proposed are unable to prevent all these attacks, especially the desynchronization attack [26,27].
Usually, to maintain consistency and synchronization between the communication nodes in such systems, the authentication schemes use different synchronization techniques, such as random numbers, pseudonym identities, timestamps, serial numbers, and hash functions [11][12][13][14][15][16][17][18][19][20][21][22][23][24]. Therefore, the improper use of such techniques to renew the nodes' identities and the session keys that will be used in the next authentication sessions may lead to extensive computational costs to prevent desynchronization attacks [25,28]. Unfortunately, healthcare IoT systems suffer from restrictions due to the limitations of the memory space and the low computation abilities of the sensor nodes that collect the patients' vital signs data [29]. Therefore, the performance of the authentication scheme is considered a critical issue when evaluating the applicability of the authentication schemes and the security services that can be achieved [30][31][32][33].

Review of E2EA Authentication Scheme
The stages of the E2EA authentication scheme are classified into four categories. The first category is the registration stages for the physician, patient, and WMSN nodes. The second category is the login stages for physician and patient nodes. The third category is the password change stages for physician and patient nodes. The last category is the authentication stages, which are called the long-term, short-term, and WMSN node authentication stages [26].
E2EA authentication scheme is executed between four authentication entities: the physician node (Pi) represents the professional doctor, the gateway node (GWN) node represents the healthcare service provider, the smart device node (SDj) represents the participant's patient, and the WMSN node (Sk) represents the sensors that will collect the patient's vital signs and be accessed by the physician. Tab. 1 summarizes the notations of the E2EA authentication scheme [26]. This section reviews the registration and authentication stages, where the other stages are not affected or will be affected by the desynchronization attack scenarios discussed in the next section. It should be noted that the registration stages are executed by authentication entities through secure communication channels, while the authentication stages are executed through public communication channels.

Physician Registration Stage
When a physician (Pi) wants to access a patient's node (SDk), the Pi needs to register in the GWN. Then, the GWN issues a smart card (SCi) to the Pi as a response to the registration request message that was sent from Pi to the GWN, as shown in Fig. 1. This procedure is summarized as follows: (1) Using a secure channel, the Pi sends the registration request message {M1: PIDi, Ci, PSCi} to the GWN. The identity number (PIDi), and security code (PSCi) are selected by the Pi. Additionally, the value of (Ci) is computed as Ci = h2 (PIDi ‖ PPWi ‖ R0), where both the password (PPWi) and the random number (R0) are also generated by the Pi; (2) Upon receipt of the {M1} message, the GWN verifies whether the PIDi has registered previously. If it exists in the physician's table, the GWN rejects {M1} and tells the Pi to choose another PIDi. Otherwise, GWN computes SNi = h0 (R1), PKi = h1 (PIDi ‖ Xi), PFi = (PKi È PSCi), and PVi = h1 ((SNi ‖ PSCi) È (Ci ‖ PKi)), where the (R1) is a random number and (Xi) is a secret key that was generated by the GWN. Then, the GWN initiates the values of the IDip = h1 (PIDi ‖ SNi) and IDis = Ф, where (Ф) is a null value. After that, the GWN node inserts the Pi's data into the physicians'

Patient Registration Stage
To register in the healthcare IoT system, the patient's smart device (SDj) sends a registration request message to the GWN. After that, GWN issues the smart card (SCj) to the SDj as a response to the registration request message that was sent from SDj to the GWN, as shown in Fig. 2. This procedure is summarized as follows: (1) Using a secure channel, the SDj sends the registration message {M1: SIDj, Cj, SSCj} to the GWN. The identity number (SIDj) and security code (SSCj) are selected by the SDj. Additionally, the value of (Cj) is computed as Cj = h2 (SIDj ‖ SPWj ‖ R2), where both the password (SPWj) and the random number (R2) are also generated by the SDj; (2) Upon receipt of the {M1} message, the GWN verifies whether the SIDj has registered previously. If it exists in the patients' table, the GWN rejects the {M1} message and tells the SDj to choose another SIDj. Otherwise, GWN computes SNj = h0 (R3), SN = (SSCj È SNj), SKj = h1 (SIDj ‖ Xj), SFj = (SKj È SSCj), and SVj = h1 ((SNj ‖ SSCj) È (Cj ‖ SKj)), where the random number (R3) and a secret key (Xj) were generated by the GWN. Then, the GWN initiates both the IDj = h1 (SIDj ‖ SNj and IDjp = IDjs = Ф, where Ф is a null value. After that, the GWN node saves the SCj's data into the patients' (3) Upon receiving SCj from the GWN, the SDj node sets up the SCj, stores the (R2) and securely initiates the session counter as (C1j = 0).

WMSN Node Registration Stage
To securely communicate with the SDj, the sensor node (Sk) sends a registration request message to the SDj. After that, the SDj issues a set of authentication parameters, such as the SSk1 and SNk0, as a response to the request message that was sent from Sk, as shown in Fig. 3. This procedure is summarized as follows: (1) Using a secure channel, the Sk sends the registration request message {M1: SIDk} to the SDj node, where the SIDk value is specified, where the Sk was designed for use by a specific healthcare service provider.

Long-Term Authentication Stage
To monitor and diagnose the patient's medical status, the Pi indirectly communicates with SDj through the GWN. Therefore, the Pi needs to satisfy a mutual authentication with both GWN and SDj, as well as create the shared keys that will be used during the direct sub-authentication sessions with the SDj, as shown in Fig. 4. This procedure is summarized as follows: (1) The Pi transmits the long-term request message {M1: IDi, CTi0, and Vi0} as a challenge message to the GWN via a public channel. The value of (IDi) was computed as IDi = h1(PIDi ‖ SNi), while the value of (CTi0) was computed as CTi0 = ETPKi (TP0 ‖ R5 ‖ SIDj), where the (TP0) is a timestamp of Pi and (R5) was generated randomly. Finally, the value of (Vi0) was computed as Vi0 = h3 (TP0 ‖ TPKi ‖ SNi ‖ IDi ‖ R5), where the (TPKi) was computed as TPKi = (IDi È PKi) using the value of (PKi), which was extracted during the previous login physician node stage.
(2) Upon receipt of the {M1} message from the Pi, the GWN finds the values of the (IDip) and (IDis) using the value of (IDi), and operates according to the following conditions [10,17,31]: If ((IDi = IDip) and (IDis ≠ Ф)), then the GWN verifies whether the Pi can diagnose the medical state of a patient remotely, by extracting the value of (SIDj) as follows: The Pi renews the (SNi) value as SNi = h0 (SNi), and calculates the PKi = h1 (PIDi ‖ Xi) and TPKi = (IDi È PKi). After that, the GWN node decrypts the value of (CTi0) using <TP0 ‖ R5 ‖ SIDj> = DTPKi(CTi0). If the SIDj does not match, the GWN rejects the {M1} message and ends the long-term authentication stage. Otherwise, the GWN node verifies the value of (TP0). If it does not match, the GWN rejects the {M1} message and ends the long-term authentication stage. Otherwise, GWN calculates the (XVi0) value as XVi0 = h3 (TP0 ‖ TPKi ‖ SNi ‖ IDi ‖ R5) to verify whether the received value of (Vi0) matches with the computed (XVi0) value. If it matches, the GWN renews the values of (IDis) and (IDip) as IDis = IDip, (IDip) = h1 (IDi ‖ R5), respectively. Otherwise, the GWN rejects the {M1} message and ends the long-term authentication stage.
However, if ((IDi = IDip) and (IDis = Ф)), then the GWN verifies whether the Pi can diagnose the medical state of a patient remotely by extracting the value of (SIDj), as follows: The Pi calculates the PKi = h1 (PIDi ‖ Xi) and TPKi = (IDi È PKi). After that, the GWN node decrypts the value of (CTi0) using the <TP0 ‖ R5 ‖ SIDj> = DTPKi(CTi0) function. If SIDj does not match, the GWN rejects the {M1} message and ends the long-term authentication stage. Otherwise, the GWN node also verifies the value of (TP0). If it does not match, the GWN rejects the {M1} message and ends the long-term authentication stage. Otherwise, GWN calculates the (XVi0) value as XVi0 = h3 (TP0 ‖ TPKi ‖ SNi ‖ IDi ‖ R5) to verify whether the value of (Vi0) that was received matches with the computed (XVi0) value. If it matches, the GWN renews the values of (IDis) and (IDip) as IDis = IDip and IDip = h1 (IDi ‖R5), respectively. Otherwise, the GWN rejects the {M1} message and ends the long-term authentication stage.
If (IDi = IDis), then the GWN verifies whether the Pi can diagnose the medical state of a patient remotely by extracting the value of (SIDj), as follows: the Pi calculates the PKi = h1 (PIDi ‖ Xi) and TPKi = (IDi È PKi). After that, the GWN node decrypts the value of (CTi0) using <TP0 ‖ R5 ‖ SIDj> = DTPKi(CTi0). If SIDj does not match, the GWN rejects the {M1} message and ends the long-term authentication stage. Otherwise, the GWN node verifies the value of (TP0). If it also does not match, the GWN rejects the {M1} message and ends the long-term authentication stage. Otherwise, GWN calculates the (XVi0) value as XVi0 = h3 (TP0 ‖ TPKi ‖ SNi ‖ IDi ‖ R5) to verify whether the received value of (Vi0) matches the computed (XVi0) value. If it matches, the GWN renews the values of (IDip) as IDip = h1 (IDi‖R5). Otherwise, the GWN rejects the {M1} message and ends the long-term authentication stage.

Short-Term Authentication Stage
In this stage, the Pi can directly communicate with the SDj, without reverting to the GWN. Therefore, the Pi can monitor and diagnose the medical status of the SDj based on real-time data during emergencies [20]. In this case, the Pi achieves mutual authentication with the SDj to protect the direct sub-authentication sessions from unauthorized access, as shown in Fig. 5. This procedure is summarized as follows: (1) Pi transmits the short-term request message {M1: C0ij, CTi2, Vi3} as a challenge message to the SDj via a public channel. The value of (C0ij) was initiated as C0ij = (C0ij + 1). The value of (CTi2) was calculated as CTi2 = EPSij (TPi ‖ R9 ‖ C0ij), where the (TPi) is a present timestamp of Pi, and (R9) was generated randomly. It should be noted that the value (PSij) was renewed as PSij = h1(PSij ‖ ID0ij), where the value of (ID0ij) was also renewed, as ID0ij = h1(SIDj ‖ ID0ij). Finally, the value of (Vi3) was computed as Vi3 = h3(TPi ‖ SIDj ‖ PSij ‖ ID0ij ‖R9); (2) Upon receipt of the {M1} message, the SDj verifies whether the (ΔCij) value falls within the (1 ≤ ΔCij ≤ µ1) range, where the value of the ΔCij is calculated using ΔCij = (C0ij -C1ij) and (µ1) was determined based on the system specifications. If it does not hold, the SDj rejects the {M1} message and ends the authentication session. Otherwise, SDj initiates the value of (ID1ij) as ID1ij = ID0ij, and then recomputes the ID1ij using the ID1ij = h1(SIDj ‖ ID1ij) function (ΔCij − 1) times, until the value of (ΔCij − 1) = 1. Then, the SDj decrypts the value of (CTi2) using the <TPi ‖ R9 ‖ C0ij> = DPSij(CTi2) function, where the value of the PSij was calculated as PSij = h1(PSij ‖ ID0ij). Next, the value of (TPi) is checked. If it does not hold, SDj rejects the {M1} message and ends the short-term authentication stage. Otherwise, the SDj calculates the value of (XVi3) as XVi3 = h3(TPi ‖ SIDj ‖ PSij ‖ ID1ij ‖ R9) to verify whether the received value of (Vi3) matches the computed value of (XVi3). If this does not match, SDj rejects the {M1} message and ends the short-term authentication stage. Otherwise, the Pi is considered a valid node. After that, the SDj transmits the short-term response message {M2: ID1ij, CTj2, Vj3} as a response message to the Pi via public channel. The value of (CTj2) was calculated using the CTj2 = EPSij (TPj ‖ R10 ‖ C1ij) function, where the (TPj) is a present timestamp of the SDj and (R10) was generated randomly. The value of (Vj3) has calculated as Vj3 = h3(TPj ‖ SIDj ‖ PSij ‖ ID1ij ‖ R10); (3) Upon receipt of the {M2} message, Pi decrypts the value of (CTj2) using the < TPj ‖ R10 ‖ C1ij > = DPSij (CTj2) function, where the key value of (PSij) was retrieved based on the fact of ID1ij = ID0ij. Then, the value of (TPj) is checked. If it does not hold, the Pi rejects the {M2} message and ends the short-term authentication stage. Otherwise, the Pi calculates (XVj3) as XVj3 = h3(TPj ‖ SIDj ‖ PSij ‖ ID1ij ‖ R10) to verify whether the received value of (Vj3) that matches the computed value of (XVj3). If it does not hold, Pi rejects the {M2} message and ends the short-term authentication stage. Otherwise, the SDj is considered a valid node.

WMSN Node Authentication Stage
This stage is accomplished between the Sk and the SDj to receive the medical instructions that were transmitted by the Pi, as well as to exchange the physiological data that were sensed by the Sk. Therefore, the mutual authentication procedure is performed whenever the SDj communicates with its connected Sk, as shown in Fig. 6. This procedure is summarized as follows: (1) The SDj transmits the sensor request message {M1: CTk, Vk0, and SSk0} as a challenge message via a public channel to the Sk. The value of (CTk) has computed as CTk = ((SKk ‖ ST) ⨁ h2(SNk0 ‖ SIDk ‖ SSk0)) where the (SKk) is generated randomly, the value of (SNk0) has computed as SNk0 = h1 (SNk0‖SIDk), and (ST) has been specified according to the system requirements. While the value of (Vk0) has computed as Vk0 = h3(ST ‖ SIDk ‖ SKk ‖ SNk0 ‖SSk0). Finally, the value of (SSk0) has updated as SSk0 = SSk0 + 1. It should be noted that the value of pseudonym identity (IDk) was also renewed as IDk = h1(SKk ‖ SIDk).

Resistance Analysis of Desynchronization Attack
Usually, the pseudonym identity, one-way hash function, serial number, timestamp, and encryption techniques are used to assign and update the communication nodes' identities, as well as to generate the session keys that will be used during the next sessions in the authentication schemes. The improper use of these techniques leads to inconsistencies in the identities or the values of the shared keys between the communication nodes. Therefore, if the adversary can block the authentication messages, this may result in a desynchronization attack [26]. To illustrate how the E2EA authentication scheme can resist desynchronization attacks and preserve consistency in the shared values of the identities and keys of communication nodes during the next authentication session, a set of attack scenarios are discussed in the following subsections.

Attack Scenarios of Long-Term Authentication Stage
To ensure the long-term authentication stage can resist desynchronization attacks, suppose the following attack scenarios, as shown in Fig. 7. (S1) Suppose an adversary has blocked the long-term request message {M1: IDi, CTi0, and Vi0} flow. The adversary cannot impact the synchronization between the Pi and the GWN during the next authentication session. In this scenario, the hash values of (SNi) and (IDi) have not yet been updated on both sides. However, the long-term response message (M4) has also not been received by the Pi. Therefore, the Pi can initiate a new authentication session and resend the (M1) message using different values for the (TP0) and (R5). As a result, the Pi can resynchronize the authentication session with GWN.
(S2) Suppose an adversary has blocked the long-term request message {M2: C0j, CTj0, and Vj0} flow. This scenario will not affect the synchronization between the Pi and GWN. Furthermore, the adversary cannot impact the synchronization between the GWN and the SDj during future authentication sessions. In this case, the hash values of (SNj) and (IDj) have only been updated on the GWN side. However, the long-term response message (M3) has not been received by the GWN. Therefore, the GWN can resend the {M2} message again, based on a new (C0j) value, with different values for the (TGWN0) and (R6). Alternatively, the SDj using the new value of (ΔCj) can resynchronize the one-way hash functions to (S3) Suppose an adversary has blocked the long-term response message {M3: IDjs, CTj1, and Vj1}. Such a scenario will not affect the synchronization between Pi and the GWN. This scenario is similar to the pervious scenario; the adversary also cannot impact the synchronization between the SDj and the GWN during the future authentication session. In this case, the hash values of the (SNj) and (IDj) have been updated on both sides. However, the long-term response message (M3) has not been received by the GWN. Therefore, the GWN can compute and resend the {M2} message using different values for (TGWN0), and (R6). After that, the SDj node using the new value of (ΔCj) can resynchronize the oneway hash functions to update the hash values of (SNj) and (IDj), as in the GWN side. Next, the SDj can compute and resend the {M3} message again, using the new values for the (TSD), and (R7). Therefore, the GWN can resynchronize the authentication session with SDj.
(S4) Suppose an adversary has blocked the long-term response message (M4: CTi1, Vj1) flow. This attack will not affect the synchronization between the GWN and SDj. Moreover, this attack cannot impact the synchronization between the Pi and the GWN during future authentication sessions. In this case, the hash values of (SNi) and (IDis) have not yet been updated, and only the synchronization is required for the hash value of the pseudonym identity (IDi). However, the long-term response message (M4) has not been received by the Pi. Therefore, the Pi can initiate and resend the long-term request message (M1) using different values of (TP0), and (R5). Since the value of (IDi) for the GWN is equal to (IDi = IDis), the GWN can compute and resend the long-term response message {M4} using the new values for (TGWN1) and (R8). Therefore, the Pi can resynchronize the authentication session with GWN.
(S5) Suppose an adversary has blocked the acknowledgment message {M5: IDi, Vix} flow. This scenario also will not affect the synchronization between the GWN and SDj. Furthermore, this attack cannot impact the synchronization between the Pi and GWN during future authentication sessions. In this case, the hash values of the (IDi) and (IDip) have been updated on both sides as (IDi = IDip), and the hash value of the (SNi) has been updated on the Pi side, but has not yet been updated on the GWN side. However, Pi will not receive any response notification from the GWN. Therefore, Pi can initiate a new authentication session and resend the {M1} message using different values of (TP0), and (R5). Since the value of (IDi) for the GWN node will be equal to ((IDi = IDip) and (IDis ≠ Ф)), the same session key value of (TPKi) will be computed by both the Pi and the GWN. After that, the GWN will resend (M4) to the Pi, using different values for (TGWN1) and (R8). Therefore, the Pi can resend (M5) and resynchronize the authentication session with GWN.

Attack Scenarios of Short-Term Authentication Stage
To ensure that the short-term authentication stage can resist desynchronization attacks, suppose the following attack scenarios, as shown in Fig. 8.
(S6) Suppose an adversary has blocked the short-term request message {M1: C0ij, CTi2, and Vi3} flow. In this attack, the adversary cannot impact the synchronization between the Pi and SDj during the future authentication session. In this case, the hash values of (ID0ij), and (PSij) have only been updated on the Pi side. However, the response authentication message (M2) has not been received by the Pi. Therefore, the Pi can initiate and resend the {M1} message using new values for (R9), (TPi), and (C0ij). On the other side, the SDj, using the new value of (ΔCij), can resynchronize the one-way hash functions to update the hash values of (ID1ij) and (PSij), as in the Pi side. Therefore, the Pi can resynchronize the authentication session with the SDj.
(S7) Suppose an adversary has blocked the short-term response message {M2: ID1ij, CTj2, and Vj3} flow. This scenario is similar to the previous scenario; the adversary cannot impact the synchronization between the Pi and SDj during future authentication sessions. In this case, the hash values of (ID0ij), and (PSij) have been updated on both sides. However, the short-term response message (M2) has also not been received by the Pi. Therefore, the Pi can resend the {M1} message using new values for (R9), (TPi), and (C0ij). On the other side, the SDj, using the new value of (ΔCij), can resynchronize the oneway hash functions to update the hash values of (ID1ij) and (PSij), as shown on the Pi side. Next, the SDj can compute and resend the {M2} message, using the new values for (TPj), and (R10). Therefore, the Pi can resynchronize the authentication session with SDj.

Attack Scenarios of WMSN Node Authentication Stage
Similarly, to ensure that the WMSN node authentication stage can resist desynchronization attacks, suppose an adversary node can perform the following attack scenarios, as shown in Fig. 9. In this attack, the adversary cannot impact the synchronization between the Sk and SDj during a future authentication session. In this case, the value of (CTk), the hash value of (IDk), and the hash value of (SNk0) have only been updated in the SDj side. However, the sensor response message (M2) has not been received by the SDj. Therefore, the SDj can initiate and resend the {M1} message, using new values for the (SKk) and (SSk0). On the other side, the Sk, using the new value of (ΔSSk), can resynchronize the one-way hash functions to update the hash values of the (IDk), (SSk1), and (SNk1), as in the SDj side. Therefore, the SDj can resynchronize the authentication session with Sk.
(S9) Suppose an adversary has blocked the sensor response message {M2: IDk, Vk2} flow. This scenario is somewhat similar to the case in scenario (S8). In this attack, the adversary also cannot impact the synchronization between the Sk and SDj node during future authentication sessions. In this case, the value of (CTk), the hash value of (IDk), and the hash value of (SNk0) have been updated on both sides. However, the sensor response message (M2) has not been received by the SDj. Therefore, the SDj can initiate and resend {M1}, using new values for (SKk), and (SSk0). On another side, the Sk, using the new value of (ΔSSk), can resynchronize the one-way hash functions to update the hash values of (IDk), (SSk1), and (SNk1), as shown in the SDj side. After that, the Sk can compute and resend the {M2} message again. Therefore, the SDj can resynchronize the authentication session with Sk.

Performance Analysis
This section offers a performance analysis of the desynchronization attack scenarios' impact on the E2EA authentication scheme in the terms of communication and computation costs. In addition, the E2EA authentication scheme is compared with a set of recently related authentication schemes that resisted the desynchronization attack [19,20]. Throughout the previous desynchronization attack scenarios, the E2EA authentication scheme showed the ability resist desynchronization attacks when executing the authentication sessions, during all authentication stages. It should be noted that the desynchronization attack may be able to make the E2EA authentication scheme suspend temporarily but cannot impact resuming the authentication sessions.
To facilitate analysis, and a reasonable comparison with the recently related authentication schemes, the performance analysis of the effect of all possible desynchronization attack scenarios will be based on the following assumptions: the size of all authentication parameters (identities, serial number, counters passwords, random numbers, timestamps, etc.) is equal to (128) bits; the block size of both encryption and decryption functions are multiples of (128) bits; the size of outputs for all hash functions is equal to (160) bits; the computation time for both encryption and decryption processes using the AES algorithm is equal (TE/D) ≅ 0.0056s [11,19,26,29]; the computation time needed to obtain all hash values using SHA-1 algorithm is equal to (Th) ≅ 0.00032s [11,19,26,29].

Computation Cost Analysis
In this section, the E2EA authentication scheme will be compared with the other proposed authentication schemes [19,20] in terms of the impact of the desynchronization attack on the computation costs. The costs are computed based on the total execution time of the cryptographic functions in each attack scenario. Tab. 2 shows the cryptographic functions that should be re-executed in each node to maintain consistency and synchronization between the communication nodes, with scenario (S5) having the highest number of reexecuted functions.
Tab. 3 shows the total computation costs for the recently related authentication schemes that resist desynchronization attacks [19,20], as well as for the E2EA authentication scheme. It should be noted that scenario (S5) causes the highest computation cost among all possible attack scenarios in [19], as well as for the E2EA scheme, while scenario (S4) represents the highest computation cost in [20]. The results indicate that the E2EA authentication scheme has lower computation costs than the authentication scheme in [19], which used both one-way hash and cryptographic functions in attack scenarios (S1-S5). However, the computation costs of E2EA authentication are higher than the computation costs of the authentication scheme in [20], which only uses one-way hash functions in the attack scenarios (S1-S4).

Communication Costs Analysis
In this section, the E2EA authentication scheme will be compared with the recently related authentication schemes [19,20] in terms of the desynchronization attack's impact on the communication costs. These costs are computed based on the total bit size of the authentication messages in each attack scenario. Tab. 4 shows the total bit size of the authentication messages that should be retransmitted to maintain consistency and synchronization between the communication nodes. The results indicate that the authentication messages that would be transmitted to resist scenario (S5) have the highest communication costs.  Tab. 5 shows the total communication costs for the recent-related authentication schemes that are resisted the desynchronization attack [19,20] as well as for the E2EA authentication scheme. It should be noted that scenario (S5) leads to the highest communication cost among all the possible attack scenarios in [19], as well as for the E2EA scheme, causing five authentication messages to be resent, while scenario (S4) represents the highest communication cost in [20], in which four authentication messages are sent. The results indicate that the E2EA authentication scheme has the minimum required communication costs.

Conclusion
This paper eliminates the ambiguity in the behavior of the end-to-end authentication scheme for healthcare IoT systems (E2EA) when resisting desynchronization attacks. The performance of the authentication scheme is considered critical to evaluating the applicability of such schemes, along with the security services that can be achieved. Therefore, this paper discusses how the E2EA authentication scheme can resist desynchronization attacks, looking at all possible attack scenarios in all authentication stages. Furthermore, the effect of desynchronization attacks on E2EA authentication scheme performance is analyzed based on a comparison with recently related authentication schemes. Finally, this paper finds that the E2EA authentication scheme not only prevents desynchronization attacks, it also offers low computation and communication costs to maintain consistency and synchronization between the system's communication nodes in future authentication sessions.