Keywords

1 Introduction

The use of IoT has expanded in popularity, and it has become part and parcel of our daily lives. As the number of IoT devices is increasing day by day, in 2016, there were around 4.6 billion devices, and by the end of 2021, the number would reach 13.8 billion. By 2025, it is estimated that approximately 30 billion IoT devices will exist [1]. When IoT was first introduced, less emphasis was placed on its security. As the Internet of Things is built on data that is mostly private and highly sensitive, it has the potential to be exploited and, thus, violating the user’s privacy [2,3,4, 24]. As a result, the security of IoT devices is being prioritized. IoT devices can be secured by employing various mechanisms where authentication plays a vital role. It can help to reduce risk and guarantee that IoT devices are trustworthy. In authentication, identity of the devices is recognized and further validated. Authentication is performed in the initial phase so that communication between devices may begin, and each device can learn about the identity of the other. If authentication is not performed securely, attackers can gain access to the machines and can steal the data generated and transferred, which results in various attacks.

In IoT networks, authentication attacks are a major concern. The classification of attacks is grouped into various categories namely denial-of-service attack, masquerade attack, forging attack, man-in-the-middle attack, guessing attack, physical attack and routing attack [5]. There are various challenges with IoT authentication that must be addressed [6]. The first challenge is to cut energy costs during the process of authentication. ECC is an authentication mechanism that leverages implicit certificates to reduce energy usage and computing overhead [7] in sensor networks for distributed IoT applications. The second challenge [8] is the implementation of IoT-adapted authentication mechanisms. Distinct network architectures are based on different concepts of IoT, and authentication mechanisms need to be implemented to secure the communication [9]. Another challenge is devising an authentication mechanism capable of identifying users in their devices while avoiding persistent interaction between those components [10]. The authentication protocols in the IoT environment should essentially avail the limited amount of memory or several bits. If an enormous amount of memory is consumed, then abundant resources are utilized for implementation, and the computational cost of the protocol increases. The stand out feature in our proposed model is a lightweight authentication protocol that consumes 2948 bits.

This paper is formatted as follows. Section 2 primarily concentrates on the related works, and Sect. 3 gives a detailed overview of the protocol that is being proposed. Section 4 describes the outcomes and properties, and finally, Sect. 5 summarizes our conclusions and lists the possible future work that can be done in this area.

2 Related Work

Over the past years, many authentication mechanisms were proposed with varied architectures in the IoT environment. The main motto behind this was to develop a secure IoT system which is resilient against attacks. Kumari et al. proposed an ECC-based authentication system for IoT and cloud servers [11]. Automated Validation of Internet Security Protocols and Applications tool was employed to formally examine the security features of the suggested scheme. Security and performance review demonstrated that the proposed model is more effective, reliable and stable than existing models in the face of a variety of known attacks. A lightweight authentication protocol for IoT devices with a three-tiered architecture was proposed by Ali et al. [12]. In their mechanism, the number of positive and hostile acts was used to calculate the device’s trust using a fuzzy method. The findings demonstrate the suggested protocol’s advantage over other techniques in terms of attack resistance. Yang et al. proposed an authentication scheme for multi-server architecture using a smart card [20]. This mechanism combines the benefits of biometrics and password authentication. Session key disclosure attack is possible in this scheme. An authentication protocol for multi-server architecture was proposed by Li et al. [22]. Unfortunately, this protocol is vulnerable to replay and impersonation attacks. Dammak et al. proposed a decentralized mechanism for group key management employing one key distribution centre and various subkey distribution centres [25]. Totally eight algorithms are presented in this approach to address the scalability issues in group key management. Nafi et al. used a matrix based scheme for developing a lightweight key management system [26]. This mechanism is suitable for networks that contain limited resources.

For multi-server architecture, an identity-based authentication protocol is discussed using smart cards [13]. It is a dual server model which imposes varying levels of trust on both the servers, which are the service provider and the control servers. The verifier’s information of the user is distributed between these two servers. They asserted that their protocol could withstand various attacks, ensure session key agreement and user anonymity. But the protocol is vulnerable to impersonation attack, stolen smart card attack and leak-of-verifier attack. The authors of [14] have proposed RSA-based two-way IoT authentication techniques using the Trusted Platform Module (TPM). The drawbacks of this mechanism are the significant key size of RSA and the large packet header. The authors of [15] proposed an elliptic curve and symmetric cryptography-based authentication and key management scheme. Additionally, it enables mutual authentication with the network control centre, besides its resistance to denial of service, replay and impersonation attacks. But this mechanism is inefficient in terms of communication and computation. Xue et al. [16] proposed a lightweight authentication and key agreement protocol for multi-server architectures based on dynamic pseudonym identity. But this protocol is vulnerable to Impersonation attack and Session key disclosure attack.

Some of the models that were proposed earlier have some gaps in them and thereby not satisfying the different attack vectors. By considering all of these mechanisms and their associated flow possibilities, in this paper, we have proposed an authentication protocol that is resistant to most of the attacks that were previously discussed in this section.

3 Proposed Mechanism

This section introduces a new authentication protocol that involves three entities: The IoT device, service provider and the trust centre. In this mechanism, various runs occur between IoT device, trust centre and service provider to establish a session key and authenticate each other. Here the trust centre holds the responsibility to authenticate the IoT device and the service provider. Later the trust centre generates a unique key for every session and can only be used by that particular device and the service provider.

Fig. 1
figure 1

Proposed protocol (SLAP-IoT)

Full size image

As per the Fig. 1 in the first step, the IoT device sends its identity \(I_i\), \(A_i\), which is the hash value generated by the concatenation of password of the device \(P_i\), Nonce \(N_i\) and the Nonce of IoT device \(N_i\). All the values are encrypted by the public key of trust centre Kpt.

In Step 2, after receiving all the values from the IoT device, the trust centre decrypts them by using its private key. Also, the trust centre calculates Mi, Ci, Di values. Mi = Hash (Ti \(\Vert \) X) is the hash value generated by concatenation of Ti and X, where is the secret number given by the trust centre for each IoT device. Ti is a hash value generated by concatenating Ii and Ni, Ti = Hash (Ii \(\Vert \) \(N_i\)). Ci is a hash value generated by the concatenation of Ti and Ai, Ci = Hash (Ti \(\Vert \) Ai). Finally, Di = XOR(Mi, Ci) is generated by performing an XOR operation on Mi and \(C_i\), and the trust centre will store this value. The trust centre will calculate the Hash of \(D_i\), which is \(D_i\prime \). The trust centre will send \(D_i\prime \), registered device acknowledgement message, the nonce of trust centre \(N_T\) and nonce of IoT device \(N_i\) received in the previous step to IoT device by encrypting them with the public key of IoT device.

In the step 3, the service provider will register itself by sending its identity \(I_S\), along with nonce \(N_S\), and will concatenate these two values to generate \(S_i\) which is a hash value of \(I_S\) and \(N_S\). It will send \(I_S\), NS, and Si encrypted with the public key of the trust centre.

In Step 4, the trust centre will send the nonce of the service provider NS and nonce of the trust centre NT by encrypting them with the service provider’s public key as described in the Fig. 1.

In Step 5, the IoT device will send a login request to the trust centre by sending its nonce \(N_i\), \(D_i\prime \), value, and the nonce of trust centre \(N_T\), received in the previous step to the trust centre by encrypting them with the public key of trust centre.

In Step 6, the trust centre will use \(D_i\prime \), values sent by the IoT device in step 5. This value is compared with Hash (\(D_i\)), this \(D_i\) which is previously calculated and stored by the trust centre. If both values are matched, then the trust centre will generate the session key \(S_k\). Later, the session key \(S_k\) is sent to IoT device along with the nonce of trust centre \(N_T\) and identity of service provider \(I_S\). These values are encrypted with the public key of the IoT device.

In the 7th step, the session key \(S_k\) is sent to the service provider along with the identity of IoT device \(I_i\) and nonce of trust centre \(N_T\). These values are sent to the service provider by encrypting with the public key of the service provider.

The IoT device and service provider will decrypt the message which the trust centre sends by using their private keys and acquire the session key. This session key is used by the IoT device and service provider for the further transactions that occur in between them. The variables and their definitions used in the protocol are mentioned in Table 1.

Table 1 Variables and their definitions
Full size table

4 Results

In this section, we will analyse the performance of the protocol and discuss the simulation results. For simulating this protocol, we have used a protocol verification tool called Scyther, which was developed in 2007 by Cas Cremersand [17]. The Scyther tool works on the adversary model proposed by Dolev-Yao [23]. It is very fast in terms of analysing the protocols formally and outperformed other state of art formal verification tools. In terms of protocol verification, this is a widely accepted tool. In Scyther [18], the verification of security properties can be done either by specifying the security properties as claims manually. If no claims are mentioned in the protocol, the tool can automatically generate the claims. The extension for protocol definition files is spdl (Security Protocol Description Language). In this tool, we can claim some security properties. After verifying the protocol, if the claims are not satisfied, then in the output console, we can see the status as Fail. Under the pattern section, scyther will generate various patterns describing the possibilities of an attack. If all the claims are satisfied, then the status is shown as OK, and the attack patterns are not generated. To model the intended security properties like Secret, Alive, Weakagree, Niagree, and Nisynch in Scyther, we use a keyword called claim.

Fig. 2
figure 2

Scyther output

Full size image

Alive is a method of ensuring that an intended entity has completed certain acts [19]. Nisynch indicates that all messages received were sent by the communication partner and received by another communication partner. We have implemented our proposed mechanism in the Scyther tool. As per the screenshot Fig. 2, we can see that this mechanism satisfies all the properties, and there is no scope for attacks. Here, we discuss some of the security features of the proposed protocol:

  1. 1.

    Resistance to Impersonation attack: An impersonation attack is not possible even if an attacker tampers the details of the IoT device because in the first step, identity Ii, Ai and nonce Ni are sent to the trust centre. Based on these values, the trust centre will calculate the values of \(M_i\), Ci, and Di. If the attacker tries to create an identical message as in step 1 and tries to send it to the trust centre, there will be a change in Ai, Ti, \(M_i\), Ci, and Di values. It will cause a mismatch so the attacker cannot impersonate a legitimate device. Also, in every step, nonce is being sent from one entity to other by encrypting them with public keys. In the next step, the concerned entity will echo the received nonce.

  2. 2.

    Resistance to Replay attack: In this attack, the attacker will forward the messages captured in the previous step. After validating the credentials, the IoT device will perform the login process. If the attacker tries to perform the replay attack after the IoT device is logged in, it will be of no use. Also, in this protocol, we are using nonce, which is a random number. As a result, the attacker cannot use the previously captured messages and pretend as a legitimate device because the nonce value will be updated at each step.

  3. 3.

    Resistance to Session key disclosure attack: Our proposed mechanism will generate the session key after validating the \(D_i\prime \), value in the 6th Step. If the \(D_i\prime \), value does not match, then the session key is not generated. If \(D_i\prime \), value matches, then it is sent to the IoT device and the service provider by the trust centre after generating the session key. Before being sent, the session key is encrypted with the public keys of the IoT device and the service provider, respectively. The difficulty of the hash function and secret random nonces generated by the IoT device, trust centre and service provider, respectively, ensure the security of the session key in our protocol. So, session key disclosure attack is not possible in our proposed mechanism.

We conducted a comparison of our protocol’s performance with other relevant publications such as Yang et al. [19], Sood et al. [12], He et al. [20], Xue et al. [15] and Li et al. [21] in terms of attack resistance and communication cost. From Table 2, it is clearly evident that our proposed protocol is better in terms of attack resistance when compared to related existing schemes where (✓) indicates that protocol resist the attack and (✗) does the opposite (Fig. 3).

Table 2 Proposed model results comparision with previous literature
Full size table
Fig. 3
figure 3

Communication cost comparison graph

Full size image

We have calculated the login cost and authentication cost of our proposed protocol. In comparison with the related protocols, our proposed mechanism has more or less a similar communication cost. This is because, in our mechanism, each hash operation will consume 224 bits, considering the SHA-3 hashing algorithm, while the hash operation in other compared protocols utilizes 128 bits, and compromised hashing algorithms were used.

5 Conclusions and Future Work

In our work, we have implemented a protocol for authentication mechanism in IoT environment. The IoT environment contains devices, sensors that have limited resources in terms of memory and computation power, because of which they have a fragile security mechanism. In our approach, the trust centre plays a crucial role in authenticating, validating the IoT device, and establishing the session key between the IoT device and the service provider. The proposed protocol resists attacks like the session key disclosure, replay attack and impersonation attack. We have used a robust formal verification tool named “Scyther” to support our claim. In comparison with the related protocols, our proposed mechanism has more or less a similar communication cost satisfying the light weight property. Currently, the proposed protocol can be used for authentication when there are two parties involved. But, when it comes to group key agreement, our proposed approach is not applicable. So, as possible future work, we would like to extend this mechanism so that it can also be used in group key agreement protocols.