A secure authentication scheme based on elliptic curve cryptography for IoT and cloud servers

Abstract

The Internet of Things (IoT) is now a buzzword for Internet connectivity which extends to embedded devices, sensors and other objects connected to the Internet. Rapid development of this technology has led to the usage of various embedded devices in our daily life. However, for resource sharing and communication among these devices, there is a requirement for connecting these embedded devices to a large pool of resources like a cloud. The promising applications of IoT in Government and commercial sectors are possible by integrating cloud servers with these embedded devices. But such an integration of technologies involves security issues like data privacy and authentication of devices whenever information is exchanged between them. Recently, Kalra and Sood proposed an authentication scheme based on elliptic curve cryptography (ECC) for IoT and cloud servers and claimed that their scheme satisfies all security requirements and is immune to various types of attacks. However, in this paper, we show that Kalra and Sood scheme is susceptible to offline password guessing and insider attacks and it does not achieve device anonymity, session key agreement, and mutual authentication. Keeping in view of the shortcomings of Kalra and Sood’s scheme, we have proposed an authentication scheme based on ECC for IoT and cloud servers. In the proposed scheme in this paper, we have formally analyzed the security properties of the designed scheme by the most widely accepted and used Automated Validation of Internet Security Protocols and Applications tool. Security and performance analysis show that when compared with other related schemes, the proposed scheme is more powerful, efficient, and secure with respect to various known attacks.

1 Introduction

An integrated system comprising of computer software, hardware as well as mechanical components and having task-specific processing ability is called as an embedded device. Embedded devices have evolved from a single microcontroller chip having limited abilities to intelligent systems having enhanced connectivity, processors, and operating systems. Such smart systems can be deployed by enterprises to create interrelated and efficient systems that are able to communicate, collect and analyze data.

Nowadays, the embedded device can act as a HTTP (Hyper Text Transfer Protocol) client. For that reason, the embedded device must be configured with TCP/IP protocol stack. HTTP is a request–response protocol in the client/server communication model. In general, all personal computers require the assistance of the HTTP protocol. This status is also appropriate for embedded devices. In the present market, the majorities of the embedded devices are configured with a Web browser and can act as HTTP clients. Such embedded devices are deployed in the field without the need of any user interface by various specialized softwares. This scenario is called as the Internet of Things (IoT). IoT is formally defined as the interconnection of distinctively identifiable embedded computing devices (i.e., things) in the prevailing Internet organization. Basically, IoT involves the connection of various embedded devices to the Internet. IoT includes real world and small things having limited storage and processing capabilities, and subsequent issues like reliability, security, privacy, and performance.

These embedded devices are widely used across the globe for data sharing and communication. The data generated from these devices need to be analyzed using one of the most popular infrastructures called as cloud computing. It possesses virtually infinite storage and processing power and has partially resolved most of the IoT issues. Hence, a novel IT paradigm where Cloud and IoT, two complementary technologies integrated together as CloudIoT, is expected to bring about an unprecedented growth in current and future Internet [1,2,3]. CloudIoT solves most problems [4,5,6], and also provides added features like ease-of-access, ease-of-use, and decreased deployment costs [5]. Security, a concern in all networked environments, is a major problem for CloudIoT as well. Both the IoT (i.e., WSN, RFID) and Cloud sides are susceptible to a number of attacks. In IoT environment, encryption guarantees data confidentiality, authenticity, and integrity. However, it is not able to address insider attacks (e.g., during WSN reprogramming) and is difficult to implement on devices that are computation-constrained.

In cloud IoT environment, with the assistance of specialized software, the embedded devices act as HTTP clients and can communicate with HTTP-enabled cloud server(HTTP server). This implies that machine-to-machine communication is feasible(as shown in Fig. 1). Embedded devices can extract a large amount of data storage and computational facilities from cloud computing infrastructure. Based on the processes in the cloud, networked embedded devices are simply not restrained to their local resources. However, security is a major issue while connecting to a cloud for using resources [7, 8]. Embedded devices (HTTP client) and HTTP-enabled cloud server (HTTP server) should be mutually authenticated before accessing cloud services. In situations where processing power and memory are limited, it is appropriate to use elliptic curve cryptography (ECC), a type of public key cryptography [9, 10].

Fig. 1

Cloud-connected embedded devices

An authentication plays a pivotal role when embedded devices and cloud computing services are integrated together. Several authentication schemes [11,12,13,14,15,16,17,18,19,20,21,22] based on ECC have been proposed in the past. Such authentication schemes are appropriate for smart devices proposed by Wu et al. [11], Tian et al. [12], Abichar et al. [13]. But these schemes suffer from several shortcomings. For example, the scheme of Wu et al. only allows the server to authenticate the users. But, this scheme is insecure as an attacker can disguise as a server and extract user information. In contrast, the schemes proposed by Tian et al. [12] and Abichar et al. [13] offer mutual authentication using certificates. Certification schemes increase the cost as extra computations need to be performed by the server and users to verify each other’s identity. Authentication schemes for smart devices based on ECC have also been presented by Yang et al. [14], Hafizul et al. [15] and Debiao et al. [16], Ray et al. [17], Granjal et al. [18], Jiang et al. [19]. The proposed schemes, based on various types of ECC, involve concepts extending from time stamps to certificate-based mutual authentication. An attribute-based light weight encryption scheme for IoT based on ECC has been presented by Yao et al. [20].

1.1 Our contributions

Very recently, in 2015, Kalra and Sood [23] proposed an authentication scheme to connect embedded devices to the cloud server using ECC for IoT and claimed their scheme achieves all security requirements and is resistant to various attacks. But, in this paper, we show that Kalra and Sood’s scheme is vulnerable to offline password guessing and insider attacks and that it fails to achieve device anonymity, session key agreement, and mutual authentication. In order to fix the shortcomings of Kalra and Sood’s scheme, we have proposed an enhanced authentication scheme based on elliptic curve cryptography (ECC) for IoT and cloud servers which is proficient to mitigate various types of known attacks and achieves various security goals.

1.2 Organization of the paper

The rest of the paper is organized as follows. The preliminaries of elliptic curve cryptography (ECC) have been discussed in Sect. 2. A review of Kalra and Sood’s scheme is discussed in Sect. 3. The weaknesses of Kalra and Sood scheme have been described in Sect. 4. The proposed scheme and its analysis have been presented in Sects. 5 and 6. The performance analysis and security requirement comparisons have been discussed in Sect. 7. Finally, conclusions have been presented in Sect. 8.

2 Preliminaries

This section provides brief introduction to the elliptic curve cryptography [24,25,26]. The security strength of the ECC based on the hardness of solving the elliptic curve discrete logarithm problem (ECDLP) and it can provide same level of security strength with smaller key size [27]. ECC with smaller key size leads to evident cost savings. ECC with smaller key size also facilitates the design of faster cryptographic operations that run on small chips with tiny memory. This is appropriate for resource-constrained systems since it reduce the power consumption and heat production. As a result, ECC is well suitable for smart devices that operate in resource constraint environments [28].

2.1 Theory of elliptic curve

The equation of the elliptic curve $E_p(a, b)$ over $F_p$ ($p>3$ and is a large prime number) is defined as $y^{2}\,\hbox {mod}\,p \equiv (x^{3}+ax+b)\,\hbox {mod}\,p$ where $(4a^{3}+27b^{2})\,\hbox {mod}\,p\ne 0$; $x,y,a,b\in [0, p-1]$. Any points $(x, y)\in E_p(a, b)$ are denoted as $E(F_p)=\{(x,y):x,y\in F_p\,\,\hbox {satisfy}\,\,y^{2}\equiv (x^{3}+ax+b)\}\cup \{\mathcal {O}\}$ where $\mathcal {O}$ is a point at infinity. The point multiplication is computed by repeated addition as $k\cdot P=\overbrace{P+P\cdots P}^{k\,\mathrm{times}}$. The detailed elliptic curve group properties can be found in [24].

Definition 1

(Elliptic Curve Discrete Logarithm Problem(ECDLP)) Given P and Q in an elliptic curve $E_{p}(a,b)$, find an integer $k \in Z_p^*$ such that $Q = kP$.

3 Review of Kalra and Sood’s scheme

In this section, we review Kalra and Sood’s scheme [23] based on ECC for embedded devices which act as HTTP clients. They used the idea of HTTP cookies in their scheme. Kalra and Sood’s scheme comprises three phases as follows: the registration phase, the pre-computation and login phase and authentication phase. They are explained as follows and also in Fig. 2.

Fig. 2

Summary of the Kalra–Sood’s scheme

3.1 Notations

The list of notations used in this paper is described in Table 1.

3.2 Initialization

Initially, ${ CS}$ chooses an elliptic curve (${ EC}$) equation $y^2=x^3+ax+b$ over $Z_p$ where $Z_{p}(p>2^{160})$ is the finite field group. Then, two field elements are selected by ${ CS}$, namely $a, b\in Z_p$, where a and b satisfy the condition $4a^{3}+27b^{2}\,(\hbox {mod}\,p)\ne 0$. Let the ${ EC}$ base point be G which has a prime order of n ($n>2^{160}$). Let $\mathcal {O}$ be the point at infinity satisfying the equation $n\cdot G = \mathcal {O}$. A random nonce $X_{\mathrm{cs}}$ is selected by ${ CS}$ as its secret key.

3.3 Registration phase

To register with ${ CS}$, ${ Ed}_i$ sends a distinct ${ Id}_i$ to ${ CS}$. Upon receiving this request, ${ CS}$ generates a distinct password ${ Pw}_i$ for each device ${ Ed}_i$.

Step R1.:

${ Ed}_i\rightarrow { CS}$: ${ Id}_i$, ${ CS}$ generates ${ Pw}_i$

${ CS}$ selects a random number $r_s$ for each ${ Ed}_i$ and computes a cookie $C_k=h(r_s|| X_{\mathrm{cs}}||E_t|| { Id}_i)$ and stores the cookie on ${ Ed}_i$ as EC point $C_k^{\prime }= C_{k}\cdot G$. Then, ${ CS}$ computes $T_i=r_s\oplus h(X_{\mathrm{cs}})$, $A_i=h(r_s\oplus h(X_{\mathrm{cs}})\oplus { Pw}_i\oplus C_{k}^{\prime })$ and stores $T_i$, $A_{i}^{\prime }=h(r_s\oplus h(X_{\mathrm{cs}})\oplus { Pw}_{i}\oplus C_{k}^{\prime })\cdot G$ along with ${ Id}_i$ of ${ Ed}_i$ in its database. The expiration time of the cookie $E_t$ that corresponds to ${ Id}_i$ of ${ Ed}_i$ is stored by ${ CS}$ itself. As well, the expiration time is updated to $E_t^{\prime }$ and the cookie is restructured as $C_{k} = h(r_s|| X_{\mathrm{cs}} ||E_t^{\prime }||{ Id}_{i})$ when the cookie expires.

Step R2.:

${ CS}\rightarrow { Ed}_i$: Cookie $C_k^{\prime }$

Table 1 Notations used in this paper

3.4 Pre-computation and login phase

Before each login, the ${ Ed}_i$ selects a random nonce $r_1$, computes the ECC point $P_1=r_1\cdot G$ and then stores it in its memory.

Step L1.:

${ Ed}_i$ computes ECC point $P_1$

To login with the cloud server(${ CS}$), ${ Ed}_i$ computes the ECC point $P_2=h(r_1\cdot C_{k}^{\prime })$ for login with ${ CS}$ and sends {$P_1$, $P_2$, ${ Id}_i$} to ${ CS}$.

Step L2.:

${ Ed}_i\rightarrow { CS}$: {$P_1$, $P_2$, ${ Id}_i$}

3.5 Authentication phase

Upon receiving the login request, ${ CS}$ computes cookie information $C_k=h(r_s||X_{\mathrm{cs}}||E_t||{ Id}_i)$ by computing $r_s$ from $T_i$ using its secret key $X_{\mathrm{cs}}$ as $r_s=T_i\oplus h(X_{\mathrm{cs}})$ and using ${ Id}_i$ of ${ Ed}_i$, $E_t$ and its secret key. Then, it computes the point $P_2^{*}=h(P_1\cdot C_{k})$ and verifies $P_{2}^{*}\overset{?}{=}P_{2}$. If the verification holds, then ${ CS}$ continues to the next step; Otherwise, ${ CS}$ rejects the login request of ${ Ed}_i$.

Step A1.:

${ CS}$ verifies $P_{2}^{*}\overset{?}{=}P_{2}$

${ CS}$ selects a random nonce $r_2$, computes the ECC point $P_3=r_2\cdot G$, $P_4=r_2\cdot A_i^{\prime }$ and sends {$P_3$, $P_4$, $T_i$} to ${ Ed}_i$.

Step A2.:

$CS\rightarrow \ { Ed}_i$: {$P_3$, $P_4$, $T_i$}

Upon receiving {$P_3$, $P_4$, $T_i$}, ${ Ed}_i$ computes $A_i=h(T_i \oplus { Pw}_i\oplus C_{k}^{\prime })$ and the ECC point $P_4^{*}=P_3\cdot A_{i}$. Then, it verifies $P_{4}^{*}\overset{?}{=}P_{4}$.

Step A3.:

${ Ed}_i$ verifies $P_{4}^{*}\overset{?}{=}P_{4}$

Then, ${ Ed}_i$ computes $V_i=h((r_1\cdot C_{k}^{\prime })||P_4^{*})$ and sends $V_i$ to ${ CS}$. After receiving $V_i$, ${ CS}$ computes $V_i^{*}=h((P_1\cdot C_{k})||P_4)$ and verifies $V_{i}^{*}\overset{?}{=}V_{i}$ to authenticate ${ Ed}_i$. If the verification holds, ${ CS}$ authenticates ${ Ed}_i$; Otherwise, $V_i$ is rejected.

Step A4.:

${ CS}$ verifies $V_{i}^{*}\overset{?}{=}V_{i}$

Subsequent to successful mutual authentication process between ${ Ed}_i$ and ${ CS}$, both agree on a common session key ${ SK}=h(X_{\mathrm{cs}}||{ Id}_i||r_1||r_2)$. From then on all the subsequent messages transmitted between ${ Ed}_i$ and ${ CS}$ are ${ XOR}$ed with the session key.

4 Cryptanalysis of Kalra and Sood’s scheme

In this section, we will discuss the security weaknesses of Kalra and Sood’s scheme. Through careful analysis, we find that Kalra and Sood’s scheme cannot achieve user anonymity, mutual authentication and session key agreement. Moreover, their scheme is vulnerable to offline password guessing and insider attacks. The details of these security weaknesses are described as follows.

4.1 Absence of device anonymity

In cloud environment, the leakage of device-specific information may facilitate an attacker to track the device’s login history and current location. Moreover, anonymity property makes authentication mechanism more strong as an attacker could not track which devices are interacting with the cloud server. A simple way to preserve anonymity is to conceal device’s valid identity throughout the communication. However, in Kalra and Sood’s scheme, ${ Ed}_i$’s identity (${ Id}_i$) is transmitted in plaintext through login request message {$P_1$, $P_2$, ${ Id}_i$}. As a result, an attacker can know about the logging device by monitoring the login request message and device’s privacy is not preserved by the scheme. Thus, an attacker can use wrongly the readily available identity(${ Id}_i$) of ${ Ed}_i$ to break the security wall of the scheme. Therefore, Kalra and Sood’s scheme fails to preserve device anonymity.

4.2 Offline password guessing attack

Suppose an attacker obtain the cookie information $C_k^{\prime }$ from the embedded device ${ Ed}_i$. Let us assume that an attacker intercepts the ${ CS}$’s response message as shown in Fig. 3. Through the intercepted message {$P_3$, $P_4$, $T_i$} from the open channel, attacker can obtain ${ Ed}_i$’s password ${ Pw}_i$ as follows:

• 1. Guess the ${ Ed}_i$’s password as ${ Pw}_a$.

• 2. Computes $A_i^{*}=h\left( T_i \oplus { Pw}_a\oplus C_{k}^{\prime }\right)$.

• 3. Computes $P_4^{\prime }=P_3\cdot A_{i}^{*}$.

• 4. Verifies the correctness of ${ Pw}_a$ by checking if $P_{4}^{\prime }\overset{?}{=}P_{4}$.

• 5. If the verification holds, considers ${ Pw}_a$ as the ${ Ed}_i$’s password. Otherwise, attacker repeats Steps 1–4 until the exact password ${ Pw}_i$ is found.

The above discussion shows that Kalra and Sood’s scheme is vulnerable to offline password guessing attack.

Fig. 3

Illustration of the offline password guessing attack

4.3 Insider attack

${ CS}$ generates a distinct password (${ Pw}_i$) for each ${ Ed}_i$ during registration phase, subsequently ${ Ed}_i$’s password (${ Pw}_i$) is known to the insider of ${ CS}$ who can misuse it. Therefore, Kalra and Sood’s scheme is vulnerable to insider attack.

4.4 Stolen-verifier attack

In Kalra and Sood’s scheme, during the registration phase of the ${ Ed}_i$, cloud server ${ CS}$ stores $T_i$, $A_i^{\prime }$ and $E_t$ with ${ Id}_i$ in its database. An attacker can steal this record from the database of ${ CS}$ and can use it to mount server impersonation attack. When ${ Ed}_i$ transmits the message {$P_1$, $P_2$, ${ Id}_i$} to ${ CS}$, the attacker intercepts and blocks it from reaching to ${ CS}$. The attacker obtains the values from the stolen record corresponding to the identity ${ Id}_i$ present in the message. Then the attacker selects a random nonce $r_a$, computes $P_{3a}=r_a\cdot G$, $P_{4a}=r_a\cdot A_i^{\prime }$ and sends {$P_{3a}$, $P_{4a}$, $T_i$} to ${ Ed}_i$. On receiving this message, ${ Ed}_i$ would compute $P_{4a}^{*}=P_{3a}\cdot h(T_i\oplus { Pw}_i\oplus C_k^{\prime })=r_a\cdot G\cdot h(T_i\oplus { Pw}_i\oplus C_k^{\prime })=r_a\cdot h(T_i\oplus { Pw}_i\oplus C_k^{\prime })\cdot G=r_a\oplus A_i^{\prime }=P_{4a}$, that is, $P_{4a}^{*}=P_{4a}$ meaning thereby that the response message sent by the attacker passes the verification test at ${ Ed}_i$. Thus, ${ Ed}_i$ is confirmed that it is connected with the legal ${ CS}$. Hence, the attacker is successful to impersonate as server using stolen verifiers of ${ Ed}_i$.

4.5 Session key computation is not possible

In Kalra and Sood’s scheme, the session key ${ SK}=h(X_{\mathrm{cs}}||{ Id}_i||r_1||r_2)$ is computed by both entities, embedded device ${ Ed}_i$ and the cloud server ${ CS}$. Considering the computation of session key at the device end, we observe that ${ Ed}_i$ has identity ${ Id}_i$ and its chosen random nonce $r_1$. However, ${ Ed}_i$ can neither obtain the random number $r_2$ from the received ECC point $P_3=r_2\cdot G$ nor it can know the value of the secret key $X_{\mathrm{cs}}$ of ${ CS}$. On the other hand, ${ CS}$ has its secret key $X_{\mathrm{cs}}$, its chosen number $r_2$ and the identity ${ Id}_i$ of ${ Ed}_i$. However, ${ CS}$ cannot retrieve the random number $r_1$ from the received ECC point $P_1=r_1\cdot G$. Consequently, none of these entities can compute the session key, hence there is no session key agreement in the Kalra and Sood’s scheme. For the reason that, in the Kalra and Sood’s scheme, the forward secrecy and backward secrecy goals are missed.

4.6 Mutual authentication is not possible

In Step A2 of the authentication phase, ${ Ed}_i$ computes $A_i=h(T_i \oplus { Pw}_i\oplus C_{k}^{\prime })$. However, ${ Ed}_i$ is not capable to compute $A_i$ since ${ Pw}_i$ is not known to ${ Ed}_i$. In fact, during the registration phase, ${ CS}$ generates ${ Pw}_i$ after receiving ${ Id}_i$ from ${ Ed}_i$. But the cloud server ${ CS}$ never provides the password ${ Pw}_i$ to ${ Ed}_i$, hence the device ${ Ed}_i$ cannot compute $A_i$. In addition, ${ Ed}_i$ cannot compute $P_4^{*}$ without the value of $A_i$ and then no verification ($P_{4}^{*}\overset{?}{=}P_{4}$) is possible to confirm the legitimacy of ${ CS}$. Thus, mutual authentication cannot be achieved properly in Kalra and Sood’s scheme.

5 The proposed scheme

In this section, we describe various phases related to our proposed scheme. As pointed out in [29, 30], we also assume that the tamper-resistant devices are available [31], where even the owner of the device cannot access the protected data stored in the device. This practical assumption is widely adopted in several applications, such as the Pay-TV systems [32, 33]. Furthermore, since attacks on tamper-resistant devices require special equipment, it would be much costly than buying an embedded device, and the attacker cannot have economic incentives in order to mount such an attack [29]. Thus, with the use of a tamper-resistant embedded device, the security of the proposed scheme will be strong enough.

5.1 Initialization

Initialization phase is similar to that in Kalra and Sood’s scheme.

5.2 Registration phase

This phase consists of the following steps:

Step R1.:

To register with ${ CS}$, the tamper proof-embedded device ${ Ed}_i$ computes $I_i=h({ Id}_i||{ Pw}_i)$ and sends $I_i$ to ${ CS}$ through a secure communication channel.

Step R2.:

When the registration request received, ${ CS}$ generates a random number $r_s$ and computes $P{ Id}_{i}=h(r_s||{ Id}_{\mathrm{cs}}||I_i) \oplus { Id}_{\mathrm{cs}}$ for ${ Ed}_i$ and stores $P{ Id}_{i}$. Then, ${ CS}$ computes the cookie $C_k$ and other security parameters as follows

$$\begin{aligned} C_k&=h(r_s|| X_{\mathrm{cs}}||E_t|| P{ Id}_i) \\ C_k^{\prime }&= C_{k}\cdot G \\ T_i&=r_s\oplus h(X_{\mathrm{cs}}||P{ Id}_i) \\ A_i&=h\left( r_s\oplus h(X_{\mathrm{cs}}||P{ Id}_i)\oplus I_i\oplus C_{k}^{\prime }\right) \\ A_{i}^{\prime }&=A_i\cdot G \end{aligned}$$

${ CS}$ stores $t_i=T_i\oplus X_{\mathrm{cs}}$, $a_i^{\prime }=A_i^{\prime }\oplus X_{\mathrm{cs}}$ and $e_t=E_t\oplus X_{\mathrm{cs}}$ corresponding to $P{ Id}_i$ of ${ Ed}_i$ in its database. The expiration time of the cookie $E_t$ that corresponds to $I_i$ of ${ Ed}_i$ is stored by ${ CS}$ itself. Subsequently, ${ CS}$ delivers {$P{ Id}_i, C_k^{\prime }$} to ${ Ed}_i$ through a secure communication channel. After receiving {$P{ Id}_i, C_k^{\prime }$}, the embedded device ${ Ed}_i$ stores $P{ Id}_i$ and $C_k^{\prime }$ in its memory. The expiration time is updated to $E_t^{\prime }$ and the cookie is restructured as $C_k=h\left( r_s|| X_{\mathrm{cs}}\left\| E_t^{\prime }\right\| P{ Id}_i\right)$ whenever the cookie expires.

5.3 Login and authentication phase

Step LA1.:

Before each login, the ${ Ed}_i$ selects a random nonce $r_1$, compute the ECC point $P_1=r_1\cdot G$ and $P_2=h(r_1\cdot C_{k}^{\prime })$. Then, it stores $P_1$ in its memory and sends the login request {$P_1$, $P_2$, $P{ Id}_i$} to ${ CS}$.

Step LA2.:

Upon receiving the login request, ${ CS}$ obtains data corresponding to the received $P{ Id}_i$ and computes $r_s=T_i\oplus h(X_{\mathrm{cs}}||PIdi)$. Next, ${ CS}$ compute the cookie information $C_k=h(r_s||X_{\mathrm{cs}}||E_t||P{ Id}_i)$ and $P_2^{*}=h(P_1\cdot C_{k})$. Then, it verifies $P_{2}^{*}\overset{?}{=}P_{2}$. If the verification holds, then ${ CS}$ continues to the next step; Otherwise, ${ CS}$ rejects the login request of ${ Ed}_i$.

Step LA3.:

${ CS}$ selects a random nonce $r_2$, computes the ECC point $P_3=r_2\cdot G$; $P_4=r_2\cdot A_i^{\prime }$ and sends {$P_3$, $P_4$, $T_i$} to ${ Ed}_i$.

Step LA4.:

Upon receiving {$P_3$, $P_4$, $T_i$}, ${ Ed}_i$ compute $A_i=h(T_i \oplus I_i\oplus C_{k}^{\prime })$ and the ECC point $P_4^{*}=P_3\cdot A_{i}$. Then, it verifies $P_{4}^{*}\overset{?}{=}P_{4}$ to authenticate ${ CS}$. If the verification holds, then ${ Ed}_i$ authenticates ${ CS}$ and continues the next step; Otherwise, ${ Ed}_i$ rejects the message {$P_3$, $P_4$, $T_i$} of ${ CS}$ and resume the login.

Step LA5.:

${ Ed}_i$ computes the session key ${ SK}=r_1\cdot P_3=r_1\cdot r_2\cdot G$ and sends $V_i=h((r_1\cdot C_{k}^{\prime })||{ SK})$ to ${ CS}$.

Step LA6.:

After receiving $V_i$, ${ CS}$ compute the session key ${ SK}^{*}=r_2\cdot P_1=r_2\cdot r_1\cdot G$ and $V_i^{*}=h((P_1\cdot C_{k})||{ SK}^{*})$. Then, ${ CS}$ verifies $V_{i}^{*}\overset{?}{=}V_{i}$ to authenticate ${ Ed}_i$. If the verification holds, ${ CS}$ authenticates ${ Ed}_i$; Otherwise, $V_i$ is rejected. From then on all the subsequent messages transmitted between ${ Ed}_i$ and ${ CS}$ are ${ XOR}$ed with the session key ${ SK}=r_1\cdot P_3=r_1\cdot r_2 \cdot G=r_2\cdot P_1={ SK}^{*}$.

The summary of the login and authentication phase is given in Fig. 4.

Fig. 4

Summary of the proposed scheme

6 Security analysis

6.1 Formal security verification using AVISPA tool

This section carries out the simulation of our proposed scheme using the most widely accepted and used Automated Validation of Internet Security Protocols and Applications (AVISPA) tool to show our scheme is secure against replay and man-in-the-middle attacks.

AVISPA is a modular and expressive formal language for specifying protocols and their security properties. It integrates different backends that implement a variety of state-of-the-art automatic analysis techniques [34]. It is a push-button tool for the automated validation of Internet security-sensitive protocols and applications, which becomes a widely accepted tool for our formal security verification in recent years [35,36,37,38,39,40,41]. AVISPA contains four backends: 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 descriptions of these backends are available in [34].

The security protocols need to be implemented in the HLPSL (High Level Protocols Specification Language), which is a role-oriented language [34], and contains the basic roles representing each participant role, and composition roles representing the scenarios of basic roles. An intruder is always represented by i and modeled using the Dolev–Yao model [42]. As a result, the intruder (i) is allowed to have a legitimate role in a protocol run. In HLPSL, a number of sessions, and a number of principals and some basic roles are defined. Using HLPSL2IF translator, HLPSL is converted to the intermediate format (IF), which then produces the output format (OF) with one of the four backends. OF has the following sections [43]:

• Summary indicates whether the tested protocol is safe, unsafe, or whether the analysis is inconclusive.

• Details either explains under what condition the tested protocol is declared safe, or what conditions have been used for finding an attack, or finally why the analysis was inconclusive.

• Protocol indicates the name of the protocol.

• Goal is the goal of the analysis.

• Backend tells the name of the backend used.

• Finally, after some comments and statistics, the trace of an attack (if any) is also printed in the standard Alice–Bob format.

Several basic types are supported in HLPSL and the details of these types are available in [34].

6.2 Specification of the protocol

We have implemented two basic roles for the embedded device ${ Ed}_i$ and the cloud server ${ CS}$ in HLPSL related to the registration phase and login and authentication phase of our scheme. Besides these two roles, the roles for the session, goal and environment in HLPSL must be specified for our scheme.

Fig. 5

Role specification in HLPSL for ${ Ed}_i$

Fig. 6

Role specification in HLPSL for ${ CS}$

The role of the initiator, ${ Ed}_i$ in HLPSL is given in Fig. 5. ${ Ed}_i$ first receives the start signal, updates its state from 0 to 1, which is maintained by the variable State, and then sends the registration request $\{I_i \}$ securely to the ${ CS}$ during the registration phase with the help of TX( ) channel. The type declaration $\hbox {channel}~(\hbox {d}y)$ declares that the channel is for the Dolev–Yao threat model [42], which indicates that the intruder (i) has the ability to intercept, analyze, and/or modify messages transmitted over a insecure public channel. After that ${ Ed}_i$ receives the message $\{P{ Id}_i, C_k'\}$ from ${ CS}$ securely by the help of ${ RX}(~)$ channel. In this role, the played_by A declaration indicates that the agent named in variable A plays in the role. By the declaration secret(Idi,Pwi, sec1, EDi), it indicates that the information ${ Id}_i$ and ${ Pw}_i$ are only known to ${ Ed}_i$. During the login and authentication phase, $ED_i$ sends the message $\{P_1,P_2,P{ Id}_i\}$ to ${ CS}$ through open channel. ${ Ed}_i$ then receives the message $\{P_3,P_4,T_i\}$ from ${ CS}$ via public channel. Finally, ${ Ed}_i$ replies with the message $\{ V_i \}$ to ${ CS}$ via open channel. A knowledge declaration (generally in the top-level Environment role) is used to specify the intruder’s initial knowledge. Immediate reaction transitions are of the form $X =|> Y$, which relate an event X and an action Y. By the declaration witness(EDi, CS, alice_bob_r1, R1’), we mean that ${ Ed}_i$ has generated the random nonce $r_1$ freshly for the ${ CS}$. On the other hand, by the declaration request(CS, EDi, bob_alice_r2, R2’), it indicates that ${ Ed}_i$’s acceptance of the random nonce $r_2$ generated for ${ Ed}_i$ by ${ CS}$. In a similar way, we have implemented the role for the ${ CS}$ during the registration as well as login and authentication phases in Fig. 6.

Fig. 7

Role specification in HLPSL for the session, goal and environment

Finally, the roles for the session, goal and environment of our proposed scheme are provided in Fig. 7. All the basic roles: embeddeddevice and cloudserver are the instances with concrete arguments in the role of the session. The top-level role (environment) is always defined in HLPSL specification. In HLPSL, the intruder (i) also participates in the execution of protocol as a concrete session as shown in Fig. 7. In our implementation, there are two secrecy goals and two authentication goals. For example, the secrecy goal: secrecy_of sec1 reveals that ${ Id}_i$ and ${ Pw}_i$ are kept secret to ${ Ed}_i$ only. The authentication goal: authentication_on alice_bob_r1 means that ${ Ed}_i$ generates a random nonce $r_1$, where $r_1$ is only known to ${ Ed}_i$. When ${ CS}$ receives $r_1$ from other messages from ${ Ed}_i$, ${ CS}$ performs a strong authentication for ${ Ed}_i$ based on $r_1$.

6.3 Simulation results

Our scheme is simulated under the widely used OFMC backend using the Security Protocol ANimator for AVISPA (SPAN) [34]. The following verifications are executed while simulating our scheme [35,36,37,38,39,40,41]:

• Executability check on non-trivial HLPSL specifications Due to some modeling mistakes, the protocol model can not sometimes execute to completion. It may happen that the AVISPA backends cannot find an attack, if the protocol model can not reach to a state where that attack can happen. An executability test is then very essential [43]. Our scheme shows that the protocol description is well matched with the designed goals as specified in Figs. 5, 6 and 7 for the executability test.

• Replay attack check For the replay attack check, the OFMC backend verifies whether the legitimate agents can execute the specified protocol by performing a search of a passive intruder. This backend provides the intruder the knowledge of some normal sessions between the legitimate agents. The test results shown in Fig. 8 indicate that our scheme is secure against the replay attack.

• Dolev–Yao model check For the Dolev–Yao model check, the OFMC backend also verifies whether there is any man-in-the-middle attack possible by an intruder. It is clear from the results reported in Fig. 8 that our scheme fulfills the design properties and is also secure under this backend.

Fig. 8

Result of the analysis using OFMC backend

6.4 Informal security analysis

The security of the proposed scheme is based on the difficulty of the high entropy ECC and the secure cryptographic hash function. This section analyzes the security features of the proposed scheme under the thought of tamper proof-embedded device and shows that all security requirements stated in Table 4 are achieved in the proposed scheme.

6.4.1 Replay attack

A replay attack involves retransmitting previously intercepted messages. In the proposed scheme, an attacker may intercept the message {$P_1, P_2, P{ Id}_i$} which is transmitted from ${ Ed}_i$ to ${ CS}$. Using this intercepted message the attacker may try to launch the replay attack. To login as a legal device, an attacker may retransmit the intercepted message {$P_1, P_2, P{ Id}_i$} to ${ CS}$. Upon receiving the login request, ${ CS}$ obtains data corresponding to $P{ Id}_i$ and derives $r_s$ as $r_s=T_i\oplus h(X_{\mathrm{cs}}||P{ Id}_i)$. Then, it compute the parameters $C_k$ and $P_2^{*}$ and verifies $P_{2}^{*}\overset{?}{=}P_{2}$. The verification holds as $P_2^{*}=h(P_1\cdot C_{k})= P_2$. Next, it sends {$P_3$, $P_4$, $T_i$} to ${ Ed}_i$. However, after receiving the message {$P_3$, $P_4$, $T_i$}, the attacker cannot compute $A_i=h(T_i \oplus I_i\oplus C_{k}^{\prime })$ without knowing $I_i$ of ${ Ed}_i$ since $I_i$ of ${ Ed}_i$ is neither sent through any messages over public channel nor can be obtained from the embedded device ${ Ed}_i$ due to its tamper proof design. Thus, an attacker cannot compute valid session key ${ SK}=r_1\cdot P_3=r_1\cdot r_2\cdot G$ and the security parameter $V_i=h((r_1\cdot C_{k}^{\prime })||{ SK})$. Hence, an attacker cannot launch the replay attack using the intercepted message {$P_1, P_2, P{ Id}_i$}.

6.4.2 Man-in-the-middle attack

In the proposed scheme, the man-in-the-middle attack is disallowed by mutual authentication between ${ Ed}_i$ and ${ CS}$. As a result, man-in-the-middle attacks are thwarted since we show that the proposed scheme achieves mutual authentication in Sect. 6.4.10.

6.4.3 Insider attack

In the proposed scheme, ${ Ed}_i$ sends $\{I_i=h({ Id}_i||{ Pw}_i)\}$ instead of ${ Pw}_i$ to ${ CS}$ securely during registration phase. The privileged insider of ${ CS}$ cannot obtain the password ${ Pw}_i$ since it is protected by ${ Ed}_i$’s identity ${ Id}_i$ and collision-resistant one-way hash function $h(\cdot )$. Therefore, the proposed scheme can resist the insider attack.

6.4.4 Stolen-verifier attack

In the proposed scheme, during the registration phase of the ${ Ed}_i$, cloud server ${ CS}$ stores $t_i=T_i\oplus X_{\mathrm{cs}}$, $a_i^{\prime }=A_i^{\prime }\oplus X_{\mathrm{cs}}$ and $e_t=E_t\oplus X_{\mathrm{cs}}$ against $P{ Id}_i$ in its database. Even if an attacker steals this record from the database of ${ CS}$, he cannot use it to apply any malicious activity such as server impersonation attack. The reason is that the values {$T_i$, $A_i^{\prime }$, $E_t$} are not accessible to the attacker in plaintext from the stolen record because these values are protected with the secret key $X_{\mathrm{cs}}$ of ${ CS}$. Moreover, an attacker cannot create a valid login request to pass the authentication steps without the knowledge of $C_k^{\prime }$ since it is not stored in ${ CS}$’s database. In addition, the computation of cookie $C_k^{\prime }= C_{k}\cdot G$ relies on the correct computation of $C_k=h(r_s|| X_{\mathrm{cs}}||E_t|| P{ Id}_i)$. Without the knowledge of ${ CS}$’s secret key $X_{\mathrm{cs}}$ the attacker cannot compute a valid cookie $C_k$. Thus, the attacker cannot create a valid login request. Therefore, the proposed scheme can withstand the stolen-verifier attack.

6.4.5 Impersonation attack

As discussed in Sect. 6.4.1, we can see that the attacker cannot impersonate the embedded device ${ Ed}_i$ and the cloud server ${ CS}$ through replaying the previously intercepted messages. Therefore, the attacker has to create a fresh login request or a response message if he/she wishes to impersonate ${ Ed}_i$ or ${ CS}$, respectively. Since the embedded device ${ Ed}_i$ is tamper proof, it is not possible to extract values stored in it. Without knowing the cookie $C_k^{\prime }$ and $P{ Id}_i$, the attacker cannot build a valid login request message {$P_1, P_2, P{ Id}_i$}, where $P_1=r_1\cdot G$ and $P_2=h(r_1\cdot C_{k}^{\prime })$. Further, without knowing ${ CS}$’s secret key $X_{\mathrm{cs}}$ and $A_i=h(r_s\oplus h(X_{\mathrm{cs}}||P{ Id}_i)\oplus I_i\oplus C_{k}^{\prime })$, the attacker cannot create the message {$P_3$, $P_4$, $T_i$}, where $P_3=r_2\cdot G$ and $P_4=r_2\cdot A_i^{\prime }$. Therefore, the proposed scheme can resist the impersonation attack.

6.4.6 Brute force attack

For deploying a brute force attack, the attacker needs to extract the security parameters {$P_1$, $P_2$, $P_3$, $P_4$ and $T_i$} from the transmitted messages between ${ Ed}_i$ and ${ CS}$. Even he obtains these security parameters, he still cannot find the password ${ Pw}_i$ as the ${ CS}$’s secret key $X_{\mathrm{cs}}$ is unknown to him and there is no way of guessing random numbers $r_1$ and $r_2$. Therefore, the proposed scheme can resist the brute force attack.

6.4.7 Cookie theft attack

In the proposed scheme, the cookie $C_k^{\prime }=h(r_s|| X_{\mathrm{cs}}||E_t|| P{ Id}_i)\cdot G$ is stored as an ECC point in the embedded device ${ Ed}_i$. But, it is not possible to extract the cookie from ${ Ed}_i$ due to its tamper proof property. Moreover, the cookie $C_k^{\prime }$ is not sent through any of the communication messages over public channel. As a result, under any situation, the attacker cannot obtain the cookie $C_k^{\prime }$. Therefore, the proposed scheme can resist the cookie theft attack.

6.4.8 Offline password guessing attack

As we illustrated above, throughout the proposed scheme, ${ Ed}_i$’s password ${ Pw}_i$ only makes one presences as $I_i=h(ID_i||{ Pw}_i)$. Manifestly, the attacker cannot toss an offline password guessing attack without knowing ${ Ed}_i$’s identity ${ Id}_i$ since ${ Id}_i$ is neither sent through any message nor stored in the ${ Ed}_i$ and ${ CS}$. In addition, we have proved that the improved scheme achieves user anonymity in Sect. 6.4.9. Therefore, the proposed scheme can resist the offline password guessing attack.

6.4.9 Device anonymity

Device anonymity means that an attacker cannot dig up the device’s masked identity $I_i$ from the transmitted messages during login and authentication phase. In the proposed scheme, ${ Ed}_i$ sends {$P_1, P_2, P{ Id}_i$} to ${ CS}$, where $P_1=r_1\cdot G$, $P_2=h(r_1\cdot C_{k}^{\prime })$ and $P{ Id}_{i}=h(r_s||{ Id}_{\mathrm{cs}}||I_i) \oplus { Id}_{\mathrm{cs}}$. Here, $P{ Id}_{i}$ is related with the ${ Ed}_i$’s masked identity $I_i$. However, $I_i$ is well protected by ${ Id}_{\mathrm{cs}}$ and the random number $r_s$ with help of hash function. $I_i$, ${ Id}_{\mathrm{cs}}$ and $r_s$ are neither sent through any message nor stored in the ${ Ed}_i$ and ${ CS}$ in plaintext. This shows that the attacker cannot obtain the masked identity $I_i$ of ${ Ed}_i$. Therefore, the proposed scheme preserves device anonymity.

6.4.10 Mutual authentication

The proposed scheme ensures the unbeaten mutual authentication between ${ Ed}_i$ and ${ CS}$. ${ CS}$ authenticates ${ Ed}_i$ by verifying $P_{2}^{*}\overset{?}{=}P_{2}$ and $V_{i}^{*}\overset{?}{=}V_{i}$. A valid $P_2$ can be computed by only a valid ${ Ed}_i$ because $P_2=h(r_1\cdot C_{k}^{\prime })$ where $C_k^{\prime }= C_{k}\cdot G$. In the proposed scheme, the attacker cannot compute valid $P_2$ without knowing the cookie $C_k^{\prime }$ and he has no way to access the cookie $C_k^{\prime }$. The reason is that $C_k^{\prime }$ is neither sent in messages transmitted over public nor can be extracted from the tamper proof device ${ Ed}_i$. For similar reasons, the attacker cannot compute $V_i=h((r_1\cdot C_k^{\prime })||{ SK})$. Thus, ${ CS}$ authenticates ${ Ed}_i$. Also, ${ CS}$ can be authenticated by ${ Ed}_i$ by verifying $P_{4}^{*}\overset{?}{=}P_{4}$ where $P_4^{*}=P_3\cdot A_{i}$. Therefore, the proposed scheme achieves proper mutual authentication.

6.5 Session key agreement

Subsequent to the authentication process, the ${ Ed}_i$ and ${ CS}$ share a session key ${ SK}=r_1\cdot P_3=r_1\cdot r_2\cdot G=r_2\cdot P_1={ SK}^{*}$. Since the attacker has no knowledge of the random number $r_1$ and $r_2$, the session key cannot be directly computed, as it is protected by a high entropy ECC point. Hence, the proposed scheme guarantees the secrecy of future session keys.

6.5.1 Forward secrecy

Forward secrecy means that the attacker cannot find session keys created in past sessions even if he/she discovers the ${ Ed}_i$’s password ${ Pw}_i$ and the ${ CS}$’s secret key $X_{\mathrm{cs}}$. In the proposed scheme, ${ Ed}_i$ and ${ CS}$ compute an incomparable session key ${ SK}=r_1\cdot P_3=r_1\cdot r_2\cdot G=r_2\cdot P_1={ SK}^{*}$ in every run of the proposed scheme. The attacker cannot compute ${ SK}$ (or ${ SK}^{*}$) from $P_1=r_1\cdot G$ and $P_3=r_2\cdot G$ even if he/she find out ${ Ed}_i$’s password ${ Pw}_i$ and ${ CS}$’s secret key $X_{\mathrm{cs}}$ due to the hardness of high entropy ECC points. Therefore, the proposed scheme can provide the forward secrecy.

6.5.2 Provides confidentiality

In the proposed scheme, the required device authentication parameter is secured by using hash function and ECC points. It allows only authenticated devices to gain access to the legitimate cloud server. The proposed scheme is also resilient to eavesdropping and traffic analysis and assures confidentiality by making sure that the difficulty of brute force attack is high.

7 Performance analysis

In this section, we compare the security requirements and performance of the proposed scheme with the Kalra and Sood’s scheme [23] to manifest the merits of the proposed scheme. In order to carry out the performance analysis, the following notations have been defined:

• $T_h$ is the execution time of a hash operation.

• $T_{\mathrm{ecm}}$ is the execution time of an ECC point multiplication operation.

7.1 Computation cost

The computational costs of the login and authentication phases have been considered since these two phases are executed more often as compared to the other phases in an authentication scheme. An experiment results of [44] demonstrate that an execution time (computation costs) of $T_{h}$ and $T_{\mathrm{ecm}}$ are $2.3\,\upmu \hbox {s}$ and $22.26\times 10^2\,\upmu \hbox {s}$. Note that since very inexpensive computation is associated with lightweight operations (i.e., concatenation, comparison and ${ XOR}$), their computational costs have been ignored.

In Table 2, we compare the computational cost of the proposed scheme with the Kalra and Sood’s scheme [23] in the login and authentication phase. Based on Table 2, the computational cost of Kalra and Sood’s scheme and the proposed scheme are $9T_h+7T_{\mathrm{ecm}}\approx 15.603\times 10^3\,\upmu \hbox {s}$ and $7T_h+8T_{\mathrm{ecm}}\approx 17.824\times 10^3\,\upmu \hbox {s}$. Here, we see that the proposed scheme has little increased computation cost as compared to Kalra and Sood’s scheme. For the reason that, in the proposed scheme, the forward secrecy and backward secrecy is achieved through the session key agreement between ${ Ed}_i$ and ${ CS}$ while Kalra and Sood’s scheme does not.

Table 2 Computational cost comparison

Table 3 Communication and storage cost comparison

7.2 Communication cost

Table 3 compares the communication cost of the proposed scheme with the Kalra and Sood’s scheme [23]. Though calculating the communication cost of the schemes, we assumed that the length of the random number($r_1$, $r_2$, $r_s$) is 160 bits, device identity (${ Id}_i$) is 160 bits, pseudo-identity ($P{ Id}_i$) is 160 bits and the security parameter($C_k^{\prime }$, $T_i$, $V_i$) is 160 bits. Also, we assumed that the output (digest) of hash function(for SHA-1 [45]) is 160 bits. In proposed scheme, we consider the elliptic curve cryptosystem (ECC) with 160-bit as its security strength is equivalent as RSA cryptosystem of 1024-bit. Hence, for an elliptic curve $E_p(a, b)$, all parameters (p, a and b) are 160-bits each. Next, an ECC point $P = (x_P, y_P) \in E_p(a, b)$ needs $(160 + 160) = 320$ bits. In proposed scheme, the login request message {$P_1$, $P_2$, $P{ Id}_i$} requires $(320 + 320 + 160) = 800$ bits, the message {$P_3$, $P_4$, $T_i$} requires $(320 + 320 + 160)= 800$ bits and the message {$V_i$} requires 160 bits. Therefore, the proposed scheme requires $(800+800+160)=1760$ bits for the communication cost of three messages transmitted between ${ Ed}_i$ and ${ CS}$. However, the communication cost of the Kalra and Sood’s scheme also 1760 bits. Here, we see that the proposed scheme has same communication cost as compared to Kalra and Sood’s scheme.

Table 4 Security requirements comparison

7.3 Storage cost

We scale the storage cost of the proposed scheme with respect to Kalra and Sood’s scheme. Here, we consider the storage cost of the embedded device since it has tiny memory. Toward the end of the registration phase in Kalra and Sood’s scheme, the embedded device (${ Ed}_i$) needs to store $\{C_k^{\prime }\}=320$ bits of data in its memory. However, in the proposed scheme, embedded device contains $\{C_k^{\prime },P{ Id}_i\}=320+160=480$ bits of data in its memory, which is little greater than the Kalra and Sood’s scheme. In the proposed scheme, the additional occupied memory space for $P{ Id}_i$ provides device anonymity while Kalra and Sood’s scheme does not. Table 3 shows that the storage cost required by the embedded device ${ Ed}_i$ in Kalra and Sood’s scheme and the proposed scheme.

7.4 Security requirements comparison

Table 4 lists the security requirements comparison between the proposed scheme and the Kalra and Sood’s. From Table 4, it is manifest that the proposed scheme can resist various attacks. In contrast, the scheme of Kalra and Sood is vulnerable to offline password guessing and insider attacks. Additionally, the scheme of Kalra and Sood does not achieve device anonymity, mutual authentication and session key agreement. Thus, the proposed scheme provides a greater result over the scheme of Kalra and Sood with respect to security strength.

Fig. 9

Performance comparison

In Fig. 9, we summarize the performance of the proposed scheme and Kalra and Sood’s scheme. In Fig. 9, let $C_1$ be the communication cost(in bits), $C_2$ be the computation cost(in $\upmu \hbox {s}$) and $C_3$ be the storage cost(in bits). Compared to the Kalra and Sood’s scheme, computation cost and storage cost in the proposed scheme are slightly increased. This is justified, because the proposed scheme achieves all the security requirements while Kalra and Sood’s scheme does not. Conclusively, the proposed scheme sustain reasonable efficiency and is well suited to authenticate the embedded device in cloud and IoT environment.

8 Conclusion

Kalra and Sood proposed an authentication scheme based on ECC for IoT and cloud servers and proved its immunity against various attacks. However, after reviewing their scheme and carrying out security analysis, two attacks, i.e., offline password guessing and insider attacks have been presented in different circumstances. Moreover, it has been shown that their scheme fails to achieve device anonymity, session key agreement and mutual authentication. The analyses show that their scheme is not suitable for practical applications. In order to fix the shortcomings of Kalra and Sood’s scheme, we have proposed an enhanced authentication scheme based on ECC. Performance and security analyses show that the proposed scheme is invincible to various attacks and is well crafted for IoT and cloud server environment.

In future, we would like to extend our scheme for non-tamper-resistant embedded devices.