# LSKE: Lightweight Secure Key Exchange Scheme in Fog Federation

Authors: Yashar Salami; Vahid Khajehvand
Journal: Complexity
 (2021)

---

## Abstract

The fog computing architecture allows data exchange with the vehicle network, sensor networks, etc. However, before exchanging data, the nodes need to know each other and key exchange. Yashar et al. recently proposed a secure key exchange scheme for the fog federation. However, their proposed scheme has a high computational overhead and is not suitable for fog federation. Therefore, we have proposed a lightweight, secure key exchange scheme for the fog federation to reduce computational overhead. To prove the lightweight, we have compared the proposed scheme with the Yashar design in terms of computing, and communication cost AVISPA Tool was used for the formal analysis of the proposed scheme. Then, we simulated the proposed scheme with the NS3 tool and compared it with Throughput, packet loss, Packet Delivery, and end-to-end delay with Yashar et al. scheme. The results show that the proposed design reduced 3.2457 ms of computational overhead and 1,024 transmitted data bits.


---

## Body

## 1. Introduction

The spread of distributed systems such as the cloud [1] has made it possible for users to access their data from anywhere and share or process their data. Furthermore, with the expansion of various branches of computer science and the relationship between these sciences, the development of distribution systems has accelerated. Today, the Internet of Things is connected to the fog layer and can generate thousands of data at any time that are sent to the fog layer for processing [2].However, the fog layer needs to provide the necessary security for data processing between its nodes before processing the data. One of the most important challenges in maintaining security is how to exchange the key from the other side so that it is resistant to known attacks in the fog layer.Novel remote user authentication and key agreement scheme for mobile client-server environment scheme in 2013 were proposed by Sun et al. [3]. This scheme was not secure and could not support the fog federation. In 2015, Li et al. [4] proposed smart card-based mutual authentication schemes in cloud computing. This scheme was not secure and could not support the fog federation. Security and privacy preservation scheme of face identification and resolution framework using fog computing in the Internet of things was presented by Hu et al. [5] in 2017; this scheme did not support fog federation and key exchange. The scheme proposed by Jia et al. [6], Wazid et al. [7], Chen et al. [8], Zheng and Chang [9], and Chen et al. [10] in 2019, 2020, and 2021 were all safe and supportive of mutual authentication and key exchange. However, they are not suitable for fog federation environments. Yashar et al. [11] proposed a secure key exchange scheme in the fog federation in 2021. This scheme supported mutual authentication and key exchange; however, this scheme is not lightweight. Table 1 shows a comparison of related work. Providing a secure and lightweight key exchange scheme in a fog federation environment is a challenge in this area.Table 1
Comparison of related work.
Related workFog federationSecureMutual authenticationKey exchangeLightweightSun et al. [3]xx✔✔xLi et al. [4]xx✔✔xHu et al. [5]x✔✔xxJia et al. [6]x✔✔✔xWazid et al. [7]X✔✔✔xChen et al. [8]x✔✔✔xZheng et al. [9]x✔✔✔xChen et al. [10]x✔✔✔xYashar et al. [11]✔✔✔✔xProposed scheme✔✔✔✔✔✔, the scheme is supported; X, the scheme is not supported.


### 1.1. Paper Contribution

(i)
In this paper, we propose a secure lightweight key exchange scheme for the fog federation(ii)
For formal security analysis, the proposed scheme uses the AVISPA tool(iii)
The proposed scheme is compared with Yashar et al. regarding computing cost, communication cost, and security requirement(iv)
The proposed scheme and Yashar et al. scheme are simulated with the NS3 tool and examined in terms of throughput, packet loss, packet delivery, and end-to-end delay criteria


### 1.2. Paper Organization

The rest of the paper is organized as follows. Section2 reviews the Yashar et al. and network model. The proposed scheme has been presented in Section 3. Section 4 provides a security analysis of the proposed scheme with the AVISPA tool. Section 5 presents the performance analysis and security requirements. Section 6 compares the proposed scheme's simulation results with Yashar et al. Finally, conclusions have been presented in Section 7.


## 1.1. Paper Contribution

(i)
In this paper, we propose a secure lightweight key exchange scheme for the fog federation(ii)
For formal security analysis, the proposed scheme uses the AVISPA tool(iii)
The proposed scheme is compared with Yashar et al. regarding computing cost, communication cost, and security requirement(iv)
The proposed scheme and Yashar et al. scheme are simulated with the NS3 tool and examined in terms of throughput, packet loss, packet delivery, and end-to-end delay criteria


## 1.2. Paper Organization

The rest of the paper is organized as follows. Section2 reviews the Yashar et al. and network model. The proposed scheme has been presented in Section 3. Section 4 provides a security analysis of the proposed scheme with the AVISPA tool. Section 5 presents the performance analysis and security requirements. Section 6 compares the proposed scheme's simulation results with Yashar et al. Finally, conclusions have been presented in Section 7.


## 2. The Background

This section provides the ECC and network model and problem statement and scheme of Yashar et al.


### 2.1. Review of ECC

The elliptic curve cryptography (ECC) is a public key encryption method, which has been designed based on an algebraic structure of elliptic curves on the finite fields. The curves of the elliptic equations are in the form ofy+axy+by=x3+cx2+dx+e. In this equation, ℝ=a,b,c,d,e. These are real numbers that must satisfy simple conditions. In these curves, a point is zero or a point in infinity. For more information, you can refer to [12].


### 2.2. Network Model and Problem Statement

The network model presented in Figure1 shows that cloud servers are at the top tier and can communicate with each other. In the network model, there is a middle layer of fog nodes. In this layer, there is a central fog whose main task is to manage other fog nodes. The middle layer can be connected to the top layer and the low layer. The purpose of developing the haze layer was to reduce latency for bottom layer processing. At the low layer are IOV, IOS, IOE, and M2M devices. If these devices require high processing, they send their data to the fog layer for processing. In the fog layer, the central node needs to be aware of the identity of the nodes so that they can exchange data with each other. Furthermore, because the central node is being processed and managed, a secure, lightweight key exchange scheme is needed that can withstand known attacks.Figure 1
Network model [11].


### 2.3. Notations

The list of notations used in this paper is shown in Table2.Table 2
Notations used for the proposed work.
No.NotationsDescription1IDAIdentity of Alice (fog center)2IDBIdentity of Bob (fog node)3NCaNonce of Alice (fog center)4NCBNonce of Bob (fog node)5ChaChallenging of Alice (fog center)6CHbChallenging of Bob (fog node)7KasThe public key of Alice (fog center)8KbsThe public key of Bob (fog node)9TATimestamp of Alice (fog center)10TBTimestamp of Bob (fog node)11∆TExpiration time12hHash13||Concatenation


### 2.4. Review of Yashar Et Al

The key exchange request steps are as follows.Step 1: Bob generates an RB message to request the key exchange and transmits it to Alice. RB is calculated as follows:Bi=IDB,NCb,NHa,Kbs,TB,HBi=hBi,RB=HBi‖Bi.Step 2: Alice separates the file contents upon receiving RB and then hashes Bi and compares the Bi` hash with HBi. Then, if the hash of Bi and HBi are the same, she checks the packet timestamp with the predetermined ∆T. If the timestamp of the received packet is smaller than ∆T, the packet is valid. Next, Alice generates RBi, and Ai sends it to Bob. RB and Ai are calculated as follows:Bi`=hBi,Check if Bi`=HBi,Check if TB≤ΔT,HRBi=hIDB,NCb,CHb,Kbs,TA,,RBi=IDB,NCb,CHb,Kbs,TA,HRBiKbs.Key generation by Alice is as follows:(i)
To generate a Galois field, Alice selects a large prime number and calls itp. The field Zp might have p − 1 generators.(ii)
Alice selects one of the generators of Zp and calls itG.(iii)
Alice selects an arbitrary number and calls it a, and keeps it secrete. Then, the selected numbers are substituted in equation (1) to generate A:(1)A=GamodP,HAi=hIDA,NCa,CHa,Kas,P,G,A,TA,Ai=IDA,NCa,CHa,Kas,P,G,A,TA,HAiKbs.Step 3: Upon receiving Ai and RBi, Bob separates the contents of RBi with his public key and hashes the contents except for HRBi and compares RBi` with HRBi. Then, continue the calculation as follows:RBi decrypt by key Kbs,RBi`=hIDB,NCb,CHb,Kbs,TA,Check if RBi`=HRBi,Check if TA≤ΔT.Key generation by Bob are as follows:Bob uses equation (2) to generate B. Next, to obtain the shared key with Alice empowers A by b in the modulus of P, according to equation (3), the result would be the shared key agreed upon by Alice. In the next step, it calculate RAi from the following relation and sends it to Alice:(2)B=GbmodP,(3)K=AbmodP=GabmodP=Ga.bmodp,Ai decrypt by key Kbs,Ai`=hIDA,NCa,CHa,Kas,GNa,TA,Check if Ai`=HAi,Check if TA≤ΔT,HAi=hIDA,NCa,CHa,Kas,B,TB,RAi=IDA,NCa,CHa,Kas,B,HAi,TBKas.Step 4: Alice opens RAi with her public key, hashes the packet contents except for HAi, and compares RAi’ with HAi. Then, Alice empowers B bya in the modulus of P according to equation (4) to obtain the shared key. Figure 2 shows the key exchange scheme of Yashar et al. The shared key calculation is as follows:(4)K=BamodP=GbamodP=Ga.bmodpRAi decrypt by key KasRAi`=hIDA,NCa,CHa,Kas,B,TBCheck ifRAi`=RAiCheck  if TB≤ΔT.Figure 2
The key exchange scheme of Yashar et al.


## 2.1. Review of ECC

The elliptic curve cryptography (ECC) is a public key encryption method, which has been designed based on an algebraic structure of elliptic curves on the finite fields. The curves of the elliptic equations are in the form ofy+axy+by=x3+cx2+dx+e. In this equation, ℝ=a,b,c,d,e. These are real numbers that must satisfy simple conditions. In these curves, a point is zero or a point in infinity. For more information, you can refer to [12].


## 2.2. Network Model and Problem Statement

The network model presented in Figure1 shows that cloud servers are at the top tier and can communicate with each other. In the network model, there is a middle layer of fog nodes. In this layer, there is a central fog whose main task is to manage other fog nodes. The middle layer can be connected to the top layer and the low layer. The purpose of developing the haze layer was to reduce latency for bottom layer processing. At the low layer are IOV, IOS, IOE, and M2M devices. If these devices require high processing, they send their data to the fog layer for processing. In the fog layer, the central node needs to be aware of the identity of the nodes so that they can exchange data with each other. Furthermore, because the central node is being processed and managed, a secure, lightweight key exchange scheme is needed that can withstand known attacks.Figure 1
Network model [11].


## 2.3. Notations

The list of notations used in this paper is shown in Table2.Table 2
Notations used for the proposed work.
No.NotationsDescription1IDAIdentity of Alice (fog center)2IDBIdentity of Bob (fog node)3NCaNonce of Alice (fog center)4NCBNonce of Bob (fog node)5ChaChallenging of Alice (fog center)6CHbChallenging of Bob (fog node)7KasThe public key of Alice (fog center)8KbsThe public key of Bob (fog node)9TATimestamp of Alice (fog center)10TBTimestamp of Bob (fog node)11∆TExpiration time12hHash13||Concatenation


## 2.4. Review of Yashar Et Al

The key exchange request steps are as follows.Step 1: Bob generates an RB message to request the key exchange and transmits it to Alice. RB is calculated as follows:Bi=IDB,NCb,NHa,Kbs,TB,HBi=hBi,RB=HBi‖Bi.Step 2: Alice separates the file contents upon receiving RB and then hashes Bi and compares the Bi` hash with HBi. Then, if the hash of Bi and HBi are the same, she checks the packet timestamp with the predetermined ∆T. If the timestamp of the received packet is smaller than ∆T, the packet is valid. Next, Alice generates RBi, and Ai sends it to Bob. RB and Ai are calculated as follows:Bi`=hBi,Check if Bi`=HBi,Check if TB≤ΔT,HRBi=hIDB,NCb,CHb,Kbs,TA,,RBi=IDB,NCb,CHb,Kbs,TA,HRBiKbs.Key generation by Alice is as follows:(i)
To generate a Galois field, Alice selects a large prime number and calls itp. The field Zp might have p − 1 generators.(ii)
Alice selects one of the generators of Zp and calls itG.(iii)
Alice selects an arbitrary number and calls it a, and keeps it secrete. Then, the selected numbers are substituted in equation (1) to generate A:(1)A=GamodP,HAi=hIDA,NCa,CHa,Kas,P,G,A,TA,Ai=IDA,NCa,CHa,Kas,P,G,A,TA,HAiKbs.Step 3: Upon receiving Ai and RBi, Bob separates the contents of RBi with his public key and hashes the contents except for HRBi and compares RBi` with HRBi. Then, continue the calculation as follows:RBi decrypt by key Kbs,RBi`=hIDB,NCb,CHb,Kbs,TA,Check if RBi`=HRBi,Check if TA≤ΔT.Key generation by Bob are as follows:Bob uses equation (2) to generate B. Next, to obtain the shared key with Alice empowers A by b in the modulus of P, according to equation (3), the result would be the shared key agreed upon by Alice. In the next step, it calculate RAi from the following relation and sends it to Alice:(2)B=GbmodP,(3)K=AbmodP=GabmodP=Ga.bmodp,Ai decrypt by key Kbs,Ai`=hIDA,NCa,CHa,Kas,GNa,TA,Check if Ai`=HAi,Check if TA≤ΔT,HAi=hIDA,NCa,CHa,Kas,B,TB,RAi=IDA,NCa,CHa,Kas,B,HAi,TBKas.Step 4: Alice opens RAi with her public key, hashes the packet contents except for HAi, and compares RAi’ with HAi. Then, Alice empowers B bya in the modulus of P according to equation (4) to obtain the shared key. Figure 2 shows the key exchange scheme of Yashar et al. The shared key calculation is as follows:(4)K=BamodP=GbamodP=Ga.bmodpRAi decrypt by key KasRAi`=hIDA,NCa,CHa,Kas,B,TBCheck ifRAi`=RAiCheck  if TB≤ΔT.Figure 2
The key exchange scheme of Yashar et al.


## 3. Proposed Scheme

This section presents the proposed scheme. The key exchange request steps are as follows:Step 1: calculates the fog node of the equationA1=IDA,IDB,TA,Kas and send it to the fog center.Step 2: the Fog center first checks the time stamp with the expiration time; if the timestamp is shorter than the expiration time, it stores theKas key.In the next step, he chooses the numbersa,b,p,R1,R2,and NB and calculates them through equations H1,B1,H2,B2,H3, and PB, through equation (5). Finally, it sends B3 to the fog node:(5)H1=hIDA,IDB,Kbs,B1=IDA,IDB,Kbs,H1,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 3: the Fog node first checks the time stamp with the expiration time; if the timestamp is shorter than the expiration time, it stores theKas key. It then hashes B1, B2, and B3 and compares it to H1, H2, and H3 to ensure that the message is not tampered with. It then saves a, b, p, R1, R2, and PB. The fog node selects a random number in the next step, places it in equation (6), and obtains PA.(6)PA=NA∗GR1,R2.After the following calculations, it sends A2 and H4 to the fog center:H4=hPA,A2=PA,TA,H4Kbs.Fog node through equation (7) calculates the common key:(7)K=NA∗PB.Step 4: the Fog center first checks the time stamp with the expiration time; if the timestamp is shorter than the expiration time, it first hashes A2 and compares it to H4. Then, it checks the time stamp with the expiration time; if the timestamp is shorter than the expiration time, the fog center calculates the common key through equation (8). Figure 3 shows the proposed scheme.(8)K=NB∗PA.Figure 3
The proposed scheme.


## 4. Security Analysis

This section presents the simulation results of the proposed scheme with the AVISPA tool.The AVISPA tool is a formal simulation to assess whether a secure or insecure protocol [13]. AVISPA uses an HLPSL language to describe and display the security specifications of protocols. HLPSL is a role-oriented language in which each entity plays an independent role during the protocol implementation [14]. In HLPSL, a legal role is conceived for the attacker, modeled by Dolew-yao [15]. AVISPA has four built-in tools OFMC (On-the-Fly Model-Checker) [16], CL-AtSe (Constraint Logic-based Attack Searcher) [17], SATMC (SAT-based Model-Checker) [18], and TA4SP (Tree Automata based on Automatic Approximations for the Analysis of Security Protocols) [19] that are used for security analysis. After parsing, the output results indicate whether the protocol is secure or insecure.


### 4.1. Analysis of Simulation Results

Figures4 and 5 show the simulation results showing the proposed design with security tools OFMC and CL-AtSe. The simulation results in the OFMC show that the total number of nodes visited for the proposed scheme was 17 and with a depth of 4 in 0.14 seconds. The simulation results in the CL-AtSe show that the total number of analyzed and reachable for the proposed scheme was four states in translation time was 0.04 seconds. Furthermore, the security analysis results with tools OFMC and CL-AtSe show that the proposed scheme is secure.Figure 4
Simulation results of the proposed scheme under OFMC.Figure 5
Simulation results of the proposed scheme under CL-ATSe.


## 4.1. Analysis of Simulation Results

Figures4 and 5 show the simulation results showing the proposed design with security tools OFMC and CL-AtSe. The simulation results in the OFMC show that the total number of nodes visited for the proposed scheme was 17 and with a depth of 4 in 0.14 seconds. The simulation results in the CL-AtSe show that the total number of analyzed and reachable for the proposed scheme was four states in translation time was 0.04 seconds. Furthermore, the security analysis results with tools OFMC and CL-AtSe show that the proposed scheme is secure.Figure 4
Simulation results of the proposed scheme under OFMC.Figure 5
Simulation results of the proposed scheme under CL-ATSe.


## 5. Performance Analysis

In this section, the performance analysis of the proposed scheme and security requirements are compared with Yashar et al. The following symbols are defined to evaluate the computing cost of the proposed scheme. Th is the execution number of a hash operation. Pm is the execution number of Point Multiplication. Pe is the execution number of public key encryption. Pd is the execution number of public key decryption. Se is the execution number of symmetric key encryption. Sd is the execution number of symmetric key decryption. The execution time to perform the computation is as follows. Th ≈0.0023, Pm ≈ 2.226, Pe ≈ 3.8500, Pd ≈ 3.8500, Se ≈ 0.0046, and Sd ≈ 0.0046. The proposed scheme uses 1024 bit RSA.


### 5.1. Computation Cost

Table3 shows a comparison of the computing cost of the proposed scheme and the Yashar et al. scheme. Our observations show that the Yashar scheme consists of 7 Th, 3Pe, and 3Pd; the total cost is 23.1161 ms. On the contrary, our proposed scheme consists of 8Th, 2Pm, 2Pe, and 2Pd; the total cost is 19.8704 seconds. Thus, compared to Yashar et al., the proposed scheme reduced the calculation by 3.2457.Table 3
Comparison of computation cost.
No.SchemesHash functionPoint multiplication (Pm)Public key encryptionPublic key decryptionSymmetric key encryption (Se)Symmetric key decryptionTotal costTC (ms)1Yashar et al.7Th03Pe3Pd00Sd7Th + 3Pe + 3Pd23.11612Proposed8Th22Pe2Pd00Sd8Th + 4Pm + 2Pe + 2Pd19.8704


### 5.2. Communication Cost

Table4 shows a comparison of the communication cost of the proposed scheme, and the Yashar et al. scheme has a communication cost of 3, and the total number of bits used is 3072. In our proposal, the communication cost is three, and the total number of bits used is 2048. Thus, we reduced 1,024 bits sent over the scheme of Yashar et al.Table 4
Comparison of communication cost and the number of bits.
No.SchemesNo. of messagesTotal cost (in bits)1Yashar et al.330722Proposed32048


### 5.3. Security Requirements’ Comparison

Our observations show that the proposed scheme is resistant to defined attacks. However, our proposal also cannot support device anonymity and session key agreement. Table5 shows the security requirements’ comparison of the proposed scheme with the Yashar et al. scheme. Note: AF1: replay attack; AF2: man-in-the-middle attack; AF3: insider attack; AF4: impersonation attack; AF5: brute force attack; AF6: offline password guessing attack; AF7: device anonymity; AF8: mutual authentication; AF9: session key agreement; AF10: key exchange, AF11: fog federation; AF12: OFMC; AF13: CL-ATSE; ✔: the scheme is supported; X: the scheme is not supported.Table 5
Comparison of security requirements.
Security requirementsSchemeYashar et al.ProposedAF1✔✔AF2✔✔AF3✔✔AF4✔✔AF5✔✔AF6✔✔AF7XxAF8✔✔AF9XxAF10✔✔AF11✔✔AF12✔✔AF13✔✔


## 5.1. Computation Cost

Table3 shows a comparison of the computing cost of the proposed scheme and the Yashar et al. scheme. Our observations show that the Yashar scheme consists of 7 Th, 3Pe, and 3Pd; the total cost is 23.1161 ms. On the contrary, our proposed scheme consists of 8Th, 2Pm, 2Pe, and 2Pd; the total cost is 19.8704 seconds. Thus, compared to Yashar et al., the proposed scheme reduced the calculation by 3.2457.Table 3
Comparison of computation cost.
No.SchemesHash functionPoint multiplication (Pm)Public key encryptionPublic key decryptionSymmetric key encryption (Se)Symmetric key decryptionTotal costTC (ms)1Yashar et al.7Th03Pe3Pd00Sd7Th + 3Pe + 3Pd23.11612Proposed8Th22Pe2Pd00Sd8Th + 4Pm + 2Pe + 2Pd19.8704


## 5.2. Communication Cost

Table4 shows a comparison of the communication cost of the proposed scheme, and the Yashar et al. scheme has a communication cost of 3, and the total number of bits used is 3072. In our proposal, the communication cost is three, and the total number of bits used is 2048. Thus, we reduced 1,024 bits sent over the scheme of Yashar et al.Table 4
Comparison of communication cost and the number of bits.
No.SchemesNo. of messagesTotal cost (in bits)1Yashar et al.330722Proposed32048


## 5.3. Security Requirements’ Comparison

Our observations show that the proposed scheme is resistant to defined attacks. However, our proposal also cannot support device anonymity and session key agreement. Table5 shows the security requirements’ comparison of the proposed scheme with the Yashar et al. scheme. Note: AF1: replay attack; AF2: man-in-the-middle attack; AF3: insider attack; AF4: impersonation attack; AF5: brute force attack; AF6: offline password guessing attack; AF7: device anonymity; AF8: mutual authentication; AF9: session key agreement; AF10: key exchange, AF11: fog federation; AF12: OFMC; AF13: CL-ATSE; ✔: the scheme is supported; X: the scheme is not supported.Table 5
Comparison of security requirements.
Security requirementsSchemeYashar et al.ProposedAF1✔✔AF2✔✔AF3✔✔AF4✔✔AF5✔✔AF6✔✔AF7XxAF8✔✔AF9XxAF10✔✔AF11✔✔AF12✔✔AF13✔✔


## 6. Simulation and Result

In this section, a simulation of the proposed design with the Yashar design is provided. In addition, simulation by network simulation tool (NS 3 2.29 simulator) on the Ubuntu-20.04.1 platform is provided. The hardware environment for carrying out NS3 simulation [20] was on Dell Inspiron 5110 machine with Intel Core i5 2410 M/2.30 GHz processor having 4 GB RAM and 1 TB HDD (Hard Disk Drive).


### 6.1. Simulation Environment and Settings

The various parameters used in the NS3 simulations are provided in Table6. The simulation time of the proposed scheme was 1800 seconds. The number of fog centers is ten, and the fog node is 20. Other parameters are as follows: the mobility of the fog centers and fog node is 0 m/s, loss model is Friis loss, transmit power is 7.5-dBm, medium access control type IEEE 802.11, wireless protocol 802.11 p, routing protocol: OLSR, and Simulation Environment Area is 300∗1500M.Table 6
Simulation parameters.
ParametersDescriptionPlatformUbuntu-20.04.1Hardware platformDell 5110, Intel Core i5, 4 GB RAM, 1 TB HDDTool usedNS 3 2.29Number of fog node20Number of fog center10Mobility of fog node0Mobility of fog center0Simulation environment area300∗1500 MLoss modelFriis lossTransmit power7.5 dBRouting protocolOLSRMedium access control typeIEEE 802.11Wireless protocol802.11 pCommunication range of fog node to fog center100 MSimulation time1800 seconds


### 6.2. Simulation Results

The simulation results show that the proposed scheme performs better in terms of throughput than the Yashar et al. scheme. Figure6 shows a comparison of the proposed scheme and Yashar et al. scheme in terms of throughput. The proposed scheme has a much better performance in packet loss than Yashar et al. Figure 7 compares the proposed scheme and Yashar et al. scheme in packet loss. In terms of packet delivery rate, the proposed scheme has shown better performance than Yashar et al. Figure 8 compares the proposed scheme and Yashar et al. scheme in terms of the packet delivery rate. Finally, in terms of end-to-end delay, the performance of the proposed design is better than that of Yashar et al. Figure 9 shows a comparison of the proposed scheme and the Yashar et al. scheme in terms of end-to-end delay.Figure 6
Comparison of throughput.Figure 7
Comparison of packet loss.Figure 8
Comparison of packet delivery.Figure 9
Comparison of end-to-end delay.


## 6.1. Simulation Environment and Settings

The various parameters used in the NS3 simulations are provided in Table6. The simulation time of the proposed scheme was 1800 seconds. The number of fog centers is ten, and the fog node is 20. Other parameters are as follows: the mobility of the fog centers and fog node is 0 m/s, loss model is Friis loss, transmit power is 7.5-dBm, medium access control type IEEE 802.11, wireless protocol 802.11 p, routing protocol: OLSR, and Simulation Environment Area is 300∗1500M.Table 6
Simulation parameters.
ParametersDescriptionPlatformUbuntu-20.04.1Hardware platformDell 5110, Intel Core i5, 4 GB RAM, 1 TB HDDTool usedNS 3 2.29Number of fog node20Number of fog center10Mobility of fog node0Mobility of fog center0Simulation environment area300∗1500 MLoss modelFriis lossTransmit power7.5 dBRouting protocolOLSRMedium access control typeIEEE 802.11Wireless protocol802.11 pCommunication range of fog node to fog center100 MSimulation time1800 seconds


## 6.2. Simulation Results

The simulation results show that the proposed scheme performs better in terms of throughput than the Yashar et al. scheme. Figure6 shows a comparison of the proposed scheme and Yashar et al. scheme in terms of throughput. The proposed scheme has a much better performance in packet loss than Yashar et al. Figure 7 compares the proposed scheme and Yashar et al. scheme in packet loss. In terms of packet delivery rate, the proposed scheme has shown better performance than Yashar et al. Figure 8 compares the proposed scheme and Yashar et al. scheme in terms of the packet delivery rate. Finally, in terms of end-to-end delay, the performance of the proposed design is better than that of Yashar et al. Figure 9 shows a comparison of the proposed scheme and the Yashar et al. scheme in terms of end-to-end delay.Figure 6
Comparison of throughput.Figure 7
Comparison of packet loss.Figure 8
Comparison of packet delivery.Figure 9
Comparison of end-to-end delay.


## 7. Conclusion

The secure key exchange in fog federation environments is a major challenge. This paper presents a lightweight, secure key exchange scheme based on ECC for fog federation environments. The results of the AVISPA tool show that the proposed scheme is safe, and the proposed scheme is compared with Yashar et al. Comparison results show that the proposed scheme has a lower computational and byte cost. The proposed scheme is then simulated with the NS3 tool. The simulation results show that the proposed scheme performs better in terms of throughput, packet loss, packet delivery, and end-to-end delay than Yashar et al. In future work, our goal is to provide a three-way key exchange scheme in fog federation.



---

*Source: 4667586-2021-10-25.xml*