# ECC-Based Authenticated Key Exchange Protocol for Fog-Based IoT Networks

Authors: Ummer Iqbal; Jyoti Bhola; M. Jayasudha; Mohd Wazih Ahmad; Rahul Neware; Arvind R. Yadav; Fraol Waldamichael Gelana
Journal: Security and Communication Networks
 (2022)

---

## Abstract

Fog computing is one of the prominent technology that bridges the gap between IoT nodes and cloud servers. For increasing the efficiency at the fog level, a fog federation can be employed. Fog federation at the fog level can be controlled by the fog coordinator. However, the information exchange between the fog coordinator and IoT nodes needs to be secured. Recently, a lightweight secure key exchange (LKSE) protocol for secure key exchange for fog federation was proposed. In this paper, the cryptanalysis of the LKSE is carried out. The cryptanalysis indicates that LKSE is vulnerable to spoofing and man in the middle attacks. To overcome the limitation of the LKSE, a design of an ECC-based secure key exchange protocol for IoT devices and fog coordinators is proposed. The security strength of the designed method has been evaluated using BAN logic and the random oracle model. Simulations on AVISPA have been performed for automatic security verification of the proposed method. A detailed security and functional comparison of the proposed scheme with LKSE have also been carried out.


---

## Body

## 1. Introduction

IoT-based smart city applications have acquired significant attraction over the years [1–4]. The various IoT-based smart applications include smart water, smart health, smart grid, etc. The introduction of the Internet of Things (IoT) has resulted in an unprecedented creation of massive and diverse amounts of data, referred to as data explosions [5]. On the other hand, while cloud computing has been an effective means to process and store this data, difficulties such as real-time access, latency, and network capacity limitations need to be handled if cloud computing is employed. To solve this issue, a new computing paradigm called fog computing has been proposed [6]. Fog computing brings cloud services to the network’s edge, thus improving low-latency, mobility, network bandwidth, security, and privacy.A typical fog computing block diagram is shown in Figure1 [7]. The architecture comprises the end device layer, fog layer, and cloud computing layer. In the end device layer, smart devices are deployed to monitor and sense various attributes depending upon the context of the application. The end device layer typically involves resource constraint devices. Because of the resource constraint nature, the security with in the device layer is an emerging research area. The fog layer comprises of fog nodes. The fog node [6] is the core component of the fog layer. Fog nodes are strongly associated with smart end devices. Fog nodes can be set as stand-alone fog nodes that interact among themselves to supply the service or can be federated to build clusters to implement a certain fog computing capability. The cloud layer comprises of different servers which can be utilized for online/offline analysis, etc. Some of the applications of fog computing include linked vehicles, smart grids and smart cities, and real-time analytics.Figure 1
Fog computing architecture.The security of the sensed data sent from the end device layer to fog nodes is of paramount importance and is an active area of research. The primary security requirements of the data communicated between smart end-devices and fog nodes include confidentiality, integrity, data freshness, and authentication of the sensed data. Confidentiality of the sensor data ensures that the data in the legitimate form are accessible only to the intended receiver [8]. If an attacker can eavesdrop on the message exchanges, confidentiality must ensure that the eavesdropped messages cannot be deciphered. Confidentially is enforced using encryption and decryption techniques. The encryption technique scrambles the sensed data in such a way that intended receiver with proper decryption process can recover the sensed data. The integrity authentication of the sensed data ensures that the sensed data messages are not altered in transit by an adversary [9]. An authentication mechanism is required to validate and verify whether the legitimate network entities are communicating with each other or not. Nonrepudiation guarantees the responsibility of action. Any security protocol targeting low power nodes must oblige to its constraints [10, 11] and must be formally verified [12].The bedrock of the security requirements discussed above is a secure authenticated key exchange between end devices and the fog nodes. Schemes have been presented in the literature for secure key establishment. Sun et al. [13], Jia et al. [14], Wahid et al. [15], Chen et al. [16], Zheng and Chang [17], and Chen et al. [18] proposed some of the schemes which are reported to be safe and support authenticated key exchange. However, all these schemes are not suitable for the fog federation environment [19, 20]. CE-SKE [19] and LKSE [20] are some of the recent schemes proposed for secure key exchange in the fog federation. CE-SKE claims to support mutual authentication and key exchange; however, this scheme is not lightweight. The second scheme called as LKSE is an improved scheme in terms of efficiency as it is based on elliptical curve cryptography. However, it can be shown that both schemes are vulnerable to spoofing attacks and man the middle attack.In this paper, a lightweight ECC-based authenticated key exchange scheme has been presented. The proposed scheme is resilient to all major security attacks while being functionally optimal in terms of resource overheads. The paper reviews the LKSE scheme in terms of security limitation and proposes a design of lightweight authenticated key exchange scheme which overcomes the limitations of LKSE.


### 1.1. Elliptical Curve Cryptography

An Elliptical CurveEpa,b over a finite prime field Fp is defined as (1):(1)Epa,b:y2=x3+ax+b,(2)Where,▲=4a3+27b2!=0.The computational hardness of the elliptical curve cryptography is based on the elliptical curve discrete log problem (ECDLP). Given two pointsPx,y and Qx,y∈Ea,b such that: Qx,y=n.Px,y where n is a scalar, ECDLP states that it is computationally infeasible to find n [10, 11].


### 1.2. Contributions

The contributions of the paper are as follows:(1)
A review and cryptanalysis of the LKSE have been made carried out to indicate that the scheme is vulnerable to various attacks.(2)
ECC-based secure key exchange protocol for IoT devices and fog coordinator is proposed with better specifications as compared to the existing schemes.(3)
The proposed scheme has been formally validated using AVISPA [21, 22]. The verification results indicate that the scheme is safe and is resilient to man in the middle attack and replay attack.(4)
The validity of the proposed protocol has also been evaluated using BAN logic [23].


### 1.3. Paper Organization

The remainder of the paper is laid out as follows. Section2 reviews and highlights the weaknesses of the LSKE Scheme. In Section 3, the details of the designed protocol are presented. In Section 4, security analysis of the designed scheme has been presented. AVISPA simulation details are presented in Section 5. BAN logic analysis has been carried out in Section 6. Finally, in Section 7, the comparative analysis of the designed scheme is presented.


## 1.1. Elliptical Curve Cryptography

An Elliptical CurveEpa,b over a finite prime field Fp is defined as (1):(1)Epa,b:y2=x3+ax+b,(2)Where,▲=4a3+27b2!=0.The computational hardness of the elliptical curve cryptography is based on the elliptical curve discrete log problem (ECDLP). Given two pointsPx,y and Qx,y∈Ea,b such that: Qx,y=n.Px,y where n is a scalar, ECDLP states that it is computationally infeasible to find n [10, 11].


## 1.2. Contributions

The contributions of the paper are as follows:(1)
A review and cryptanalysis of the LKSE have been made carried out to indicate that the scheme is vulnerable to various attacks.(2)
ECC-based secure key exchange protocol for IoT devices and fog coordinator is proposed with better specifications as compared to the existing schemes.(3)
The proposed scheme has been formally validated using AVISPA [21, 22]. The verification results indicate that the scheme is safe and is resilient to man in the middle attack and replay attack.(4)
The validity of the proposed protocol has also been evaluated using BAN logic [23].


## 1.3. Paper Organization

The remainder of the paper is laid out as follows. Section2 reviews and highlights the weaknesses of the LSKE Scheme. In Section 3, the details of the designed protocol are presented. In Section 4, security analysis of the designed scheme has been presented. AVISPA simulation details are presented in Section 5. BAN logic analysis has been carried out in Section 6. Finally, in Section 7, the comparative analysis of the designed scheme is presented.


## 2. Review and Weakness of the LSKE Scheme

### 2.1. Review of the LSKE Scheme

The key exchange steps between the end device node and the fog center in the LSKE scheme is given as below:Step 1: The node computesA1 as in (3) and sends it to the fog center.(3)A1=IDA,IDB,TA,Kas.Step 2: The fog center checksTA<▲T, if true, then it performs the following:(1)
Stores theKas.(2)
Chooses the numbersa,b,p,R1,R2, and NB.(3)
Calculate equationsH1,B1,H2,B2,H3, and PB as (4)–(10):(4)H1=hIDA,IDB,Kbs,(5)B1=IDA,IDB,Kbs,H1,(6)H2=ha,b,p,R1,R2,(7)B2=a,b,p,R1,R2,H2,(8)PB=NB∗GR1,R2,(9)H3=hPB,(10)B3=PB,TB,H3,B1,B2Kas.Step 3: Fog center sendsB3 to nodeStep 4: The node checks:TB<▲T, if true then it performs the following:(1)
ComputeH1′=hB1, check H1′=H1 , if true, then store Kbs.(2)
ComputeH2′=hB2, check H2′=H2 , if true, then store a,b,p,R1,R2.(3)
ComputeH3′=hB3, check H3′=H3, if true, then store PB.Step 5: The node selects a random numberNA and obtains PA as follows:(11)PA=NA∗GR1,R2.Step 6: The node calculates the common key asfollows:(12)K=NA∗PB.Step 7: The node calculatesA2 and H4 and sends it to fog center:(13)H4=hPA,A2=PA,TA,H4Kbs.Step 8: Fog center computesH4′=hPA, check 4′=H4 , check TA< ▲T, then calculate(14)K=NB∗PA.


### 2.2. Cryptanalysis of the LSKE Scheme

In this section, the cryptanalysis of the LSKE scheme has been carried out. Considering an active adversaryα in the middle, α can spoof the messages and subsequently launch man in the middle attack as given below:Step 1: The node computesA1 as (15) and sends it to the fog center.(15)A1=IDA,IDB,TA,Kas.Step 2: Adversaryα, intercepts the message and performs the following steps:(1)
Selects a public keyKasα.(2)
ComputesA1α=IDA,IDB,TAα,Kasα.(3)
SendsA1α to fog centerStep 3: The fog center checksTAα< ▲T, which evaluates to be true. The fog center then performs the following:(1)
Stores theKasα key.(2)
Chooses the numbersa,b,p,R1,R2, and NB.(3)
Calculates equationsH1,B1,H2,B2,H3, and PB as (16)–(22):(16)H1=hIDA,IDB,Kbs,(17)B1=IDA,IDB,Kbs,H1,(18)H2=ha,b,p,R1,R2,(19)B2=a,b,p,R1,R2,H2,(20)PB=NB∗GR1,R2,(21)H3=hPB,(22)B3=PB,TB,H3,B1,B2Kasα.Step 4: Fog center sendsB3 to the fog nodeStep 5: Adversaryα intercepts the message and performs the following steps:(1)
Decrypts:PB,TB,H3,B1,B2Kasα using the private key.(2)
Adversaryα selects a random number NAα and obtains PAαas follows:(23)PAα=NAα∗GR1,R2.(3)
Adversaryα calculates the common key with the fog center as (24):(24)KFCα=NAα∗PB.Step 6: Adversaryα calculates A2α and H4α and sends it to the fog center:(25)H4α=hPAα,A2α=PAα,TAα,H4αKbs.Step 7: Fog center decryptsA2α and compute H4α′=hPAα, check 4′=H4 , check ,TAα< ▲T, calculate (26)(26)KFCα=NB∗PAα.Step 8: Adversaryα, further performs the following functions(1)
Adversaryα selects a random number NBα and obtains PBα as follows:(27)PBα=NBα∗GR1,R2.(2)
Selects a public keyKbsα.(3)
Chooses the numbersa,b,p,R1α,R2α.(4)
Calculate equationsH1α,B1α,H2α,B2α,H3α and PBα as follows: (28)H1α=hIDA,IDB,Kbsα,(29)B1α=IDA,IDB,Kbsα,H1α,(30)H2α=ha,b,p,R1α,R2α,B2α=a,b,p,R1α,R2α,H2α,PBα=NBα∗GR1α,R2α,H3α=hPBα,B3α=PBα,TBα,H3α,B1α,B2Kas.Step 9: The node decryptsB3α, first checks the time stamp with TBα< ▲T, if true then it performs the following:(1)
ComputeH1′=hB1α, check H1′=H1 , if true, store Kbs.(2)
ComputeH2′=hB2α, check H2′=H2 , if true, store a,b,p,R1α,R2α.(3)
ComputeH3′=hB3α, check H3′=H3 , if true, store PBα.Step 10: The node selects a random numberNA and obtains PA as follows: (31)PA=NA∗GR1,R2.Step 11: The node calculates the common key as follows:(32)KFNα=NA∗PBα.Step 12: The node calculatesA2 and H4 and sends it to the fog center:(33)H4=hPA,A2=PA,TA,H4Kbsα.Step 13: Adversaryα intercepts the message and performs the following steps:(1)
DecryptA2 using Kbsα(2)
ComputeH4′=hPA, check H4′=H4 , check TA< ▲T, calculate (34):(34)KFNα=NBα∗PA.From the above cryptanalysis, we understand that an adversaryα, by spoofing the message exchange can execute a Man-in-the-Middle-Attack. Attacker α forms a shared key KFCα with the fog center, wherein the fog center believes that KFCα is key formed with the fog node and forms a shared key KFCα with the fog node, wherein the fog node believes that KFCα is key formed with the node fog center. The genesis of this attack originates from the fact that there is no complete integrity check on the messages being exchanged as such an adversary α was able to manipulate and spoof the messages.


## 2.1. Review of the LSKE Scheme

The key exchange steps between the end device node and the fog center in the LSKE scheme is given as below:Step 1: The node computesA1 as in (3) and sends it to the fog center.(3)A1=IDA,IDB,TA,Kas.Step 2: The fog center checksTA<▲T, if true, then it performs the following:(1)
Stores theKas.(2)
Chooses the numbersa,b,p,R1,R2, and NB.(3)
Calculate equationsH1,B1,H2,B2,H3, and PB as (4)–(10):(4)H1=hIDA,IDB,Kbs,(5)B1=IDA,IDB,Kbs,H1,(6)H2=ha,b,p,R1,R2,(7)B2=a,b,p,R1,R2,H2,(8)PB=NB∗GR1,R2,(9)H3=hPB,(10)B3=PB,TB,H3,B1,B2Kas.Step 3: Fog center sendsB3 to nodeStep 4: The node checks:TB<▲T, if true then it performs the following:(1)
ComputeH1′=hB1, check H1′=H1 , if true, then store Kbs.(2)
ComputeH2′=hB2, check H2′=H2 , if true, then store a,b,p,R1,R2.(3)
ComputeH3′=hB3, check H3′=H3, if true, then store PB.Step 5: The node selects a random numberNA and obtains PA as follows:(11)PA=NA∗GR1,R2.Step 6: The node calculates the common key asfollows:(12)K=NA∗PB.Step 7: The node calculatesA2 and H4 and sends it to fog center:(13)H4=hPA,A2=PA,TA,H4Kbs.Step 8: Fog center computesH4′=hPA, check 4′=H4 , check TA< ▲T, then calculate(14)K=NB∗PA.


## 2.2. Cryptanalysis of the LSKE Scheme

In this section, the cryptanalysis of the LSKE scheme has been carried out. Considering an active adversaryα in the middle, α can spoof the messages and subsequently launch man in the middle attack as given below:Step 1: The node computesA1 as (15) and sends it to the fog center.(15)A1=IDA,IDB,TA,Kas.Step 2: Adversaryα, intercepts the message and performs the following steps:(1)
Selects a public keyKasα.(2)
ComputesA1α=IDA,IDB,TAα,Kasα.(3)
SendsA1α to fog centerStep 3: The fog center checksTAα< ▲T, which evaluates to be true. The fog center then performs the following:(1)
Stores theKasα key.(2)
Chooses the numbersa,b,p,R1,R2, and NB.(3)
Calculates equationsH1,B1,H2,B2,H3, and PB as (16)–(22):(16)H1=hIDA,IDB,Kbs,(17)B1=IDA,IDB,Kbs,H1,(18)H2=ha,b,p,R1,R2,(19)B2=a,b,p,R1,R2,H2,(20)PB=NB∗GR1,R2,(21)H3=hPB,(22)B3=PB,TB,H3,B1,B2Kasα.Step 4: Fog center sendsB3 to the fog nodeStep 5: Adversaryα intercepts the message and performs the following steps:(1)
Decrypts:PB,TB,H3,B1,B2Kasα using the private key.(2)
Adversaryα selects a random number NAα and obtains PAαas follows:(23)PAα=NAα∗GR1,R2.(3)
Adversaryα calculates the common key with the fog center as (24):(24)KFCα=NAα∗PB.Step 6: Adversaryα calculates A2α and H4α and sends it to the fog center:(25)H4α=hPAα,A2α=PAα,TAα,H4αKbs.Step 7: Fog center decryptsA2α and compute H4α′=hPAα, check 4′=H4 , check ,TAα< ▲T, calculate (26)(26)KFCα=NB∗PAα.Step 8: Adversaryα, further performs the following functions(1)
Adversaryα selects a random number NBα and obtains PBα as follows:(27)PBα=NBα∗GR1,R2.(2)
Selects a public keyKbsα.(3)
Chooses the numbersa,b,p,R1α,R2α.(4)
Calculate equationsH1α,B1α,H2α,B2α,H3α and PBα as follows: (28)H1α=hIDA,IDB,Kbsα,(29)B1α=IDA,IDB,Kbsα,H1α,(30)H2α=ha,b,p,R1α,R2α,B2α=a,b,p,R1α,R2α,H2α,PBα=NBα∗GR1α,R2α,H3α=hPBα,B3α=PBα,TBα,H3α,B1α,B2Kas.Step 9: The node decryptsB3α, first checks the time stamp with TBα< ▲T, if true then it performs the following:(1)
ComputeH1′=hB1α, check H1′=H1 , if true, store Kbs.(2)
ComputeH2′=hB2α, check H2′=H2 , if true, store a,b,p,R1α,R2α.(3)
ComputeH3′=hB3α, check H3′=H3 , if true, store PBα.Step 10: The node selects a random numberNA and obtains PA as follows: (31)PA=NA∗GR1,R2.Step 11: The node calculates the common key as follows:(32)KFNα=NA∗PBα.Step 12: The node calculatesA2 and H4 and sends it to the fog center:(33)H4=hPA,A2=PA,TA,H4Kbsα.Step 13: Adversaryα intercepts the message and performs the following steps:(1)
DecryptA2 using Kbsα(2)
ComputeH4′=hPA, check H4′=H4 , check TA< ▲T, calculate (34):(34)KFNα=NBα∗PA.From the above cryptanalysis, we understand that an adversaryα, by spoofing the message exchange can execute a Man-in-the-Middle-Attack. Attacker α forms a shared key KFCα with the fog center, wherein the fog center believes that KFCα is key formed with the fog node and forms a shared key KFCα with the fog node, wherein the fog node believes that KFCα is key formed with the node fog center. The genesis of this attack originates from the fact that there is no complete integrity check on the messages being exchanged as such an adversary α was able to manipulate and spoof the messages.


## 3. Proposed Scheme

In this section, the ECC-based scheme for secure key exchange protocol for Iota devices and fog coordinator is proposed. The design of the protocol is based on elliptical curve cryptography. The notations used are listed in Table1. The various phases in the proposed access control protocol include the setup and initialization phase, fog node registration phase, fog center registration phase, and authentication and key establishment Phase.Table 1
Symbols and their description.
SymbolDescriptionH()Hash functionNodeINode with identity iFogCenIdentity of the fog centerGKPrPrivate key of certification authorityGKPux,yPublic key of certification authorityNKPrPrivateKey ofNodeINKPux,yPublic Key ofNodeINFPrPrivate key ofFogCenNFPux,yPublic key ofFogCenri,siECDSA signature pair ofNodeIKIJShared key betweenNodeI and NodeJVSPIKCertificate version ofNodeIVSPKKCertificate version ofFogCenLSDILast seen certificate version ofNodeI in FogCenGx,yGenerator point ofEpa,bK∗Gx,yScalar point multiplication betweenK and Gx,yPx,y+Qx,yPoint addition betweenPx,y and Qx,yGNCACertification authority


### 3.1. Setup and Initialization Phase

The certification authorityGNCA performs the system setup phase. The various steps undertaken in this phase are as follows:(i)
GNCA chooses an elliptical curve; EPa,b defined as y2=x3+ax+bmodp is chosen where a and b∈ZP and P is a large prime number.(ii)
TheGNCA chooses GKPr and computes GKPux,y, where GKPux,y=GKPr.Gx,y


### 3.2. Fog Node Registration Phase

(i)
For each IoT node,NodeI,GNCA chooses NKPr and calculates NKPux,y=NKPr.Gx,y(ii)
GNCA creates a signature point SPIx,y for each NodeI as (35):(35)SPIx,y=NKPr+GKPr∗VSPIK∗HNodeI∗Gx,y,whereVSPIK is the version of the signature SPIx,y and guards its freshness. Initially, the VSPIK=1. for each redeployment of NodeI the VSPIK is incremented by 1.(iii)
GNCA computes the ECDSA signature ri,si for each NodeI as (36):(36)ri,si=ECDSA−SIGSPIx,yNKPux,yVSPIKNodeI,GKPr,Ea,b.The ECDSA signatureri,si computed using the private key of the GNCA is to thwart any spoofing or malicious manipulation of authentication and key establishment request and response messages between the deployed node and its neighbors. The evaluation of ri,si during the authentication and key establishment phase ensures that messages exchanged are authentic and their integrity is maintained.(iv)
GNCA preloads each IoT node, NodeI with the following:Epa,b,H,SPIx,y,GKPux,y,NodeI,NKPr,NKPux,y,ri,si and VSPIK


### 3.3. Fog Centre Registration Phase

(i)
GNCA chooses FKPr and calculates FKPux,y=FKPr.Gx,y for Fog central node-FogCen(ii)
GNCA creates a signature point SPFx,y for FogCen as (37):(37)SPFx,y=FKPr+GKPr∗VSPFK∗HFogCen∗Gx,y,whereVSPFK is the version of the signature SPFx,y and guards its freshness.(iii)
GNCA computes the ECDSA signature rf,sf for FogCen as (38):(38)rf,sf=ECDSA−SIGSPFx,yFKPux,yVSPFKFogCen,GKPr,Ea,b.(iv)
FogCen stores the following:Epa,b,H,SPFx,y,GKPux,y,FogCen,FKPr,FKPux,y,rf,sf and VSPFK.


### 3.4. Authentication and Key Establishment Phase

The authentication and key establishment phases undertaken betweenNodeI and the FogCen are detailed below:(i)
NodeI sends the authentication and key establishment request ANIRR to FogCen(39)NodeI⟶FogCen:ANIRR=SPIx,yNKPux,yVSPIKNodeIri,si.(ii)
FogCen verifies the integrity and the authenticity of ANIRR by computing:(40)ECDSA−VERIFYANIRR,GKPux,y,Ea,bIf the verification check evaluates to be false, no processing is done, and the request is rejected. However, if the verification check evaluates to be true, Step iii is performed.(iii)
FogCen authenticates NodeI by performing the following computational steps:(a)
FogCen calculates V =  VSPIK∗HNodeI−1 where NodeI,VSPIK are received through ANIRR(b)
FogCen performs the scalar multiplication of SPIx,y and V as (41):(41)RIx,y=SPIx,y∗V,RIx,y=NKIPr+GKPr∗VSPIK∗HNodeI∗VSPIK∗HNodeI−1∗Gx,y,RIx,y=NKIPr+GKPr∗Gx,y.(c)
FogCen calculates the authentication point as (42):(42)APIx,y=RIx,y+GKPux,−y,APIx,y=NKIPux,y+GKPux,y+GKPux,−y,APIx,y=NKIPux,y.(d)
FogCen compares APIx,y==NKIPux,y where NKPux,y is received through ANIRR. If true, then ANIRR from NodeI is validated and step iv is performed; otherwise, the phase is abortedthe phase is aborted.(iv)
FogCen computes key with NodeI as follows:(43)KJI=HFKPr∗VSPIK∗APIx,y,KJI=HFKPr∗NKIPr∗VSPIK∗Gx,y.(v)
FogCen sends authentication and key establishment response AFogRE as follows::(44)FogCen⟶NodeI:AFogRE=SPFx,yFKPux,yVSPFKFogCenrf,sf.(vi)
NodeI verifies the integrity and the authenticity of ANJRE by computing the following:(45)ECDSA_VERIFYAFogRE,GKPux,y,Ea,b.If the verification check evaluates to be false, no processing is done, and the request is rejected. However, if the verification check evaluates to be true, Step viii is performed.(vii)
NodeI is authenticates FogCen by performing the following computational steps:(a)
NodeI calculates V =  VSPFK∗HFogCen−1 where FogCen,VSPFK are received through AFogRE(b)
NodeI performs the scalar multiplication of SPFx,y and V as (46):(46)RFx,y=SPFx,y∗V,RFx,y=FKPr+GKPr∗VSPFK∗HFogCen∗VSPFK∗HFogCen−1∗Gx,y,RFx,y=FKPr+GKPr∗Gx,y.(c)
NodeI calculates the authentication point as (47):(47)APFx,y=RFx,y+GKPux,−y,APFx,y=FKPux,y+GKPux,y+GKPux,−y,APFx,y=FKPux,y.(d)
NodeI compares APFx,y==FKPux,y where FKPux,y is received through AFogRE . If true, then AFogRE from FogCen is validated and step v is performed; otherwise, the phase is aborted.(viii)
NodeI computes key with FogCen as 60(48)KJI=HNKIPr∗VSPFK∗APFx,y,KJI=HFKPr∗NKIPr∗VSPFK∗Gx,y.(ix)
NodeI chooses a nonce N1 , computes EKJIN1HN1 and sends the following to the FogCen :(49)NodeI⟶FogCen:EKJIN1HN1.(x)
FogCen receives EKJIN1HN1 and decrypts EKJIN1HN1 as DKIJEKJIN1HN1. FogCen further calculates H1N1 using the N1 obtained by decrypting EKJIN1HN1 and verifies HN1==H1N1. If HN1==H1N1 is true, the authentication and key exchange process is completed.


## 3.1. Setup and Initialization Phase

The certification authorityGNCA performs the system setup phase. The various steps undertaken in this phase are as follows:(i)
GNCA chooses an elliptical curve; EPa,b defined as y2=x3+ax+bmodp is chosen where a and b∈ZP and P is a large prime number.(ii)
TheGNCA chooses GKPr and computes GKPux,y, where GKPux,y=GKPr.Gx,y


## 3.2. Fog Node Registration Phase

(i)
For each IoT node,NodeI,GNCA chooses NKPr and calculates NKPux,y=NKPr.Gx,y(ii)
GNCA creates a signature point SPIx,y for each NodeI as (35):(35)SPIx,y=NKPr+GKPr∗VSPIK∗HNodeI∗Gx,y,whereVSPIK is the version of the signature SPIx,y and guards its freshness. Initially, the VSPIK=1. for each redeployment of NodeI the VSPIK is incremented by 1.(iii)
GNCA computes the ECDSA signature ri,si for each NodeI as (36):(36)ri,si=ECDSA−SIGSPIx,yNKPux,yVSPIKNodeI,GKPr,Ea,b.The ECDSA signatureri,si computed using the private key of the GNCA is to thwart any spoofing or malicious manipulation of authentication and key establishment request and response messages between the deployed node and its neighbors. The evaluation of ri,si during the authentication and key establishment phase ensures that messages exchanged are authentic and their integrity is maintained.(iv)
GNCA preloads each IoT node, NodeI with the following:Epa,b,H,SPIx,y,GKPux,y,NodeI,NKPr,NKPux,y,ri,si and VSPIK


## 3.3. Fog Centre Registration Phase

(i)
GNCA chooses FKPr and calculates FKPux,y=FKPr.Gx,y for Fog central node-FogCen(ii)
GNCA creates a signature point SPFx,y for FogCen as (37):(37)SPFx,y=FKPr+GKPr∗VSPFK∗HFogCen∗Gx,y,whereVSPFK is the version of the signature SPFx,y and guards its freshness.(iii)
GNCA computes the ECDSA signature rf,sf for FogCen as (38):(38)rf,sf=ECDSA−SIGSPFx,yFKPux,yVSPFKFogCen,GKPr,Ea,b.(iv)
FogCen stores the following:Epa,b,H,SPFx,y,GKPux,y,FogCen,FKPr,FKPux,y,rf,sf and VSPFK.


## 3.4. Authentication and Key Establishment Phase

The authentication and key establishment phases undertaken betweenNodeI and the FogCen are detailed below:(i)
NodeI sends the authentication and key establishment request ANIRR to FogCen(39)NodeI⟶FogCen:ANIRR=SPIx,yNKPux,yVSPIKNodeIri,si.(ii)
FogCen verifies the integrity and the authenticity of ANIRR by computing:(40)ECDSA−VERIFYANIRR,GKPux,y,Ea,bIf the verification check evaluates to be false, no processing is done, and the request is rejected. However, if the verification check evaluates to be true, Step iii is performed.(iii)
FogCen authenticates NodeI by performing the following computational steps:(a)
FogCen calculates V =  VSPIK∗HNodeI−1 where NodeI,VSPIK are received through ANIRR(b)
FogCen performs the scalar multiplication of SPIx,y and V as (41):(41)RIx,y=SPIx,y∗V,RIx,y=NKIPr+GKPr∗VSPIK∗HNodeI∗VSPIK∗HNodeI−1∗Gx,y,RIx,y=NKIPr+GKPr∗Gx,y.(c)
FogCen calculates the authentication point as (42):(42)APIx,y=RIx,y+GKPux,−y,APIx,y=NKIPux,y+GKPux,y+GKPux,−y,APIx,y=NKIPux,y.(d)
FogCen compares APIx,y==NKIPux,y where NKPux,y is received through ANIRR. If true, then ANIRR from NodeI is validated and step iv is performed; otherwise, the phase is abortedthe phase is aborted.(iv)
FogCen computes key with NodeI as follows:(43)KJI=HFKPr∗VSPIK∗APIx,y,KJI=HFKPr∗NKIPr∗VSPIK∗Gx,y.(v)
FogCen sends authentication and key establishment response AFogRE as follows::(44)FogCen⟶NodeI:AFogRE=SPFx,yFKPux,yVSPFKFogCenrf,sf.(vi)
NodeI verifies the integrity and the authenticity of ANJRE by computing the following:(45)ECDSA_VERIFYAFogRE,GKPux,y,Ea,b.If the verification check evaluates to be false, no processing is done, and the request is rejected. However, if the verification check evaluates to be true, Step viii is performed.(vii)
NodeI is authenticates FogCen by performing the following computational steps:(a)
NodeI calculates V =  VSPFK∗HFogCen−1 where FogCen,VSPFK are received through AFogRE(b)
NodeI performs the scalar multiplication of SPFx,y and V as (46):(46)RFx,y=SPFx,y∗V,RFx,y=FKPr+GKPr∗VSPFK∗HFogCen∗VSPFK∗HFogCen−1∗Gx,y,RFx,y=FKPr+GKPr∗Gx,y.(c)
NodeI calculates the authentication point as (47):(47)APFx,y=RFx,y+GKPux,−y,APFx,y=FKPux,y+GKPux,y+GKPux,−y,APFx,y=FKPux,y.(d)
NodeI compares APFx,y==FKPux,y where FKPux,y is received through AFogRE . If true, then AFogRE from FogCen is validated and step v is performed; otherwise, the phase is aborted.(viii)
NodeI computes key with FogCen as 60(48)KJI=HNKIPr∗VSPFK∗APFx,y,KJI=HFKPr∗NKIPr∗VSPFK∗Gx,y.(ix)
NodeI chooses a nonce N1 , computes EKJIN1HN1 and sends the following to the FogCen :(49)NodeI⟶FogCen:EKJIN1HN1.(x)
FogCen receives EKJIN1HN1 and decrypts EKJIN1HN1 as DKIJEKJIN1HN1. FogCen further calculates H1N1 using the N1 obtained by decrypting EKJIN1HN1 and verifies HN1==H1N1. If HN1==H1N1 is true, the authentication and key exchange process is completed.


## 4. Security Analysis

### 4.1. Informal Security Analysis

In this section, the proposed protocol has been evaluated on some of the major security requirements as indicated in [13–20](a)
Eavesdropping and false injection attacks: To prevent the eavesdropping and the false injection of sensed data, a shared key is established between the and theFogCen as follows:(50)KJI=HFKPr∗NKIPr∗VSPIK∗Gx,y.The keyKJI can be used with any lightweight cipher to provide basic security primitives of confidentiality, integrity, and authentication of the sensed data.(b)
Impersonation attack: During the setup, and the initialization phase, each nodeNodeI is preloaded with the following key material:(51)Epa,b,H,SPIx,y,GKPux,y,NodeI,NKPr,NKPux,y,ri,si,DSIK.Let us assume that theNodeI is captured by an adversary α. α has access to all the preloaded material of the NodeI. The complete network security will get compromised if the private key of GNCA is extracted. The private key GKPr is used in the SPIx,yGKPux,y and ri,si. However, the adversary α cannot extract the private of GNCA from SPIx,yGKPux,y and ri,si due to the computational hardness of the elliptical discrete logarithm problem [24–26].(c)
Man-in-the-Middle-Attack: Suppose attackerα wants to undertake a MITM Attack between a NodeI and FogCen. To accomplish so, α must fabricate SPMAL−Ix,y, rMAL−I,sMAL−I and F, rMAL−F,sMAL−F so that NodeI and FogCen recognize them as authentic signatures. Due to ECDLP [24–26], it is computationally impossible for α to fake SPMAL−Ix,y, rMAL−I,sMAL−I and SPMAL−Fx,y, rMAL−F,sMAL−F; hence, MIMA is prevented in the proposed protocol.(d)
Replay attacks: Let us sayANIRR is an old authentication request of NodeI .The scheme design causes the request to be refused if replayed later as the signature version is maintained. Let FogCen gets the replayed request ANIRR . FogCen checks to see if VSPFK≤LSDI. If true, the request is rejected else, it is accepted.(e)
Spoofing attack: The resistance against spoofing attacks is provided using ECDSA verification. The ECDSA [25] signature pair r,s pair sent along with request and response authentication messages between the new node and the neighboring nodes ensures the integrity authentication of the messages exchanged. In the proposed protocol, NodeI broadcasts the authentication request ANIRR to become part of the network. Any neighbor node who receives the message, before processing further to determine the legitimacy of the node and subsequently to form the shared key, verifies the authenticity and the integrity of the received broadcast using(52)ECDSA−VERIFYANIRR,ri,si,GKPux,y,Ea,b.Any spoofing or modification of the broadcastANIRR would be detected by the neighboring nodes which in turn would result in the rejection of the broadcast before any further processing is done. Thus, the use of ECDSA signature to ensure the integrity and the authenticity of the messages exchanged in the proposed protocol provides a strong resilience against spoofing attacks.


### 4.2. Security Proof

Theorem 1.
The design of the proposed scheme is resilient to impersonation attack malicious node deployment, man in the middle attack, and spoofing attack: under the ECDLP assumption.Proof.
The proof is based on [27–29]. Let us define the following oracles for the adversary α:(i)
Reveal−GKPr: outputs the GKPr using Ea,b and GKPux,y as input.(ii)
Reveal−FKPr: outputs the FKPr using Ea,b and FKPux,y as input.(iii)
Reveal−NKPr: outputs the NKPr using Ea,b and NKPux,y as input.(iv)
Create−SPMAL−Ix,y&rMAL−I,sMAL−I: generate the SPMAL−Ix,y&rMAL−I,sMAL−I for NodeI(v)
Create−SPMAL−Fx,y&rMAL−F,sMAL−F: generate the SPMAL−Fx,y&rMAL−F,sMAL−F for FogCen
α runs the experiment EXPEa,bMAL as shown in Figure 2. The success of the experiment is defined as follows:(53)SuccessMALECDLP=2PEXPEa,bMAL=1−1.
Accordingly, the advantage is defined as follows:(54)ADVMALECDLPt,QCA,QFOG,QNODE,QSIG−N,QSIG−F=MaxASuccessMALECDLP.where in maximum is taken over all execution t, QCA is the number of queries to the Reveal−GKPr, QFOGis the number of queries to the Reveal−FKPr, QNODE is the number of queries to the Reveal−NKPr, QSIG−N is the number of queries to the Create−SPMALx,y&rMAL,sMAL, QSIG−F is the number of queries to Create−SPMAL−Fx,y&rMAL−F,sMAL−F. The proposed protocol would be secure against malicious node deployment attacks if:(55)ADVMALECDLPt,QCA,QFOG,QNODE,QSIG−N,QSIG−F≤εwhereε>0.
Based on the experiment shown in Figure2, α can extract the private key of GKPr and NKPr. Subsequently, the adversary generates SPMAL−Ix,y&rMAL−I,sMAL−I and SPMAL−Fx,y&rMAL−F,sMAL−F. However, as per the ECDLP definition, extracting GKPr and NKPr is a computationally infeasible problem. Thus, we can conclude the following:(56)ADVACLFSECDLPt,QCA,QFOG,QNODE,QSIG−N,QSIG−F≤εwhereε>0.
The proposed scheme provides a strong resilience to malicious node deployment.Figure 2
ExperimentEXPEa,bMAL run by the adversary.


## 4.1. Informal Security Analysis

In this section, the proposed protocol has been evaluated on some of the major security requirements as indicated in [13–20](a)
Eavesdropping and false injection attacks: To prevent the eavesdropping and the false injection of sensed data, a shared key is established between the and theFogCen as follows:(50)KJI=HFKPr∗NKIPr∗VSPIK∗Gx,y.The keyKJI can be used with any lightweight cipher to provide basic security primitives of confidentiality, integrity, and authentication of the sensed data.(b)
Impersonation attack: During the setup, and the initialization phase, each nodeNodeI is preloaded with the following key material:(51)Epa,b,H,SPIx,y,GKPux,y,NodeI,NKPr,NKPux,y,ri,si,DSIK.Let us assume that theNodeI is captured by an adversary α. α has access to all the preloaded material of the NodeI. The complete network security will get compromised if the private key of GNCA is extracted. The private key GKPr is used in the SPIx,yGKPux,y and ri,si. However, the adversary α cannot extract the private of GNCA from SPIx,yGKPux,y and ri,si due to the computational hardness of the elliptical discrete logarithm problem [24–26].(c)
Man-in-the-Middle-Attack: Suppose attackerα wants to undertake a MITM Attack between a NodeI and FogCen. To accomplish so, α must fabricate SPMAL−Ix,y, rMAL−I,sMAL−I and F, rMAL−F,sMAL−F so that NodeI and FogCen recognize them as authentic signatures. Due to ECDLP [24–26], it is computationally impossible for α to fake SPMAL−Ix,y, rMAL−I,sMAL−I and SPMAL−Fx,y, rMAL−F,sMAL−F; hence, MIMA is prevented in the proposed protocol.(d)
Replay attacks: Let us sayANIRR is an old authentication request of NodeI .The scheme design causes the request to be refused if replayed later as the signature version is maintained. Let FogCen gets the replayed request ANIRR . FogCen checks to see if VSPFK≤LSDI. If true, the request is rejected else, it is accepted.(e)
Spoofing attack: The resistance against spoofing attacks is provided using ECDSA verification. The ECDSA [25] signature pair r,s pair sent along with request and response authentication messages between the new node and the neighboring nodes ensures the integrity authentication of the messages exchanged. In the proposed protocol, NodeI broadcasts the authentication request ANIRR to become part of the network. Any neighbor node who receives the message, before processing further to determine the legitimacy of the node and subsequently to form the shared key, verifies the authenticity and the integrity of the received broadcast using(52)ECDSA−VERIFYANIRR,ri,si,GKPux,y,Ea,b.Any spoofing or modification of the broadcastANIRR would be detected by the neighboring nodes which in turn would result in the rejection of the broadcast before any further processing is done. Thus, the use of ECDSA signature to ensure the integrity and the authenticity of the messages exchanged in the proposed protocol provides a strong resilience against spoofing attacks.


## 4.2. Security Proof

Theorem 1.
The design of the proposed scheme is resilient to impersonation attack malicious node deployment, man in the middle attack, and spoofing attack: under the ECDLP assumption.Proof.
The proof is based on [27–29]. Let us define the following oracles for the adversary α:(i)
Reveal−GKPr: outputs the GKPr using Ea,b and GKPux,y as input.(ii)
Reveal−FKPr: outputs the FKPr using Ea,b and FKPux,y as input.(iii)
Reveal−NKPr: outputs the NKPr using Ea,b and NKPux,y as input.(iv)
Create−SPMAL−Ix,y&rMAL−I,sMAL−I: generate the SPMAL−Ix,y&rMAL−I,sMAL−I for NodeI(v)
Create−SPMAL−Fx,y&rMAL−F,sMAL−F: generate the SPMAL−Fx,y&rMAL−F,sMAL−F for FogCen
α runs the experiment EXPEa,bMAL as shown in Figure 2. The success of the experiment is defined as follows:(53)SuccessMALECDLP=2PEXPEa,bMAL=1−1.
Accordingly, the advantage is defined as follows:(54)ADVMALECDLPt,QCA,QFOG,QNODE,QSIG−N,QSIG−F=MaxASuccessMALECDLP.where in maximum is taken over all execution t, QCA is the number of queries to the Reveal−GKPr, QFOGis the number of queries to the Reveal−FKPr, QNODE is the number of queries to the Reveal−NKPr, QSIG−N is the number of queries to the Create−SPMALx,y&rMAL,sMAL, QSIG−F is the number of queries to Create−SPMAL−Fx,y&rMAL−F,sMAL−F. The proposed protocol would be secure against malicious node deployment attacks if:(55)ADVMALECDLPt,QCA,QFOG,QNODE,QSIG−N,QSIG−F≤εwhereε>0.
Based on the experiment shown in Figure2, α can extract the private key of GKPr and NKPr. Subsequently, the adversary generates SPMAL−Ix,y&rMAL−I,sMAL−I and SPMAL−Fx,y&rMAL−F,sMAL−F. However, as per the ECDLP definition, extracting GKPr and NKPr is a computationally infeasible problem. Thus, we can conclude the following:(56)ADVACLFSECDLPt,QCA,QFOG,QNODE,QSIG−N,QSIG−F≤εwhereε>0.
The proposed scheme provides a strong resilience to malicious node deployment.Figure 2
ExperimentEXPEa,bMAL run by the adversary.


## 5. AVISPA Simulation

With the help of AVISPA simulation, we prove that the proposed scheme is resistant to man-in-the-middle and replay attacks.


### 5.1. HLPSL Specification of the Proposed Scheme

In this section, the HLPSL model of the proposed access control scheme is discussed. The authentication and the key exchange between theNodeI and the FogCen are modeled by defining their corresponding HLPSL roles. The HLPSL model of the NodeI is given in Figure 3. The role_FogDevice is played by agent A. The RCV (start) in state 0 of the role_FogDevice initiates the simulation. On receiving the start, agent A sends the ANIRR=SPIx,yNKPux,yVSPIKNodeI,ri,si using the SND() operation. SND and RCV are defined as a channel (dy). Channel (dy) defines the Dolev and Yoa threat model in which the communication channel is completely insecure. In-state 0, NKPr is specified to be a secrecy goal identified by protocol_id type seed_Ki. The roleNewNode in state 1, on receiving the response AFogRE=SPFx,yFKPux,yVSPFKFogCenrf,sf using the RCV() from FogCen , NodeI sends EKJIN1HN1 and the conjunction, witness(A,B,bob_alice_na,Ni)) is validated. Witness (A, B, bob_alice_na, Ni) demands a weak authentication of NodeI by FogCen , where FogCen is witness to the information given by NodeI, i.e., Ni’. Bob_alice_na identifies this property in the goal section defined in the environment role.Figure 3
HLPSL role for new nodeNodeI.The HLPSL model of theFogCen is given in Figure 4. The role_FogCentre is played by agent B. On receiving ANIRR=SPIx,yNKPux,yVSPIKNodeI,ri,si using RCV(), agent B, sends ANIRR=SPIx,yNKPux,yVSPIKNodeI,ri,si using SND() operation. The FKPr is specified to be a secrecy goal identified by protocol_id type seed_KJ. request(B,A,bob_alice_na,Ni) is a strong authentication where FogCen is a witness of the Ni for NodeI and is identified by bob_alice_na in the goal section. The role session and environment are shown in Figure 5. A session is a composing role instantiating one or more basic roles. The composed role does not have a transition section. /\ is used to indicate the basic role that runs in parallel. Role A and B are initiated in parallel as shown in Figure 5.Figure 4
HLPSL role forFogCen.Figure 5
HLPSL role for session and environment.


### 5.2. Simulation Results

The HLPSL code of the proposed protocol was simulated on SPAN, which is the simulation animator for AVISPA. The corresponding message sequence chart on SPAN depicts 02 messages being exchanged, as shown in Figure6. The HLPSL model of the proposed protocol has been verified on the OFMC backend. OFMC backend employs symbolic techniques to create on-the-fly state representation. OFMC provides fast detection of attacks in a bounded number of sessions. To verify the replay attack in the proposed scheme, the backend performs a search of a passive intruder. The simulation results on the OFMC backend are shown in Figure 7. Thus, the AVISPA verification of the scheme indicates that the scheme is SAFE. The search time is 0.25 sec and the number of nodes visited is 3 with a depth of 2.Figure 6
Message sequence chart.Figure 7
AVISPA verification results on OFMC backend.


## 5.1. HLPSL Specification of the Proposed Scheme

In this section, the HLPSL model of the proposed access control scheme is discussed. The authentication and the key exchange between theNodeI and the FogCen are modeled by defining their corresponding HLPSL roles. The HLPSL model of the NodeI is given in Figure 3. The role_FogDevice is played by agent A. The RCV (start) in state 0 of the role_FogDevice initiates the simulation. On receiving the start, agent A sends the ANIRR=SPIx,yNKPux,yVSPIKNodeI,ri,si using the SND() operation. SND and RCV are defined as a channel (dy). Channel (dy) defines the Dolev and Yoa threat model in which the communication channel is completely insecure. In-state 0, NKPr is specified to be a secrecy goal identified by protocol_id type seed_Ki. The roleNewNode in state 1, on receiving the response AFogRE=SPFx,yFKPux,yVSPFKFogCenrf,sf using the RCV() from FogCen , NodeI sends EKJIN1HN1 and the conjunction, witness(A,B,bob_alice_na,Ni)) is validated. Witness (A, B, bob_alice_na, Ni) demands a weak authentication of NodeI by FogCen , where FogCen is witness to the information given by NodeI, i.e., Ni’. Bob_alice_na identifies this property in the goal section defined in the environment role.Figure 3
HLPSL role for new nodeNodeI.The HLPSL model of theFogCen is given in Figure 4. The role_FogCentre is played by agent B. On receiving ANIRR=SPIx,yNKPux,yVSPIKNodeI,ri,si using RCV(), agent B, sends ANIRR=SPIx,yNKPux,yVSPIKNodeI,ri,si using SND() operation. The FKPr is specified to be a secrecy goal identified by protocol_id type seed_KJ. request(B,A,bob_alice_na,Ni) is a strong authentication where FogCen is a witness of the Ni for NodeI and is identified by bob_alice_na in the goal section. The role session and environment are shown in Figure 5. A session is a composing role instantiating one or more basic roles. The composed role does not have a transition section. /\ is used to indicate the basic role that runs in parallel. Role A and B are initiated in parallel as shown in Figure 5.Figure 4
HLPSL role forFogCen.Figure 5
HLPSL role for session and environment.


## 5.2. Simulation Results

The HLPSL code of the proposed protocol was simulated on SPAN, which is the simulation animator for AVISPA. The corresponding message sequence chart on SPAN depicts 02 messages being exchanged, as shown in Figure6. The HLPSL model of the proposed protocol has been verified on the OFMC backend. OFMC backend employs symbolic techniques to create on-the-fly state representation. OFMC provides fast detection of attacks in a bounded number of sessions. To verify the replay attack in the proposed scheme, the backend performs a search of a passive intruder. The simulation results on the OFMC backend are shown in Figure 7. Thus, the AVISPA verification of the scheme indicates that the scheme is SAFE. The search time is 0.25 sec and the number of nodes visited is 3 with a depth of 2.Figure 6
Message sequence chart.Figure 7
AVISPA verification results on OFMC backend.


## 6. BAN Logic Analysis

NodeI and FogCen represent the communicating parties, where NKPr and FKPr denote their private keys, respectively. The BAN notations are given in Table 2 [30], and the BAN postulates are tabulated in Table 3. Synthesis rules are tabulated in Table 4 [31].Table 2
BAN notations.
NotationDescriptionNodeI|≡MessageNodeI believes MessageNodeI⇐MessageNodeI receives MessageNodeI|∼MessageNodeI sent the Message in past.NodeI∼MessageNodeI sent the Message currently.NodeI|⟶VNodeI has jurisdiction over V#MM is fresh⟶NKIPux,yNodeINKPux,y is the public key of NodeINodeI⟶KJIFogCenKJI is the shared key between NodeI and FogCenXKJIKJI is the key used to encrypt X.EXP1/EXP2IfEXP1 is true, then EXP2 is trueTable 3
Basic postulates.
Rule NoRuleRepresentationR1Message meaningNodeI|≡⟶FKPux,yFogCen,NodeI⇐XFKPr/NodeI|≡FogCen|∼XR2Nonce verificationNodeI|≡#X,NodeI|≡FogCen|∼X/NodeI|≡FogCen|≡XR3JurisdictionNodeI|⟶X,NodeI|≡FogCen|≡X/NodeI|≡XR4SeeingNodeI⇐X,NodeI⇐Y/NodeI⇐X,YR5BeliefNodeI|≡X,NodeI|≡Y/NodeI|≡X,YR6FreshnessNodeI|≡#X/NodeI|≡#X,YR7Session keyNodeI|≡#SK,NodeI|≡FogCen|≡X/NodeI|≡NodeI⟶SKFogCenTable 4
Synthesis rules.
Rule NoSynthesis ruleS1NodeI⇐A¬NodeI⇐A,BS2NodeI|≡FogCen|∼A¬NodeI|≡FogCen|∼A,BS3NodeI|≡FogCen|∼A,B¬NodeI|≡FogCen|∼AS4NodeI|≡FogCen∼A¬P|≡#A


### 6.1. Assumptions

The assumptions are listed below:(AS1)NodeI|≡⟶NKIPux,yNodeI(AS2)FogCen|≡⟶NKIPux,yNodeI(AS3)FogCen|≡⟶FKPux,yFogCen(AS4)NodeI|≡⟶FKPux,yFogCen(AS5)NodeI|≡#VSPIK(AS6)FogCen|≡#VSPFK


### 6.2. Idealized Form

(57)NodeI⟶FogCen;SPIx,yNKPr,FogCen⟶NodeI;SPFx,yFKPr.


### 6.3. Goals

(G1)FogCen|≡NodeI⟶KIJFogCen.(G2)FogCen|≡NodeI|≡NodeI⟶KIJFogCen(G3)NodeI|≡NodeI⟶KIJFogCen.(G4)NodeI|≡FogCen|≡NodeI⟶KIJFogCen


### 6.4. BAN Verification of the Proposed Protocol

From (M1), we infer the following:(1)
NodeI|≡SPIx,yNKPr(2)
FogCen⇐SPIx,yNKPrFrom (2), (AS2) and (R1), we obtain as below:(3)
FogCen|≡NodeI|∼SPIx,yVSPIK is a part of SPIx,y; from (AS5) and (R6), we obtain as below:(4)
NodeI|≡#SPIx,yFrom 3 and 4, we obtain as below:(5)
FogCen|≡NodeI∼SPIx,yFrom (5) and (SR4), we obtain as below:(6)
FogCen|≡#SPIx,yFrom (3), (6), and (R2), we obtain as below:(7)
FogCen|≡NodeI|≡SPIx,yVSPIK is a part of SPIx,y; from (R5), we obtain as below:(8)
FogCen|≡NodeI|≡VSPIKFrom (SR3) and (3), we obtain as below:(9)
FogCen|≡NodeI|∼VSPIKFrom (AS5) and (9), we obtain as below:(10)
FogCen|≡NodeI∼VSPIKFrom (RS4) and (10), we obtain as below:(11)
FogCen|≡#VSPIKVSPIK is a part of KIJ; from (R6), we obtain as below:(12)
FogCen|≡#KIJFrom (10), (12), and (R7), we obtain as below:(13)
FogCen|≡NodeI⟶KIJFogCenDue to the symmetry of the protocol,(14)
NodeJ|≡FogCen|≡NodeI⟶KIJFogCenFrom (M2), we infer that(15)
FogCen|≡SPFx,yFKPr(16)
NodeI⇐SPJx,yNKJPrFrom (16), (AS2), and (R1), we obtain as below:(17)
NodeI|≡FogCen|∼SPFx,yVSPFK is a part of SPFx,y; from (AS5) and (R6), we obtain as below:(18)
FogCen|≡#SPFx,yFrom 17 and 18, we obtain as below:(19)
NodeI|≡FogCen∼SPFx,yFrom (19) and (SR4), we obtain as below:(20)
NodeI|≡#SPFx,yFrom (17), (20), and (R2), we obtain as below:(21)
NodeI|≡FogCen|≡SPFx,yVSPFK is a part of SPFx,y; from (R5), we obtain as below:(22)
NodeI|≡FogCen|≡VSPFKFrom (SR3) and (17), we obtain as below:(23)
NodeI|≡FogCen|∼VSPFKFrom (AS5) and (23), we obtain as below:(24)
NodeI|≡FogCen∼VSPFKFrom (RS4) and (24), we obtain as below:(25)
NodeI|≡#VSPFKVSPFK is a part of KIJ;from (R6), we obtain as below:(26)
NodeI|≡#KIJFrom (25), (26), and (R7), we obtain as below:(27)
NodeI|≡NodeI⟶KIJFogCenDue to the symmetry of the protocol,(28)
NodeI|≡FogCen|≡NodeI⟶KIJFogCen


## 6.1. Assumptions

The assumptions are listed below:(AS1)NodeI|≡⟶NKIPux,yNodeI(AS2)FogCen|≡⟶NKIPux,yNodeI(AS3)FogCen|≡⟶FKPux,yFogCen(AS4)NodeI|≡⟶FKPux,yFogCen(AS5)NodeI|≡#VSPIK(AS6)FogCen|≡#VSPFK


## 6.2. Idealized Form

(57)NodeI⟶FogCen;SPIx,yNKPr,FogCen⟶NodeI;SPFx,yFKPr.


## 6.3. Goals

(G1)FogCen|≡NodeI⟶KIJFogCen.(G2)FogCen|≡NodeI|≡NodeI⟶KIJFogCen(G3)NodeI|≡NodeI⟶KIJFogCen.(G4)NodeI|≡FogCen|≡NodeI⟶KIJFogCen


## 6.4. BAN Verification of the Proposed Protocol

From (M1), we infer the following:(1)
NodeI|≡SPIx,yNKPr(2)
FogCen⇐SPIx,yNKPrFrom (2), (AS2) and (R1), we obtain as below:(3)
FogCen|≡NodeI|∼SPIx,yVSPIK is a part of SPIx,y; from (AS5) and (R6), we obtain as below:(4)
NodeI|≡#SPIx,yFrom 3 and 4, we obtain as below:(5)
FogCen|≡NodeI∼SPIx,yFrom (5) and (SR4), we obtain as below:(6)
FogCen|≡#SPIx,yFrom (3), (6), and (R2), we obtain as below:(7)
FogCen|≡NodeI|≡SPIx,yVSPIK is a part of SPIx,y; from (R5), we obtain as below:(8)
FogCen|≡NodeI|≡VSPIKFrom (SR3) and (3), we obtain as below:(9)
FogCen|≡NodeI|∼VSPIKFrom (AS5) and (9), we obtain as below:(10)
FogCen|≡NodeI∼VSPIKFrom (RS4) and (10), we obtain as below:(11)
FogCen|≡#VSPIKVSPIK is a part of KIJ; from (R6), we obtain as below:(12)
FogCen|≡#KIJFrom (10), (12), and (R7), we obtain as below:(13)
FogCen|≡NodeI⟶KIJFogCenDue to the symmetry of the protocol,(14)
NodeJ|≡FogCen|≡NodeI⟶KIJFogCenFrom (M2), we infer that(15)
FogCen|≡SPFx,yFKPr(16)
NodeI⇐SPJx,yNKJPrFrom (16), (AS2), and (R1), we obtain as below:(17)
NodeI|≡FogCen|∼SPFx,yVSPFK is a part of SPFx,y; from (AS5) and (R6), we obtain as below:(18)
FogCen|≡#SPFx,yFrom 17 and 18, we obtain as below:(19)
NodeI|≡FogCen∼SPFx,yFrom (19) and (SR4), we obtain as below:(20)
NodeI|≡#SPFx,yFrom (17), (20), and (R2), we obtain as below:(21)
NodeI|≡FogCen|≡SPFx,yVSPFK is a part of SPFx,y; from (R5), we obtain as below:(22)
NodeI|≡FogCen|≡VSPFKFrom (SR3) and (17), we obtain as below:(23)
NodeI|≡FogCen|∼VSPFKFrom (AS5) and (23), we obtain as below:(24)
NodeI|≡FogCen∼VSPFKFrom (RS4) and (24), we obtain as below:(25)
NodeI|≡#VSPFKVSPFK is a part of KIJ;from (R6), we obtain as below:(26)
NodeI|≡#KIJFrom (25), (26), and (R7), we obtain as below:(27)
NodeI|≡NodeI⟶KIJFogCenDue to the symmetry of the protocol,(28)
NodeI|≡FogCen|≡NodeI⟶KIJFogCen


## 7. Comparison with Other Schemes

To draw a comparison of the computational cost between the LKSE and the proposed scheme, the various computational operations considered include Hash Operation:OPHASH , ECC Point Addition OPECC−ADD, ECC Scalar multiplication OPECC−MUL , Public key Encryption OPPK−ENC, Public Key Decryption OPPK−DEC, Symmetric key Encryption OPSK−ENC, Symmetric Key Decryption OPSK−DEC , ECDSA-Verification: OPECDSA−VER , and Modular Inverse OPINV . The comparison of the computational cost in terms of computational operation is shown in Table 5. The total no of operations for the proposed scheme is: 8OPHASH+2OPECC−MUL+2OPPK−ENC+2OPPK−DEC and LKSE is 8OPHASH+2OPECC−ADD+4OPECC−MUL+OPSK−ENC+OPSK−DEC+2OPECDSA+2OPINV. From Table 5, we can infer that as the proposed scheme does include any public-key encryption and decryption; thus, the computational cost of the proposed scheme is less than LKSE. The size of each message exchanged is shown in Table 6. The total communication cost in the proposed scheme is 2144 bits. The energy consumed for the computational operators on the MicaZ [32] node is depicted in Table 7 [33]. The time taken for public-key encryption and decryption on MicaZ is 0.79 s and 21.5 s [34]. Thus, on a MicaZ mote, the required energy for public key encryption and decryption is 18.96 mJ and 516 mJ respectively. The communication overhead comparison is shown in Figure 8. The energy overhead comparison is shown in Figure 9. The highest communication and energy overhead is that of CE-SKE with 3072 bits and 1606.56 mJ. The high energy overhead in CE-SKE and LKSE scheme is owing to the use of OPPK−ENC and OPPK−DEC. From Figures 8 and 9, it can be inferred that the proposed protocol has low communication and computational overheads as compared to the CE-SKE and LKSE schemes.Table 5
Computational overhead.
SchemeOPHASHOPECC−ADDOPECC−MULOPPK−ENCOPPK−DECOPSK−ENCOPSK−DECOPECDSAOPINVCE-SKENodeI400120000FogCen400210000LKSENodeI401110000FogCen401110000ProposedNodeI212001011FogCen212000111Table 6
Communication overhead in the proposed scheme.
S.NoMessageSize1ANIRR=SPIx,yNKPux,yVSPIKNodeI,ri,si10082AFogRE=SPFx,yFKPux,yVSPFKFogCenrf,sf10083EKJIN1HN1128Total2144SPIx,y=320bits,SPFx,y=320bits || NKPux,y=160bits,FKPux,y=160bitsri,si=320bitsrf,sf=320bits,VSPIK=32bits,NodeI=16bits,VSPFK=32bitsFogCen=16bits,EKJI=128bitsTable 7
Energy consumed.
SymbolEnergy(mJ)OPHASH0.21OPECC−ADD3.84OPECC−MUL67.68OPPK−ENC18.96OPPK−DEC516OPSK−ENC0.00069OPPK−ENC0.00069OPECDSA67.68OPINV3.36Figure 8
Communication overhead comparison.Figure 9
Energy overhead comparison.The security comparison is shown in Table8. The cryptanalysis of LKSE indicates that an adversary can spoof the message exchange and as such can execute a man in the middle attack. The genesis of this attack originates from the fact that there is no complete integrity check on the messages being exchanged as such an adversary was able to manipulate and spoof the messages. As a result of this design flaw, LKSE is not resilient to a man-in-the-middle attack, impersonation attack, and does not support mutual authentication and message integrity. In the proposed protocol, it is computationally impossible for an adversary α to fake SPIx,y,ri,si and SPJx,y,rj,sj; hence, MIMA and impersonation attack are prevented in the proposed protocol. The design of the proposed scheme also achieves mutual authentication and message integrity using SPIx,y,ri,si and SPJx,y,rj,sj.Table 8
Security comparison.
Security attackLSKEProposed schemeReplay attack✔✔Man-in-the-middle attackX✔Insider attack✔✔Impersonation attackX✔Brute force attack✔✔Offline password guessing attack✔✔Mutual authenticationX✔Key exchange✔✔Fog federation✔✔Message integrityX✔AVISPA verification✔✔Thus, with the analysis presented, it can be inferred that the proposed scheme with the energy overhead of 210.66 mJ and communication overhead of 2144 bits conforms to all security specifications.


## 8. Conclusion

The security of sensed data sent from end fog nodes to the fog center is critical and an active area of research. A secure authenticated key exchange between the fog nodes and the fog center is an essential security requirement. Recently, the LKSE scheme for secure key exchange in fog federations was presented. In this paper, a brief review and cryptanalysis of LKSE has been presented. The cryptanalysis indicates that an active adversary can carry out spoofing of the messages, thus resulting in a man in the middle attack. In this paper, a lightweight ECC-based key exchange mechanism for fog federation has been presented. A detailed informal and formal security analysis of the proposed scheme indicates that the scheme is safe from various attacks. The overhead analysis depicts that the proposed scheme requires an energy overhead of 210.66 mJ and communication overhead of 2144 bits while conforming to the desired security specifications.



---

*Source: 7264803-2022-06-22.xml*