LSKE: Lightweight Secure Key Exchange Scheme in Fog Federation

. 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.2457ms of computational overhead and 1,024 transmitted data bits.


Introduction
e 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 ings 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]. is 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.is 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.e 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. is 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.

The Background
is section provides the ECC and network model and problem statement and scheme of Yashar et al.

Review of ECC.
e 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.e curves of the elliptic equations are in the form of y + axy + by � x 3 + cx 2 + dx + e.In this equation, R � a, b, c, d, e { }. ese 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].

Network Model and Problem Statement.
e network model presented in Figure 1 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.
e middle layer can be connected to the top layer and the low layer.e 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.

Notations.
e list of notations used in this paper is shown in Table 2.

Review of Yashar Et Al.
e 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:

Cloud Layer Fog Layer
End device
Step 2: Alice separates the file contents upon receiving RB and then hashes Bi and compares the Bi`hash with HBi.en, if the hash of Bi and HBi are the same, she checks the packet timestamp with the predetermined ∆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: (3) Step 4: Alice opens RAi with her public key, hashes the packet contents except for HAi, and compares RAi' with HAi.en, Alice empowers B by a 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.
e shared key calculation is as follows:

Proposed Scheme
is section presents the proposed scheme.e key exchange request steps are as follows:

Complexity
Step 1: calculates the fog node of the equa-tionA1 � (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 the Kas key.
In the next step, he chooses the numbers a, 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: B3 � (PB, TB, H3, B1, B2)Kas. ( 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 the Kas 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. e fog node selects a random number in the next step, places it in equation ( 6), and obtains PA.
Fog node through equation ( 7) calculates the common key: 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. en, 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.

Security Analysis
is section presents the simulation results of the proposed scheme with the AVISPA tool.
e 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.

Analysis of Simulation Results
. Figures 4 and 5 show the simulation results showing the proposed design with security tools OFMC and CL-AtSe.e 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.e 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.

Performance Analysis
In this section, the performance analysis of the proposed scheme and security requirements are compared with Yashar et al. e following symbols are defined to evaluate the computing cost of the proposed scheme.
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.e execution time to perform the computation is as follows.
≈ 0.0023, Pm ≈ 2.226, Pe ≈ 3.8500, Pd ≈ 3.8500, Se ≈ 0.0046, and Sd ≈ 0.0046.e proposed scheme uses 1024 bit RSA. 3 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 , 3Pe, and 3Pd; the total cost is 23.1161 ms.On the contrary, our proposed scheme consists of 8 , 2Pm, 2Pe, and 2Pd; the total cost is 19.8704 seconds.us, compared to Yashar et al., the proposed scheme reduced the calculation by 3.2457.4 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.us, we reduced 1,024 bits sent over the scheme of Yashar et al.

Security Requirements' Comparison.
Our observations show that the proposed scheme is resistant to defined attacks.However, our proposal also cannot support device Complexity 6 Complexity anonymity and session key agreement.Table 5 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.

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.e hardware environment for carrying out NS3 simulation [20]    e various parameters used in the NS3 simulations are provided in Table 6.
e simulation time of the proposed scheme was 1800 seconds.e 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.

Simulation Results.
e simulation results show that the proposed scheme performs better in terms of throughput than the Yashar et al. scheme.Figure 6 shows a comparison of the proposed scheme and Yashar et al. scheme in terms of throughput.e 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 endto-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.

Conclusion
e secure key exchange in fog federation environments is a major challenge.is paper presents a lightweight, secure key exchange scheme based on ECC for fog federation environments.e 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.e proposed scheme is then simulated with the NS3 tool.e 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.
(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) e proposed scheme is compared with Yashar et al. regarding computing cost, communication cost, and security requirement (iv) e proposed scheme and Yashar et al. scheme are simulated with the NS3 tool and examined in terms of throughput, packet loss, packet delivery, and endto-end delay criteria 1.2.Paper Organization.e rest of the paper is organized as follows.Section 2 reviews the Yashar et al. and network model.e 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.

Figure 2 :
Figure 2: e key exchange scheme of Yashar et al.

Figure 5 :
Figure 5: Simulation results of the proposed scheme under CL-ATSe.

Figure 9 :
Figure 9: Comparison of end-to-end delay.

Table 1 :
Comparison of related work.

Table 2 :
Notations used for the proposed work.
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).

Table 3 :
Comparison of computation cost.

Table 4 :
Comparison of communication cost and the number of bits.

Table 5 :
Comparison of security requirements.