A secure mutual authentication protocol for IoT environment

Abstract

Rapid development in the field of Internet of Things (IoT) has made it possible to connect many embedded devices to the internet for the sharing of data. Since, the embedded device has limited storage, power, and computational ability, an integration of embedded devices with the large pool of resource such as cloud is required. This integration of technologies is expected to provide extraordinary growth in current and future promising applications of IoT. In this context, the security issues such as authentication and data privacy of devices are major issues of concern. The research motivation of the present work is to propose a secure mutual authentication protocol for IoT and cloud servers based on elliptic curve cryptography. In this work, the security properties of the proposed protocol have been formally verified by using Automated Validation of Internet Security Protocols and Applications tools and informally analyzed and compared with the related protocols in terms of various security attributes such as device privacy, impersonation attack, replay attack, password guessing attack, mutual authentication and so on. Moreover, the performance of the proposed protocol has also been evaluated in terms of computational, communication, storage overhead and total computational time. The security and performance analyses found the supremacy of the proposed protocol over the other related protocols.

1 Introduction

Internet of Things (IoT) [1] is a network of physical devices, objects, buildings, vehicles and other things that are embedded with software, electronics, sensors, and network connectivity. These objects are connected together and interchange the information between them and with other digital devices without any human interference [2, 3]. IoT contributes to boosting the life we live in through many applications such as smart cities, e-healthcare, smart buildings, smart grids and many more.

In recent years, due to the rapid development of IoT, internet connectivity with embedded devices for information sharing has also increased. Since the embedded device has limited storage, power, and computational ability, it is integrated with the cloud server, where the cloud has more storage and processing power and also can resolve most of the IoT issues. Combining the IoT devices with the cloud makes a new paradigm named CloudIoT which is expected to provide an extraordinary growth in current and future internet [4]. In the CloudIoT environment, the embedded device can depend on the computational skill of the cloud and can extract a large amount of data storage from the cloud server. Moreover, the embedded devices are more suitable for the practical implementation of IoT which results in different types of IoT services by incorporating smart embedded devices. However, while connecting an embedded device to a cloud, security is the prime issue of concern [5, 6]. Also, the mutual authentication must be established between the cloud server and the embedded devices. To meet these security requirements, many authentication protocols have been proposed for IoT and cloud servers. However, the existing protocols have certain shortcomings which need to be addressed further. In the environment, where memory and power are limited and higher security needs to be achieved at a minimum key length, then elliptic curve cryptography (ECC) is considered to be the best public key cryptography scheme [7].

Being motivated by the above research issues and trends, an improved mutual authentication and security protocol for IoT environments based on ECC has been proposed in this paper.

The major contributions of this work are summarized below:

• The ECC technique has been adopted to eliminate several security issues.

• The proposed protocol employs the concept of password verifier with the status bit in such a way that the server stores the password in the form of a password verifier with a status bit to achieve the device privacy and to prevent the impersonation attack and many logged-in devices’ attack.

• Proper mutual authentication and perfect forward secrecy have been achieved by following a unique way of computing the values of several authentication parameters and session key.

• The formal security verification of the proposed protocol by using the Automated Validation of Internet Security Protocols and Applications (AVISPA) tool has been provided.

• An informal security analysis of the proposed protocol has also been carried out with respect to several security attributes such as mutual authentication, device privacy, impersonation attack, replay attack, offline password guessing attack, many logged-in device attacks, insider attack, session key agreement, perfect forward secrecy, etc., and compared with the existing protocols to establish the supremacy of our work over the existing ones.

• The performance analysis of the proposed work has been compared with the existing work for computational overhead, communication overhead, storage overhead and total computational time. The results of the analysis show that the proposed protocol outperforms the related work in this regard.

The remainder of this paper has been structured as follows: In Sect. 2, related work to the proposed protocol has been described. In Sect. 3, preliminaries of the ECC have been summarized. Section 4 describes the methodology of the proposed protocol. Formal and informal security analysis of the proposed protocol has been analyzed and compared with the related protocol with respect to several security attributes in Sect. 5. In Sect. 6, the performance of the proposed protocol has been analyzed and compared with the related protocols to different performance parameters. Finally, some concluding notes and outline for future directions have been included in Sect. 7.

2 Related work

Authentication plays an important role for the successful integration of embedded devices with cloud computing services. Recently, several authentication protocols have been proposed for smart devices. Many authentication protocols based on ECC which apply to smart devices have been proposed in [8,9,10,11,12,13,14,15,16,17]. However, they have their own merits and demerits. The protocol proposed by Yang et al. [8] offers mutual authentication and also supports session key agreement between the user and the server. Afterward, Yoon et al. [9] analyzed that the protocol [8] does not offer perfect forward secrecy. Moreover, it gets affected by the impersonation attack. To overcome these issues, the author in [9] proposed an improved protocol to provide better security. Later, Islam et al. [10] found that the protocol [9] also fails to provide forward secrecy. Subsequently, the authors proposed a secure identity-based remote login protocol with a three-way challenge-response handshake technique. The protocol in [10] removes the clock synchronization problems, reduces the computational cost and also provides better security than the above protocols. In 2013, Chou et al. [11] analyzed the protocols [8, 9] and pointed out that users do not have the appropriate public key in the protocols [8, 9]. Moreover, in [11] the authors developed two ID-based key agreement protocols for mobile environments based on ECC. Next, in [12], Farash et al. reviewed the protocol [11] and found that the protocol [11] is vulnerable to impersonation attack. To overcome the limitations, the author proposed an enhanced ID-based key exchange protocol. However, the computational cost of the protocol [12] is higher than that of the protocol in [11].

Liao et al. [13] proposed an RFID authentication protocol combined with the ID-verifier transfer scheme. The authors claimed that their protocol offers mutual authentication and resist various security attacks. However, Peeters et al. [14] showed that the protocol [13] does not achieve mutual authentication and privacy. Moreover, it also gets affected by server spoofing attack. In 2014, Moosavi et al. [15] developed a mutual authentication protocol for RFID system based on ECC. The authors demanded that their protocol is immune to several attacks. However, Khatwani et al. [16] analyzed the protocol [15] and proved that the protocol [15] is affected by a kind of denial-of-service (DoS) attack, i.e., clogging attack. Abbasinezhad-Mood et al. [17] proposed a novel ECC-based self-certified two-factor key management scheme for medical data protection. The authors have been used ProVerif tool to proof the security features of their proposed scheme. Moreover, to compute the execution time, they have implemented the cryptographic elements on hardware’s. Some other authentication and key establishment protocols developed in [18, 19] which have been proofed the security features of the protocol by using ProVerif tool. The efficiency of the both protocols [18, 19] has been evaluated experimentally by using Advanced RISC Machines (ARM) platforms.

Meanwhile, many authentication protocols for the IoT environment have also been proposed. A secure lightweight mutual authentication protocol for IoT smart home has been proposed by Alshahrani et al. [20] based on cumulative keyed hash chain. The authors adopt cumulative keyed hash chain to confirm the identity of the sender. In this protocol, Automated Validation of Internet Security Protocols and Applications (AVISPA) and Burrows-Abadi-Needham (BAN) logic have been used to validate the security of the protocol. An ECC-based secure authentication protocol with privacy protection for Industrial Internet of Things (IIoT) has been developed by Li et al. [21]. The authors presented a biometric-based authentication with ECC to mitigate the security flaws. The security of this work has been proved under random oracle model. Moreover, the work has been simulated by using NS-3 and the authors claimed that the protocol is more suitable for IIoT environment. Alcaide et al. [22] established a decentralized anonymous authentication scheme for the users in the IoT environment. The scheme holds some exponentiation operations and is suitable for powerful platforms. Nevertheless, Lin et al. [23] pointed out that the adversary can capture the data from data collectors by impersonating the user. In 2017, a remote-user authentication protocol by using three factors such as passwords, smart cards, and biometrics for IoT environments was proposed by Dhillion et al. [24]. This protocol only uses hash and XOR operations which are appropriate for the resource-constrained nodes and devices. The authors proved that it is resistant to many security attributes such as DoS attack, impersonation attack, stolen smart device attack, and offline password guessing. To mitigate the security flaws which are shown in several light weight two-factor or three-factor authentication and key agreement protocols, Ostad-Sharif et al. [25] proposed an three-factor authentication and key agreement protocol for IoT-based Wireless Sensor Network. The formal security analysis of this protocol has been validated by using AVISPA tool. The authors claimed that this work is efficient and appropriate for IoT-based WSN environments.

Based on dynamic reconstruction of metadata, a structure for preservation of cloud users’ data privacy has been established by Waqar et al. [26]. The authors also used the mechanisms of database table splitting, data classification, and data encryption/decryption for protecting the metadata stored in cloud’s database. A top-down utility paradigm for cloud and IoT by using mobile devices and sensor networks has been established by Distefano et al. [27]. To achieve efficient communication between the device and cloud, a framework for integrating the IoT and cloud in a unified programming model has been proposed by Persson et al. [28]. Stergiou et al. [29] presented a survey on IoT and cloud computing by focusing on the security issues of these technologies. Moreover, the authors integrated both technologies to determine the common features and to examine the benefits of the combination. Furthermore, the authors proposed an algorithm to survey the security challenges of the merged IoT and cloud computing. An authentication scheme was developed by Chatterjee et al. [30] which uses three-way approaches for IoT environment based on ECC. The authors perform the security analysis and claims that their protocol secure against various cryptographic attack.

Another ECC-based authentication protocol for IoT and cloud environments has been developed by Kalra et al. [31]. The authors claimed that their protocol offers mutual authentication using the HyperText Transfer Protocol (HTTP) cookies. Additionally, they proved that the protocol is resistant to several security attacks. However, Chang et al. [32] found that the protocol in [31] failed to achieve mutual authentication and the session key agreement is infeasible. The authors also tried to overcome the security flaws of the protocol [31] by establishing an improved authentication protocol for IoT and cloud environments. Afterward, in 2017, Wang et al. [33] reviewed the protocols [31, 32] and pointed out that both of the protocols [31, 32] are insecure. Subsequently, the authors proposed a secure authentication protocol for IoT networks and ensured the security of their protocol. However, the protocol in [33] failed to achieve device privacy and vulnerable to impersonation attack and many logged-in devices’ attack. Kumari et al. [34] analyzed and found that the protocol [31] does not offer mutual authentication, affected by various security attacks and session key agreement is infeasible. To overcome these security flaws, the authors proposed an improved authentication protocol for IoT environment based on ECC. However, this protocol consumes more computational cost and storage cost as compared to the protocol [31]. In 2018, Bhubaneswari et al. [35] also analyzed the protocol [31] and showed that the protocol is vulnerable to several security attacks and subsequently approached an enhanced mutual authentication protocol for IoT network. However, this protocol does not provide mutual authentication and also unable to offer perfect forward secrecy.

The advantages and disadvantages of the most relevant authentication schemes to the proposed protocol are summarized in Table 1.

Table 1 Analysis of relevant authentication protocols

3 Preliminaries

3.1 Elliptic curve cryptography (ECC)

Elliptic curve cryptography is a public key cryptography technique which depends on the algebraic structure of elliptic curves over finite fields $Z_{q}$ [36]. Most of the current cryptographic systems prefer to use ECC to achieve greater security and efficient computation. The security strength of the ECC mainly lies in the difficulty involved to solve the elliptic curve discrete logarithm problem (ECDLP). It can provide an equivalent level of security as of RSA by using fewer key bits [36], i.e., the 160-bit elliptic curve key achieves the equivalent level of security strength as RSA key size of 1024 bits [37]. A brief overview of ECC is analyzed below:

The equation of the elliptic curve $E{}_{q}(a,b)$ over $Z_{q}$ is written as $y^{2} \bmod q = x^{3} + ax + b(\bmod q)$, where $q$ is a large prime number and $a$ and $b$ are two constant ($a,b \in Z_{q}$) such that the condition $4a^{3} + 27b^{2} \ne 0$ should be satisfied. Any point $(x,y)$$\in$$E_{q} (a,b)$,$x,y \in$$Z_{q}$ together with $O$ forms an additive cyclic group $E_{g} = \{ (x,y)\, \in\, E_{q} (a,b)\} \cup \{ O\}$, where $O$ is defined as ‘point at infinity.’ The point multiplication on the cyclic group is computed by repeated addition, i.e., $m \cdot P = \overbrace {P + P \cdot \cdot \cdot \cdot + P}^{{{\text{m }}times}}$. The further details of the elliptic curve cryptosystem properties are analyzed in [36].

The computational problems over $E_{g}$ have been described below [36, 38, 39]:

Definition 1

(ECDLP: Elliptic Curve Discrete Logarithm Problem): Given $P, \, Q \in E_{g}$, difficult to find an integer $m \in$ [1, $n$ − 1], such that $Q = m \cdot P$.

Definition 2

(CDHP: Computational Diffie Hellman Problem): For $a,b \in$ [1, $n$ − 1], given $P, \, aP$ and $bP$, difficult to compute $abP$.

4 The proposed protocol

In this section, a secure authentication protocol based on ECC has been proposed for the IoT environment. Here, various phases of the proposed protocol have also been described. The notations which are used in the proposed protocol are listed in Table 2.

Table 2 Notations used in the proposed protocol

The operational workflow diagram of the proposed protocol is presented in Fig. 1. The proposed protocol consists of two phases: (1) Registration phase and (2) Login and authentication phase. These phases are described as follows:

Fig. 1

The operational flow diagram of the proposed protocol

4.1 Registration phase

Step 1 ($ED_{i} \to CS$): $ED_{i}$

• 1. At the initial stage of the network entry, to register with the cloud server $CS$, the embedded device $ED_{i}$ computes protected identity $I_{i} = H(ID_{i} )$ and generates a unique password $PW_{i}$ for each device $ED_{i}$. Then, it computes the password verifier $PV_{i} = PW_{i} \cdot P$ and sends {$I_{i}$,$PV_{i}$} to CS, where password verifier $PV_{i}$ has been computed and sends to achieve the device privacy and to prevent the impersonation attack and many logged-in devices’ attack.

Step 2 ($CS \to ED_{i}$): $CS$

• 1. After receiving the registration request, $CS$ stores {$I_{i}$,$PV_{i}$} and a status bit into a write protected mode as defined in Table 3. Here, the status bit signifies the current status of the device, i.e., when the device is logged into the server, the status bit is set to one ‘1,’ otherwise it is set to zero ‘0.’

  Table 3 The verifier table with device status bit

• 2. Generates a random number $R_{S}$ and computes the cookie $CK$,

  $$ CK = H(R_{S} \parallel X_{CS} \parallel E_{T} \parallel I_{i} ) $$
  $$ CK^{'} = CK \cdot P. $$

• 3. Calculates the other security parameters as follows:

  $$ T_{i} = R_{S} \oplus H(X_{CS} ) $$
  $$ A_{i} = H(R_{S} \oplus H(X_{CS} ) \oplus CK^{'} ) $$
  $$ A_{i}^{'} = A_{i} \cdot P. $$

• 4. Stores {$ET_{i} = T_{i} \oplus X_{CS}$, $EA_{i}^{'} = A_{i}^{'} \oplus R_{S}$ and $EE_{T} = E_{T} \oplus R_{S}$} corresponding to $I_{i}$ of the device $ED_{i}$ in its database. Here, the security parameters are encrypted and then stored to avoid the impersonation attack.

• 5. Afterward, $CS$ sends $CK^{'}$ to the embedded device $ED_{i}$ in a secure channel.

Step 3 $ED_{i}$

• 1. After receiving $CK^{'}$, the embedded device stores $CK^{'}$ in its memory.

4.2 Login and authentication phase

Step 1 ($ED_{i} \to CS$): $ED_{i}$

• 1. Before every login, it generates a random nonce $R_{1}$ and then calculates the values of $P_{1}$,$P_{2}$ using the formulas:

  $$ P_{1} = R_{1} \cdot PW_{i} \cdot P $$
  $$ P_{2} = H(R_{1} \cdot PW_{i} \cdot CK^{'} ) $$

• 2. It encrypts $I_{i}$ such as, $EI_{i} = I_{i} \oplus K_{PV}$ where, $K_{PV} = PV_{x} \oplus PV_{y}$. Here, $K_{PV}$ has been derived by performing the XOR of the ECC point ($PV_{x} ,PV_{y}$) and used to encrypt the protected identity $I_{i}$.

• 3. Next, it sends the login request with { $P_{1}$, $P_{2}$, $EI_{i}$ } to the server.

Step 2 ($CS \to ED_{i}$): $CS$

• 1. After receiving the login request, it decrypts $I_{i}$ by using $K_{PV}$ and validates by checking $I_{i}$ to know whether $ED_{i}$ is a legal device or not. If not, rejects the login request. If yes, it retrieves the data associated with received $I_{i}$ from its database. Then, calculate different parameters as follows:

  $$ T_{i} = ET_{i} \oplus X_{CS} $$
  $$ R_{S} = T_{i} \oplus H(X_{CS} ) $$
  $$ E_{T} = EE_{T} \oplus R_{S} $$
  $$ A_{i}^{'} = EA_{i}^{'} \oplus R_{S} $$
  $$ CK = H(R_{S} \parallel X_{CS} \parallel E_{T} \parallel I_{i} ). $$

• 2. Computes $P_{2}^{*} = H(P_{1} \cdot CK)$ and verifies $P_{2}^{*} \mathop = \limits^{?} P_{2}$.

• 3. If the above condition is not valid, it discards the message; otherwise, it generates a random nonce $R_{2}$ and computes the values of $P_{3}$, $P_{4}$ and $T_{i}^{'}$ as follows:

  $$ P_{3} = R_{2} \cdot P $$
  $$ P_{4} = H(P_{1} \parallel R_{2} \cdot A_{i}^{'} ) $$
  $$ T_{i}^{'} = T_{i} \oplus K_{PV} . $$

• 4. Afterward, $CS$ sends { $P_{3}$,$P_{4}$,$T_{i}^{'}$ } to $ED_{i}$ for authentication.

Step 3 ($ED_{i} \to CS$): $ED_{i}$

• 1. After receiving { $P_{3}$, $P_{4}$, $T_{i}^{'}$}, it calculates $T_{i} = T_{i}^{'} \oplus K_{PV}$ and then $A_{i} = H(T_{i} \oplus CK^{'} )$.

• 2. Computes $P_{4}^{*} = H(P_{1} \parallel A_{i} \cdot P_{3} )$ and verifies $P_{4}^{*} \mathop = \limits^{?} P_{4}$.

• 3. If above condition is not satisfied, discard the message {$P_{3}$, $P_{4}$, $T_{i}^{'}$}; otherwise, $ED_{i}$ authenticates $CS$ and continues the process.

• 4. Afterward, it computes the session key $SK = R_{1} \cdot PW_{i} \cdot P_{3} = R_{1} \cdot R_{2} \cdot PW_{i} \cdot P$ and compute and sends a verifier $V_{i} = H(SK\parallel R_{1} \cdot PW_{i} \cdot P_{3} )$ to $CS$ for authentication.

Step 4 $CS$

• 1. After receiving the verifier $V_{i}$, it calculates the session key $SK = R_{2} \cdot P_{1} = R_{1} \cdot R_{2} \cdot PW_{i} \cdot P$.

• 2. Computes $V_{i}^{*} = H(SK\parallel R_{2} \cdot P_{1} )$ and verifies $V_{i}^{*} \mathop = \limits^{?} V_{i}$.

• 3. If the above condition is false, $V_{i}$ is discarded. Else, $CS$ authenticates $ED_{i}$ to achieve mutual authentication.

• 4. After mutual authentication between $ED_{i}$ and $CS$, the session key $SK = R_{1} \cdot PW_{i} \cdot P_{3} = R_{2} \cdot P_{1} = R_{1} \cdot R_{2} \cdot PW_{i} \cdot P$ is shared between them and all the consequent messages are transmitted between them by performing XOR operation with $SK$.

5 Security analysis

This section presents the attack model to show the capabilities of adversary, formal security verification using Automated Validation of Internet Security Protocols and Applications (AVISPA) tools to show the proposed protocol is secure against various attacks and also analyzes different security attributes related to the proposed protocol by the informal security analysis.

5.1 Attack model

Security is the most important part while designing the IoT model. In order to design attack free and more secure IoT devices and applications below issues should be addressed [24]:

• Denial-of-Service attack An adversary may disturb the network by overloading with the fake messages to degrade the performance of the network and making service unavailable. This will help the adversary to make the resources unavailable to the intended users.

• Eavesdropping attack The adversary may intercept the messages and read the ongoing communication between embedded device and cloud server. Subsequently, adversary may store the information and used that to launch the eavesdropping attack.

• Password guessing attack By using offline dictionary attack, an adversary can try to guess the password of the legal device to make feasible the attack.

• Impersonation attack By sending the valid messages of the previous communications with in the valid entities, an adversary can impersonate as a legal device.

• Man-in-the-middle attack At the time of live communication is going on with in two legitimate entities, an adversary can try to listen it. Later on, he can delete, alter or delay the transmission messages.

5.2 Formal security verification using AVISPA

The formal security verification of the proposed protocol through the simulation using the AVISPA [40, 41] tool has been performed. AVISPA is a push-button tool for automated validation of internet security protocols, which is a commonly accepted tool for formal security verification [42]. It integrates four back-ends: On-the-fly Model-Checker (OFMC), Constraint Logic-based Attack Searcher (CL-AtSe), SAT-based Model-Checker (SATMC) and Tree Automata based on Automatic Approximations for the Analysis of Security Protocols (TA4SP). The detailed analyses of these back-ends are described in [40]. The role oriented language such as High-Level Protocol Specification Language (HLPSL) [40] in AVISPA has been used for implementing the security protocols. This language contains the basic roles and composition roles representing each participant role and the scenarios of basic roles, respectively. An intruder (i) is modeled by using the Dolev–Yao model [43]. Consequently, in the protocol run time, the intruder (i) is permitted to act a legitimate role. In HLPSL, some basic roles, a number of principals and a number of sessions are defined. The HLPSL2IF translator is used to convert HLPSL to intermediate format (IF). The IF is then used as input to any one of the four back-ends which produces output format (OF). The detailed description of the OF is presented in [40].

The proposed protocol is simulated by using the Security Protocol Animator for AVISPA (SPAN) [40] under the OFMC and CL-AtSe back-ends. To check the chance of a replay attack, both the back-ends verify if the specified legitimate agents can execute the specified protocol by performing a search of a passive intruder. The back-ends provide the intruder (i) about the information of some normal sessions between the legitimate agents. Subsequently, both the back-ends also verify if there is any possibility of a man-in-the-middle attack by the intruder for the Dolev–Yao model checking. The simulation has been done to show the proposed protocol is secure and safe against various security attacks.

The HLPSL code developed for simulation is shown in Fig. 2, 3 and 4. The simulation results of the analysis under both back-ends are presented in Fig. 5. The simulation results ensure that the proposed protocol is safe from replay and man-in-the-middle attack.

Fig. 2

HLPSL code for role specification of Edi

Fig. 3

HLPSL code for role specification of CS

Fig. 4

HLPSL code for role specification of session, goal and environment

Fig. 5

The simulation results of the proposed protocol using OFMC and CL-AtSe back-ends

5.3 Informal security analysis

This section analyzes different security attributes related to the proposed protocol and compares them with the other related protocols [10, 13, 31,32,33,34,35]. The result of the analysis is summarized in Table 4.

Table 4 Security comparison of the proposed protocol with other existing protocols

5.3.1 S1: mutual authentication

In the proposed protocol, during login and authentication process, cloud server authenticates embedded device by verifying $P_{2}^{*} \mathop = \limits^{?} P_{2}$ and $V_{i}^{*} \mathop = \limits^{?} V_{i}$. In step 1 of login and authentication phase, the device computes $P_{2} = H(R_{1} \cdot PW_{i} \cdot CK^{'} )$ which is only computed by a legal device and sends it to the cloud server. Then, the server computes $P_{2}^{*} = H(P_{1} \cdot CK)$ where, $P_{1} = R_{1} \cdot PW_{i} \cdot P$ and verifies $P_{2}^{*} \mathop = \limits^{?} P_{2}$. Similarly, in step 3 of the login and authentication phase, the device computes $V_{i} = H(SK\parallel R_{1} \cdot PW_{i} \cdot P_{3} )$ and sends it to cloud server. Next, the cloud server verifies $V_{i}^{*} \mathop = \limits^{?} V_{i}$ to authenticate embedded device. Also, the device authenticates the cloud server by verifying $P_{4}^{*} \mathop = \limits^{?} P_{4}$. In step 2 of the login and authentication phase, the server computes $P_{4} = H(P_{1} \parallel R_{2} \cdot A_{i}^{'} )$ where, $A_{i}^{'} = A_{i} \cdot P$ and sends it to device. After this, the device computes $P_{4}^{*} = H(P_{1} \parallel A_{i} \cdot P_{3} )$ and verifies $P_{4}^{*} \mathop = \limits^{?} P_{4}$ to authenticate cloud server. By observing this process, it is found that above conditions are satisfied. Hence, it is concluded that the proposed protocol provides proper mutual authentication. In contrast, in the existing protocols [31, 35], the embedded device cannot compute $A_{i} = H(T_{i} \oplus PW_{i} \oplus CK^{'} )$ and $A_{i} = H(B_{i} \oplus CK^{'} \oplus H(S\_ID_{i} |PW_{i} ))$ since it does not have the knowledge of $PW_{i}$ and $B_{i}$. Hence, the verification $P_{4}^{*} \mathop = \limits^{?} P_{4}$ is not possible. Thus, the protocols [31, 35] failed to provide the mutual authentication.

5.3.2 S2: replay attack

In the proposed protocol, an adversary may try to capture the transmission message { $P_{1}$,$P_{2}$,$I_{i}$ } which is transmitted from device to server. The adversary may login as a legal device by re-transmitting the captured message to affect the replay attack. After receiving the login request, the server will assume that replay attack has been occurred as the status bit is already set to ‘1’ for the previously logged device. If it is assumed that by any means adversary impersonates the legal device, then, after receiving adversary login request, $CS$ retrieves the data associated to $I_{i}$ and computes $CK$ and $P_{2}^{*}$. Afterward, $CS$ verifies $P_{2}^{*} \mathop = \limits^{?} P_{2}$ and delivers {$P_{3}$,$P_{4}$, $T_{i}^{'}$} to $ED_{i}$. However, upon receiving the message {$P_{3}$, $P_{4}$, $T_{i}^{'}$}, the adversary is unable to calculate $A_{i} = H(T_{i} \oplus CK^{'} )$ without the knowledge of $T_{i}$ because of the encrypted $T_{i}$ where, $T_{i}^{'} = T_{i} \oplus K_{PV}$ is sent through the channel and $K_{PV}$ is only computed by $ED_{i}$ and $CS$. Moreover, it will not be easy for the adversary to calculate the session key $SK = R_{1} \cdot PW_{i} \cdot P_{3} = R_{1} \cdot R_{2} \cdot PW_{i} \cdot P$ and the authentication parameter $V_{i} = H(SK\parallel R_{1} \cdot PW_{i} \cdot P_{3} )$. Thus, the proposed protocol is free from replay attack.

5.3.3 S3: password guessing attack

The password guessing attack is a vital problem in any password based secure authentication scheme. In the proposed protocol, the password verifier $PV_{i} = PW_{i} \cdot P$ is stored in the server in a write protected file and it is difficult for the adversary to retrieve the password $PW_{i}$ from $PV_{i}$ due to the hard of ECDLP. Hence, the password guessing attack is not possible in the proposed protocol. In contrast, in the existing protocol [24], the adversary retrieves a password $PW_{i}$ in a following manner;

Assume that $ED_{i}$’s password is $PW_{1}$ and it is used to calculate $A_{i}^{*} = H(T_{i} \oplus PW_{1} \oplus CK^{'} )$. Next, $P_{4}^{*} = P_{3} \cdot A_{i}^{*}$ is computed and the condition $P_{4}^{*} \mathop = \limits^{?} P_{4}$ is verified to find the correct value of $PW_{1}$. If the condition is satisfied, the adversary will consider $PW_{i} = PW_{1}$. Otherwise, the process will continue till the adversary obtains the proper password $PW_{i}$. Similar process can be followed for the protocol [32] to obtain the password $PW_{i}$. Hence, these protocols can get affected by password guessing attack.

5.3.4 S4: device privacy

To ensure the privacy of the device, the identity of the device should not be transmitted directly without protection. In the login and authentication phase of the proposed protocol, device transmits {$P_{1}$, $P_{2}$, $EI_{i}$} to the server. Here, $EI_{i}$ is the encryption version of protected identity $I_{i}$ i.e. $EI_{i} = I_{i} \oplus K_{PV}$, where, $K_{PV} = PV_{x} \oplus PV_{y}$. Moreover, $K_{PV}$ is calculated from $PV$ which is difficult to calculate by an adversary due to the fact that $PV$ is never transmitted through any messages in the login and authentication phase. Therefore, the proposed protocol preserves the device privacy. However, in the existing protocols [31, 33], the identity of the device $ID_{i}$ is transmitted directly from $ED_{i}$ to $CS$ through the login request message {$P_{1}$, $P_{2}$, $ID_{i}$} during login and authentication phase. Thus, these protocols fail to preserve device privacy.

5.3.5 S5: insider attack

Insider attack can occur when a privileged insider steals the password from the server’s information to use it for accessing other servers (where the device is previously registered with the same information) by making a login request. In the proposed protocol, a password verifier table has been maintained which contains protected device identity $I_{i}$, password verifier $PV_{i} = PW_{i} \cdot P$ and a status bit. The retrieval of the password $PW_{i}$ from the password verifier $PV_{i}$ is impossible due to the hard of ECDLP. Hence, the proposed protocol prevents the insider attack. In the existing protocols [31, 32], password $PW_{i}$ is generated by $CS$ for every $ED_{i}$ during the registration phase. Consequently, the insider of $CS$ easily gets the password $PW_{i}$ which can be misused. Hence, the protocols [31, 32] are vulnerable to insider attack.

5.3.6 S6: man-in-the-middle attack

In the proposed protocol, due to the achievement of mutual authentication between $ED_{i}$ and $CS$, man-in-the-middle attack is not feasible. However, the existing protocols [13, 14, 35] do not achieve mutual authentication. Thus, man-in-the-middle attack is feasible for the existing protocols [13, 14, 35].

5.3.7 S7: impersonation attack

If the adversary accesses the security parameters stored in the server, the impersonate attack takes place. In the proposed protocol, the server stores {$PV_{i}$, $ET_{i} = T_{i} \oplus X_{CS}$, $EA_{i}^{'} = A_{i}^{'} \oplus R_{S}$ and $EE_{T} = E_{T} \oplus R_{S}$} corresponding to $I_{i}$ of the device $ED_{i}$ in its database. Let us assume that the server compromises the stored value. Under this situation also the adversary cannot access the values of {$T_{i}$, $A_{i}^{'}$, $E_{T}$} because these are protected by the random nonce $R_{S}$ and the secret key $X_{CS}$ of the cloud server and $PV_{i}$ is stored with a status bit in a write protected mode. Moreover, without knowing the value of {$T_{i}$, $A_{i}^{'}$, $E_{T}$}, $R_{S}$ and $X_{CS}$, it is impossible to obtains the cookie $CK = H(R_{S} \parallel X_{CS} \parallel E_{T} \parallel I_{i} )$ to validate the login request. Furthermore, it is not possible to communicate further for authentication. Therefore, the proposed protocol is immune to impersonation attack. In contrast, in the existing protocol [31], during registration process, the cloud server stores {$A_{i}^{'}$, $T_{i}$, $ID_{i}$ and $E_{T}$} in its database. If the server compromises these values, the adversary can impersonate as server as follows: In the login and authentication process, the adversary intercepts the login request message {$P_{1}$, $P_{2}$, $ID_{i}$ }. Then, it retrieves the values associated with $ID_{i}$ from the captured values. Afterward, the adversary selects a random number $R_{x}$, computes $P_{3x} = R_{x} \cdot P$ and $P_{4x} = R_{x} \cdot A_{i}^{'}$ and subsequently sends{$P_{3x}$, $P_{4x}$, $T_{i}$} to $ED_{i}$. Upon receiving {$P_{3x}$, $P_{4x}$, $T_{i}$}, device $ED_{i}$ would calculate $P_{4x}^{*} = A_{i} \cdot P_{3x}$. Since, $P_{4x}^{*} = A_{i} \cdot P_{3x} = A_{i} \cdot R_{x} \cdot P = R_{x} \cdot A_{i}^{'} = P_{4x}$, device will confirm that it is connected to the legal server. Thus, it is easy for the adversary to impersonate as server. By following the similar process, it can be said that the impersonation attack is feasible for the protocols [32,33,34,35].

5.3.8 S8: many logged-in device’s attack

If the identity and password of the legal devices are exposed by any means to many adversaries, then, by using that information the adversaries can access the account of the legal device resulting in many logged-in devices’ attack. In the proposed system, many adversaries can try to access the account by using the proper identity and password of the legal device but only a single adversary can access the account. This is due to the fact that when a device logs in, the status bit is set to ‘1.’ In the meantime, if other adversaries use the same information to log into the server, then the server rejects the attempt because the status bit indicates that some device is already logged in. Hence, the proposed protocol is free from many logged-in devices’ attack. However, for the protocols [10, 31,32,33,34,35], if the identity and password are leaked, they are unable to prevent the many logged-in devices’ attack as they have not included the concept of setting the login status of the logged device.

5.3.9 S9: session key agreement

In the proposed protocol, during the authentication process, the device and the server individually generates the session key $SK = R_{1} \cdot PW_{i} \cdot P_{3} = R_{2} \cdot P_{1} = R_{1} \cdot R_{2} \cdot PW_{i} \cdot P$ and shares it. Since the computation of the session key depends on the device password $PW_{i}$ and the random nonce $R_{1}$ and $R_{2}$, it is impossible for the adversary to compute the session key. Thus, the session key agreement is achieved properly. However, in the existing protocol [31] the computation of session key $SK = H(X_{CS} \parallel ID_{i} \parallel R_{1} \parallel R_{2} )$ is not possible due to the fact that neither $ED_{i}$ has the knowledge of $R_{2}$ and $X_{CS}$ nor $CS$ has the knowledge of $R_{1}$. Correspondingly, in the protocol [35], the verification $V_{i}^{ * } \begin{array}{*{20}c} ? \\ = \\ \end{array} V_{i}$ is false and hence session key cannot be generated. Thus, the session key agreement is not feasible in the protocols [31, 35].

5.3.10 S10: perfect forward secrecy

Perfect forward secrecy indicates that the session keys should not be affected by the adversary even if the device’s password $PW_{i}$ and the cloud server’s secret key $X_{CS}$ are exposed. In the proposed protocol, the session key $SK = R_{1} \cdot PW_{i} \cdot P_{3} = R_{2} \cdot P_{1} = R_{1} \cdot R_{2} \cdot PW_{i} \cdot P$ has been generated by the device and the server individually. Assuming the adversary has the knowledge of $PW_{i}$ and $X_{CS}$, it is impossible to generate the session key because it requires random nonce $R_{1}$ and $R_{2}$. If the adversary tries to retrieve $R_{1}$ and $R_{2}$ from the pair ($P_{1}$, $P_{2}$) = ($R_{1} \cdot PW_{i} \cdot P$, $R_{2} \cdot P$), it is difficult to find due to the hard of CDHP. Therefore, the proposed protocol achieves perfect forward secrecy. In contrast, the protocols [31, 35] cannot achieve perfect forward secrecy because session key agreement is not feasible as mentioned in S8.

6 Performance analysis

In this section, the performance of the proposed protocol has been analyzed and compared with the existing related protocols [10, 13, 31,32,33,34,35] with respect to computational overhead, bandwidth consumption, storage overhead and total computational time.

6.1 Computational overhead

A comparison of the computational overhead of the proposed protocol with the existing related protocols is presented in Table 5. Since, in an authentication protocol, the login and authentication phase is executed more frequently as compared to other phases, only this phase has been considered for the purpose of calculation. In this regard, $T_{H}$, $T_{EPM}$ and $T_{ECA}$ have been denoted as the computational time of hash operation, elliptic curve point multiplication and elliptic curve point addition, respectively. During calculation, the computational overhead of some lightweight operations such as XOR, concatenation, comparison, etc., have been ignored because of their insignificant impact as compared to other operations.

Table 5 Computational overhead of the proposed protocol and related protocols

From Table 5, it is found that the computational overhead of the proposed protocol is lesser than the related protocols [10, 32, 33]. However, the computational overhead of the proposed protocol is little higher than the protocols [13, 31, 34, 35]. This is due to the fact that, the proposed protocol achieves forward secrecy through the session key agreement between embedded device and cloud server which is not feasible in the protocol [31, 35]. Moreover, the proposed protocol adopts password verifier and uses more security function to avoid some of the security flaws which are cannot prevent by the protocol [13].

6.2 Communication overhead

Bandwidth consumption is the essential measure of communication overhead. Bandwidth consumption of the proposed protocol is equivalent to the total size of the login and authentication messages. For calculating the size of the login and authentication messages, the length of following parameters has been assumed:

• The length of the each of the random nonce ($R_{1}$,$R_{2}$,$R_{s}$) is 160 bits.

• The length of device identity $ID_{i}$ is 160 bits.

• The length of the each of the security parameters {$CK^{'}$, $T_{i}^{'}$, $V_{i}$} is 160 bits.

• The length of the output of hash function (SHA-1) [44] is 160 bits.

• Since the security strength of 160 bit ECC is equivalent to 1024 bit RSA cryptosystem [37, 45], an ECC point $P = (P_{x} ,P_{y} )$ needs (160 + 160) = 320 bits [46].

The calculation of the size of the login and authentication messages of the proposed protocol has been analyzed bellow:

Message 1 = $P_{1} \parallel P_{2} \parallel EI_{i}$ = 320 + 320 + 160 = 800 bits

Message 2 = $P_{3} \parallel P_{4} \parallel T_{i}^{'}$ = 320 + 320 + 160 = 800 bits

Message 3 = $V_{i}$ = 160 bits

Therefore, bandwidth consumption of the proposed protocol is:

Bandwidth = $\sum\nolimits_{i = 1}^{3} {Message(i)}$ = 1760 bits.

The bandwidth consumption of the proposed protocol and the related protocols [10, 13, 31,32,33,34,35] is presented in Table 6.

Table 6 Bandwidth consumption of the proposed protocol and related protocols

Table 6 shows that the bandwidth consumption of the proposed protocol is the same as the related protocols [31,32,33,34,35] and little larger than the protocols [10, 13]. Hence, the proposed protocol has equivalent communication overhead as compared to the protocols [31,32,33,34,35] and competitive value with the protocols [10, 13].

6.3 Storage overhead

In this section, the storage overhead of the proposed protocol and some related protocols has been presented and compared. Here, the storage overhead of the embedded device has been considered for the purpose of calculation since it has minute memory as compared to the server memory. In the proposed protocol, the cookie $CK^{'}$ is stored in the embedded device ($ED_{i}$). The memory required by the $ED_{i}$ to store the cookie $CK^{'}$ is 320 bits. Similarly, in the protocols [31, 33] the $ED_{i}$ stores $CK^{'}$ = 320 bits in its memory. However, in the protocol [32], the $ED_{i}$ stores {$CK^{'}$, $H(PW_{i} )$} = 320 + 160 = 480 bits in its memory. Correspondingly, in the protocols [10] and [13], the device stores 1120 bits and 480 bits, respectively [31]. Comparison of the storage overhead of the embedded device of the proposed protocol with respect to the related protocols is illustrated in Table 7 and Fig. 6.

Table 7 Comparison of storage overhead of the proposed protocol with related protocols

Fig. 6

Comparative storage overhead

Figure 6 shows that the storage overhead of the embedded device in the proposed protocol is equivalent to the storage overhead of the protocols [31, 33, 35]. Moreover, the memory required by the embedded device in the proposed protocol is much lesser than the protocols [10, 13, 32, 34].

6.4 Computational time

The total computational time of the proposed protocol and the other related protocols is presented in Fig. 7. Here, the simulation has been performed by using MATLAB 2015a environment.

Fig. 7

Total computational time of the proposed protocol and the related protocols

From Fig. 7 it is noticed that the computational time of the proposed protocol is little larger than the protocols [31,32,33,34,35] which consumes 465.39 s. This is due to the fact that the proposed protocol adopts the concept of password verifier with the status bit and also uses some more security parameters to protect the system from various security attacks such as impersonation attack, device privacy, password guessing attack, insider attack, many login device’s attack and provide perfect forward secrecy as well as achieves proper mutual authentication which the protocols [31,32,33,34,35] cannot prevent. Hence, it can be said that the proposed protocol achieves greater security than the protocols [31,32,33,34,35] with the competitive computational time.

6.5 Discussion

The overall outcomes of the above analysis have been summarized below:

• 1. The proposed protocol achieves mutual authentication where the protocol [31] does not.

• 2. The proposed protocol attains better security than the related protocols [10, 13, 31,32,33,34,35].

• 3. The proposed protocol outperforms the protocols [10, 32, 33] in terms of computational overhead. The proposed protocol is also superior to the protocols [10, 13, 32, 34] as far as the storage overhead is concerned. However, the computational overhead of the proposed protocol is little higher than the protocols [13, 31, 34, 35] because the proposed protocol attains forward secrecy through the session key agreement between $ED_{i}$ and $CS$ which is not feasible in the protocols [31, 35] and also achieves better security than the protocols [13, 31, 34, 35].

• 4. The proposed protocol consumes little more time than the related existing protocols [31,32,33,34,35] for the total computation. The reason is that the proposed protocol employs a password verifier and some additional security parameters to defend several attacks which the protocols [31,32,33,34,35] are unable to prevent.

• 5. Overall, our proposed protocol outperforms the related protocols [10, 13, 31,32,33,34,35] in all respect.

7 Conclusions and future work

In this work, an ECC-based mutual authentication and security protocol has been proposed for the IoT and cloud servers. Earlier related existing authentication protocols for the IoT and cloud servers failed to provide the necessary security requirements as required. Simulation for the formal security analysis of the proposed protocol using AVISPA tool ensures that the protocol is safe and secure from various security attacks. Moreover, the informal security analysis of the present work shows that the proposed protocol attains higher security than the related protocols [10, 13, 31,32,33,34,35]. The performance analysis of the present work finds that the computational overhead of the proposed protocol is lesser than the protocols [10, 32, 33]. Furthermore, the communication and storage overhead of the proposed protocol is equivalent to the protocols [31,32,33,34,35] and [31, 33, 35], respectively, and also needs much lesser storage overhead than the protocols [10, 13, 32, 34]. However, the total computational time and the computational overhead of the proposed protocol are little larger than the protocols [31,32,33,34,35] and [13, 31, 34, 35], respectively. Hence, it can be concluded that our proposed protocol is capable enough to provide an improved secure mutual authentication model for IoT and cloud server environments.

In the future, our work can be extended toward the further improvement of the total computational time and the computational overhead of the proposed protocol without sacrificing the level of security. We would also like to derive the behavior and reliability model for the proposed protocol so that the users could have prior knowledge about the system behaviors and reliabilities before using the model. The proposed protocol can be applicable to any IoT industries, where the data security and the authentication are the prime important part of the integration of embedded devices and cloud servers.