An ECC-based lightweight remote user authentication and key management scheme for IoT communication in context of fog computing

Abstract

Fog computing is a computing structure which is distributed in nature. Low latency, reasonably low communication overhead and ability to support real time applications are the reasons for which fog computing approach said to provide better performance than cloud computing. Although, it is an extension of the cloud computing. Fog computing also inherits some critical security and privacy issues of cloud computing. Secure key management and user authentication are among the key issues faced by fog computing. Various schemes with probable solutions of these issues have been proposed by many authors in this context. Among them, a notable scheme has been presented by Wajid et al. known as SAKA-FC, where authors used three-factor authentication with privacy preservation for remote user based on ECC, hash functions, fuzzy extractor and symmetric bivariate polynomial function. This paper analyses the SAKA-FC protocol and found that it is not resilient against fog server insider attack, message intercept attack and replay attack. Consequently, an improved, lightweight and secure authentication scheme in context of fog-centric IoT communication is proposed in this paper to eradicate all the above mentioned security shortfalls of Wajid et al scheme. The proposed scheme is verified using mathematical security analysis and simulated using AVISPA which proves that the proposed scheme prevents all pertinent security threats. The performance analysis of our scheme proves its effectiveness over other related existing schemes in this context.

1 Introduction

Fog computing is defined as an augmentation of cloud computing which extends basic analytic facilities towards network edges i.e. in vicinity of the user [1,2,3,4,5,6,7].The IoT-fog communication model depicted in Fig. 1. Alike cloud, it also offers storage of data and usage of various other platforms and application-based services. The main objective of fog computing is that along with providing all benefits of cloud, it also fills the holes between remote data centers and IoT devices. Moreover, security enhancement, lower computational overhead, lower bandwidth and comparably lesser latency are the various perks of it [6, 7]. Thus, fog computing looks like a capable technology for various IoT services like smart home, smart city, smart health care, vehicular network, etc. [1,2,3,4,5,6,7,8,9,10,11,12,13]. In addition, there are other advantages of fog computing that includes better on-time communication and support for movability due to local alertness. Real-time data from the smart devices are accessed by many users in IoT and since the idea of fog computing came as augmentation of cloud computing, it inherits the similar privacy and security issues from the later. Therefore, in fog computing environment we have to deal with some serious security issues too. For example, spoofing, impersonation, insider attack, password guessing, user anonymity and many more to mention [1, 14,15,16]. Thus, these security concerns call for well-built user authentication and key management scheme for IoT communication to work over all secure as well as insecure channels in fog computing environment. Hence, only a legitimate authenticated user could gain access to system and valuable information. This paper covers deep analysis of many such recent literature on authentication and key management in fog computing context. One among them is a very relevant scheme in fog environment i.e. SAKA-FC, proposed by Wajid et al. [1]. In this paper, analysis of the Wajid et al. scheme is carried out and the prevailing security flaws have been identified and accordingly as a counter measure, a new key management and user authentication protocol for fog-centric IoT communication is proposed that can withstand all the relevant attacks.

Fig. 1

A fog computing based IoT environment [17]

Our contribution: In this paper we have thoroughly cryptanalyzed the scheme presented by Wajid et al. [1] and found that contrary to the claim by the authors in [1] the scheme is prone to some security attacks such as—(i) fog server insider attack, (ii) Message intercept attack and (iii) Replay attack. Accordingly, we have proposed an upgraded lightweight key management and authentication protocol which eradicates the above security flaws with overall better security and efficiency. In support of our claim, we have shown that our scheme achieves the desired security goals such as authentication, integrity, availability, confidentiality etc. and also resilient against all known security attacks through informal security analysis, and formal security analysis using Automated Validation of Internet Security Protocols and Applications tool (AVISPA). In addition, the performance analysis in terms of computation, communication and storage overheads shows that our scheme achieves better efficiency comparing to the relevant existing protocols available in the literature.

Outline of the paper: Sect. 2 deliberates the literature review in context of efficiency and security issues in fog-centric IoT communication. In Sect. 3, the used system model and security goals have been presented. The preliminaries of ECC and a brief review of Wajid et al. scheme SAKA-FC [1] along with its security analysis are demonstrated in Sect. 4. In Sect. 5, the proposed protocol is discussed and in Sect. 6 A thorough Scrutiny of security of our proposed scheme is being presented which includes both informal and formal security analysis. The proposed scheme is simulated using AVISPA and the results are also given in this section. After that in Sect. 7 the proposed scheme’s performance is analyzed and compared with other relevant schemes in terms of computation, communication and storage overheads and lastly, conclusion of the paper and future research direction is given in Sect. 8.

2 Literature review

In this section, several newly proposed schemes for authentication and key negotiation in IoT communication are presented. To begin with, we have studied the IoT authentication scheme proposed by Hu et al. [3] in 2017. This scheme is useful for preserving the confidentiality of data, maintain the integrity of data and ensures availability by using face identification and face resolution. In the same year, Abdul et al. [4] proposed one secure IoT authentication scheme using facial image as a biometric authentication factor. The scheme also used visual cryptography for securing the multiple sharing data and used zero watermarking technique for protecting the owner rights on multimedia contents. In addition, authors also incorporated the rewards that comes with using fog computing applications in smart traffic lighting system, smart vehicles, smart grid and also in software defined networks, etc. Since efficient method for dynamic ownership data management in fog environment is a very important aspect, Koo et al. [5] proposed an authentication scheme in this context in 2018 that preserved owner’s privacy and de-duplication of data. Later on, Wang et al. [6] proposed a secure data aggregation scheme for fog enabled public cloud that gather data from the fog node, terminal or edge nodes and are sent securely to the cloud server. After that, in 2019 Sowjanya et al. [18] proposed an ECC-based lightweight IoT communication scheme that uses key-policy attribute-based encryption (KP-ABE) with key refresh and key update techniques. On that very year Li et al. [19] have introduced a secure three-factor user authentication scheme built on ECC and used for wireless medical sensor network that ensure forward secrecy. The biometric information required for authentication is handled using fuzzy commitment scheme in this work. Moreover, in 2019 a scheme for WSN based IoT application is proposed by Harbi et al. [20] which is claimed as secure against replay attack, denial of service attack and impersonation attack, but it lacks secure mutual authentication and session key agreement. During this time Wajid et al. [1] proposed a three-factor scheme for fog-centric IoT communication environment, which can efficiently manage the cryptographic key and to authenticate the different entities involved. The scheme known as SAKA-FC, used for secure communication in fog computing environment. In the said protocol the three factors are—user password, biometrics and the mobile device. For biometric verification, authors used a fuzzy extractor technique using the user’s mobile device. Further cryptographic one-way hash function and XOR operation are used in the said protocol so that it remains lightweight and can be used for devices that are not resource-rich. Later on, in 2020 Sadhukhan et al. [15], proposed a ECC-based remote user authentication scheme which uses three-factor verification and thereby users privacy and data confidentility is protected against multiple attacks. On the other hand, authors Rostampour et al. [8] presented an efficient method for securing communication between edge devices of IoT and cloud servers in which authors used an ECC based authentication protocol. Later on in 2021, Wu et al. [9] have done thorough analysis of the scheme proposed by Jia et al. [7] and found the scheme vulnerable to various attacks. So, they proposed an authentication and key agreement scheme useful for IoT healthcare system using fog computing. But it is found that the communication overhead of Wu et al. scheme is very high therefore, overall efficiency is not praise worthy. Then, another scheme for fog based authentication in vehicular adhoc network is again proposed by Wu et al. [10] in which authors have used the fog nodes as relay nodes for mutual authentication. In order to deliver a lightweight authentication in internet of drones perspectives, Jan et al. [11] have proposed a scheme which is able to solve various long pending problems like insider attack, stolen verifier attack, etc. in this context. In another scheme, Banerjee et al. [12] have developed a failover authentication mechanism where the disconnected IoT end nodes can be smoothly reconnected and authenticated with the fog nodes. Most recently, Rangwani et al. in [13] have proposed an authentication scheme useful for cloud computing environment, where authors have also done cryptanalysis of the Wajid et al. [1] scheme. But in their proposed method authors have not considered fog computing perspective. Very recently, Ali et al. [21] have done the cryptanalysis of the Wajid et al. [1]scheme and found the proof that the scheme is prone to clogging attack and accordingly proposed a new authentication scheme for fog environment. However, Ali et al. [21] scheme is not lightweight and efficient as the computation overhead of the scheme is much higher than the Wajids SAKA-FC scheme. So, after thorough study of SAKA-FC and Ali et al. scheme, we have found there were few more security shortfalls which still remain in [1].These security shortfalls motivate us to propose a new authentication and key agreement scheme in IoT-fog computing context which is being discussed elaborately in the later part of this paper.

3 System model and security goals

The system model for our scheme and Wajid et al. scheme (SAKA-FC) is discussed in this section along with the different security requirement aspects of the proposed scheme.

3.1 System model

In the proposed scheme the same network scenario and interaction model between the entitties in Fog computing network is used as in Wazid et al. [1] (SAKA-FC scheme) have used. Here, we assume that there are initially cloud server (CS), fog server (FS) and smart devices, which are being deployed in the network and users try to get the data from the smart devices. In this scenario different type of possible communication could take place such as—(i) User to fog server communication, (ii) Device to fog server communication and (iii) Cloud server to fog server communication. Thus, for these communications, secret keys are needed to communicate securely on an insecure channel where otherwise an adversary can easily meddle with the data. So, to overcome from such situation, user needs to be authenticated to the smart device with fog server’s help. After this authentication becomes successful, session key is calculated to securely communicate between smart device and user. Also, initially a trusted agency (TA) is in-charge of registration of fog servers, cloud server and smart devices.

3.2 Security goals

Following are the security requirements that are being kept in mind while developing the proposed scheme:

Authentication: The user, FS and CS are mutually authenticated, and the smart devices are accessed by the user. Also access to a confidential resource, or giving away significant information will not be granted to unauthorized user.

Integrity: The object/entity or the message in a particular communication must not be changed/modified during the communication.

Confidentiality: Confidential/private information must not be revealed to anyone except the authorized person.

Availability: Vital network amenities must be made accessible to the authenticated users and smart devices even if the system is under the threat of Denial-of-Service (DoS) attack.

Non-repudiation: Hiding the identity of malicious unauthorize entity is prevented by this.

Authorization: It guarantees that the information provided to network services, will be only through the authorized smart devices.

4 Preliminaries

This section discusses the preliminary ideas which are essential for the proposed scheme. In this segment we describe the basics of elliptic curve cryptography and a brief review of Wajid et al. scheme.

4.1 Elliptic curve cryptography (ECC)

Neal Koblitz and Victor Miller proposed ECC in 1985 [22] and later on, it was adopted in cryptosystem which is public key based. ECC is an lightweight state-of-the-art method built upon the algebraic pattren of elliptic curves over finite fields. Due to hardness of ECC, it has rapidly risen as the standard organized and inexpensive public key cryptosystem which can provide higher security, efficiency in computation and communication. ECC algorithms have been extensively used for key management and authentication [23, 24]. ECC can be defined by the following equation [22,23,24]:

$$\begin{aligned} y^2 mod q=(x^3+ax+b) mod q \end{aligned}$$

(1)

Following operations are commonly being performed in ECC.

• Point addition: Assuming that P, Q be the two points on equation (1) . Then $P+Q=R$ where P and Q are not equal.The line through these points P and Q intersects the curve of equation (1) in the point R [22].

• Point Subtraction: If $Q= - P$, then $P + Q = P - P = 0$ then, it can be said that the line jolining P and $-P$ will intersect equation (1) at O, the point of infinity [23] .

• Point doubling: Addition of a point P with itself is Point doubling. $2P=P+P=Q$ is a point on equation (1). The tangent of the point P intersects at $-Q$ whose reflection to x- axis is Q [24].

• Scalar point multiplication: Is an operation on elliptic curve where a point is added t times with itself such as $t.P= P+P+P+\cdots +P(t times)= \sum _{1}^{n} P \$ where t $\in Z_p^*$ and t is a scalar number in the cyclic group $G_q$ [16, 25].

Benefits of ECC

• As compared to other similar cryptosystems, ECC uses smaller key size. For example, RSA cryptosystem requires 1024 bits key, contrasting to which ECC just requires 160 bits key to ensure same security level [22].

• Solving the ECC based computational problem such as elliptic curve discrete logarithm problem (ECDLP) in polynomial time is impossible [26] . Approximately $\sqrt{p}$ steps are required to solve the ECC computational problem, where p is the cardinality of that elliptic curve and is a large prime number [23].

• ECC has smaller and compressed message size to run ECC-based protocols. Due to smaller key size And faster operation, it allows less power consumption and hence, ECC-based protocols are suitable for the resource constraint devices like IoT nodes [27].

4.2 Computational hardness of ECC

ECC has the several computational hardness, two of them are listed here.

• Elliptic curve discrete logarithm problem (ECDLP): Given that, two points P and Q lie on Eq (a, b) such that P,Q $\in$ Gqand Q=k.P where k $\in Z_p^*$. In polynomial time, it is hard to find k if Q is given [15, 16, 24].

• Computational Diffie-Helmen Problem (CDHP): For any random occurrences a, b and P finding a, b is computationally very hard after the value of abP is known where (P, aP, bP)$\in$ E/Fqand a,b $\in Z_p^*$ [15, 16, 27].

4.3 Review and cryptanalysis of Wajid et al. scheme

This subsection deliberates a brief review of Wajid et al. scheme, SAKA-FC and also discusses its security flaws by doing its cryptanalysis. In the said scheme, the authors mainly used hash functions and bitwise XOR technique. The scheme tries to establish a secure communication channel between user/user’s mobile device, fog server and smart sensor devices. The said scheme has eight phases namely—(i) Pre-Deployment phase, (ii) Key management phase, (iii) User registration phase, (iv) Login phase, (v) Authentication and key agreement phase, (vi) Password and biometric update phase, (vii) New device addition phase and (viii) Mobile device revocation phase. In pre-deployment phase, the smart devices, FS and CS will be registered to the trusted agency (TA). In the next phase, a secret session key is being negotiated and thus creating a secure channel to communicate between smart device and FS, and between FS and CS for future use. In user registration phase, user registers himself to TA and later on in log in phase, user log in through her/his mobile device to get the information from the smart device. After login, initially user is authenticated to the smart device, negotiates a session key for securing the communication i.e the key management and authentication phase shown in Fig. 2. The Table 1 shows the symbols used in the Wajid et al. scheme.

Fig. 2

login and authentication phase of Wazid et al scheme [1]

Table 1 Symbol table of Wajid et al. scheme [1]

4.4 Cryptanalysis of Wajid et al. scheme SAKA-FC

A thorough cryptanalysis of secure authentication of user and key management scheme (SAKA-FC) proposed by Wajid et al. [1] is presented here and it is found that it has some security flaws, therefore, vulnerable to (i) Fog server insider attack, (ii) Message intercept attack and (iii) Replay attack. The detailed security analysis is demonstrated below:

(A) Fog Server Insider Attack: If an adversary somehow gains access to the fog server then it could easily acquire the information stored in it and then computation of the session key by the adversary would be possible. The stepwise demonstration of compromisation of the same due to fog server insider attack is given below:

Step 1: In Wajid et al. scheme the session key calculated at smart device as $SK_{ki}=h(I_j||h(TC_k||r_k)||TS_k)$ where$I_j=G_j \oplus h(K_{jk}||RID_k||TS_f).$The same session key is also calculated at server side. Thus if an adversary resided in the fog server $FS_j$ can calculate the same session key with the available components then the session key will be compromised to the adversary and thus fog server insider attack could be possible.

Step 2: In fog server side, if the adversary resides in the fog server $FS_j$ then it can easily calculate $G_j$ and $RID_k$ since all the component required to calculate $G_j$ and $RID_k$ are available in the $FS_j$ including $K_{j_k}$ and $TS_f$ . Thus, $I_j$ could be calculated by the adversary as well.

Step 3: Now the adversary can calculate $h(TC_k||r_k)$ as: $h(TC_k||r_k) =M_k \oplus (RID_k||h(RID_i)||TS_k)$ where $M_k$ is public, $RID_k$ is known by the adversary. $RID_i$ is also known by the adversary as it’s being stored by $FS_j$ in step 1 and $TS_k$ is noted down. Thus, the adversary can easily compute the session key $SK_{ki}=h(I_j||h(TC_k||r_k)||TS_k)$ using $h(TC_k||r_k)$ since all other component are available to it.

Above is the proof that the session key can be calculated by an adversary resided in the server. So, if a fog server is being captured it poses a great security risk of exposing the session key. Hence the Wajid et al. scheme is exposed to fog server insider attack.

(B) Message intercept attack: During login and authentication phase in Wajid et al. scheme [1], in the third step smart devices DK sends a message to the ui (user) via open channel: ${RID_{K_{**}}, M_k, N_k, P_f, TS_k}$ along with the message $D_K$ sends a time stamp $TS_k$ publicly. In this scenario if an adversary can capture the message and can change the timestamp to $TS_{kf}$ and send with the rest of the message normally. Upon getting the message, the user will verify the timestamp $TS_{kf}$ and it appears to be fresh. Thus, user starts computing the subsequent parts using this forged timestamp and at the end of this phase while validating using previously stored parameter it will fail the validation. Due to which a legal user will be posed as imposter and service will be denied. From the above proof, it can be said that the Wajid et al. scheme is prone to message tampering/intercept attack.

(C)Replay attack: In the Wajid et al. [1] scheme during login and authentication phase, to start a new session user $u_i$ sends a request for authentication: Msg1= $RID_{i}^{'}, R_u, a_u, E_u, F_u, TS_u$ to the fog server via open channel. Now an adversary can intercept that message of the previous session and in the next session, it can very easily change the timestamp $TS_u$ into $TS_{u}^{'}$ such that it is always pose to be fresh and retransmitted to the fog server as the original message. In the fog server side, this msg1 will be acknowledged as a fresh message request from the same user ui because the timestamp is fresh and fog server first checks the timestamp if $| TS_{u}^{'} - TS^*_u | \le \Delta T?$ If it is fresh then it starts computing other credentials and in this case the server will always find the message fresh, thus think that the message is from legitimate user and thereby adversary can easily launch a replay attack. So, we can conclude that Wajid et al. scheme is not safe from replay attack.

5 Proposed scheme

This section eradicates the inefficiencies of Wajid et al. scheme and accordingly presents an improved lightweight remote user authentication and key management scheme for IoT communication in fog computing context. The proposed scheme is comprising of six phases namely—(i) Pre-negotiation phase, (ii) Pre deployment phase, (iii) Key management phase, (iv) User registration phase, (v) User login phase and (vi) User authentication and key agreement phase. Each phase is demonstrated in following sub sections and the notations used in the proposed scheme are given in Table 2. A workflow diagram of the entire scheme is given in Fig. 3.

Table 2 Symbols used in the proposed scheme and their meaning

5.1 Pre-negotiation phase

In this subsection trusted agency (TA) picks and finalize system limitations and the steps involved in this process are as follows:

• i. An elliptic curve $E_q (a, b)$ is chosen whose equation is $y^2 mod q = (x^3 + ax + b) mod q$ over $F_q$, where $F_q$ is a large prime finite field such that $(4a^3 + 27b^2)\ne 0 mod q$ and where a, b $\in F_q.$

• ii. $E_k()/D_k()$ is chosen as the symmetric encryption/decryption algorithm in which k represents the symmetric key.

• iii. A generator P is selected of order n over $E_q (a, b)$.

• iv. Now TA publishes ${E_q (a, b), E_k()/D_k(), F(x,y), P}$.These parameters will be published as public.

• v. Each party involved in communication like, SD, FS, CS, U, TAchooses their private key as $\alpha , \gamma , \upsilon$ and $\beta$ then computes public keys as $V_{SD} = \alpha .P$, $V_{FS} = \gamma .P$, $V_{CS} = \upsilon .P$ and $V_T = \beta .P$ respectively.

5.2 Pre deployment phase

In this phase smart devices SD, fog servers (FS) and cloud servers (CS) register themselves with trusted agency (TA) prior to their deployment in the network. This phase has three subsections (i) Registration of smart device, (ii) Registration of fog server and (iii) Registration of cloud server.

5.2.1 Registration of smart device

In this phase smart device SD is registered to the trusted agency (TA). The registration method is illustrated in stepwise manner where A$\rightarrow$ B: C stands for message C is sent by A to B. It is also given in summarize form in Fig. 4.

Fig. 3

Flow diagram of the proposed scheme

Step 1: $SD \rightarrow TA$: $E_{K_{x}}( H_{SD}||A_{SD} || R_1)$

Smart device selects it’s private key $\alpha$ and calculates its public key $V_{SD} = \alpha .P$ Further, it calculates ECDH based contributory shared session key $K_{SDT }= \alpha .V_T = \alpha \beta .P=(k_x, k_y).$. Now it selects a random nonce $r_1 \in Z_p^*$ and further calculates $R_1$ as, $R_1 = r_1.V_{SD}.$ It also calculates$H_{SD}=h(ID_{SD}||V_{SD})$ and $A_{SD}=h(H_{SD}||R_1||K_{SDT}).$ After performing these operations smart device stores $\{A_{SD}, R_1, F(A_{SD} , y)\}$. Then it encrypts $H_{SD}, A_{SD}, R_1$as $E_{K_x }( H_{SD}||A_{SD} || R_1)$ and sends the encrypted registration request to TA.

After receiving the registration request message, TA calculates its shared key as $K_{SDT} = \beta .V_{SD}= \alpha \beta .P=(k_x, k_y).$Then decrypts the encrypted message using $D_{K_x }$ and retrieves $\{H_{SD} , A_{SD} , R_1 \}$. It further calculates $A_{SD'}= h(decrypted H_{SD'} ||decrypted R_1|| K_{SDT})$ and checks if calculated $A_{SD'}= received A_{SD}$, if this satisfies then TA stores $\{ ASD\}$ for smart device authentication.

Fig. 4

Registration phase of smart device

5.2.2 Registration of fog server

In this phase fog server FS completes registration to the trusted agency (TA). The registration method is illustrated in Fig. 5 and demonstrated stepwise manner where message exchanges A $\rightarrow$ B: C stands for message C is sent by A to B.

Step 1: $FS \rightarrow TA:E_{K_{x1}} (H_{FS} || A_{FS}|| R_2)$

Fog server selects its private key $\gamma$ and calculates it’s public key $V_{FS} = \gamma .P.$ Further, it calculates ECDH based contributory shared session $K_{FST} = \gamma .V_T = \gamma . \beta .P =(k_{x1}, k_{y1}),$. Now it selects a random nonce $r_2 \in Z_p^*$and further calculates $R_2 as, R_2 = r_2.V_{FS}$. It also calculates $H_{FS}=h(ID_{FS}||V_{FS})$ and $A_{FS}=h(H_{FS}||R_2||K_{FST})$. After performing these operations, it stores $\{A_{FS}, R_2, F(A_{FS} , y)\},$ encrypts $H_{FS}, A_{FS}, R_2$ as $E_{K_{x1}} (H_{FS} || A_{FS}|| R_2)$ and sent as a registration request to TA.

Step 2: $TA\rightarrow FS: E_{K_{x1}} (A_{SD})$

Upon receiving the registration request, TA calculates the same shared key as $K_{FST} = \beta .V_{FS} = \gamma . \beta .P=(k_{x1}, k_{y1})$. It decrypts the encrypted message using the calculated $K_{x1}$ and gets $\{ H_{FS} , A_FS , R_2 \}$. It further calculates $A_{FS'} = h (decrypted H_{FS'} ||decrypted R_2|| K_{FST})$ and checks if calculated $A_{FS'}= received A_{FS}$, if this satisfies then TA stores $\{A_{FS}\}$for fog server authentication, encrypts $\{A_{SD}\}$ calculated in step 1 of Sect. 5.2.1 using $K_{x1}$ and sends the encrypted message $E_{K_{x1}} (A_{SD})$ to the fog server. The fog server receives the encrypted $E_{K_{x1}} (A_{SD})$ as a response to its registration request, decrypts it using $D_{K_{x1}}$, gets $A_{SD}$ and stores it for future use.

Fig. 5

Fog server registration phase

5.2.3 Registration of cloud server

In this phase, cloud server CS get registered with the trusted agency (TA). The registration method is demonstrated in stepwise manner where $A\rightarrow B: C$ stands for message C is sent by A to B. It is also given in summarize form in Fig. 6.

Step 1: $CS \rightarrow TA: E_{K_{x2}} (H_{CS} || A_{CS} || R_3)$

Cloud server selects it’s private key $\nu$ and calculates its public key $V_{CS} = \nu .P.$ Further it calculates ECDH based contributory shared session key $K_{CST} = \nu .V_T = \nu . \beta .P=(k_{x2}, k_{y2})$. Now it selects a random nonce $r_3$ $\in$ $Z_p^*$ and further calculates $R_3$ as $R_3 = r_3.V_{CS}.$ It also calculates$H_{CS}=h(ID_{CS}||V_{CS})$ and $A_{CS}=h(H_{CS}||R_3||K_{CST})$. Now, the cloud server stores $\{A_{CS}, R_3, F(A_{CS}, y)\}$, encrypts $H_{CS}, A_{CS}, R_3$ using $K_{x2}$ as $E_{K_{x2} }(H_{CS} || A_{CS} || R_3)$ and sends the encrypted registration request message to TA.

Step 2: $TA\rightarrow CS: E_{K_{x2} }(A_{FS})$

Upon receiving the registration request, TA calculates its own contributory shared key $K_{CST} = \nu .V_{CS} = \nu . \beta .P=(k_{x2}, k_{y2})$. then, it decrypts the received message using $k_{x2}$ and gets ${H_{CS} , A_{CS} , R_3 }$. It further calculates$A_{CS'} = h(decrypted H_{CS'} ||decrypted R_3|| K_{CST})$ and checks if calculated $A_{CS'}= received A_{CS}$. If it is satisfied, TA stores ${A_{CS}}$ for cloud server authentication and sends $\{A_{FS}\}$ calculated in step 1of Sect. 5.2.2 by encrypting it using $K_x$ back to the cloud server. Finally, cloud server decrypts the received message using calculated $k_{x2}$, gets $A_{FS}$ and stores it for future use.

Fig. 6

Cloud server registration phase

5.3 Key management phase

In this subsection, a secure communication channel is established amid smart device and fog server, and between fog and cloud server.

5.3.1 Key management between smart device and fog server

The following steps need to be accomplished for smart device and fog server to establish secret key amid them for securing the communication. The key management process is shown stepwise manner where A$\rightarrow$ B: C stands for message C is sent by A to B. It is also summarized in Fig. 7.

Fig. 7

Key management between smart device and fog server

Step 1: $SD\rightarrow FS: {r_{4'}, T_{S1}}$

Smart device selects a random nonce $r_4 \in Z_p^*$, records the current time stamp $T_{S1}$ and calculates $r_{4'}= h(r_4||A_{SD}||T_{S1})$. Now, it sends the message$\{r_{4'}, T_{S1}\}$ to the fog server.

Step 2: $FS\rightarrow SD: {A_{FS}, r_5, BB_{FS}, TS2}$

After receiving the message, fog server records the current time stamp as $TS_2$ and checks if $|TS2-TS1|\le \Delta T$. If the condition is satisfied, FS calculates another random nonce $r_5 \in Z_p^*$ and calculates $F(stored A_{FS}, stored A_{SD})$ and $K_{a'}= \gamma .V_{SD}.$ Then it calculates $h(K_{a}||r_5)$ and secret key $K_{FSSD}$ as $K_{FSSD}=h (F(A_{FS},A_{SD})||r_{4'}||h(K_{a'}||r_5 )||TS2)$. To check correctness of this key, it further calculates $BB_{FS}= h(K_{FSSD}||TS2)$ and sends $\{A_{FS}, r_5, BB_{FS}, TS2 \}$back to smart device.

Now, the smart device saves the current time stamp TS’ and checks if $|TS'-TS_2|\le \Delta T$. If yes, it calculates $F(A_{SD}, A_{FS})$ and $K_a'= \alpha .V_{FS}.$ Further, it calculates $h(K_a'||r_5)$and finally obtains the secret key as $K_{FSSD}=h(F(A_{FS},A_{SD})||r_4'||h(K_a'||r_5)||TS_2)$. Finally, it calculates $BB_{FS}'=h(K_{FSSD}|| TS_2)$ and checks if calculated $BB_{FS}'=$ received $BB_{FS}$. If it is satisfied, the smart device is ensured that it has obtained the correct secret key.

5.3.2 Key management between fog server and cloud server

In this subsection, key negotiation between fog and cloud server is being described. To establish secret key for secure communication between fog server and cloud server, they need to perform the following steps where A$\rightarrow$ B: C stands for message C is sent by A to B and summarized in Fig. 8.

Fig. 8

Key management between fog server and cloud server

Step 1: $FS\rightarrow CS: {r_6', TS_3}$ Fog server selects a random nonce $r_6 \in Z_p^*$, records the current time stamp $TS_3$ and calculates $r_6'= h(r_6||A_{FS}||TS_3)$. Now, it sends the message $\{r_6', TS_3\}$ to the cloud server.

Step 2: $CS\rightarrow FS: {A_{CS}, r_7, BB_{CS}, TS_4 }$ After receiving the message, cloud server records the current time stamp as $TS_4$ and checks if $|TS_4-TS_3|\le \Delta T.$ If the condition is satisfied, CS calculates another random nonce $r_7 \in Z_p^*$,$F(stored A_{FS}, stored A_{CS})$ and $K_b'= \nu .V_{CS}.$ Now, it calculates $h(K_b'||r_7)$ and the secret key $K_{FSCS}$ as $K_{FSCS}=h(F(A_{FS},A_{CS})||r_6'||h(K_b'||r_7 )||TS_4)$. To check correctness of this key, it further calculates $BB_{CS}= h(K_{FSCS}||TS_4)$ and sends $\{A_{CS}, r_7, BB_{CS}, TS_4 \}$ back to fog server.

Now, the smart device records the current time stamp TS’ and checks if $|TS'-TS_2|\le \Delta T.$ If yes, it calculates$F(A_{SD},A_{FS}), K_a'= \alpha .V_{FS}, h(K_a'||r_5)$ and finally obtains the secret key as $K_{FSSD}=h(F(A_FS,A_SD)||r_4'||h(K_a'||r_5)||TS_2)$. Lastly, it calculates $BB_{FS}'=h(K_{FSSD}|| TS_2)$ and checks if calculated $BB_{FS}'= received BB_{FS}$. If it is satisfied, the fog server has obtained the correct secret key.

Fig. 9

User registration

5.4 User registration

In this phase, the user is registered with the fog server via mobile device. The process is described step by step where ${A\rightarrow B: C}$ stands for message C is sent by A to B. Also, the summary is given in Fig. 9.

Step 1: $U \rightarrow FS:E_{K_{x3}}(M_U ||H_U ||A_U ||R_8)$ User selects its private key $\eta$ and calculates its public key $V_U= \eta .P$. Further, it calculates its shared key with the fog server $K_{UFS}= \eta .V_{FS} = \eta . \gamma .P=(k_{x3}, k_{y3})$. Then it generates its registration request with the following operations: User choses its identity $ID_U$, it’s password $PW_U$ and then imprints its biometrics $B_U$. After this, it selects a random nonce $r_8 \in Z_p^*$, calculates $R_8=r_8.P, then H_U=h(ID_U||V_U), M_U=h(ID_U||PW_U||B_U)$ and $A_U=h(K_{UFS}||M_U||R_8)$. After completing these operations, it encrypts $(M_U||H_U||A_U||R_8)$ using $E_{K_x}$ and encrypted message is sent to fog server.

Step 2: $FS\rightarrow U:E_{K_{x3}} (C_{FS} || D_{FS})$ After reception of the registration request, fog server calculates shared key with user by $K_{UFS}=\gamma .V_U = \eta .\gamma .P=(k_{x3}, k_{y3})$ and retrieves $\{M_U, H_U, A_U, R_8\}$ by decrypting it using $K_{X3}$. It further calculates $A_U'=h(K_{UFS}||decrypted M_U||decrypted R_4)$ and checks if calculated $A_U'=A_U$. If the condition is satisfied, the request is treated as legitimate. It now selects a random nonce $r_9 \in Z_p^*$ and $R_9=r_9.P.$ Now it calculates $C_{FS}=h(decrypted A_U||R_9)$ and $D_{FS}=h(decrypted H_U||C_{FS}||decrypted R_8||K_{UFS})$ and sends $(C_{FS}|| D_{FS})$ by encrypting it with the calculated shared key $E_{K_{x3}}$. After receiving above message from fog server, the user retrieves $C_{FS}$ and $D_{FS}$ and validates $D_{FS}$. If criteria holds true, it stores $\{M_U$[to verify user’s login],$D_{FS}$ [for user authentication]} and fog server also stores $\{ D_{FS}$ [For user authentication] }.

5.5 User login

In this phase, the user logs in to the fog server using mobile devices. The whole process is depicted in Fig. 10 and demonstrated below, where $A\rightarrow B: C$ depicts message C is sent by A to B.

Step 1: $U\rightarrow FS: {M', LM}$ User inputs its $ID_U, PW_U and B_U$ in the mobile device’s application interface. Now, it calculates$H_U=h(ID_U||V_U), M_U'=h(given ID_U||given PW_U||imprinted B_U)$ and checks if the calculated $M_U'= stored M_U.$ If it is true, the user calculates $M'=h(PW_U||B_U), LM=h (M' || K_{UFS}|| D_{FS})$ and finally sends ${M', LM}$ as the login request to FS.

Fig. 10

User login phase

After receiving the request, FS calculates $LM'= h (received M' || K_{UFS}|| stored D_{FS})$ and checks LM’ = received LM ? If yes the FS permits the user login.

5.6 User authentication and key agreement

This phase is the final phase of the proposed scheme where user is authenticated and key is negotiated between the user and smart device through the fog server. The whole process is described stepwise manner where $A\rightarrow B: C$ stands for message C is sent by A to B. It is also depicted in Fig. 11.

Fig. 11

User authentication and key agreement

Step 1: $U \rightarrow FS: \{M_{U1},R_{10},TS_5\}$

After being logged in, user selects $r_{10} \in Z_p^*$ and calculates $R_{10}=r_{10}.\eta .P$. It also records the current time stamp $TS_5$ and calculates $M_{U1}=h(D_{FS}||R_{10}||TS_5||K_{UFS}).$ Now it sends ${M_{U1}, R_{10}, TS_5}$ to fog server.

Step 2: $FS\rightarrow SD: \{H_U,M_{FS3},R_{11},R_{10},TS_6\}$

Upon getting the authentication request from user, FS records the present time stamp $TS_6$ and checks $|TS_6-TS_5|\le \Delta T.$ If yes, it calculates $M_U'=h(stored D_{FS}||recievedR_{10}||recievedTS_5||K_{UFS})$ and checks $M_U'=$ received $M_U?$ If yes, the user is authenticated. Now, FS selects $r_{11} \in Z_p^*$ and calculates $R_11=r_11.P$. It also calculates $M_{FS2}=h(H_U||ID_{FS}||A_{SD}||TS_6)$ and $M_{FS3}=h(M_{FS2}||R_{11}||R_{10}||K_{FSSD})$ and finally sends $\{H_U,M_{FS3},R_{11},R_{10},TS_6\}$to smart device.

Step3: $SD \rightarrow U: \{M_{SK},K'',TS_7\}$

On receiving the message from FS, SD records the current time stamp $TS_7$ and checks $|TS_7-TS_6|\le \Delta T$. If yes, it calculates $M_{FS2}'=h(received H_U||ID_{FS}||A_{SD}||received TS_6)$ and $M_{FS3'}=h(M_{FS2'}||received R_{11}||received R_{10}||K_{FSSD}).$ If calculated $M_{FS3'}=$received $M_{FS3}$, then fog server request is treated as legitimate and session key is calculated as $SK_{SDU}=\alpha .r_1.R_{10}=\alpha .r_1.r_{10}.\eta .P$ and it also calculates $K''=r_1.V_{SD}$ and$M_{SK}=h(SK_{SDU}||R_{10}||TS_7)$. Now, finally $\{M_{SK},K'',TS_7\}$ is sent back to the user.

Now, the user records the current time stamp as TS” and checks $|TS''-TS_7|\le \Delta T ?$ If yes, the session key is calculated as $SK_{SDU}=r_{10}.\eta .K''=r_{10}.\eta .r1.\alpha .P$. To check it’s correctness, $M_{SK'}=h(SK_{SDU}||R_{10}||TS_7)$ is calculated and if it matches the received $M_{SK}$ then it is ensured that correct session key is established.

6 Security analysis

This section analyzes the security aspects of the proposed protocol. Using the informal security analysis, we propose how our protocol is secure from different relevant attacks, then through formal security analysis using AVISPA (Automated Validation of Internet Security Protocols and Applications) we establish our security claims.

6.1 Informal security analysis

In this subsection, the informal analysis of our scheme is shown and proved that the proposed scheme is very well secured againt all probable threats.Also we have shown that the scheme is protected and at the same time achieves the desired security goals like integrity, availability, anonymity among other.

Proposition 1

Three-factor security measures are taken in the proposed scheme.

Proof

The three factors in the proposed scheme are identity $(ID_U),$ password $(PW_U)$and biometrics $(B_U)$ to authenticate to fog server to access any kind of data of a smart device. Even if an adversary guesses the password, identity or both, it still won’t be able to login because in login phase, check at user’s end is laid on $M_{U'}$ which is calculated as $M_{U'}=h (given ID_U||given PW_U||imprinted B_U)$, only if calculated $M_U'$ matches the stored $M_U'$ then only login request is forwarded to FS. $\square$

Proposition 2

Proposed scheme can withstand stolen mobile device attack.

Proof

Suppose the mobile device is somehow stolen and an adversary, through power analysis, guesses $H_U=h(ID_U||V_U), M_U=h(ID_U||PW_U||B_U)$ and $A_U=h(K_{UFS}||M_U||R_8)$. Thus, it would pass the login phase but still won’t be able to authenticate with FS. Since in authentication phase it needs to generate message $M_{U1}=h(D_{FS}||R_{10}||TS_5||K_{UFS})$ which won’t be feasible to calculate as it needs ECDH based symmetric key $K_{UFS}$. Further, it would need to generate $R_{10}$ which too can’t be computed as it requires private key $\eta$ and random nonce $r_{10}$ which is changed after each session. Thus, adversary would fail generate a legitimate authentication request. $\square$

Proposition 3

Proposed scheme is safe from impersonation attack.

Proof

Suppose an adversary intercepts a valid authentication request message $\{M_{U1}, R_{10}, TS_5\}$ where MU1 is calculated as $M_{U1}=h(D_{FS}||R_{10}||TS_5||K_{UFS})$. Now if somehow he guesses $D_{FS }$ and tries to modify $M_{U1}$ such that it is treated as a genuine request then it still needs to guess $K_{UFS}$ which will be computationally infeasible due to hardness of ECPM. $\square$

Proposition 4

Proposed scheme provides security against Fog Server insider attack

Proof

Suppose an adversary gains access to a fog server and comes to know all the secrets stored in the fog server like $r_{11}$, $M_{FS2}$ and $M_{FS3}.$ It still fails to guess the session key. Since the session key could be calculated in 2 ways: At smart device, session key is calculated as $SK_{SDU}=\alpha .r_1.R_{10 }$ where both $\alpha$ and $r_1$ are still unknown, thus it would be infeasible to calculate session key from this method. At user/mobile device end, the session key is calculated as $SK_{SDU}=r_{10}.\eta .K''$, here also $r_{10}$ and $\eta$ are still unknown. Thus, it won’t be possible to compute the session key by the adversary. $\square$

Proposition 5

Proposed scheme is resilient against replay attack.

Proof

An adversary might intercept the authentication message and keep on sending it again and again. In that case the proposed scheme is resilient against the same since it contains time stamps. Thus, whenever same message would be repeated it would be discarded automatically by FS as it won’t be able to satisfy the timeliness condition at FS. $\square$

Proposition 6

The proposed scheme guarantees user anonymity.

Proof

User anonymity describes that user’s identity is kept anonymous during the whole phase of communication. The proposed scheme keeps the user’s identity safe as at none of the phases never send user’s identity directly on the public channel. Thus, the proposed scheme is preventing any kind of tracking of user’s activity. $\square$

Proposition 7

Proposed scheme achieves perfect forward secrecy.

Proof

Our scheme maintains perfect forward secrecy, i.e. even if any long term secret key like $K_{UFS}$ (shared key between user and fog server) or $K_{FSSD}$(shared key between FS and SD) but that information still won’t help adversary in calculating $SK_{SDU}=\alpha .r_1.R_{10}=\alpha .r_1.r_{10}.\eta .P$ as it still would require short term secret $r_{10}$ and secret keys $\alpha$ and $\eta$ to calculate the key. $\square$

Proposition 8

Proposed scheme is protected against clogging attack

Proof

Our scheme is resistant to clogging attack, i.e., even if any adversary intercepts in login phase and gets the message $LM= h(M' || K_{UFS}|| D_{FS})$, the adversary still cannot login since at the fog server side it will be checked with previously stored $D_{FS}$. Hence the adversary cannot produce correct $LM'$ and so login request will be denied. Hence our scheme prevents the clogging attack. $\square$

6.2 Formal security analysis using AVISPA

In this subsection, formal security investigation of the proposed scheme is being demonstrated using a very widely recognized simulation tool called (AVISPA) [16]. The AVISPA is an acronym that stands for the Automated Validation of Internet Security Protocols and Applications. It is a push-button tool. It provides a modular and expressive formal language for describing protocols and their security features, as well as a variety of back-ends that integrate a variety of automated protocol analysis tools. The HLPSL stands for High-Level Protocol Specification Language is a language for designing the protocols for security and establishing security features that were proposed. Also it is a collection of tools for officially verifying the protocols, as defined by AVISPA [15, 16]. In AVISPA, the specification in HLPSL will be translated into the intermediate format using a translator named HLPSL2IF. It uses a different language than HLPSL and is read directly by the AVISPA tool’s back-ends. After that, the specification in intermediate format will be work as input and input to the back-ends of AVISPA tools, so that, those tools can analyze the security goals and specifications. There are four available tools in AVISPA back-ends that are OFMC (On the fly model checker), CL-AtSe (CL-based Attack Searcher), SATMC (SAT-based model checker), and TA4SP (Tree automata-based protocol analyzer) [14,15,16, 25, 28,29,30,31]. AVISPA is a role-based language where each participant plays an independent key role for execution of the particular protocol [15, 16]. For formal security analysis, the AVISPA tool is chosen because it certifies that whether the proposed scheme is SAFE or UNSAFE against various existing security threats.

Fig. 12

Smart device role specification in HLPSL

Fig. 13

Fog server role specification in HLPSL

Fig. 14

User role specification in HLPSL

Fig. 15

Cloud server Role specification in HLPSL

In AVISPA, there is a detailed specification of the different participants. These participants are called basic roles. Like in the proposed protocol, the primary participants named as user, fog server, cloud server, smart devices and trusted agency. So our basic role will be for these three participants. A collection of transitions may be found in the transition section of an HLPSL standard. In general, each one denotes the receipt of a message and the subsequent transmission of a reply message. A transition is made up of a trigger, sometimes known as a precondition, and an action to be taken when the trigger event happens.

In order to ensure the confidentiality/secrecy of the proposed protocol, some security aims/goals which they have to satisfy are setup and defined in role environment using HLPSL as secrecy of subs1 to secrecy_of_subs25. After that it starts execution accordingly. To achieve the above, here in our paper, we define eight roles in total and they are: (a) User Role where user denoted as U (depicted Fig. 14), (b) Role Smart_device denoted as SD (depicted in Fig. 12), (c) Role fog_server denoted as FS (depicted in Fig. 13), (d) role cloud_server as CS.(depicted Fig. 15), (e) role trusted_agency represented as TA (Fig. 17), (f) role session which consists of all the main roles (role U, role FS , role CS and role TA), and shown in Fig. 16. In Fig. 18, (g) role session and (h) environment is depicted. Also, global variables and functions are defined; and other above mentioned security goals of the proposed protocol are also depicted. The role based HLPSL codes for the proposed protocol are given in Figs. 12, 13, 14, 15, 16, 17 and 18 and the simulation results are given in Figs. 19 and 20. The results of simulation approves that the proposed scheme is SAFE and can resist all known attacks like man-in-the-middle attack, replay attacks,etc.

Fig. 16

specification of Role session in HLPSL

Fig. 17

Trusted agency Role specification in HLPSL

Fig. 18

Session and environment role specifcation in HLPSL

Fig. 19

Output of the proposed scheme using CLAtSe backend of AVISPA

Fig. 20

Output of the proposed scheme using OFMC backend of AVISPA

7 Performance analysis

In this section, we have done a detailed performance evaluation of the proposed scheme in terms of security features, computation, communication and storage overheads. The performance of the proposed scheme is compared with Wajid et al scheme [1] and other relevant existing schemes [3, 9, 32, 33] and presented in below subsections.

7.1 Security features

The comparative analysis of security features and functionality of our scheme against other relevant schemes is shown in Table 3 which shows that our proposed scheme is very well secure against all relevant cryptographic attacks.

7.2 Computation overhead comparison

In this subsection we have compared the computation time (in milliseconds) required for the execution of the proposed scheme with other existing schemes.The summarized result is shown in Table 4 where $T_{ecm} ,T_{eca} ,T_{sed}, T_h, T_{fe}, T_{enc-ibe}, T_{dec-ibe}, T_{sig-ibe}, T_{ver-ibe}, T_{exp}, T_{pke}$ and $T_{pkd}$ signify the required time for computation for point multiplication in elliptic curve, time taken for point addition in elliptic curve, time required for a symmetric encryption/decryption, time taken for one-way hash function, total time for a fuzzy extraction operation, encryption based on identity (IBE), decryption based on identity, signature generation based on identity, signature verification based on identity, time required for modular exponentiation, public key encryption and decryption, respectively. Since, login and authentication phases are most commonly executed, we have considered these 2 phases for calculation. The experimental setup reported in [1, 16, 34,35,36] are used in this paper. It is seen that the values of cryptographic operations $T_{ecm}, T_{eca}, T_{sed}$ and $T_h$ are 0.063075 s, 0.010875 s, 0.0087 s and 0.0005 s, respectively. The fuzzy extractor execution time needed is approximately equal to that of an elliptic curve point multiplication time i.e.$T_{fe} \approx T_{ecm}=$ 0.063075 s [1, 15, 16, 36]. Thus, we have $T_{exp} \approx 60T_{sed}$= 0.522 s, and $T_{pke}/T_{pkd} \approx 100T_{sed}$= 0.87 s [1, 34].

7.3 Communication overhead

In our proposed scheme the communication overhead is computed using some considerations such as the length of password, identity (user, fog server and smart device) and random nonce wich is considered to be 128 bits each and timestamp is considered to be 32 bits. The messages used for symmetric-key encryption or decryption is considered to be 128 bits and hash functions to be 160 bits. The comparative results of communication overhead is summarized in Table 5 which demonstrates that our scheme partakes much less communication overhead as compared to its counterparts.

7.4 Storage overhead

The storage overhead in user side of our proposed scheme is compared with the other relevant schemes and found that our scheme is significantly efficient in this context. In our scheme, the user only stores two hash digests $D_{FS}$ and $M_u$ in user registration phase and as mentioned in Sect. 7.2, the total storage overhead in user side is $160+160=320$ bits. Table 6 shows the comparison of storage overhead of the proposed scheme with other existing schemes in this context and it is clearly established that the overhead of our scheme is fewer than other schemes.

Hence, it can be concluded that the proposed scheme is not only resilient to all relevant security threats but also has much less computation, communication and storage overheads as compared to its counterparts. Thus, the proposed scheme maintains an excellent tradeoff between performance and security.

From the performance analysis described in the above Sects. 7.1–7.4 and the given comparison Tables 3, 4, 5 and 6, it is very prominent that the strength of the proposed method is that (i) it is lightweight, (ii) it uses smaller key size because of using ECC for authentication and key management and (iii) it provides higher level of security. The performance of the scheme is also very efficient since the comparative study shows that the computation, communication, and storage overheads are less than other recently published schemes. At the same time, the proposed scheme is able to resist all possible security attacks in this fog based IoT communication. The computation overhead of the proposed scheme might be little higher than those schemes which use hash-based methods for authentication and key management. but since the hash-based schemes are very easily vulnerable and prone to various security attacks, ECC based encryption or decryption is chosen in the proposed method to ensure sufficient security.

8 Conclusion and further researches

In this new era of IoT technology, every day numerous devices are joining in IoT network. With this increasing rate, the need for low latency computing is also increasing and that’s why fog and edge computing are so widely used in these scenarios and have emerged as one of the main research topic. With many advantages like low latency communication, faster data availability, less network congestion, support of real time services, etc., fog computing also brings some security issues like various privacy threats, confidentiality of data and authentication issues. Most prominent concern in this scenario is to authenticate the legitimate user and refuse the adversary. To solve this issue many researchers have proposed their valuable suggestions. In this paper, the recent literatures on the said context are minutely analyzed. Specifically, the scheme proposed by Wajid et al. [1] and after exhaustive cryptanalysis of the same, it is shown that the scheme still have some security drawbacks i.e., the scheme is not secure against fog server insider attack, message intercept attack and replay attack which are still unpublished in any other recent literature. From this motivation, a lightweight remote user authentication and key agreement scheme for fog-centric IoT communication is proposed in this paper. Which is more secure and efficient than all the preceding schemes. The state-of-art informal security analysis of the proposed scheme and the formal security analysis using AVISPA shows that the scheme is resilient to all relevant malicious attacks. The performance analysis of the proposed scheme clearly demonstrates that our scheme is more efficient in all aspect and practically implementable.

Table 3 Comparison of security features between the proposed scheme and other relevant schemes

Table 4 Comparison of computational overhead of different schemes in related field

Table 5 Communication overhead comparison

Table 6 Storage overhead comparison

The further research in this context would be the usage of artificial intelligence, blockchain technology since their presence are already on the rise in IoT communication environments. As a result, these can prove to be very useful for providing security and privacy in fog/edge centric IoT communications in future. So, future research direction could be how more efficiently these technologies can be used in combination with our proposed method for authentication and key management purposes, and also implementing and evaluating them in real-world testbed on the way to find more secure IoT environment.