LDAKM-EIoT: Lightweight Device Authentication and Key Management Mechanism for Edge-Based IoT Deployment

In recent years, edge computing has emerged as a new concept in the computing paradigm that empowers several future technologies, such as 5G, vehicle-to-vehicle communications, and the Internet of Things (IoT), by providing cloud computing facilities, as well as services to the end users. However, open communication among the entities in an edge based IoT environment makes it vulnerable to various potential attacks that are executed by an adversary. Device authentication is one of the prominent techniques in security that permits an IoT device to authenticate mutually with a cloud server with the help of an edge node. If authentication is successful, they establish a session key between them for secure communication. To achieve this goal, a novel device authentication and key management mechanism for the edge based IoT environment, called the lightweight authentication and key management scheme for the edge based IoT environment (LDAKM-EIoT), was designed. The detailed security analysis and formal security verification conducted by the widely used “Automated Validation of Internet Security Protocols and Applications (AVISPA)” tool prove that the proposed LDAKM-EIoT is secure against several attack vectors that exist in the infrastructure of the edge based IoT environment. The elaborated comparative analysis of the proposed LDAKM-EIoT and different closely related schemes provides evidence that LDAKM-EIoT is more secure with less communication and computation costs. Finally, the network performance parameters are calculated and analyzed using the NS2 simulation to demonstrate the practical facets of the proposed LDAKM-EIoT.


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

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.

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.

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. 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 XOR" operation.

System Models
The following two models are utilized to describe the working and usability of LDAKM-EIoT.

Network Model
The network model of LDAKM-EIoT is presented in Figure 1. In this figure, we have IoT devices, an edge node, which is a gateway to the Internet, the cloud server(s), and a trusted authority (TA). IoT devices can be deployed as per their applications (for example, smart health care, smart manufacturing, smart cities, and smart homes). The task of each IoT device is to collect and process information about some activity (i.e., level of fumes in a industrial plant) and then to send the data to the cloud server(s) through the edge node. At the cloud server, this will be stored and utilized for other processing and decision making tasks. In this model, IoT devices are resource constrained, whereas the edge node and cloud server are resource rich as they are able to do intensive computations and have more storage capacity and battery backup. The TA is responsible for the registration of different devices (i.e., IoT devices, edge nodes, and cloud servers). In such a kind of communication environment, we have to secure the communication between the IoT device and edge node and the edge node and cloud server. Since most of IoT devices are resource constrained, we preferred to use lightweight cryptographic operations (i.e., hash and XOR operations) in different exchanged messages' computation. Consequently, to secure such kinds of communication, we urge a new "authentication and key management" protocol with lightweight operations. Using this scheme, the communicating entities can securely access the resources of other entities and also communicate securely.

Threat Model
The widely accepted "Dolev-Yao (DY) threat model" [43] was followed in the designing of LDAKM-EIoT. As per the guidelines of the DY model, two communicating entities communicate over an open (insecure) channel. The end-point entities such as "IoT devices" are not fully trusted in general. The existing network adversary (A) can eavesdrop, update, or delete the communicated messages as the channel is insecure. We also followed Canetti and Krawczyk's adversary model, also named as the "CK adversary model" [40], which is the current de facto standard model in the designing and modeling of an "authenticated key agreement" security scheme. In the CK adversary model, A can have all the capabilities like the DY model. In addition to that, A can also compromise the secret credentials along with the "session states and session keys" during a session. Moreover, A can physical capture some IoT devices and extract the stored information from the IoT devices by the application of a sophisticated power analysis attack [13]. The obtained credentials can be further used to perform other kinds of malicious activities, such as the computation of "secret credentials" and the "session key", and launch some attacks, such as "IoT device impersonation", "replay", "privileged-insider", and "man-in-the-middle". As per the information available in [44], we also assumed that the edge node (EN) was fully trusted and could not be compromised by A. Otherwise, if the EN was compromised, the entire network would be compromised. For such a purpose, we followed the method discussed by Bertino et al.'s protocol [45]. We assumed that the EN was equipped with a tamper resistant hardware device so that all the sensitive confidential information (for example, stored cryptographic keys) should be protected from A. Therefore, the application of a tamper resistant EN attained strong enough security in LDAKM-EIoT. Though it is also true that the attacks are possible on tamper resistant devices, A needs special equipment (device) to perform such an attack to acquire the stored information. This is because it is less expensive to install the EN than to use special equipment because A does not have any economic benefits to perform such an attack on a security scheme [45]. Moreover, we could secure the EN by putting it inside a physical locking system so that the physical capture of the EN will be difficult for A as compared to that for the unattended IoT smart devices. In addition, the "trusted authority (TA)" was also assumed to be a "fully trusted" entity of the network and that it would not be compromised, although the "cloud servers" were considered to be "semi-trusted" entities.

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. Table 1. Notations used in the lightweight authenticated key management mechanism for the edge-based IoT environment (LDAKM-EIoT).

Symbol
Meaning ith IoT device and its identity, respectively CS j , ID CS j jth cloud server and its identity, respectively EN, ID EN Edge node and its identity, respectively TA, ID TA Trusted authority and its identity, respectively RID D i , RID CS j Pseudo identities of D i and CS j , respectively TID D i Temporary identity of D i K EN−D i 1024 bit shared secret key of the IoT device and edge node generated by TA K EN−CS i 1024 bit shared secret key of the edge node and cloud server generated by TA n 160 bit secret secret of TA, which is only known to TA.

RTS D i
Registration timestamp of D i n d , n c Number of IoT devices and cloud servers deployed initially, respectively r d i , r en 1 , r en 2 , r cs j 128 bit random numbers of D i , EN, and CS j , respectively Current timestamps generated by different entities ∆ T "Maximum transmission delay" associated with a message h(·) "Collision resistant cryptographic one way hash function" Session key between D i and CS j ||, ⊕ Concatenation and bitwise XOR operations, respectively

Pre-Deployment Phase
This phase permitted the trusted authority (TA), 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 n d number of IoT devices D i were associated with a particular edge node EN, and the real-time information could be accessed from the IoT devices to n c number of cloud servers CS j , provided that a mutual authentication and key establishment happened successfully among the IoT devices and cloud servers with the presence of the edge node EN.

Registration of IoT Devices
The TA firsts picked a distinct unique identity ID D i for every IoT device D i and computed its corresponding pseudo identity as is a 1024 bit shared secret key between each IoT device D i and edge nodes generated by the TA, where i = 1, 2, · · · n d , and n d is the total count of IoT devices. Moreover, ID EN is the identity of an edge node EN where the IoT devices need to authenticate a cloud server CS j with an IoT device D i . ID TA is the identity of TA, and n is a 160 bit secret number of TA that is only disclosed to the TA. After that, TA generates a temporary identity TID D i for each D i . Note that temporal credentials are different for each IoT device D i , 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 {RID D i , TID D i , TC D i , AD i , h(·)} in the memory of D i prior to its placement in the IoT network.

Registration of Cloud Servers
The TA picks a distinct unique identity ID CS j for each cloud server CS j and proceeds to calculate its pseudo identity as RID CS j = h(n ||ID CS j ) and ACS j = h(K EN−CS j ||ID CS j ||ID EN ||RTS CS j ) where RTS CS j is the registration timestamp for CS j and j = 1, 2, · · · n c , n c are the number of cloud servers placed initially in the IoT network, while K EN−CS j is a 1024 bit shared secret key of the edge node and cloud server CS j generated by the TA. Next, the TA stores the credentials {RID CS j , ACS j , ID CS j , h(·)} in the database of CS j before its placement in the network.

Registration of Edge Node
The TA picks a distinct unique identity ID EN for edge node EN and stores previously computed information, as well as this information, that is {( , in the database of EN before its placement in the network.
The registration process is summarized in Figure 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 D i , wants to initiate secure data transmission to a cloud server, first of all, D i needs to compute the following parameters. D i picks a random nonce r d i and current timestamp T 1 and calculates If it is valid, D i is authenticated by the EN and can access its resources to get access to a cloud server CS j selected by the EN. Next, the EN chooses a random nonce r en 1 and current timestamp T 2 , picks ACS j from its database corresponding to ID CS j , and computes A3. After the arrival of message Msg 2 at time T * 2 , CS j verifies the timeliness of T 2 by checking if If it is valid, the EN is authenticated by CS j . Otherwise, CS j halts the session with the EN immediately. Furthermore, CS j picks up a random nonce r cs j and current timestamp T 3 and computes Next, the EN checks whether M 7 = M 7 , and if it holds, CS j is authenticated by the EN. Otherwise, the EN halts the session with CS j instantly. Furthermore, the EN selects a random nonce r en 2 along with current timestamp T 4 and computes ). In addition, D i also calculates M 6 = h(SK D i −CS j ||T 3 ) and M 9 = h(M 6 || M 8 || h(r en 2 ||T 4 ) ||T 3 ||T 4 ). Then, D i checks whether M 9 = M 9 , and if it is legitimate, the EN, as well as CS j are authenticated by D i , and the computed session key is treated as the valid one. Thus, both D i and CS j will maintain the same computed shared session key SK D i −CS j (= SK CS j −D i ) for secret communications. Moreover, D i calculates the new temporary identity as TID new D i = M 10 ⊕ h(M 9 ||T 3 ||T 4 ||AD i ||TC D i ||TID D i ) and will use this new identity in all its future communications with the EN and CS j . 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. (Protection for synchronization attack). We may consider a situation where the message Msg 4 has been tampered with or there is a communication error that occurs so that an IoT device cannot receive the parameter M 10 , as well as the new temporary identity TID new D i . 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 SID = {sid 1 , sid 2 , · · · , sid l }. In this context, when an IoT device, say D i , could not receive the message Msg 4 within a specific time period (maximum round-trip time), it needs to select one of the unused shadow identities, say sid j ∈ SID, and then send it within the message Msg 1 . When the EN receives the sid j , it can generate a new TIDand send it securely to the device D i . By using this method, we can address the synchronization attacks without compromising the privacy of an IoT device in the proposed scheme (LDAKM-EIoT).

IoT device (D i )
Edge node (EN) Cloud server (CS j ) Choose r di and T 1 .
(via public channel) choose rcs j and T 3 .
(via public channel) choose ren 2 and T 4 .

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 A. 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.

Dynamic IoT Device Addition
The upcoming procedure is needed to add a new IoT device, say D ni , in the required part of the IoT environment.
DD1. The TA picks a new unique identity ID D ni for the new IoT device D ni and computes its corresponding pseudo identity as RID D ni = h(n ||ID D ni ), temporal credentials TC D ni = h(RID D ni ||ID EN ||ID TA ||n ||RTS D ni ), AD ni = h(K EN−D ni || ID D ni || ID EN || RTS D ni ) where RTS D ni is registration timestamp generated for D ni and K EN−D ni is the shared secret key between IoT device D ni and the edge node EN generated by the TA. TA also generates a unique temporary identity TID D ni for D ni that is different from the previously deployed IoT devices.
DD2. The TA stores the credentials {RID D ni , TID D ni , TC D ni , AD ni , h(·)} in the memory of D ni before its placement in the deployment area. Furthermore, the TA securely sends the information {RID D ni , TID D ni , TC D ni , AD ni } related to D ni to EN so that the EN can update these information in its database corresponding to the newly added IoT device D ni . Note that for secure communication between TA and EN, a pre-shared symmetric key among them is essential, and it is generated by the TA prior to the placement of the EN.

Dynamic Cloud Server Addition
The upcoming procedure is required to add a new cloud server, say CS nj , in the required part of the IoT environment.
DC1. The TA chooses a distinct unique identity ID CS nj for CS nj and computes its pseudo identity as RID CS nj = h(n ||ID CS nj ) and ACS nj = h(K EN−CS nj ||ID CS nj ||ID EN ||RTS CS nj ) where RTS CS nj is the registration timestamp for CS nj . Moreover, K EN−CS nj is the shared secret key of the edge node EN and cloud server CS nj generated by the TA.
DC2. The TA then stores the credentials {RID CS nj , ACS nj , ID CS nj , h(·)} into the database of CS nj prior to its deployment in the IoT environment.

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 (D i , EN, and CS j ). In the each exchanged message of LDAKM-EIoT, we used the maximum transmission delay ∆ T factor, which is a small value. Consequently, an adversary A can not gain any advantage in replaying the old transmitted messages, which are used in the authentication and key management procedure among D i , EN, and CS j within ∆ T. 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 A seizes an authentication request message {TID D i , M 1 , M 2 , T 1 } exchanged between D i and EN and further tries to update this message in such a way that it looks similar to a genuine authentication message, as {TID a D i , M a 1 , M a 2 , T a 1 } by using the parameters such as M a where RTS D i is the registration timestamp for D i and K EN−D i is the shared secret key of IoT device and edge node generated by the TA. To launch this attack, A can initiate the generation of random nonce r a d i and current timestamp T a 1 . However, without obtaining the information about "long term secret" RID D i , ID EN , ID TA , n, and K EN−D i , A cannot re-create another valid authentication request message {TID a D i , M a 1 , M a 2 , T a 1 }. By using a similar approach, we can also explain that other messages cannot be recomputed by A, which are used in the "authentication and key management" phase without the "long term secrets" used by D i , EN, and CS j . This proves the resilience of LDAKM-EIoT against MITM.

Proposition 3. LDAKM-EIoT provides protection against different impersonation attacks.
Proof. Suppose an adversary A attempts to create a valid authentication request message on behalf of a communicating party (for example, D i ) after obtaining D i 's authentication request where RTS D i is the registration timestamp for D i and K EN−D i is the shared secret key of IoT device and edge node generated by the TA. Note that Msg 1 uses M 1 and M 2 , which are computed using the "long term secrets"(RID D i , ID EN , ID TA , n, K EN−D i ) and also the "short term secrets" (random nonce r d i ). Without knowing these secret values, A is not able to create a valid authentication request message on behalf of the genuine IoT device D i . 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 Msg 2 , Msg 3 , and Msg 4 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 CS j and the accessed D i during the the authentication and key management phase as is the shared secret key of the IoT device and edge node generated by the TA and K EN−CS i is the shared secret key of the EN and cloud server generated by the TA. Further, the identities of the IoT device, ID D i , the identity of the edge node ID EN , and the identity of the cloud server ID CS j 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 A 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 D i and CS j 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 A, knows the registration information {RID CS j , ACS j , ID CS j , h(·)}. 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, r en 1 is the random nonce of the EN. The identities of the IoT device, ID D i , the identity of the edge node ID EN , and identity of the cloud server ID CS j are also utilized in SK CS j −D i . The privileged-insider user of the cloud server does not have any information about ID D i , ID EN , and K EN−D i . Therefore, A 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. 5 , M 6 , M 7 , T 3 }, and Msg 4 = {M 8 , α, β, M 9 , M 10 , T 3 , T 4 } during the "authentication and key management phase" between D i and CS j via the EN. 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 ID D i , ID EN , and ID CS j 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. Let us assume an adversary A intercepts the messages
Proof. Each IoT device stores the credentials {RID D i , TID D i , TC D i , AD i , h(·)}, 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 n c IoT devices are physically captured by an adversary A. We assess the IoT device physical capture attack as the fraction of total secure communications that are compromised from the capturing of n c IoT devices not including the communication in which the "compromised IoT devices" are straightforwardly extended. For example, one can estimate the probability of A's ability to decrypt the secure communication between a cloud server CS j and a non-compromised IoT device D i when n c IoT devices are already physically stolen and compromised. Suppose this probability is represented by P e (n c ). If P e (n c ) = 0, an "authentication and key management" protocol is termed as "unconditionally secure against IoT device physical capture attack". From a captured IoT device D i , A will have the extracted credentials {RID D i , TID D i , TC D i , AD i , h(·)} along with the secret pairwise session key SK CS j −D i shared between D i and CS j from its memory. However, it is very important to notice that all RID D i , TID D i , TC D i , AD i , RTS D i , and K EN−D i are distinct for all installed IoT devices. Thus, the stolen D i by A can only help to find the secret keys between that D i and CS j . Furthermore, this results in all other secret keys between that CS j and other non-compromised IoT devices D i 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.

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 TA, (b) the role for an IoT device D i , (c) the role for the edge node EN, and (d) the role for a cloud server CS j . 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.

Comparative Study of Computation Costs
The notations T ecm , T f e , and T h are used to represent the time required for an "ECC point multiplication", a "fuzzy extractor function" for biometric verification in the case of the scheme designed by Challa et al. [3], and a "one way hash function", respectively. Based on the experimental results available in [57], we took T h ≈ 0.00032 s, T ecm ≈ 0.0171 s, and T f e ≈ T ecm , that is T f e ≈ 0.0171 s. The computation costs' comparison among LDAKM-EIoT and other schemes is depicted in Table 3. In LDAKM-EIoT, during the authentication and key agreement procedure, D i , EN, and CS j incurred 9T h ≈ 2.88 ms, 15T h ≈ 4.8 ms, and 8T h ≈ 2.56 ms, respectively. The comparative results demonstrated that LDAKM-EIoT performed better than Challa et al.'s scheme [3] and Zhou et al.'s scheme [41]. Moreover, LDAKM-EIoT needed the same computation cost as compared to that for Farash et al.'s scheme [21]. However, LDAKM-EIoT required more computation cost as compared to that for Sharma and Kalra's scheme [39] and Turkanovic et al.'s scheme [18]. However, this was accepted as LDAKM-EIoT provided extra security and functionality features as compared to those for the other compared schemes of Challa et al. [3], Farash et al. [21], Sharma and Kalra [39], Zhou et al. [41], and Turkanovic et al. [18] (see Table 4).   18 : protection for session-key security under the CK adversary model. ×: insecure against a "specific attack" or a "particular feature" is not there; : secure against a "specific attack" or a "particular feature" is present; NA: not applicable.

Comparative Study of Security and Functionality Attributes
The comparison of the security and functionality attributes for the proposed LDAKM-EIoT and other related schemes is shown in Table 4. Various features (FSF 1 -FSF 4 , FSF 6 , FSF 17 , and FSF 18 ) were not supported/available in the scheme of Farash et al. [21], whereas Challa et al.'s scheme [3] did not support the features FSF 11 and FSF 14 , which were shown by Jia et al. [37]. Moreover, other schemes, such as the schemes of Sharma and Kalra [39], Zhou et al. [41], and Turkanovic et al. [18] did not provide the required functionality and security features. On the other hand, LDAKM-EIoT provided better security and functionality features as compared to other related schemes.

NS2 Simulation Study
In this section, we conduct the simulation study on LDAKM-EIoT and other existing related schemes of Challa et al. [3], Farash et al. [21], Sharma and Kalra [39], Zhou et al. [41], and Turkanovic et al. [18] using the NS2 simulator. The impact of LDAKM-EIoT and other related schemes is studied and compared on important network performance parameters (for example, throughput (available in bits per second (bps)) and end-to-end delay (available in seconds)).

Simulation Parameters
The specifics of the network parameters used in the NS2 simulation are given in Table 5. The simulation time was 30 min (1800 s). S j and CS j respectively represent the jth sensor node and cloud server, whereas U i /D i represents the ith user/IoT smart device respectively in LDAKM-EIoT and other schemes [3,21]. Moreover, we took one gateway node (GW)/edge node (EN) in all the compared schemes. The communication range of smart device or sensor was taken as 100 m. The messages exchanged among different communicating entities along with their communication costs (in bits) for different schemes are depicted in Table 6, which were used in the simulation for exchanging the packets (messages) among the entities. We applied the ad hoc on-demand distance vector (AODV) [58] as the routing protocol. All other parameters used in the simulation were taken as standard ones.

Comparative Analysis of the Simulation Results
The comparative analysis of the network performance parameters for LDAKM-EIoT, Challa et al. [3], and Farash et al. [21] is discussed in the following.

Comparative Analysis of the Network Throughput
The network throughput can be calculated as "the number of bits transmitted per unit time, and it can be mathematically expressed as (ν r × |ρ|)/T d , where T d is the total time (in seconds), |ρ| the size of a packet, and ν r the total number of received packets". The simulation time was 1800 s, which was the actual total considered time. In Figure 5a, the throughput values for the schemes of Challa et al. [3], Farash et al. [21], Turkanovic et al. [18], Sharma and Kalra [39], Zhou et al. [41], and the proposed LDAKM-EIoT are 173.49 bps, 164.34 bps, 160.41 bps, 169.85 bps, 217.16 bps, and 148.95 bps, respectively. It was observed that the throughput of LDAKM-EIoT was less than the other schemes [3,18,21,39,41]. This was primarily due to the reason that LDAKM-EIoT applied the small sized messages, which caused less communication overhead for the authentication procedure as compared to the other schemes (see Table 6).

Comparative Analysis of the End-to-End Delay
The end-to-end delay (EED) is measured as "the average time taken by the data packets to arrive at a receiving node from a sender node, and it is mathematically expressed in the form ∑ ν p i=1 (T rec i − T send i )/ν p , where T rec i and T send i are the receiving and sending time of a packet i, respectively, and ν p the total number of packets". From the simulation results provided in Figure 5b, it was observed that EED values for the schemes of Challa et al. [3], Farash et al. [21], Turkanovic et al. [18], Sharma and Kalra [39], Zhou et al. [41], and LDAKM-EIoT were 0.17230 s, 0.15151 s, 0.12478 s, 0.12496 s, 0.13707 s, and 0.11640 s, respectively. The EED value of LDAKM-EIoT was less than the schemes provided in [3,18,21,39,41]. This was again due to the reason that LDAKM-EIoT applied small sized messages for the authentication procedure, which caused less end-to-end delay as compared to other schemes.

Conclusions
The edge based IoT environment suffers from serious security and privacy issues. It was observed that the majority of the existing schemes for authentication and key management have limitations as they were vulnerable to various attacks. Some of them were not even efficient from the computation and communication cost point of view. Consequently, a new authentication and key management scheme with lightweight cryptographic operations was designed for the edge based IoT environment (LDAKM-EIoT). The rigorous security analysis of LDAKM-EIoT using formal security verification using AVISPA tool and also other security analysis evidenced that LDAKM-EIoT could prevent different possible well known attacks. LDAKM-EIoT also supported new smart IoT device deployment in the network after the initial deployment. Moreover, LDAKM-EIoT preserved the anonymity and untraceability properties. LDAKM-EIoT was also compared with the closely related existing schemes in the IoT environment. The conducted comparative performance analysis and NS2 based simulation study on the network performance parameters evidenced that LDAKM-EIoT was much better in security and functionality features, communication, and computation as compared to other existing schemes.
In the future, we would like to implement the proposed LDAKM-EIoT in a testbed environment. Moreover, we would also like to include more functionality features in the proposed LDAKM-EIoT while maintaining less communication and computational overheads without degrading the security.
This work was also supported by the Office of the Assistant Secretary of Defense for Research and Engineering (OASD (R&E)) agreement FA8750-15-2-0120.