1. Introduction
The Internet of Things (IoT) is a network of physical objects (for example, smart devices) such as smart vehicles, smart industrial monitoring machines, smart home appliances, and many more. Such objects are connected together to gather, process, rectify, and exchange relevant data over the Internet [
1,
2,
3,
4,
5,
6]. Furthermore, smart devices along with application programming interfaces (APIs) are used to connect and exchange data over the Internet. Each physical object (i.e., smart lighting system) has a provided IP address, which makes it capable to communicate (i.e., sending and receiving) over the network without human involvement. The shortage of IPv4 addresses resulted in designing the “IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN)”, which has significantly changed the IoT in order to increase the use of IPv6 by smart, as well as small scale objects [
7]. The IoT communication environment is used in various types of applications, such as “smart health care”, “smart traffic monitoring”, and “smart homes”, to name a few. Edge computing introduced a new concept of computing. It has already become popular in industry, as well as academic research communities. It empowers many future technologies (for example, 5G, vehicle-to-vehicle and vehicle-to-cloud communications, augmented reality) by putting the connection in between end users and the cloud computing model and services [
8,
9,
10]. Edge computing brings the utilities and services of cloud computing, which results in the faster processing and quicker response time of applications. Edge computing facilities the produced data of smart devices in the IoT environment to be processed nearby the location where it was generated in place of sending it across long routes to the “cloud” or “data centers” [
10,
11,
12]. Though the edge based IoT environment provides many advantages over the traditional computing environment, at the same time, it has also the following security and privacy issues:
The exchanged messages among different communicating parties (i.e., “IoT device”, “edge node”, and “cloud server”) should be protected against several known attacks (for example, “replay”, “man-in-the-middle”, “impersonation”, “offline or online password guessing”, and some other kinds of “bypassing attacks”).
The edge node receives and processes the data, which are sent by the IoT devices. After the required processing, the edge node sends the data to the cloud server(s) for further processing and storage. Sometimes, the sent data are very critical and important, and any kind of disclosure of the data creates big trouble. Therefore, we need strong secure privacy preservation techniques to protect the data in the edge based IoT environment.
As existing authentication protocols have security flaws that make them vulnerable to some known attacks (for example, “privileged insider attack”, “online and offline password guessing”, etc.), consequently, it becomes important to enhance the security of the authentication protocols, for instance in the case of “new device addition or revocation”, other communicating parties of the network should also be informed by the concerned (trusted) authority so that they can become aware about this activity and can update their memories accordingly [
1,
4]. Hence, it is an exigent task to provide a design for such a kind of protocol that supports “dynamic installation/update” without compromising the security of the system [
4].
In the edge based IoT environment, there is a possibility that some IoT devices may be “physically stolen/captured” by the adversary
. After the physical capturing,
can use a “power analysis attack” [
13] to obtain the data from the memory of the captured smart IoT devices. Later on, this drawn out information is used for other malicious works, such as deriving the “session key” among an IoT device and cloud server.
can replace the physical captured device with his/her own malicious device(s) that he/she has cloned in the laboratory. We should be more careful while going for the design of authentication and key management techniques in case some IoT devices are physically compromised so that there should not be any affect on the security of communication happening in the rest of the network [
1,
4].
As discussed earlier, the edge based IoT environment has several issues related to security and privacy. The existing authentication schemes have various “security flaws” that make them vulnerable to different known and unknown attacks. Some of them are not efficient from the computation and communication cost point of few. Hence, there is an essential requirement for a new “lightweight authentication and key management” scheme for the edge based IoT environment. Consequently, we design a new “lightweight authentication and key management” scheme for such an environment.
1.1. Contributions of LDAKM-EIoT
The contributions of this paper are many-fold in the following contexts:
We propose a new “lightweight authentication and key management” scheme for edge based IoT environment (LDAKM-EIoT). In LDAKM-EIoT, we use various efficient operations such as bitwise “exclusive-OR (XOR)” and “one way collision resistant cryptographic hash functions”.
LDAKM-EIoT is secure against different kinds of attacks by the help of “formal security verification” using the widely used AVISPA tool and also through other mathematical security analysis.
The detailed comparative investigation among related existing schemes and LDAKM-EIoT evidences that LDAKM-EIoT achieves more security and additional functionality features and LDAKM-EIoT has also less communication and computation costs as compared to the other related schemes.
The practical simulation study of LDAKM-EIoT is also executed with the help of the broadly used NS2 tool.
1.2. Paper Structure
The information about the “network model” and “threat model” of LDAKM-EIoT is discussed in
Section 2. The brief discussion on the related existing authentication techniques is provided in
Section 3. Different phases of LDAKM-EIoT are explained in
Section 4. The security analysis of LDAKM-EIoT is conducted in
Section 5. The formal security verification by the help of the AVISPA tool is done and explained in
Section 6. The performance comparison among LDAKM-EIoT and other related existing authentication techniques is explained in
Section 7. The impact of LDAKM-EIoT and other related schemes on network performance parameters is measured, analyzed, and then compared in
Section 8 using the NS2 simulation. At last, the paper is concluded in
Section 9.
2. Related Work
Wolf and Serpanos [
14] explained different security issues of cyber-physical systems (CPS) and IoT systems. They discussed a security (safety) threat model for CPS and IoT systems. Ni et al. [
15] explained the role of fog nodes in various IoT applications. After that, they examined several promising IoT applications as per these different roles.
Yeh et al. [
16] demonstrated an “elliptic curve cryptography (ECC)” based user authentication mechanism for wireless sensor networks (WSNs). Their scheme did not achieve the mutual authentication property. To fix the problem of their scheme, Shi and Gong [
17] proposed another improved “ECC based user authentication” scheme in WSNs. After that, Turkanovic et al. [
18] came up with another user “authentication and key establishment” protocol for heterogeneous WSNs. Later on, their scheme was discovered to be insecure against “offline password guessing”, “offline identity guessing”, “smart card stolen”, “sensor node impersonation”, and “user impersonation” attacks. Moreover, their scheme did not support one of the essential properties, named as “mutual authentication” [
19].
Khalil et al. [
20] shed some light on the integration of WSNs in IoT. In the IoT environment, smart devices have limited computing and storage resources, like WSNs. It is also emphasized that some of the existing authentication techniques had serious security flaws as they were vulnerable to “impersonation”, “sensing node physical capture”, “replay”, “man-in-the-middle”, and “privileged insider” attacks [
3,
21].
Farash et al. [
21] demonstrated a technique for “user authentication and key establishment” for heterogeneous WSNs, which can be applicable for IoT communication. Later on, Amin et al. [
22] did cryptanalysis on the scheme of Farash et al. [
21] and discovered that it was not secure against possible attacks such as “offline password guessing” by using the lost/stolen smart card, “session-specific temporary information leakage”, and “user impersonation” attacks. Furthermore, Amin et al. [
22] proposed an improved version of their scheme to mitigate the security flaws of Farash et al.’s scheme [
21]. Srinivas et al. [
23] demonstrated that the scheme of Amin et al. [
22] was insecure against “user impersonation”, “leakage of different keys”, “stolen smart card”, and “server spoofing” attacks. Srinivas et al. further presented an improved and enhanced version of their scheme for “user authentication” in multi-gateway WSNs applicable to the IoT environment. Jiang et al. [
24] also discovered the security flaws in the scheme of Amin et al. [
22] as it was not able to mitigate some attacks. To overcome these vulnerabilities in the scheme of Amin et al., Jiang et al. presented an improved scheme.
Hsieh and Leu [
25] proposed a new technique to resolve the security weaknesses of the other schemes [
26,
27,
28]. Later on, Wu et al. [
29] performed crypto-analysis of Hsieh–Leu’s scheme and identified the vulnerabilities of their scheme as it was not secure against different attacks such as “offline guessing”, “user forgery”, “insider attack”, and “sensor node physical capturing”. In addition, their scheme was not secure against the session key security, and also, it did not provide the mutual authentication property. To resolve these problems, Wu et al. presented a new “user authentication” protocol for WSN, which was also applicable to IoT communication.
Li et al. [
30] presented a device-to-device authentication protocol in the IoT environment. Their approach relied on public key techniques that needed public key encryption and decryption by the resource limited IoT smart devices. Though their approach maintained security, it demanded high communication and computation overheads from the IoT devices’ point of view.
Santos et al. [
31] designed a “federated identity management (FIdM)” system in order to assist in improving privacy and user authentication in the IoT deployment, where an IoT device accesses services from a service provider. Their approach was lightweight as it required low computational cost due to symmetric cryptographic operations. They applied their proposal to a cashless toll system environment.
Gope and Sikdar [
32] designed a “lightweight and privacy preserving two factor authentication” scheme in which physical security was included. In their proposal, an IoT device and a server mutually authenticated each other for accessing services in the IoT environment. However, their scheme needed more computational cost due to fuzzy extractor generation and reproduction functions [
33].
In order to design an access control and security policy, Han and Kim [
34] designed a mutual authentication scheme between IoT devices. Though their scheme was lightweight due to symmetric cryptographic operations, it did not preserve device anonymity and untraceability properties.
Group key management (GKM) is considered as another important security aspect in the IoT environment, which helps with assigning IoT devices into predefined groups in the network. After that, key management is essential within each group and also among various groups in order to improve efficiency and security in the IoT environment. For this issue, Kung and Hsiao [
35] designed an efficient GKM policy in an IoT deployment. Their approach also permitted joining and leaving the devices in a group dynamically in the IoT environment. Their approach was lightweight as it relied on the “cryptographic hash function” and symmetric cryptographic operations.
Raza and Magnusson [
36] pointed out that “unanimous consensus” is extremely essential in the IoT environment for cyber security purposes. They presented a lightweight adaptation of the “Internet Key Exchange Version 2 (IKEv2)” for the IoT deployment, called TinyIKE. With the help of TinyIKE, they were able to solve the key management issue for several IoT protocols by applying a single IKEv2 based approach. TinyIKE relies on certificates, elliptic curve cryptographic techniques, as well as symmetric cryptographic techniques.
Challa et al. [
3] recommended an ECC based user authentication protocol for IoT applications that can be used in the coming future. However, Jia et al. [
37] highlighted that Challa et al.’s method did not protect against impersonation attack and also it did not preserve the untraceability property. Moreover, Challa et al.’s scheme [
3] was expensive in computation and communication. Recently, Malani et al. [
38] presented a “certificate based device access control” scheme applied to IoT communication to mitigate the security problems and limitations of the existing authentication and access control protocols. Their scheme the preserved anonymity property.
Sharma and Kalra [
39] proposed a lightweight user authentication protocol that can be applied to healthcare services in the cloud-IoT environment. However, their scheme was insecure against privileged-insider attack during the registration of medical professional, where the password of the medical professional was easily guessed by an attacker with the help of stolen smart card attack and registered information supplied by the medical professional to the gateway node. Moreover, their scheme did not provide the sensor node anonymity property and session key security under the Canetti and Krawczyk (CK) adversary model [
40] (discussed in the threat model in
Section 3.2). Zhou et al. [
41] designed an authentication protocol that utilized IoT based architectures combined with cloud servers. Though their scheme was lightweight in nature, Martinez-Pelaez et al. [
42] pointed out that Zhou et al.’s scheme [
41] was vulnerable to various attacks, such as privileged-insider attack, man-in-the-middle attack, replay attack, and user impersonation attack. Furthermore, Martinez-Pelaez et al. also showed that Zhou et al.’s scheme failed to provide mutual authentication and secret key protection. To mitigate the security limitations mentioned in Zhou et al.’s scheme, Martinez-Pelaez et al. proposed an efficient authentication scheme.
As discussed above, most of the available methods for “authentication and key agreement” for communication in IoT and WSNs are insecure against different types of attacks. In addition, some of these techniques use heavy weight operations as they require more communication and computing resources. As a result, these existing techniques demonstrated for the “IoT environment” may not be much suitable for the authentication procedure in the edge based IoT environment. Consequently, we perceive that there is a requirement for a secure “authentication and key management” mechanism for the edge based IoT environment that should be lightweight. To fulfill this goal, we propose a new “lightweight authentication and key management” scheme for the edge based IoT environment that utilizes only an efficient “one way cryptographic hash” function and “bitwise ” operation.
4. The Proposed Scheme: LDAKM-EIoT
In this section, we talk about the precise workings of the proposed scheme, called the “lightweight authenticated key management mechanism for the edge-based IoT environment (LDAKM-EIoT)”. The distinct phases of LDAKM-EIoT are provided in the upcoming part of the paper. It was also assumed that the different network entities (i.e., IoT device, edge node, cloud server) were synchronized with their clocks. It is mandatory to have this assumption while we go for the designing of an authentication mechanism for different networks [
1,
2,
3,
46,
47,
48]. We needed different notations for the designing of LDAKM-EIoT, which we summarize in
Table 1 along with their significance.
4.1. Pre-Deployment Phase
This phase permitted the trusted authority , a fully trusted entity in the network, to perform the registration of IoT devices, edge nodes, and cloud servers before they were installed in the deployment area. We assumed that number of IoT devices were associated with a particular edge node , and the real-time information could be accessed from the IoT devices to number of cloud servers , provided that a mutual authentication and key establishment happened successfully among the IoT devices and cloud servers with the presence of the edge node .
4.1.1. Registration of IoT Devices
The firsts picked a distinct unique identity for every IoT device and computed its corresponding pseudo identity as , temporal credentials , where is the registration timestamp for , is a 1024 bit shared secret key between each IoT device and edge nodes generated by the , where , and is the total count of IoT devices. Moreover, is the identity of an edge node where the IoT devices need to authenticate a cloud server with an IoT device . is the identity of , and n is a 160 bit secret number of that is only disclosed to the . After that, generates a temporary identity for each . Note that temporal credentials are different for each IoT device , which protects against various attacks including impersonation attack, in case any IoT device is physically compromised by an attacker. Lastly, the trusted authority stores the credentials {} in the memory of prior to its placement in the IoT network.
4.1.2. Registration of Cloud Servers
The picks a distinct unique identity for each cloud server and proceeds to calculate its pseudo identity as and where is the registration timestamp for and , are the number of cloud servers placed initially in the IoT network, while is a 1024 bit shared secret key of the edge node and cloud server generated by the . Next, the stores the credentials {} in the database of before its placement in the network.
4.1.3. Registration of Edge Node
The picks a distinct unique identity for edge node and stores previously computed information, as well as this information, that is , in the database of before its placement in the network.
The registration process is summarized in
Figure 2.
4.2. Authentication and Key Agreement Phase
The key management procedure helps to secure the authentication and key management among IoT devices and cloud servers by the involvement of a trusted edge node. The upcoming steps are essential to achieve this goal.
- A1.
When an IoT device, say , wants to initiate secure data transmission to a cloud server, first of all, needs to compute the following parameters. picks a random nonce and current timestamp and calculates and . Next, sends the message to the edge node via an open channel.
- A2.
After the arrival of message at time , the checks the timeliness of with the verifying condition . If it is valid, the fetches , , , and corresponding to received and computes , and checks whether . If it is valid, is authenticated by the and can access its resources to get access to a cloud server selected by the . Next, the chooses a random nonce and current timestamp , picks from its database corresponding to , and computes , and . After that, the sends the message to via an open channel.
- A3.
After the arrival of message at time , verifies the timeliness of by checking if is valid. After successful verification of , computes , and . After that, checks whether is satisfied. If it is valid, the is authenticated by . Otherwise, halts the session with the immediately. Furthermore, picks up a random nonce and current timestamp and computes . Then, computes the session key shared with as , , and . After computing these values, sends the message to the via an open channel.
- A4.
After arrival of message at time , the verifies the timeliness of by checking if is valid. Upon successful validation of , the calculates and . Next, the checks whether , and if it holds, is authenticated by the . Otherwise, the halts the session with instantly. Furthermore, the selects a random nonce along with current timestamp and computes , , and . After computing these values, the picks a new temporary identity for and calculates . The also replaces with in its database. Finally, the sends the message to via an open channel.
- A5.
After arrival of message at time , verifies the timeliness of by checking if is valid. After successful validation of , calculates , , , the shared session key with as . In addition, also calculates and . Then, checks whether , and if it is legitimate, the , as well as are authenticated by , and the computed session key is treated as the valid one. Thus, both and will maintain the same computed shared session key for secret communications. Moreover, calculates the new temporary identity as and will use this new identity in all its future communications with the and . It is worth noticing that the new temporary identity generation mechanism makes the proposed scheme prevent the traceability attack.
Finally, the above phase is abridged in
Figure 3.
Remark 1 (Protection for synchronization attack).
We may consider a situation where the message has been tampered with or there is a communication error that occurs so that an IoT device cannot receive the parameter , as well as the new temporary identity . In order to resolve this problem, we contemplated a possible solution suggested in [49], where an IoT device needs to maintain a set of l shadow identities {}. In this context, when an IoT device, say , could not receive the message within a specific time period (maximum round-trip time), it needs to select one of the unused shadow identities, say , and then send it within the message . When the receives the , it can generate a new TIDand send it securely to the device . By using this method, we can address the synchronization attacks without compromising the privacy of an IoT device in the proposed scheme (LDAKM-EIoT). 4.3. Dynamic Node Addition Phase
There is the chance that some of the IoT devices fail to work properly or might stop their working completely. Furthermore, there is the possibility that some of the IoT devices can be “physically stolen (capture)” by an adversary . In order to draw out the useful data from the stolen IoT devices (i.e., session key, temporary and pseudo identities, and other credentials stored in their memory), henceforth, it becomes very important to add new IoT devices in the required area. LDAKM-EIoT provides a facility for the addition of new IoT devices and also cloud servers in the network at any time after initial installment.
4.3.1. Dynamic IoT Device Addition
The upcoming procedure is needed to add a new IoT device, say , in the required part of the IoT environment.
DD1. The picks a new unique identity for the new IoT device and computes its corresponding pseudo identity as , temporal credentials , where is registration timestamp generated for and is the shared secret key between IoT device and the edge node generated by the . also generates a unique temporary identity for that is different from the previously deployed IoT devices.
DD2. The stores the credentials {} in the memory of before its placement in the deployment area. Furthermore, the securely sends the information related to to so that the can update these information in its database corresponding to the newly added IoT device . Note that for secure communication between and , a pre-shared symmetric key among them is essential, and it is generated by the prior to the placement of the .
4.3.2. Dynamic Cloud Server Addition
The upcoming procedure is required to add a new cloud server, say , in the required part of the IoT environment.
DC1. The chooses a distinct unique identity for and computes its pseudo identity as and where is the registration timestamp for . Moreover, is the shared secret key of the edge node and cloud server generated by the .
DC2. The then stores the credentials {} into the database of prior to its deployment in the IoT environment.
5. Security Analysis of LDAKM-EIoT
In this section, we provide the security analysis of LDAKM-EIoT in Propositions 1–7, which prove its robustness against the following possible attacks.
Proposition 1. LDAKM-EIoT is resilient against replay attack.
Proof. In LDAKM-EIoT, we utilized various current timestamp values for the communicating entities (, , and ). In the each exchanged message of LDAKM-EIoT, we used the maximum transmission delay factor, which is a small value. Consequently, an adversary can not gain any advantage in replaying the old transmitted messages, which are used in the authentication and key management procedure among , , and within . Thus, LDAKM-EIoT is secure against replay attack. □
Proposition 2. LDAKM-EIoT is resilient against man-in-the-middle attack (MITM).
Proof. Suppose an adversary seizes an authentication request message exchanged between and and further tries to update this message in such a way that it looks similar to a genuine authentication message, as by using the parameters such as and . The values of the used variables are , , where is the registration timestamp for and is the shared secret key of IoT device and edge node generated by the . To launch this attack, can initiate the generation of random nonce and current timestamp . However, without obtaining the information about “long term secret” , , , n, and , cannot re-create another valid authentication request message . By using a similar approach, we can also explain that other messages cannot be recomputed by , which are used in the “authentication and key management” phase without the “long term secrets” used by , , and . This proves the resilience of LDAKM-EIoT against MITM. □
Proposition 3. LDAKM-EIoT provides protection against different impersonation attacks.
Proof. Suppose an adversary attempts to create a valid authentication request message on behalf of a communicating party (for example, ) after obtaining ’s authentication request sent towards the by , where and . The values of the used variables are , , and where is the registration timestamp for and is the shared secret key of IoT device and edge node generated by the . Note that uses and , which are computed using the “long term secrets”(, , , n, ) and also the “short term secrets” (random nonce ). Without knowing these secret values, is not able to create a valid authentication request message on behalf of the genuine IoT device . Hence, we can say that LDAKM-EIoT is resilient against IoT device impersonation attack. In the same way, it can also be proven that LDAKM-EIoT provides protection against edge node and cloud server impersonation attacks as the creation of other messages , , and employs both “long term” and “short term” secrets. Therefore, LDAKM-EIoT is secure against impersonation attacks. □
Proposition 4. LDAKM-EIoT protects Ephemeral secret leakage (ESL) attack.
Proof. In LDAKM-EIoT, the session key is computed by a genuine cloud server
and the accessed
during the the authentication and key management phase as
. Here,
where
is the shared secret key of the IoT device and edge node generated by the
and
is the shared secret key of the
and cloud server generated by the
. Further, the identities of the IoT device,
, the identity of the edge node
, and the identity of the cloud server
are also utilized. It is understandable that the “session key” is the combination of both the session temporary (ephemeral) information, also called “short term secrets” (different random nonces and timestamps), as well as the “long term secrets” (different secret keys and identities). Thus, the session key can only be disclosed if
compromises both the session temporary and long term secrets. Moreover, as different random nonces and timestamps are used in the computation of the session keys between
and
in distinct sessions, even if a session key is disclosed for a specific session, it will not result in computing the session keys of other sessions because of the combination of short and long term secrets. Thus, LDAKM-EIoT provides protection against session temporary information attack, and it also preserves the “perfect forward secrecy” goal. Therefore, LDAKM-EIoT is resilient against “ESL attack”. Consequently, LDAKM-EIoT preserves the session key security under the “CK adversary model” [
40]. □
Proposition 5. LDAKM-EIoT is resilient against privileged-insider attack.
Proof. The privileged-insider user of a cloud server, say , knows the registration information {}. However, he/she cannot calculate the “session key” on behalf of the cloud server as the session key utilizes the credentials that are only known to the IoT devices or the edge node. The “session key” calculated by the legitimate cloud server is . Moreover, is the random nonce of the . The identities of the IoT device, , the identity of the edge node , and identity of the cloud server are also utilized in . The privileged-insider user of the cloud server does not have any information about , , and . Therefore, cannot calculate the “session key” on behalf of the cloud server, as well as he/she cannot impersonate the cloud server, as explained in Proposition 3. Hence, LDAKM-EIoT is resilient against “privileged-insider attack”. □
Proposition 6. LDAKM-EIoT preserves the anonymity and untraceability properties.
Proof. Let us assume an adversary intercepts the messages , , , and during the “authentication and key management phase” between and via the . We used random nonces and current timestamps in the construction of messages, which helped to generate dynamic and unique messages for different sessions. Moreover, the identities , , and are not transmitted in the plaintext format during transmission. This helps to attain both the anonymity and untraceability objectives of LDAKM-EIoT. □
Proposition 7. LDAKM-EIoT provides protection against IoT device physical capture attack.
Proof. Each IoT device stores the credentials {
}, which are used for the “authentication and key management” purposes with other network communicating entities. The protection against IoT device physical capture attack is a very essential security requirement [
50,
51]. Suppose
IoT devices are physically captured by an adversary
. We assess the IoT device physical capture attack as the fraction of total secure communications that are compromised from the capturing of
IoT devices not including the communication in which the “compromised IoT devices” are straightforwardly extended. For example, one can estimate the probability of
’s ability to decrypt the secure communication between a cloud server
and a non-compromised IoT device
when
IoT devices are already physically stolen and compromised. Suppose this probability is represented by
. If
, an “authentication and key management” protocol is termed as “unconditionally secure against IoT device physical capture attack”. From a captured IoT device
,
will have the extracted credentials {
} along with the secret pairwise session key
shared between
and
from its memory. However, it is very important to notice that all
,
,
,
,
, and
are distinct for all installed IoT devices. Thus, the stolen
by
can only help to find the secret keys between that
and
. Furthermore, this results in all other secret keys between that
and other non-compromised IoT devices
to be not still revealed. Therefore, compromising an IoT device will not cause the compromise of the entire communication, and we get the secure communications among the cloud server and other non-compromised IoT devices. This means that LDAKM-EIoT is unconditionally secure against IoT device physical capture attack. □
6. Formal Security Verification Using AVISPA
This section shows the resilience of the proposed scheme (LDAKM-EIoT) against replay and man-in-the-middle attacks based on the formal security verification. We applied the broadly-accepted “Automated Validation of Internet Security Protocols and Applications (AVISPA)” tool [
52] to achieve this goal. There are four backends, namely “on-the-fly mode-checker (OFMC)”, “constraint-logic based attack searcher (CL-AtSe)”, “SAT (Boolean satisfiability problem) based model checker (SATMC)”, and “tree automata based on automatic approximations for the analysis of security protocols (TA4SP)”, which are integrated with the AVISPA tool. These backends help in automatic execution analysis of the security protocols. The “High-Level Protocol Specification Language (HLPSL)” helps in converting the high level implementation of the the security protocols into the “Intermediate Format (IF)” using the HLPSl2IF translator. HLPSL defines the roles for all the involved participating entities in a protocol, which are termed as the basic roles. The compulsory roles, known as “session” and “goal and environment”, consist of the composition of the sessions along with globally defined constants, respectively. The IF is provided as input to one of the four backends to produce the “Output Format (OF)”, which explicitly explains under what conditions the protocol becomes “safe”, “unsafe”, or “inconclusive”. The precise discussion on AVISPA and its HLPSL is available in [
52]. The AVISPA tool is one of the widely used formal security verification tools. Researchers working in the authentication domain frequently use this software tool to validate the security of authentication protocols [
1,
2,
3,
46,
48,
53].
In our implementation of the proposed scheme (LDAKM-EIoT) under HLPSL, we defined four basic roles: (a) the role for the
, (b) the role for an IoT device
, (c) the role for the edge node
, and (d) the role for a cloud server
. Apart from these basic roles, we had two compulsory roles (“session” and “goal and environment”). We applied the “SPAN (Security Protocol ANimator for AVISPA)” [
54] for simulating LDAKM-EIoT. The backends that we covered were OFMC and CL-AtSe, because they support the bitwise XOR operation. Therefore, we excluded the simulation results under other backends (i.e., SATMC and TA4SP) from the simulation part, because they did not currently support XOR operation, and the results would be under these backends “inconclusive”.
Figure 4 shows the simulation results under the OFMC and CL-AtSe backends. The summary of these backends helped us to predict the security of a designed scheme against replay and man-in-the-middle attacks. Under the OFMC backend, the simulation took 1019 milliseconds, while traversing 129 visited nodes at a depth of 20 plies. On the other hand, under the CL-Atse backend, 256 states were analyzed, and out of those states, 124 states were reachable with 0.58 s of translation time and 0.05 s of computation. The provided simulation results assured that LDAKM-EIoT was safe against the replay and man-in-the-middle attacks.