Towards a Provably Secure Authentication Protocol for Fog-Driven IoT-Based Systems

Abstract

The emergence of fog-based Internet of Things (IoT) systems have played a significant role in enhancing the applicability of the IoT paradigm. In such systems, fog-nodes are proficient enough to retain, process and transmit the data coming from IoT devices. Nevertheless, as an extension of cloud computing, inheriting the security and privacy concerns of cloud computing is also inevitable in fog-based IoT systems. To deal with such challenges, a diverse range of security solutions are reported in the literature. However, most of them have several limitations (i.e., vulnerability to known security attacks and high computation overhead) that curtail their practical implementation applicability. Keeping these limitations in mind, this paper propose a privacy-preserving hash-based authenticated key agreement protocol using XOR and concatenation operations for fog-driven IoT systems. Using healthcare as a case study, the security of the novel protocol is evaluated by using informal and formal security analysis. In order to obtain the experimental results, the key cryptographic operations used at the user, fog node and cloud server-side are implemented on a mobile device, Arduino and cloud server, respectively. Findings from the performance evaluation results show that the proposed protocol has the least computation cost compared to several related competing protocols.

1. Introduction

In this modern era, the healthcare system has proved to be an influential industrial IoT (IIoT) application in which IoT devices are deployed either at enormous healthcare centers or small private clinics. Moreover, the increasing popularity of the several wearable smart IoT devices has significantly transformed the typical healthcare system from an originally hospital-centric to a patient-centric system. Such a patient-centric approach bridges the gap between practitioners and patients by offering reliable and seamless delivery of sensitive information. It allows citizens to contact practitioners remotely and be availed of medical advice and prescriptions at their doorstep. For instance, wearable smart IoT devices (i.e., heart rate monitors, Electrocardiograms (ECG) monitoring instruments, etc.) are proficient enough to sense, inspect and stream information to various healthcare professionals without any requirement of a physical visit to the hospital [1,2].

The healthcare system is considered a particular industry that requires minimized latency. For instance, a delay of only a minute can cause damage to the life of an individual who is suffering from a heart attack. Therefore, in this context, a remarkable fog-driven solution is considered. A fog-driven healthcare system based on IoT is illustrated in Figure 1. It is obvious from Figure 1 that the fog-driven healthcare system based on IoT comprises three layers including (i) the cloud layer of IoT healthcare, (ii) the fog layer of IoT healthcare and (iii) the device layer of IoT healthcare [3,4].

Conventionally, fog computing exhibits classified infrastructure which consists of the fog-nodes and cloud data centers. The sequential architecture of fog computing is depicted in Figure 2, where the sensors and connected IoT devices are utilized to manage unique tasks such as physical objects monitoring, the collection of data related to objects, and communication of data towards the fog-nodes. All the involved devices are further connected to the nearest fog-nodes via numerous communication protocols. The fog-nodes installed at suitable sites are responsible for storing, processing and transmitting the collected data of different objects. The fog-nodes command the data from both cloud and user. Further, they are responsible for refining the collected data and transmitting this accumulated data towards the cloud for interpretation or storage. However, the cloud data center comprises storage devices and high-performance servers. It offers networking, computing and storage facilities for large scale data. Furthermore, the core network and edge network ensure two-way communication for the smooth transmission of data among IoT devices, fog-nodes and the cloud data center.

Contrary to the concept of cloud computing, which is purely considered a centralized system, the deployment of fog-nodes is performed without any suitable safety scope. Simply, fog-nodes and end devices have a high chance of being compromised. This situation could lead to privacy violation through leakage of users’ information, such as location, identity, medical records and health status, etc.

Table 1. Summary of existing studies.

Authors	Year	Technique	Demerits
Yang and Chang [5]	2009	ECC-based	Lacks perfect forward secrecy and vulnerable to impersonation attacks
Li et al. [6]	2012	Identity-based	Prone to impersonation and DoS attacks
Tsai and Lo [7]	2015	Bilinear pairing	High computation overhead and prone to impersonation attacks
Amin et al. [8]	2018	Hash-based	Prone to stolen smart-card and insider attacks
Kumar et al. [9]	2018	Identity-baseds	Lacks user anonymity and privacy
Jia et al. [10]	2019	Identity-based	Vulnerable to impersonation attacks
Ma et al. [11]	2020	Bilinear pairing	Vulnerable to impersonation and secret key leakage attacks
Jia et al. [12]	2020	Bilinear pairing	Vulnerable to ephemeral secret leakage (ESL) attack
Chen et al. [13]	2020	Bilinear pairing	Vulnerable to impersonation attacks

gives an in-depth summary of contemporary existing key agreement protocols with respect to the techniques employed by each protocol, and their limitations against various attacks, in chronological order. Moreover, it is noticeable that no work in the existing literature supports user revocation to the best of our knowledge. In summary, the secure, robust and practical design of an authentication protocol for a fog-based environment is still a challenging job. Keeping this in mind, this paper introduces a three-party identity-based authenticated key agreement protocol for a fog-driven IoT healthcare framework by focusing on the security and privacy challenges faced during the communication.

In order to prevent impersonation and to establish a firm trust, each fog-node or user in the system must be authenticated and identified uniquely. Further, to ensure privacy and security, there is a vital need to encrypt the data that are transmitted via open medium and then stored in the cloud server or fog-nodes. Nonetheless, the pre-sharing of session keys between the end devices and the fog-nodes is not realistic due to the mobile and dynamic nature of various fog-nodes and end devices. Thus, AKA (authenticated key agreement) protocol provides the best solution for authenticating nodes or users and generating session keys [14]. The main contributions of this article are as follows:

• This paper presents a three-party identity-based authenticated key agreement scheme to secure the communication of data among the participants in an IoT based fog-driven healthcare system. The robust identity-based three-party AKA protocol is designed using hash, XOR and concatenation operations.
• The proposed protocol ensures mutual authentication among users, fog-nodes and cloud service providers for the establishment of a shared session key. This shared session key is used by all the participants.
• Our designed protocol guarantees that the identity of any user can not be exposed to any adversary except the cloud server.

The rest of our article is formulated according to the following. The complexity assumptions are illustrated in Section 2, while introduced protocol is presented in Section 3. Section 4 describes the security analysis of our presented scheme. Performance comparison of the proposed protocol and related competing protocols is illustrated in Section 5. Lastly, we have concluded our work in Section 6.

2. Complexity Assumptions

This section briefly describes the communal threat model. Moreover, the commonly used notations throughout the article are presented in

Table 2. Commonly used notations.

Notations	Elucidation
${\mathcal{U}}_k$	$k_{th}$ user of the system
$I{D}_k$	Identity of ${\mathcal{U}}_k$
${\mathcal{TPD}}_k$	Tamper proof device issued to each specific ${\mathcal{U}}_k$
$TI{D}_k$	Temporary identity of ${\mathcal{U}}_k$
${\mathcal{FN}}_f$	Fog-node
$I{D}_f$	Identity of ${\mathcal{FN}}_s$
$TI{D}_f$	Temporary identity of ${\mathcal{FN}}_s$
${\mathcal{TPD}}_f$	Tamper proof device of ${\mathcal{FN}}_s$
$\mathcal{CSP}$	Cloud service provider
$I{D}_{csp}$	Identity of $\mathcal{CSP}$
x	Private key of $\mathcal{CSP}$
${\mathcal{SK}}_{k-f-csp}$	Session key between ${\mathcal{U}}_k$, $\mathcal{FN}$ and $\mathcal{CSP}$
∥	Concatenation operator
⊕	XoR operator
${\mathcal{A}}_{att}$	Attacker
$h(.)$	One-way hashing function
$IBC$	Identity-based cryptography
$AKA$	Authenticated key agreement

.

Threat Assumption Model

In order to discuss the capabilities of an adversary, an adversarial model is briefly described as mentioned in [15,16]. An adversary ${\mathcal{A}}_{att}$ has the following capabilities:

• ${\mathcal{A}}_{att}$ has full control over the public channel.
• ${\mathcal{A}}_{att}$ can be a user or cloud service provider.
• $\mathcal{CSP}$ is assumed to be honest but curious, whereas, ${\mathcal{FN}}_f$ is assumed as untrustworthy entity; because of that, it does not keep any verifier of ${\mathcal{U}}_k$.
• ${\mathcal{A}}_{att}$ can intercept the messages that are exchanged over the public channel between ${\mathcal{U}}_k$, ${\mathcal{FN}}_f$ or $\mathcal{CSP}$.
• ${\mathcal{A}}_{att}$ can modify and replay the intercepted messages to misuse them.
• The cloud service provider $\mathcal{CSP}$ is a secure entity, so, ${\mathcal{A}}_{att}$ cannot access it.
• ${\mathcal{A}}_{att}$ can be an insider or outsider. An outsider ${\mathcal{A}}_{att}$ can be a deceitful user and internal ${\mathcal{A}}_{att}$ can be a cloud server, provider or user.

3. Proposed ITP-AKA Protocol

This section demonstrates our proposed identity-based three-party authenticated key agreement (ITP-AKA) protocol. Detailed descriptions of all these phases are shown in Section 3.1, Section 3.2 and Section 3.3, respectively. Login and authentication phase was shown in Figure 3.

3.1. User Registration Phase

Initially, user ${\mathcal{U}}_k$ imitates the process to get himself registered with the cloud service provider $\mathcal{CSP}$. For this purpose, ${\mathcal{U}}_k$ performs the subsequent steps:

1:

${\mathcal{U}}_k$ randomly chooses $r_k\in Z_p^{*}$, identity $I{D}_k$ and computes $RI{D}_k=h(I{D}_k\oplus r_k)$. ${\mathcal{U}}_k$ sends $I{D}_k,RI{D}_k$ to $\mathcal{CSP}$ via a secure channel.

2:

After receiving ${\mathcal{U}}_k^{\prime }s$ request, $\mathcal{CSP}$ computes the following values: $X_k=h(I{D}_k\parallel x),$$Y_k=RI{D}_k\oplus X_k$. Further, $\mathcal{CSP}$ selects $TI{D}_k$ for the respective user ${\mathcal{U}}_k$ and calculates $Z_k=h(X_k\parallel I{D}_k\parallel TI{D}_k\parallel RI{D}_k)$ and stores $I{D}_k$ in its database corresponding to $TI{D}_k$ and using x. $\mathcal{CSP}$ then transmits $\{Y_k,TI{D}_k,Z_k\}$ to ${\mathcal{U}}_k$ using a private channel.

3:

After receiving the message from $\mathcal{CSP}$, ${\mathcal{U}}_k$ computes $\overline{Y_k}=(Y_k\parallel r_k)\oplus I{D}_k$ and stores $\{\overline{Y_k},Z_k,TI{D}_k\}$ in its tamper-proof device.

3.2. Fog-Node Registration Phase

In order to deploy the fog-node, it must initially be registered with $\mathcal{CSP}$, according to the subsequent steps:

1:

${\mathcal{FN}}_f$ sends its identity to the $\mathcal{CSP}$. On obtaining the ${\mathcal{FN}}_f$ identity, $\mathcal{CSP}$ calculates $X_f=h(I{D}_f\parallel x),$$Y_f=X_f\oplus I{D}_f$ and selects $TI{D}_f$. $\mathcal{CSP}$ stores $I{D}_f$ in its database corresponding to $TI{D}_f$ using x, and transmits $\{Y_f,TI{D}_f\}$ to the fog-node via a secure channel.

2:

After taking the message from $\mathcal{CSP}$, ${\mathcal{FN}}_f$ stores $\{Y_f,TI{D}_f\}$ in its tamper-proof device.

3.3. Login and Authentication Phase

This phase of proposed protocol finishes with the below-mentioned subsections taken by all the participants:

• Step#1 • Login:
  • ${\mathcal{U}}_k$ inputs its identity and computes $(Y_k\parallel r_k)=\overline{Y_k}\oplus I{D}_k$, $RI{D}_k=h(I{D}_k\oplus r_k)$, $X_k^{\prime }=Y_k\oplus RI{D}_k$. After that, ${\mathcal{U}}_k$ verifies $Z_k\stackrel{?}{=}h(X_k^{\prime }\parallel I{D}_k\parallel TI{D}_k\parallel RI{D}_k)$. If the condition is true, ${\mathcal{U}}_k$ generates arbitrary numbers $r_3$, $r_4$ and calculates $M_1=(r_3\parallel r4)\oplus X_k^{\prime }$, $aut{h}_k=h(I{D}_k\parallel I{D}_{csp}\parallel X_k\parallel r_4)$ and forwards the login request message $\{M_1,TI{D}_k,aut{h}_k\}$ towards ${\mathcal{FN}}_f$. Otherwise, the login request by ${\mathcal{U}}_k$ is rejected. ${\mathcal{U}}_k\to {\mathcal{FN}}_f:\{M_1,TI{D}_k,aut{h}_k\}$.
• Step#2 • Login:
  • After receiving the authentication request from ${\mathcal{U}}_k$, ${\mathcal{FN}}_f$ generates an arbitrary numbers $r_5$, $r_6$ and computes $X_f^{\prime }=I{D}_f\oplus Y_f$, $M_2=(r_5\parallel r_6)\oplus X_f^{\prime }$, $aut{h}_f=h(I{D}_f\parallel I{D}_{csp}\parallel X_f^{\prime }\parallel r_6)$. ${\mathcal{FN}}_f$ forwards $\{M_1,M_2,TI{D}_k,TI{D}_f,aut{h}_k,aut{h}_f\}$ to the $\mathcal{CSP}$. ${\mathcal{FN}}_f\to \mathcal{CSP}:\{M_1,M_2,TI{D}_k,TI{D}_f,aut{h}_k,aut{h}_f\}$.
• Step#3 • Authentication & Key Establishment:
  • After receiving the authentication request message from ${\mathcal{FN}}_f$, $\mathcal{CSP}$ extracts user’s $I{D}_k$ corresponding to $TI{D}_k$ from its database using x, and determines $X_k=h(I{D}_x\parallel x)$, $(r_3\parallel r_4)=X_k\oplus M_1$. For authenticating the user, $\mathcal{CSP}$ verifies $aut{h}_k\stackrel{?}{=}h(I{D}_k\parallel I{D}_{csp}\parallel X_k\parallel r_4)$. If the condition is false, the current session will be ended. Otherwise, $\mathcal{CSP}$ extracts fog-node $I{D}_f$ corresponding to $TI{D}_f$ from its database using x, and determines $X_f=h(I{D}_f\parallel x)$, $(r_5\parallel r_6)=X_f\oplus M_2$. Now, for authenticating the fog-node, $\mathcal{CSP}$ verifies $aut{h}_f\stackrel{?}{=}h(I{D}_f\parallel I{D}_{csp}\parallel X_f\parallel r_6)$. If this condition is wrong, the session will be aborted. Once the aforementioned conditions are true, $\mathcal{CSP}$ then generates an arbitrary number $r_7\in Z_p^{*}$ and computes $N_1=r_3\oplus (r_5\parallel r_7)$, $N_2=r_5\oplus (r_3\parallel r_7)$, $S{K}_{k-f-csp}=h((r_3\oplus r_5\oplus r_7)\parallel N_1\parallel I{D}_{csp})$, $aut{h}_{csp1}=h(I{D}_k\parallel I{D}_{csp}\parallel X_k\parallel S{K}_{k-f-csp}\parallel r_4\parallel r_7)$ $aut{h}_{csp2}=h(I{D}_f\parallel I{D}_{csp}\parallel X_f\parallel S{K}_{k-f-csp}\parallel r_6\parallel r_7)$. Furthermore, $\mathcal{CSP}$ selects $TI{D}_k^{new}$ for the user and $TI{D}_f^{new}$ for the fog-node and computes $Q_k=r_4\oplus TI{D}_k^{new}$, $Q_f=r_6\oplus TI{D}_f^{new}$ and updates the value of $TI{D}_k^{new}$ and $TI{D}_f^{new}$ for the user and the fog-node in its database and transmits the response message $\{N_1,N_2,Q_k,Q_f,aut{h}_{csp1},aut{h}_{csp2}\}$ to the ${\mathcal{FN}}_f$. $\mathcal{CSP}\to {\mathcal{FN}}_f:\{N_1,N_2,Q_k,Q_f,aut{h}_{csp1},aut{h}_{csp2}\}$.
• Step#4 • Key Establishment:
  • On receiving the response message from $\mathcal{CSP}$, ${\mathcal{FN}}_f$ computes $(r_3\parallel r_7)=N_2\oplus r_5$, $S{K}_{k-f-csp}=h((r_3\oplus r_5\oplus r_7)\parallel N_1\parallel I{D}_{csp})$. Furthermore, ${\mathcal{FN}}_f$ authenticates $\mathcal{CSP}$ by verifying $aut{h}_{csp2}^{\prime }\stackrel{?}{=}h(I{D}_f\parallel I{D}_{csp}\parallel X_f\parallel S{K}_{k-f-csp}\parallel r_6\parallel r_7)$. If this condition is wrong, the current session will be ended. Otherwise, it will calculate $TI{D}_f^{new}=Q_f\oplus r_6$ and update the value of $TI{D}_k^{New}$ in the tamper-proof device ${\mathcal{TPD}}_k$ of the fog-node and relays $\{N_1,Q_k,aut{h}_{csp1}\}$ to ${\mathcal{U}}_k$. ${\mathcal{FN}}_f\to {\mathcal{U}}_k:\{N_1,Q_k,aut{h}_{csp1}\}$.
• Step#5 • Key Establishment:
  • On receiving the response message from ${\mathcal{FN}}_f$, ${\mathcal{U}}_k$ computes $(r_5\parallel r_7)=N_1\oplus r_3,$$S{K}_{k-f-csp}=h((r_3\oplus r_5\parallel r7)\parallel N_1\parallel I{D}_{csp})$. Moreover, ${\mathcal{U}}_k$ authenticates $\mathcal{CSP}$ by verifying $aut{h}_{csp1}\stackrel{?}{=}h(I{D}_k\parallel I{D}_{csp}\parallel X_k\parallel S{K}_{k-f-csp}\parallel r_4\parallel r_7)$. If this condition goes wrong, the current session will be ended. Otherwise, it will calculate $TI{D}_k^{new}=Q_k\oplus r_4$ and update the value of $TI{D}_k^{New}$ in the user tamper-proof device.

3.4. User Revocation Phase

Several circumstances in the fog computing system require the ${\mathcal{U}}_k$ revocation mechanism to revoke a compromised ${\mathcal{U}}_k$’s account from the system. Assume that once a ${\mathcal{U}}_k$’s memory device is lost, ${\mathcal{U}}_k$ revokes their account with $\mathcal{CSP}$ using the same $I{D}_k$. The mentioned points are critical to execute the user revocation phase:

1:

${\mathcal{U}}_k$ randomly chooses a new $r_k^{new}\in Z_p^{*}$, identity $I{D}_k$ and computes $RI{D}_k^{new}=h(I{D}_k\oplus r_k^{new})$. ${\mathcal{U}}_k$ sends $I{D}_k,RI{D}_k^{new}$ to $\mathcal{CSP}$ using a private channel.

2:

After getting ${\mathcal{U}}_k^{\prime }s$ request, $\mathcal{CSP}$ computes the following values $X_k=h(I{D}_k\parallel x),$$Y_k^{new}=RI{D}_k^{new}\oplus X_k$. Afterwords, $\mathcal{CSP}$ selects $TI{D}_k^{new}$ for the respective ${\mathcal{U}}_k$ and calculates $Z_k^{new}=h(X_k\parallel I{D}_k\parallel TI{D}_k^{new}\parallel RI{D}_k^{new})$ and stores $I{D}_k$ in its database corresponding to $TI{D}_k^{new}$ using x. $\mathcal{CSP}$ then transmits $\{Y_k^{new},TI{D}_k^{new},Z_k^{new}\}$ to ${\mathcal{U}}_k$ via a private channel.

3:

After getting the message from $\mathcal{CSP}$, ${\mathcal{U}}_k$ computes $\overline{Y_k^{new}}=(Y_k^{new}\parallel r_k)\oplus I{D}_k$ and stores

$\{\overline{Y_k^{new}},Z_k^{new},TI{D}_k^{new}\}$ in its tamper-proof device.

4. Security Analysis

In this section, the security of the fog-based proposed protocol for an IoT healthcare environment is analyzed. The proposed protocol is evaluated formally and informally to determine its security strength. A detailed description of the security features is described in subsections.

4.1. Informal Security Analysis

This analysis shows that the proposed protocol is secure against different attacks. Furthermore, it shows that the proposed protocol achieves mutual authentication and ensures user anonymity.

4.1.1. Providing Mutual Authentication

In our proposed protocol, both participants ${\mathcal{U}}_k$ and $\mathcal{CSP}$ mutually authenticate each other to ensure their legitimacy. $\mathcal{CSP}$ authenticates ${\mathcal{U}}_k$ by checking whether $aut{h}_k\stackrel{?}{=}h(I{D}_k\parallel I{D}_{csp}\parallel X_k\parallel r_4)$ holds or not. Any adversary cannot pass this check, as he cannot compute valid $X_k=h(I{D}_k\parallel x)$, because it involves the secret key x of $\mathcal{CSP}$. So, $\mathcal{CSP}$ only authenticates the legitimate user ${\mathcal{U}}_k$. Likewise, ${\mathcal{U}}_k$ authenticates $\mathcal{CSP}$ while checking $aut{h}_{csp1}^{\prime }\stackrel{?}{=}h(I{D}_k\parallel I{D}_{csp}\parallel x_k\parallel s{k}_{k-f-csp}\parallel r_4\parallel r_7)$. The valid $\mathcal{CSP}$ can pass this check because an adversary cannot know the value $I{D}_{csp}$ of the legitimate $\mathcal{CSP}$. Furthermore, an adversary cannot compute $X_k$ because he does not have any knowledge of server’s secret key. Hence, the proposed protocol provides mutual authentication among ${\mathcal{U}}_k$ and $\mathcal{CSP}$.

4.1.2. Providing User Anonymity and Untraceability

User anonymity is considered an important security feature while designing authenticated key agreement protocols. The proposed protocol ensures the anonymity of user because instead of transmitting the identity $I{D}_k$ of ${\mathcal{U}}_k$ in plain text over a public channel, $TI{D}_k$ is forwarded, which is randomly selected by $\mathcal{CSP}$ and not known to any adversary. Similarly, in every session, dynamic $TI{D}_k$ is transmitted over a public channel. Therefore, no adversary can determine the identity of user. Consequently, the devised protocol is resistant to traceability attacks.

4.1.3. Resisting Tamper-Proof Device Stolen Attacks

The ${\mathcal{U}}_k$ holds $\{\overline{Y_k},Z_k,TI{D}_k\}$ in a tamper-proof device $TP{D}_k$. It is quite possible that an adversary can steal $TP{D}_k$, extract all the values stored in it and initiate a valid request message. In our proposed protocol, an adversary cannot compute a valid login request message even after stealing $TP{D}_k$. If an adversary wants to calculate a valid login request message $\{M_1,TI{D}_k,aut{h}_k\}$, he will have to compute a valid $aut{h}_k$. The computation of $aut{h}_k=h(I{D}_k\parallel I{D}_{csp}\parallel X_k^{\prime }\parallel r_4)$ is not possible for an adversary as he can neither compute the valid value of $X_k^{\prime }$, nor can he retrieve the value of the random number $r_4$. Further, the adversary does not know the identity $I{D}_k$ of $U_k$. So, the proposed protocol is secure against tamper-proof device stolen attacks.

4.1.4. Resisting User Masquerading Attacks

In the proposed protocol, legitimate user ${\mathcal{U}}_k$ sends the login request message to ${\mathcal{FN}}_f$, and ${\mathcal{FN}}_f$ relays the message $\{M_1,M_2,TI{D}_k,TI{D}_f,aut{h}_k,aut{h}_f\}$ towards $\mathcal{CSP}$. Suppose an adversary intercepts the login request message $\{M_1,TI{D}_k,aut{h}_k\}$ initiated by ${\mathcal{U}}_k$ and tries to impersonate the legal user ${\mathcal{U}}_k$. In our proposed protocol, even after breaching the login request message $\{M_1,TI{D}_k,aut{h}_k\}$, ${\mathcal{A}}_{att}$ cannot compute a valid $aut{h}_k$, as the computation of an $aut{h}_k$ requires the $I{D}_k$ of ${\mathcal{U}}_k$ which is unknown to ${\mathcal{A}}_{att}$. So, ${\mathcal{A}}_{att}$ cannot masquerade as the legitimate user.

4.1.5. Resisting Fog-Node Masquerading Attacks

During the login and authentication phase of proposed protocol, fog-node ${\mathcal{FN}}_f$ transmits a message $\{M_1,M_2,TI{D}_k,TI{D}_f,aut{h}_k,aut{h}_f\}$ towards cloud service provider $\mathcal{CSP}$. As the message is transmitted over a public channel, ${\mathcal{A}}_{att}$ can intercept this message and try to impersonate the ${\mathcal{FN}}_f$. Therefore, in order to impersonate the fog-node ${\mathcal{FN}}_f$ successfully, ${\mathcal{A}}_{att}$ needs to re-generate the message $\{M_1,M_2,TI{D}_k,TI{D}_f,aut{h}_k,aut{h}_f\}$. It is obvious from Section 4.1.4 that ${\mathcal{A}}_{att}$ cannot compute a valid $aut{h}_k$, as it involves the $I{D}_k$ of ${\mathcal{U}}_k$, which is unknown to ${\mathcal{A}}_{att}$. Likewise, the computation of $aut{h}_f$ is also not possible for ${\mathcal{A}}_{att}$, due to the involvement of $I{D}_f$. Therefore, it is quite impossible for ${\mathcal{A}}_{att}$ to re-generate the message $\{M_1,M_2,TI{D}_k,TI{D}_f,aut{h}_k,aut{h}_f\}$. So, the impersonation of ${\mathcal{FN}}_f$ is not possible in our proposed protocol.

4.1.6. Resisting Cloud Service Provider Masquerading Attacks

In the proposed protocol, $\mathcal{CSP}$ transmits the challenge message towards ${\mathcal{U}}_k$ through ${\mathcal{FN}}_f$. Suppose an adversary intercepts the challenge message; even then, he cannot impersonate the valid $\mathcal{CSP}$. Although ${\mathcal{A}}_{att}$ can compute all the other values of challenge message, he cannot compute a valid $aut{h}_{csp1}$ and $aut{h}_{csp2}$. The computation of $aut{h}_{csp1}$ and $aut{h}_{csp2}$ needs the calculation of valid $X_k$ and $X_f$ which is only possible with secret key x of $\mathcal{CSP}$. As, x is not known to ${\mathcal{A}}_{att}$, so ${\mathcal{A}}_{att}$ cannot impersonate valid $\mathcal{CSP}$. This is how our protocol resists a $\mathcal{CSP}$ masquerading attack.

4.1.7. Stolen-Verifier Attacks

In the proposed protocol, $\mathcal{CSP}$ maintains a database to store the identities $\{I{D}_k,I{D}_f\}$ of ${\mathcal{U}}_k$ and ${\mathcal{FN}}_f$, respectively. However, the real identities of ${\mathcal{U}}_k$ and ${\mathcal{FN}}_f$ are encrypted using the private key x of $\mathcal{CSP}$. Since x is the private key of $\mathcal{CSP}$, which is only known to $\mathcal{CSP}$, ${\mathcal{A}}_{att}$ cannot extract $\{I{D}_k,I{D}_f\}$. Hence, our protocol resists stolen verifier attacks.

4.1.8. Resisting Known Session Key Attacks

During the computation of session key ${\mathcal{SK}}_{k-f-csp}=h((r_3\oplus r_5\oplus r_7)\parallel N_1\parallel I{D}_{csp}),$ session specific random numbers $r_3$, $r_5$ and $r_7$ are used. So, the computed session key of each session is not dependent on any other session. Therefore, even if the session key of one session is leaked, there will be no impact on the privacy of other session keys.

4.1.9. Perfect Forward and Backward Secrecy

It is clearly mentioned in Section 4.1.8 that even the leakage of one session key does not impact upon the privacy of upcoming/previous session keys. Therefore, the devised protocol offers perfect backward as well as forward secrecy.

4.2. Formal Security Analysis

In this subsection, the formal security analysis of the proposed protocol is discussed using random oracle model (ROM) and automated validation of internet security protocols and applications (AVISPA).

Random Oracle Model

In this subsection, the formal security analysis of the proposed protocol is discussed using the following theorem.

Theorem 1. 

Let P denote the proposed protocol. If an adversary ${\mathcal{A}}_{att}$ wins the AKA attack game, having advantage $Adv{t}_p^{AKA}\left({\mathcal{A}}_{att}\right)$, then there must be a polynomial time algorithm that can solve the $DBDH$ hard problem with following:

$$\begin{array}{c}\hfill Adv{t}_{G{m}_1,G{m}_2}^{DBDH}\le \frac{1}{q_{sd}}Adv{t}_p^{AKA}\left({\mathcal{A}}_{att}\right)-\\ \hfill \frac{{\Sigma }_{a=0}^{a=4}{q}_{ha}^2+{(q_{sn}+q_{ex})}^2}{2p{q}_{sn}}+\frac{q_{h5}}{p{q}_{sn}}+\frac{2q_{h0}{q}_{h3}}{p^2{q}_{sn}}\end{array}$$

(1)

whereas $q_{ha}=(a=0,1,2,3,4,5),q_{sn},q_{ex},q_{rv}$ indicates the time of $Hash,Send,Execution$, and $Reveal$ queries, respectively.

Proof. 

Let ${\mathcal{A}}_{att}$ be an attacker who attacks on protocol and wins the game with an advantage of $\epsilon$. A challenger C is constructed, who solves $DBDH$ problem instance $(P,SP,YP,VP,h)$ for some unknown $s,t,v\epsilon Z_p^{*}$ and $h\epsilon G_2$, to decide if $h=e{(P,P)}^{stv}$ holds or not. All the hash functions of the proposed protocol are simulated as random oracles, and C established a hash list $L_{Hash}$ which is initialized as an empty list. Message (a = 1,2,3,4) indicates the messages that are being transmitted by the entities during protocol’s execution. C chooses $r_k\epsilon Z_p^{*}$ randomly and publishes $RI{D}_k=h(I{D}_k\oplus r_k)$; C also sets identities $I{D}_k$, $I{D}_f$ for the user and fog-node. C runs the proposed protocol and answers the following queries of $A_{att}^{{}^{\prime }s}$ oracle. □

Send query: ${\mathcal{A}}_{att}$ initiates an active attack and using different $Send$ queries forwards the messages. Four different $Send$ queries are available to ${\mathcal{A}}_{att}$, which are as follows:

• $Send$ (${\mathcal{U}}_k^i(F{N}_f,START))$: After getting the query, C initiates a new session and returns the login message produced by the user. Particularly, C chooses $r_3$ and $r_4$ randomly and computes $M_1=(r_3\parallel r_4)\oplus X_k^{\prime }, aut{h}_k=h(I{D}_k\parallel I{D}_{csp}\parallel X_k^{\prime }\parallel r_4).$ Moreover, C returns $\{M_1,TI{D}_k,aut{h}_k\}$ to ${\mathcal{A}}_{att}$, and ${\Pi }_c^i$ is set to an expecting state.
• $Send$($F{N}_f^j,Messag{e}_1$): After getting this query, C first breaks the $Messag{e}_1$ into $(M_1,TI{D}_k,aut{h}_k),$ picks $r_5,r_6$, and computes $X_f^{\prime }=I{D}_f\oplus Y_f$, $M_2=(r_5\parallel r_6)\oplus X_f^{\prime }$, $aut{h}_f=h(I{D}_f\parallel I{D}_{csp}\parallel X_f^{\prime }\parallel r_6)$. Then C returns $\{M_1,M_2,TI{D}_k,TI{D}_f,aut{h}_k,aut{h}_f\}$ to ${\mathcal{A}}_{att}$ and sets ${\Pi }_{FN}^j$ to an expecting state.
• $Send$(${\mathcal{CSP}}^k,Messag{e}_2$): After getting this query, C breaks the $Messag{e}_2$ into $\{M_1,M_2,TI{D}_k,TI{D}_f,aut{h}_k,aut{h}_f\}$ and computes $aut{h}_k^{\prime }$ and $aut{h}_f$ and checks either $aut{h}_k^{\prime }\stackrel{?}{=}h(I{D}_k\parallel I{D}_{csp}\parallel X_k\parallel r_4)$ and $aut{h}_f\stackrel{?}{=}h(I{D}_f\parallel I{D}_{csp}\parallel X_f\parallel r_6)$ holds or not. If not, $A_{att}^{{}^{\prime }s}$ query is rejected by C and returns nothing. Else, C picks $r_7$ and calculates $(N_1,N_2,{\mathcal{SK}}_{k-f-csp},aut{h}_{cs{p}_1},aut{h}_{cs{p}_2},Q_k,Q_f)$ and sends $\{N_1,N_2,Q_k,Q_f,aut{h}_{cs{p}_1},aut{h}_{cs{p}_2}\}$ to ${\mathcal{A}}_{att}$ and instance $csp$ terminates.
• $Send$($F{N}_f^j,Messag{e}_3$): After getting this query, it is assumed that ${\Pi }_{F{N}_f}^j$ is in an expecting state, and determines if $aut{h}_{cs{p}_2}^{\prime }\stackrel{?}{=}h(I{D}_f\parallel I{D}_{csp}\parallel X_f\parallel {\mathcal{SK}}_{k-f-csp}\parallel r_6\parallel r_7)$ holds or not, If not, then C rejects ${\mathcal{A}}_{att}^{\prime }s$ query otherwise C returns back $\{N_1,aut{h}_{cs{p}_1},Q_k\}$ to ${\mathcal{A}}_{att}$ and fog instance terminates.
• $Send$(${\mathcal{U}}_k^i,Messag{e}_4$): After getting this send query, it is supposed that ${\Pi }_{{\mathcal{U}}_k}^i$ is in an expecting state, C breaks $Messag{e}_4$ into $\{N_1,Q_k,aut{h}_{csp1}\}$ which verifies $aut{h}_{cs{p}_1}^{\prime }\stackrel{?}{=}h(I{D}_k\parallel I{D}_{csp}\parallel X_k\parallel {\mathcal{SK}}_{k-f-csp}\parallel r_4\parallel r_7)$. If this condition does not hold then C rejects ${\mathcal{A}}_{att}^{\prime }s$ query and returns nothing. Otherwise, C calculates $TI{D}_f^{new}=Q_k\oplus r_4$ and the instance of the client is accepted and terminated. Furthermore, $\{Messag{e}_1,Messag{e}_2,Messag{e}_3,Messag{e}_4\}$ are added to list.

Corrupt query: In order to obtain the long term key of user, an adversary initiates this query.

Upon receiving corrupt $(C,DB),$ the information stored in the database protected with secret key x is returned.

Execute (${\mathcal{U}}_{\mathbf{k}}^{\mathbf{i}},{\mathbf{F}\mathbf{N}}_{\mathbf{f}}^{\mathbf{j}},{\mathcal{CSP}}^{\mathbf{k}}$): On this query, the execution process of proposed protocol is simulated by C after issuing the following $Send$ queries.

$$Send\left({\mathcal{U}}_k^i\right(F{N}_f,START))$$

$$Send\left(F{N}_f^j,Messag{e}_1\right)$$

$$Send\left({\mathcal{CSP}}^k,Messag{e}_2\right)$$

$$Send\left(F{N}_f^j,Messag{e}_3\right)$$

and C returns $\{Messag{e}_1,Messag{e}_2,Messag{e}_3,Messag{e}_4\}$ to ${\mathcal{A}}_{att}$.

Reveal ${\Pi }_{\mathbf{p}}^{\mathbf{a}}$: On receiving this query, C responds with a session key if instance ${\Pi }_l^a$ is accepted; otherwise, it returns ⊥.

Test query: On receiving the test query $\left({\mathcal{U}}_k^i\right)$, C chooses $\tau \epsilon \{0,1\}$. If $\tau =1$, then C gives back the true session key; otherwise, it return a the random value of similar size. The above said proof is compared on sequence games $G{m}_0,G{m}_1,G{m}_2,G{m}_3,G{m}_4,G{m}_5$. Let $S_a$ be the event that ${\mathcal{A}}_{att}$ outputs the correct $\tau$ in game $G{m}_a$ (a = 0,1,2,3,4).

Game$\mathit{G}{\mathit{m}}_{\mathbf{0}}$: $G{m}_0$ is the actual attacking game. Just like a real player, C simulates the oracle queries in this game. The chances of success in this game are quite equal to the probability that ${\mathcal{A}}_{att}$ succeeds in attacking the proposed protocol and obtains the following:

$$\begin{array}{c}\hfill \epsilon =|2P_r\left[S_0\right]-1|\end{array}$$

(2)

Game$\mathit{G}{\mathit{m}}_{\mathbf{1}}$: This game is identical to $G{m}_0$. The difference is that C maintains a list of values $L_0-L_5$. C searches the related list when the hash oracle is queried. If there exists any entry, then the same value is returned; otherwise, C returns the random value and inserts it into corresponding list $L_i$. It is visible and concluded here from the properties of oracle that $G{m}_1$ is indistinguishable from $G{m}_0$. Therefore:

$$\begin{array}{c}\hfill P_r\left[S_1\right]=P_r\left[S_0\right]\end{array}$$

(3)

Game $\mathit{G}{\mathit{m}}_{\mathbf{2}}$: This game is identical to $G{m}_1$. The difference is that in this game, the simulation of all queries will be terminated only if the following two events occur:

• Event (${\mathit{E}}_{\mathit{A}}$): Collision on the result hash queries.
• Event (${\mathit{E}}_{\mathit{B}}$): Collision on the copy of all messages ($Messag{e}_1,Messag{e}_2,Messag{e}_3,Messag{e}_4$).

As per the the definition of birthday paradox:

$$\begin{array}{c}\hfill P_r\left[E_a\right]\le {\Sigma }_{a=0}^{a=4}\frac{q_{ha}^2}{2_p}\end{array}$$

(4)

Since a,b,c are randomly chosen, the probability of $E_B$ happening is $P_r\left[E_b\right]\le \frac{{(q_{sn}=q_{ex})}^2}{2p}$, where $q_{sn}$ and $q_{ex}$ are upper bound of the $Send$ and $Execute$ queries, respectively. Therefore, we have:

$$\begin{array}{c}\hfill |P_r\left[S_2\right]-P_r\left[S_1\right]|\le ({\Sigma }_{a=0}^{a=4}{q}_{ha}^2+{(q_{sn}+q_{ex})}^2|\left(2p\right))\end{array}$$

(5)

Game $\mathit{G}{\mathit{m}}_{\mathbf{3}}$: In this game, the send query is modified. C picks an instance (${\mathcal{U}}_k^i,F{N}_f^j,{\mathcal{CSP}}^k$) and answers ${\mathcal{A}}_{att}^{\prime }s$$Send$ queries as follows:

• When ${\mathcal{A}}_{att}$ initiates a $Send$ (${\mathcal{U}}_k^i,(F{N}_f,START$)) query, C generates $\{M_1,TI{D}_k,aut{h}_k\}$ and forwards $Messag{e}_1=\{M_1,TI{D}_k,aut{h}_k\}$ to ${\mathcal{A}}_{ah}$.
• When ${\mathcal{A}}_{att}$ generates a $Send$ query $(F{N}_f^j,Messag{e}_1)$, C generates a message $\{M_1,M_2,TI{D}_k,TI{D}_f,aut{h}_k,aut{h}_f\}$ to ${\mathcal{A}}_{att}$.
• When ${\mathcal{A}}_{att}$ initiates a $Send$ query $({\mathcal{CSP}}^k,Messag{e}_2)$, C sets $S{k}_{k-f-csp}=h((r_3\oplus r_5\oplus r_7)\parallel N_1\parallel I{D}_{csp})$ and terminates the instance.
• When ${\mathcal{A}}_{att}$ initiates a $Send$ query ($F{N}_f^j,Messag{e}_3$), C sets $(r_3\parallel r_7)=N_2\oplus r_5$ and returns message $\{N_1,Q_k,aut{h}_{cs{p}_1}\}$ to ${\mathcal{A}}_{att}$. It is demonstrated that if the hard assumption $DBDH$ holds, then the difference between $G{m}_2$ and $G{m}_3$ is ignorable, just as follows:

$$\begin{array}{c}\hfill |P_r\left[S_3\right]-P_r\left[S_2\right]|\le q_{sn}Adv{t}_{G{m}_1,G{m}_2}^{DBDH}\end{array}$$

(6)

If there is a differentiator which can easily differentiate $G{m}_2$ and $G{m}_3$, then C can solve the $DBDH$ problem by using a differentiator. In the case that the differentiator interacts with $G{m}_2$, then C outputs 1; otherwise, it outputs 0. So, we get $Adv{t}_{G{m}_1,G{m}_2}^{DBDH}\le \left(\frac{1}{q_{sn}}\right)|P_r\left[S_3\right]-P_r\left[S_2\right]$, and Equation (5) holds; the ${\mathcal{A}}_{att}$ can easily differentiate the true and random session key because the values used in $G{m}_3$ are random. This can only be possible if the following events occur.

• Event (${\mathit{E}}_{\mathit{C}}$): ${\mathcal{A}}_{att}$ queried $h_5$ oracle, which has probability of

  $$\begin{array}{c}\hfill P_r\left[E_c\right]=q_{h5}|P\end{array}$$

  (7)
• Event (${\mathit{E}}_{\mathit{D}}$): ${\mathcal{A}}_{att}$ impersonates the user by forging the $messag{e}_1=\{M_1,TI{D}_k,aut{h}_k\}$ which posseses the verification executed by $\mathcal{CSP}$. The probability of generating a valid $Messag{e}_1$ by ${\mathcal{A}}_{att}$ is:

  $$\begin{array}{c}\hfill P_r\left[E_D\right]\le \frac{q_{ho}}{p}.\frac{q_{h1}}{p}=\frac{q_{h_0}{q}_{h_3}}{p^2}\end{array}$$

  (8)
• Event (${\mathit{E}}_{\mathit{E}}$): ${\mathcal{A}}_{att}$ successfully impersonates the fog-node by forging $Messag{e}_2$, which passes the verification executed by $\mathcal{CSP}$. Like Event $E_D$, the probability of generating a valid $Messag{e}_2$ by ${\mathcal{A}}_{att}$ is:

  $$\begin{array}{c}\hfill P_r\left[E_E\right]\le \frac{q_0}{p}.\frac{q_{h_3}}{p}=\frac{q_{h_0}{q}_{h_3}}{p^2}\end{array}$$

  (9)

Then:

$$\begin{array}{c}\hfill P_r\left[S_3\right]\le \frac{1}{2}+\frac{q_{h_5}}{p}+\frac{2q_{h_0}{q}_{h_3}}{p^2}\end{array}$$

(10)

Using Equations (1) to (5) and (9):

$$\begin{array}{c}\hfill Adv{t}_p^{AKA}\left({\mathcal{A}}_{ah}\right)\le {\Sigma }_{a=0}^{a=4}\frac{q_{ha}^2={(q_{sn}+q_{ex})}^2}{2p}+\frac{q_{h5}}{P}+\\ \hfill \frac{2q_{h_0}{q}_{h_3}}{p^2}+q_{sn}Adv{t}_{G{m}_1,G{m}_2}^{DBDH}\end{array}$$

(11)

Hence,

$$\begin{array}{c}\hfill Adv{t}_{G{m}_1,G{m}_2}^{DBDH}\le \frac{1}{q_{sd}}Adv{t}_p^{AKA}\left({\mathcal{A}}_{att}\right)-\\ \hfill \frac{{\Sigma }_{a=0}^{a=4}{q}_{ha}^2+{(q_{sn}+q_{ex})}^2}{2p{q}_{sn}}+\\ \hfill \frac{q_{h5}}{p{q}_{sn}}+\frac{2q_{h0}{q}_{h3}}{p^2{q}_{sn}}\end{array}$$

(12)

Now, it can be concluded from Theorem 1 that as much as the $DBDH$ problem is hard, for any challenger, it is computationally challenging to break the $AKA$ security of the proposed protocol in polynomial time.

5. Performance Comparison

This section presents the performance analysis between the proposed ITP-AKA and related competing protocols [11,12,13,17,18] in terms of communication, computation and storage overhead.

5.1. Experimental Setup

In order to calculate the computation overhead of the proposed and related competing protocols, hash function and point multiplication are only considered as cryptographic operations. These cryptographic operations are implemented separately for user ${\mathcal{U}}_k$, fog-node ${\mathcal{FN}}_f$ and cloud service provider $\mathcal{CSP}$, according to their respective devices in a controlled fog-based IoT environment, to determine their time complexity. The average values of these cryptographic operations are obtained by implementing them several times under same assumptions. The cryptographic operations that have been used at the ${\mathcal{FN}}_f$ side are implemented on Arduino, while the cryptographic operations used at the $\mathcal{CSP}$ and ${\mathcal{U}}_k$ end are implemented on a cloud server and mobile device, respectively. The specifications of Arduino, the cloud server and the mobile device are listed down in

Table 3. Specifications of devices.

Attribute	Arduino	Cloud Server	Mobile Device
Platform	-	Online cloud server	Android
System	Microcontroller: ATmega328	PythonAnywhere	Mediatek P60
RAM	SRAM: 2 KB (ATmega328)	—	6 GB
Clock Speed	16 MHz	—	2.0 GHZ
IDE	Arduino IDE	Python console	Android Studio

.

5.2. Computation Overhead

The computation overhead is computed while comparing the time required for the execution of basic cryptographic operations used in the login and authentication phase of the proposed and related protocols [11,12,13,17,18]. The notations and required execution time for each entity are listed down in

Table 4. Cryptographic Operations used for Analysis.

Execution Time	Parameter	${\mathcal{U}}_{\mathit{k}}$	$\mathcal{CSP}$	${\mathcal{FN}}_{\mathit{f}}$
Hash function	$E_{hash}$	$0.002$ ms	$0.00063$ ms	$0.192$ ms
Point multiplication	$E_m$	$0.010$ ms	$0.00087$ ms	$0.388$ ms
Encryption/decryption	$E/D$	$0.008$ ms	$0.00076$ ms	$0.259$ ms

, whereas the detailed comparison of computation overhead among the proposed and related protocols is shown in

Table 5. Comparison of computation and communication overhead.

Protocols	${\mathcal{U}}_{\mathit{k}}$	$\mathcal{CSP}$	${\mathcal{FN}}_{\mathit{f}}$	Aggregated Computation Overhead	Aggregated Communication Overhead
Ours	$5E_{hash}$	$7E_{hash}$	$3E_{hash}$	0.5904 ms	3744 bits
Jia et al. [12]	$5E_{hash}+2E_m$	$9E_{hash}+3E_m$	$4E_{hash}+2E_m$	1.5823 ms	4064 bits
Chen et al. [13]	$16E_{hash}+2E_m$	$11E_{hash}$	$10E_{hash}+3E_m$	3.1449 ms	4832 bits
Ma et al. [11]	$4E_{hash}+3E_m$	$9E_{hash}+8E_m$	$4E_{hash}+4E_m$	2.3706 ms	4254 bits
Sahoo et al. [17]	$10E_{hash}+2E_m$	$6E_{hash}+1E_m$	$4E_{hash}$	1.5825 ms	2560 bits
Ever [18]	$3E_{hash}+1E/D$	$3E_{hash}+2E/D$	$2E_{hash}+2E/D$	0.91771 ms	1120 bits

.

5.3. Communication Overhead

The communication overhead of the proposed ITP-AKA and related protocols [11,12,13,17] is determined on the basis of messages that are transmitted among the participating entities of respective protocols. In the proposed ITP-AKA, during the login phase, message $\{M_1,TI{D}_k,aut{h}_k\}$ needs $(256+160+256)=672$ bits, whereas the messages $\{M_1,M_2,TI{D}_k,TI{D}_f,aut{h}_k,aut{h}_f\}$, $\{N_1,N_2,Q_k,Q_f,aut{h}_{cs{p}_1},aut{h}_{cs{p}_2}\}$ and $\{N_1,Q_k,aut{h}_{cs{p}_1}\}$ transmitted during the authentication and key-establishment phase need $(256+256+160+160+256+256)=1344, (160+160+160+160+256+256)=1152$ and $(160+160+256)=576$ bits, respectively. So, the accumulative communication overhead of ITP-AKA is (672 + 1344 + 1152 + 576) = 3744 bits. Furthermore, the communication overhead of all related protocols [11,12,13,17,18] is computed in the same way. The communication overheads of Jia et al. [12], Chen et al. [13], Ma et al. [11], Sahoo et al. [17] and Ever [18] are 4064 bits, 4832 bits, 4254 bits, 2560 bits and 1120 bits, respectively. The comparative analysis of communication overhead reveals that the communication overhead of proposed protocol is less than all related competing protocols except [17,18]. The complete communication overhead comparison among the proposed and related competing protocols is presented in Table 5.

Table 6. V of security and functionality.

Protocols →	Ours	[12]	[13]	[11]	[17]	[18]
Security Features ↓
Provides mutual authentication	✓	✗	✓	✓	✓	✓
Provides user anonymity	✓	✓	✗	✓	✓	✓
Resists tamper-proof device stolen attack	✓	✓	✗	✓	✓	✓
Resists user masquerading attack	✓	✓	✗	✗	✗	✗
Resists fog-node masquerading attack	✓	✓	✗	✗	✗	✗
Resists cloud server-provider masquerading attack	✓	✗	✗	✗	✓	✗
Resists stolen-verifier attack	✓	✓	✗	✗	✗	✓
Free from clock synchronization problem	✓	✗	✗	✗	✗	✗
Ephemeral secret leakage (ESL) attack	✓	✗	✓	✓	✗	✓
Resists insider attack	✓	✗	✗	✗	✓	✓
Resists known session key attack	✓	✗	✗	✓	✗	✓

✗: Attribute is not satisfied/claimed, ✓: Attribute is satisfied.

demonstrates that the designed protocol provides more security and functionality features than the related competing protocols.

6. Conclusions

There are numerous applications of fog computing, ranging from normal to specific. Hence, the potential for offering privacy and security with fog-driven deployment is indispensably significant. In this article, an identity based three-party authenticated and key agreement protocol is proposed for a fog-driven IoT healthcare system. The proposed protocol is efficiently resists numerous known security attacks, as shown in Section 4. The performance analysis demonstrates that the proposed scheme has great potential for deployment in real-world healthcare systems; the computation cost of our protocol is $0.5904$ ms, which is less than the computation cost of related protocols. Similarly, the communication cost of the proposed protocol is less than the related protocols, except Sahoo et al. and Ever.

In the future, we will design a blockchain-assisted access control protocol for fog-driven IoT healthcare systems. The reason behind employing blockchain in such infrastructure is that patients’ healthcare information is highly sensitive and confidential. Therefore, data will be stored in the blocks; due to its strong integrity and immutable and tamper-resistant qualities, blockchain will restrict adversaries from modifying healthcare data. Moreover, the proposed protocol will be simulated in a broadly-recognized NS3-simulator tool to assess its performance from distinct network parameters (i.e., end-to-end delay, throughput, etc.).