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.

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.

3. System Models

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

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

Figure 1

Network model of the edge based IoT environment.

3.2. 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 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, can have all the capabilities like the DY model. In addition to that, can also compromise the secret credentials along with the “session states and session keys” during a session. Moreover, 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 was fully trusted and could not be compromised by . Otherwise, if the 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 was equipped with a tamper resistant hardware device so that all the sensitive confidential information (for example, stored cryptographic keys) should be protected from . Therefore, the application of a tamper resistant attained strong enough security in LDAKM-EIoT. Though it is also true that the attacks are possible on tamper resistant devices, needs special equipment (device) to perform such an attack to acquire the stored information. This is because it is less expensive to install the than to use special equipment because does not have any economic benefits to perform such an attack on a security scheme [45]. Moreover, we could secure the by putting it inside a physical locking system so that the physical capture of the will be difficult for as compared to that for the unattended IoT smart devices. In addition, the “trusted authority ” 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.

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.

Table 1

Notations used in the lightweight authenticated key management mechanism for the edge-based IoT environment (LDAKM-EIoT).

Symbol	Meaning
D_i, ID_D_i	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
T_1,T_2,T_3,T_4	Current timestamps generated by different entities
ΔT	“Maximum transmission delay” associated with a message
h(·)	“Collision resistant cryptographic one way hash function”
SK_D_i−CS_j	Session key between D_i and CS_j
||, ⊕	Concatenation and bitwise XOR operations, respectively

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.

Figure 2

Credentials stored in , , and during registration processes.

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.

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.

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.

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.

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.

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.

Figure 3

Abridging of the authentication and key agreement phase.

(Protection for synchronization attack). We may consider a situation where the message

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.

LDAKM-EIoT is resilient against replay attack.

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

LDAKM-EIoT is resilient against man-in-the-middle attack (MITM).

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

LDAKM-EIoT provides protection against different impersonation attacks.

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

LDAKM-EIoT protects Ephemeral secret leakage (ESL) attack.

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]. □

LDAKM-EIoT is resilient against privileged-insider attack.

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”. □

LDAKM-EIoT preserves the anonymity and untraceability properties.

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

LDAKM-EIoT provides protection against IoT device physical capture attack.

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.

Figure 4

Analysis of simulation results under the CL-AtSe and OFMC backends.

7. Comparative Analysis with Existing Schemes

In this section, the comparative study of LDAKM-EIoT with other related existing schemes, such as the schemes designed by Challa et al. [3], Farash et al. [21], Sharma and Kalra [39], Zhou et al. [41], and Turkanovic et al. [18], is done. It is worth noting that the schemes of Challa et al. [3], Farash et al. [21], Sharma and Kalra [39], Zhou et al. [41], and Turkanovic et al. [18] were designed for the IoT environment.

7.1. Comparative Study of Communication Costs

We took the identity, random nonce, hash digest (if the secure hash algorithm (SHA-1) [55] was utilized), and timestamp as 160, 128, 160, and 32 bits, respectively. It well known that the 1024 bit “RSA public key cryptosystem” maintains the same security level as that for the 160 bit “elliptic curve cryptography (ECC) cryptosystem” [56]. Thus, an elliptic curve point of the form took bits. The communication costs of LDAKM-EIoT and other schemes are provided in Table 2. In LDAKM-EIoT, the messages , , , and incurred the costs of bits, bits, bits, and bits, respectively, and hence, all the messages needed a total of bits. On the other side, the communication costs for the schemes of Challa et al. [3], Farash et al. [21], Sharma and Kalra [39], Zhou et al. [41], and Turkanovic et al. [18] were 2528, 2752, 2912, 3840, and 2720 bits, respectively. It is depicted in Table 2 that LDAKM-EIoT performed better in terms of communication cost as compared to other considered existing schemes of Challa et al. [3], Farash et al. [21], Sharma and Kalra [39], Zhou et al. [41], and Turkanovic et al. [18].

Table 2

Communication costs’ comparison. LDAKM-EIoT, the lightweight authentication and key management scheme for the edge based IoT environment.

Protocol	No. of Messages	No. of Bits
LDAKM-EIoT	4	2400
Challa et al. [3]	3	2528
Farash et al. [21]	4	2752
Sharma and Kalra [39]	4	2912
Zhou et al. [41]	4	3840
Turkanovic et al. [18]	4	2720

7.2. Comparative Study of Computation Costs

The notations , , and 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 s, s, and , that is 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, , , and incurred ms, ms, and 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).

Table 3

Comparison of computation costs.

Scheme	User/Smart	Gateway Node/	Sensing Device	Total Cost
	IoT Device	Edge Node	/Cloud Server
LDAKM-EIoT	9T_h	15T_h	8T_h	32T_h
	≈2.88 ms	≈4.8 ms	≈2.56 ms	≈10.24 ms
Challa et al. [3]	1T_fe+5T_ecm+ 5T_h	5T_ecm+4T_h	4T_ecm+3T_h	1T_fe+14T_ecm+ 12T_h
	≈104.20 ms	≈86.78ms	≈69.36 ms	≈260.34 ms
Farash et al. [21]	11T_h	14T_h	7T_h	32T_h
	≈3.52 ms	≈4.48 ms	≈2.24 ms	≈10.24 ms
Sharma and Kalra [39]	11T_h	7T_h	5T_h	23T_h
	≈3.52 ms	≈2.24 ms	≈1.6 ms	≈7.36 ms
Zhou et al. [41]	10T_h	7T_h	19T_h	36T_h
	≈3.2 ms	≈2.24 ms	≈6.08 ms	≈11.52 ms
Turkanovic et al. [18]	7T_h	5T_h	7T_h	19T_h
	≈2.24 ms	≈1.6 ms	≈2.24 ms	≈6.08 ms

Table 4

Comparison of functionality and security features.

Feature	Farash	Challa	Turkanovic	Sharma and	Zhou	LDAKM-EIoT
	et al. [21]	et al. [3]	et al. [18]	Kalra [39]	et al. [41]
FSF_1	×	✓	✓	×	✓	✓
FSF_2	×	✓	×	×	×	✓
FSF_3	×	✓	×	×	✓	✓
FSF_4	×	✓	×	×	✓	NA
FSF_5	✓	✓	✓	✓	✓	✓
FSF_6	×	✓	×	✓	×	NA
FSF_7	✓	✓	✓	✓	×	✓
FSF_8	✓	✓	✓	✓	×	✓
FSF_9	✓	✓	✓	✓	×	✓
FSF_10	✓	✓	✓	✓	✓	✓
FSF_11	✓	×	×	✓	✓	✓
FSF_12	✓	✓	✓	✓	NA	✓
FSF_13	✓	✓	✓	✓	×	NA
FSF_14	✓	×	✓	✓	NA	✓
FSF_15	NA	✓	×	×	×	NA
FSF_16	✓	✓	×	✓	✓	✓
FSF_17	×	✓	×	×	×	NA
FSF_18	×	✓	✓	×	×	✓

Note: : the property to make the user or smart IoT device anonymous; : protection for privileged-insider attack; : protection for off-line password guessing attack; : protection for stolen smart card or mobile device attack; : protection for denial-of-service attack; : protection for user impersonation attack; : protection for replay attack; : protection for man-in-the middle attack; : achieves mutual authentication; : achieves session key agreement; : property to make messages untraceability; : protection for sensor node/sensor/smart IoT device physical capture attack; : presence of server independent password update phase; : protection for sensor node/sensing device/smart IoT device impersonation attack; : support biometric update phase; : provide formal security verification using the automated software verification tool; : presence of the smart card revocation phase; : 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.

7.3. 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 (-, , , and ) were not supported/available in the scheme of Farash et al. [21], whereas Challa et al.’s scheme [3] did not support the features and , 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.

8. 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)).

8.1. 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). and respectively represent the jth sensor node and cloud server, whereas represents the ith user/IoT smart device respectively in LDAKM-EIoT and other schemes [3,21]. Moreover, we took one gateway node /edge node 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.

Table 5

Different parameters used in the simulation. AODV, ad hoc on-demand distance vector.

Parameter	Description
Platform	Ubuntu 14.04 LTS
Tool used	NS2 2.35
Number of gateway nodes/edge nodes	1
(whenever applicable)
Number of users or IoT device	9
(whenever applicable)
Number of sensors or cloud server	10
(whenever applicable)
Simulation time	1800 s
Communication range of sensors/IoT devices	100 m
Routing protocol	AODV [58]

Table 6

Different messages exchanged among entities used in the simulation.

Exchanged Messages between Network Entities	Challa	Farash	Turkanovic	Sharma	Zhou	LDAKM-EIoT
	et al. [3]	et al. [21]	et al. [18]	and Kalra [39]	et al. [41]
U_i/D_i→GW/EN	992 bits	512 bits	672 bits	672 bits	800 bits	512 bits
GW/EN→SD_j/S_j/CS_j	1024 bits	1024 bits	1024 bits	1024 bits	1600 bits	512 bits
SD_j/S_j/CS_j→GW/EN	−	672 bits	576 bits	672 bits	960 bits	512 bits
GW/EN→U_i/D_i	−	544 bits	448 bits	544 bits	480 bits	864 bits
SD_j/S_j/CS_j→U_i/D_i	512 bits	−	−	−	−	−

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

8.2.1. 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 , where is the total time (in seconds), the size of a packet, and 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).

Figure 5

Comparison of network parameters: (a) network throughput; (b) end-to-end delay.

8.2.2. Comparative Analysis of the End-to-End Delay

The end-to-end delay 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 , where and are the receiving and sending time of a packet i, respectively, and the total number of packets”. From the simulation results provided in Figure 5b, it was observed that 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 s, s, s, s, s, and 0.11640 s, respectively. The 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.

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