Next Article in Journal
3D Printed Personalized Corneal Models as a Tool for Improving Patient’s Knowledge of an Asymmetric Disease
Previous Article in Journal
Multidimensional Interpolation Decoupling Strategy for CD Basis Weight of Papermaking Process
Previous Article in Special Issue
Towards an Efficient Privacy-Preserving Decision Tree Evaluation Service in the Internet of Things

Symmetry 2020, 12(1), 150; https://doi.org/10.3390/sym12010150

Article
A Secure Authentication and Key Agreement Scheme for IoT-Based Cloud Computing Environment
College of Computer Science and Technology, Jilin University, Chaoyang District, Changchun 130012, Jilin, China
*
Author to whom correspondence should be addressed.
Received: 25 December 2019 / Accepted: 8 January 2020 / Published: 10 January 2020

Abstract

:
The integration of Internet of things (IoT) and cloud computing technology has made our life more convenient in recent years. Cooperating with cloud computing, Internet of things can provide more efficient and practical services. People can accept IoT services via cloud servers anytime and anywhere in the IoT-based cloud computing environment. However, plenty of possible network attacks threaten the security of users and cloud servers. To implement effective access control and secure communication in the IoT-based cloud computing environment, identity authentication is essential. In 2016, He et al. put forward an anonymous authentication scheme, which is based on asymmetric cryptography. It is claimed that their scheme is capable of withstanding all kinds of known attacks and has good performance. However, their scheme has serious security weaknesses according to our cryptanalysis. The scheme is vulnerable to insider attack and DoS attack. For overcoming these weaknesses, we present an improved authentication and key agreement scheme for IoT-based cloud computing environment. The automated security verification (ProVerif), BAN-logic verification, and informal security analysis were performed. The results show that our proposed scheme is secure and can effectively resist all kinds of known attacks. Furthermore, compared with the original scheme in terms of security features and performance, our proposed scheme is feasible.
Keywords:
authentication; internet of things; cloud computing; adversary model; security analysis

1. Introduction

Internet of things (IoT) takes advantage of massive sensors, intelligent terminals, global positioning system, and other technologies to establish connections between people and things whenever and wherever, and realize intelligent control and management [1]. For example, users can use smartphones to remotely control lamps, TVs, and refrigerators at home through the Internet of things. Internet of things makes people’s lives more convenient, and also makes the social economy develop faster. However, limited by the low power and computation ability of embedded devices, applying the IoT in the real applications is still a critical issue. To settle the matter, researchers apply cloud computing to the Internet of things.
Cloud computing makes plentiful computing and storage resources accessible to all of the servers and users through the Internet. A cloud server has more resources and more powerful computation ability. Cooperating with the cloud server, IoT devices can provide a better quality of services for users [2]. In a typical scenario of the IoT-based cloud computing environment as shown in Figure 1, IoT devices and sensors submit the IoT-releated data they collected to a cloud server via a wired/wireless network. Users can access the cloud servers to get the IoT-releated data from anywhere at any time. Furthermore, Users can send commands to the IoT devices through the cloud server for productive remote control. The IoT-based cloud computing environment combines the advantages of IoT and cloud computing, making the Internet of things more efficient and practical.
As the cloud servers provide IoT services for users over an insecure public channel, the communications between users and cloud servers must be confidential [3]. It is essential to authenticate each other in an IoT-based cloud computing environment. Only authorized users can access the cloud server to obtain the services of IoT devices. Figure 1 shows the assumed architecture for an IoT-based cloud computing environment. As a trusted third party, the registration center (RC) provides registration services for users and cloud servers. After that, users and cloud servers establish secure communication through mutual authentication.
Authentication and key agreement protocols are playing a crucial part in the security of an IoT-based cloud computing environment. Since the first authentication scheme was put forward by Lamport in 1980 [4], the research on the authentication protocol has not stopped. Numerous schemes were proposed based on different cryptography technologies. Generally, the scheme using symmetric key cryptography [5,6,7,8,9,10,11,12,13,14] has better performance while it cannot achieve forward security. For the scheme using asymmetric cryptography [15,16,17,18,19,20,21,22,23], the balance between security and performance is a crucial problem.
In 2016, He et al. presented an anonymous authentication protocol [24], which is based on asymmetric cryptography. They declared that their scheme is capable of withstanding various known attacks and has good performance. However, we found that their scheme is vulnerable to DoS attack and insider attack under our proposed adversary model.

Contributions

The main contributions of this article include: (1) we propose a new adversary model in Section 2.3. (2) In Section 4, we show that He et al.’s scheme is unable to defend against insider attack and DoS attack under our proposed adversary model. (3) In Section 5, we present an improved authentication and key agreement scheme for the IoT-based cloud computing environment. The proposed scheme modifies the registration and authentication phases, uses ‘fuzzy verifier’, and adds the validation in the side of cloud servers, so as to effectively resist insider attack and DoS attack. (4) It is proven that our proposed scheme is secure via an automated security verification tool ProVerif [25] in Section 6.1. Meanwhile, we present the proofs of BAN logic [26] verification in Section 6.2. Furthermore, informal security analysis is put forward in Section 6.3. (5) In Section 7, we compare the proposed scheme with He et al.’s scheme in terms of security features and performance.

2. Preliminaries

2.1. Bilinear Pairing

Let G 1 be a cyclic additive group with a large prime order q and G 2 a cyclic multiplicative group of the same order q . Let P and g be generators of G 1 and G 2 separately. A bilinear pairing is a map e :   G 1 × G 1     G 2 and satisfies the following properties:
(1) Bilinear: Give e   ( a · P , b · Q )   =   e ( P ,   Q ) a b for all P ,   Q     G 1 ,   a ,   b     Z q * .
(2) Non-degenerate: There exists P ,   Q     G 1 such that e   ( P ,   Q )     1 .
(3) Computable: There exists an efficient algorithm to calculate e   ( P ,   Q ) for all P ,   Q     G 1 in polynomial time.

2.2. Related Mathematical Problems

The mathematical problems for designing authentication protocols are as follows.

2.2.1. Discrete Logarithm Problem

Given X   =   τ · P   ( x   =   g τ ) , where X     G 1 ( x     G 2 ) , it is relatively easy to calculate X ( x ) given τ and P ( τ and g), while it is relatively hard to determine τ given X and P (x and g).

2.2.2. Computational Diffie–Hellman Problem

For a , b     Z q * , given a · P , b · P G 1 ( g a , g b G 2 ) , it is hard to find ( a · b ) · P     G 1 ( g a b     G 2 ) .

2.3. Adversary Model

The adversary model makes clear assumptions about the adversary’s ability in advance. The adversary model of remote authentication protocol always follows the classic Dolev–Yao model [27]. Recently, Side-channel technology [28] enables attackers to extract information from smart cards, and the ability of the adversary is enhanced. In this paper, we improve the adversary models in literature [29] and literature [30], and propose a more rigorous (but practical) multi-factor authentication protocol adversary model (see Table 1).
In real life, when someone finds the lost smart card and the owner cannot be found, usually, the person who finds the smart card will give it to the insider to find the owner. Therefore, it is possible for insiders to obtain users’ smart cards. Meanwhile, the insiders have the opportunity to obtain the user’s registration information. Thus,   Capability   7 is realistic.

3. Review of He et al.’s Scheme

This section briefly reviews the authentication scheme proposed by He et al. There are the following phases in their scheme. Table 2 shows the notations used herein.

3.1. Setup Phase

RC selects G 1 , G 2 ,   e ( * , * ) and chooses his private keys τ , τ ^   Z q * . Then, it calculates g   =   e ( P , P ) , g p u b   =   g τ , P p u b = τ ^ · P as public keys. Furthermore, RC selects seven secure hash functions { h i } ,   i   =   0 6 and publishes all public parameters.

3.2. User Registration Phase

1.
U i chooses I D U i , P W U i , and a random number b U i freely. Then, U i computers h 0   ( ID U i ,   P W U i ,   b U i ) . Finally, U i sends the registration message { I D U i ,   h 0   ( I D U i ,   P W U i ,   b U i ) } towards RC.
2.
RC selects ω U i     Z q * freely and computes g U i   =   g ω U i , ξ U i   =   h 1 ( I D U i ,   g U i ) , τ U i   =   ω U i   +   τ · ξ U i , φ U i   =   τ U i h 0   ( I D U i ,   P W U i ,   b U i ) , ϑ U i   =   h 0 ( h 0 ( I D U i ,   P W U i ,   b U i ) ,   φ U i ) . Then, RC transmits { g U i ,   φ U i ,   ϑ U i } towards U i .
3.
U i writes { g U i , φ U i , ϑ U i , b U i } into S C U i .

3.3. Cloud Server Registration Phase

1.
S j transmits I D S j to RC.
2.
RC calculates D S j = 1 τ ^ + h 2 ( I D S j ) and responses { D S j } to S j via a private channel.
3.
S j receives and stores D S j safely.

3.4. Login and Authentication Phase

1.
U i inserts S C U i to a reader, and inputs I D U i and P W U i . S C U i verifies the equality check for ϑ U i ?   =   h 0   ( h 0   ( I D U i ,   P W U i ,   b U i ) ,   φ U i ) . If it holds true, S C U i ensures that I D U i and P W U i are correct. Then, S C U i randomly generates a number r U i     Z q * and calculates R U i   =   r U i · ( P p u b   +   h 2   ( I D S j ) · P ) , x   =   g r U i . Finally, U i transmits a login request { R U i } towards S j .
2.
S j receives R U i and calculates x   =   e   ( R U i ,   D S j ) . Then, S j randomly chooses a number r S j     Z q * and calculates y   =   g r S j , α S j   =   h 3 ( R U i , x , y ) . Finally, S j responds { y ,   α S j } towards U i .
3.
U i receives { y ,   α S j } and checks the equality for α S j ?   =   h 3   ( R U i ,   x ,   y ) . If α S j h 3   ( R U i ,   x ,   y ) , U i terminates the session. Otherwise, U i calculates θ U i   =   h 4   ( I D U i ,   R U i ,   x ,   y ) , τ U i   =   φ U i h 0 ( I D U i , P W U i , b U i ) , α U i   =   τ U i + θ U i · r U i , the session key s k U i   =   h 5   ( I D U i ,   I D S j ,   x ,   y ,   y r U i ) , and C U i   =   h 6 ( x ) ( I D U i ,   g U i ,   α U i ) . Finally, U i transmits C U i towards cloud server S j .
4.
S j receives C U i and recovers I D U i , g U i , α U i via computing ( I D U i ,   g U i ,   α U i )   =   h 6 ( x ) C U i . Furthermore, S j calculates ξ U i   =   h 1 ( I D U i ,   g U i ) , θ U i   =   h 4 ( I D U i ,   R U i ,   x ,   y ) and checks the equality for g α U i ?   =   g U i · g p u b ξ U i · x θ U i . If it holds true, S j gets the session key s k S j   =   h 5   ( I D U i ,   I D S j ,   x ,   y ,   x r S j ) .

3.5. Password Modification Phase

1.
U i inputs I D U i , P W U i . S C U i checks the equality ϑ U i ?   =   h 0 ( h 0   ( I D U i ,   P W U i ,   b U i ) ,   φ U i ) .
2.
If ϑ U i h 0 ( h 0   ( I D U i ,   P W U i ,   b U i ) ,   φ U i ) , S C U i rejects the modification request. Otherwise, U i inputs P W U i * . S C U i chooses a new random number b U i * , calculates φ U i *   =   φ U i h 0   ( I D U i ,   P W U i ,   b U i ) h 0 ( I D U i ,   P W U i * ,   b U i * ) , ϑ U i *   =   h 0   ( h 0   ( I D U i ,   P W U i * ,   b U i * ) ,   φ U i * ) . Finally, SC replaces { g U i ,   φ U i ,   ϑ U i ,   b U i } with { g U i ,   φ U i * ,   ϑ U i * ,   b U i * } and the new password is P W U i * .

4. Cryptanalysis of He et al.’s Scheme

4.1. Insider Attack

In our proposed adversary model, an insider adversary is able to acquire the user’s registration information and smart card. Suppose an insider adversary A acquires the registration information { I D U i , h 0 ( I D U i , P W U i , b U i ) } of U i . Furthermore, A gets U i ’s smart card and extracts the values g U i , φ U i , ϑ U i and b U i . Using this information, A can launch the following attacks through the following procedure.

4.1.1. Offline Password Guessing

Suppose an insider being an adversary A knows the registration information { I D U i , h 0 ( I D U i , P W U i , b U i ) } of U i . Furthermore, A gets U i ’s smart card and extracts the values g U i , φ U i , ϑ U i and b U i . Using this information, A is able to launch an offline password guessing attack through following these steps:
1.
A guesses a candidate password P W i * .
2.
A calculates x   =   h 0 ( I D U i , P W i * , b U i ) .
3.
A checks whether x ?   =   h 0 ( I D U i , P W U i , b U i ) holds. If not, A repeats Steps 1–3 until he acquires a true password. Otherwise, A has already succeeded in getting the true password. The attack is finished.
The computational overhead of this offline password attack is T h * | D i d | * | D p w | , where T h is the running time of one-way hash function, and D i D and D p w are the spaces of user identity and password, respectively. According to [31,32], we have | D i D | | D p w | 10 6 . According to experiment data in [33], we have T h 0.591 μ s . The adversary can obtain the true password in seven days. If using a high-performance cloud computing platform, the attack can be completed in a few hours.

4.1.2. User Impersonation

1.
A randomly generates a number r U i     Z q * and calculates R U i   =   r U i · ( P p u b + h 2 ( I D S j ) · P ) , x   =   g r U i . Afterwards, A transmits the request R U i to server S j .
2.
Upon receiving { y , α S j } from S j , A computes θ U i   =   h 4 ( I D U i , R U i , x , y ) , τ U i   =   φ U i h 0 ( I D U i , P W U i , b U i ) , where φ U i and h 0 ( I D U i , P W U i , b U i ) were obtained before. Subsequently, A calculates α U i   =   τ U i + θ U i · r U i , and gets the session key s k U i   =   h 5 ( I D U i , I D S j , x , y , y r U i ) . Finally, A sends C U i   =   h 6 ( x ) ( I D U i , g U i , α U i ) to S j .
The information generated by A is legal. The cloud server S j considers A as the user U i .

4.2. Possible DoS Attack

In the authentication phase, S j doesn’t validate the login request information until formula g α U i ?   =   g U i · g p u b ξ U i · x θ U i is validated. Even if the adversary sends illegal information, the cloud server still responds and completes the relevant calculations. This results in unnecessary communication costs and time costs and leads a possible DoS attack.

5. Our Improved Scheme

For overcoming the weaknesses above, we put forward an enhanced authentication and key agreement protocol. Figure 2 depicts our proposed scheme.

5.1. Setup Phase

RC selects G 1 , G 2 ,   e ( * , * ) and chooses his private keys   t 1 , t 2 , t 3     Z q * . Then, RC calculates g   =   e ( P , P ) , g p u b   =   g t 1 , P p u b   =   t 2 · P as public keys. Furthermore, RC selects seven secure hash functions { h i } , i   =   0 6 . Finally, RC publishes all public parameters { ( h i ) ,   i   =   0 6 , G 1 ,   G 2 ,   e ,   q ,   P ,   g ,   P p u b } .

5.2. User Registration Phase

1.
U i chooses I D U i , P W U i and a number b U i freely. Then, U i computers P W B   =   h 0 ( I D U i | | P W U i | | b U i ) m o d   n ,   2 4   n   2 6 . Note that n is an integer that determines the capacity of ( I D ,   P W ) . Then, it transmits the registration message { I D U i , P W B } towards RC.
2.
RC selects w U i     Z q * freely and computes g U i   =   g w U i , f U i   =   h 1 ( I D U i , g U i ) , t U i   =   w U i + t 1 · f U i , d U i   =   t U i P W B , v U i   =   h 0 ( P W B | | d U i ) m o d   n , m U i   =   h 0 ( h 0 ( I D U i ) | | h 0 ( t 3 ) ) . Then, RC responses { g U i , d U i , v U i , m U i } to U i via a private secure channel.
3.
U i receives { g U i , d U i , v U i } and computes k U i   =   d U i h 0 ( I D U i , P W U i ) , M U i   =   m U i P W B . Finally, U i   writes { g U i , k U i , v U i , M U i , b U i } into S C U i .

5.3. Cloud Server Registration Phase

1.
S j sends I D S j to RC.
2.
Upon reception of I D S j , RC calculates D S j   =   1 t 2 + h 2 ( I D S j ) · P and sends { D S j ,   h 0   ( t 3 ) } to S j via a private channel.
3.
S j stores { D S j ,   h 0   ( t 3 ) } in secret.

5.4. Login and Authentication Phase

1.
U i inserts S C U i to the reader and inputs I D U i and P W U i . S C U i calculates d U i   =   k U i h 0 ( I D U i | | P W U i ) , P W B   =   h 0 ( I D U i | | P W U i | | b U i ) m o d   n and verifies the equality check for v U i ?   =   h 0 ( P W B | | d U i ) m o d   n . If v U i     h 0 ( P W B | | d U i ) m o d   n , S C U i rejects the login request. Otherwise, it randomly chooses r U i     Z q * and calculates R U i   =   r U i · ( P p u b + h 2 ( I D S j ) · P ) , x   =   g r U i , m U i   =   M U i P W B , X U i   =   x m U i , n U i   =   x · h 0 ( I D U i ) . Finally, U i transmits login request { R U i , X U i , n U i } towards S j .
2.
S j receives { R U i , X U i , n U i } and calculates x   =   e ( R U i , D S j ) , m U i   =   h 0 ( ( n U i x ) | | h 0 ( t 3 ) ) . Then, S j verifies the equality check X U i ?   =   x m U i . If X U i x m U i , S j terminates the session. Otherwise, S j randomly selects r S j     Z q * and calculates y   =   g r S j , a S j   =   h 3   ( R U i ,   x ,   y ,   n U i ) . Finally, S j transmits { y ,   a S j } towards U i .
3.
Upon reception of { y , a S j } from S j , U i verifies the equality check a S j ?   =   h 3 ( R U i ,   x ,   y ,   n U i ) . If a S j     h 3 ( R U i ,   x ,   y ,   n U i ) , U i terminates the session. Otherwise, U i calculates O U i   =   h 4   ( I D U i ,   R U i ,   x ,   y ) , t U i   =   d U i P W B , a U i   =   t U i + O U i · r U i , the session key s k U i   =   h 5   ( I D U i , I D S j ,   x ,   y ,   y r U i ) and C U i   =   h 6   ( x ) ( I D U i | | g U i | | a U i | | y ) . Finally, U i transmits C U i towards S j .
4.
S j receives C U i and recovers I D U i , g U i and a U i via computing ( I D U i | | g U i | | a U i | | y )   =   h 6   ( x ) C U i . Furthermore, S j calculates f U i   =   h 1   ( I D U i ,   g U i ) , O U i   =   h 4   ( I D U i ,   R U i ,   x ,   y ) and checks the equality for g a U i ?   =   g U i · g p u b f U i · x O U i . If it holds true, S j gets the session key s k S j   =   h 5   ( I D U i ,   I D S j ,   x ,   y ,   x r S j ) .

5.5. Password Modification Phase

1.
U i inputs I D U i , P W U i . S C U i computes d U i   =   k U i h 0 ( I D U i | | P W U i ) , P W B   =   h 0 ( I D U i | | P W U i | | b U i ) m o d   n and checks the equality v U i ?   =   h 0 ( P W B | | d U i ) m o d   n .
2.
If v U i h 0 ( P W B | | d U i ) m o d   n , S C U i rejects the request. Otherwise, U i inputs P W U i n e w . S C U i randomly generates b U i * and calculates k U i n e w   =   k U i h 0 ( I D U i | | P W U i ) h 0 ( I D U i | | P W U i | | b U i ) h 0 ( I D U i | | P W U i n e w | | b U i n e w ) h 0 ( I D U i | | P W U i n e w ) , v U i n e w   =   h 0 ( h 0 ( I D U i | | P W U i n e w | | b U i n e w ) , k U i n e w h 0 ( I D U i | | P W U i n e w ) ) . Finally, S C U i replaces { g U i ,   k U i ,   v U i ,   b U i } with { g U i ,   k U i n e w ,   v U i n e w ,   b U i n e w } .

6. Security Analysis

6.1. Security Verification Using ProVerif

ProVerif [25] is one of the most widely used automated security verification tools. The security validation of ProVerif works on applied π calculus, and ProVerif can verify the authentication and confidentiality of authentication protocol. We elaborate the design process and results of security validation using ProVerif in this section.
First, we define two channels for communication between participants, an insecure channel Pch and a secure channel SEch.
(*--Channels--*)
free SEch:channel [private]. (* Secure Channel *)
free Pch:channel. (*Insecure Channel *)
Then, public and private parameters and constructors are defined as follows:
(*----------------Variable and constants---------------------*)
const P: bitstring.
const g: bitstring.
const q: bitstring.
const n: bitstring.
free Uid: bitstring. (* User ID *)
free PWi: bitstring [private]. (* Password of user *)
free bUi:bitstring. (* Random number of user in registration phase *)
free Sid: bitstring. (* Server ID *)
free t1, t2, t3: bitstring [private]. (* Private key of RC *)
free Ppub: bitstring. (* Ppub = t2. P *)
free gpub: bitstring. (* gpub = Exp (g, t1) *)
(*----------------Constructor---------------------*)
fun CONCAT (bitstring, bitstring): bitstring. (* CONCAT operation *)
fun Div1 (bitstring): bitstring. (* Division operation and get the first part *)
fun Div2 (bitstring): bitstring. (* Division operation and get the second part *)
fun h0 (bitstring): bitstring. (* Hash operation h0 *)
fun h1 (bitstring,bitstring): bitstring. (* Hash operation h1 *)
fun h2 (bitstring): bitstring. (* Hash operation h2 *)
fun h3 (bitstring,bitstring,bitstring,bitstring):bitstring. (* Hash operation h3 *)
fun h4 (bitstring,bitstring,bitstring,bitstring):bitstring. (* Hash operation h4 *)
fun h5 (bitstring,bitstring,bitstring,bitstring,bitstring): bitstring. (* Hash operation h5 *)
fun h6 (bitstring): bitstring. (* Hash operation h6 *)
fun Xor (bitstring, bitstring): bitstring. (* XOR operation *)
fun Smul (bitstring, bitstring): bitstring. (* Scalar multiplication operation *)
fun Padd (bitstring, bitstring): bitstring. (* Point addition operation *)
fun BPL (bitstring, bitstring): bitstring. (* Bilinear paring operation *)
fun Exp (bitstring, bitstring): bitstring. (* Exponentiation operation *)
fun Mod (bitstring, bitstring): bitstring. (* Mod operation *)
fun Mul (bitstring, bitstring): bitstring. (* multiplication operation *)
fun Add (bitstring, bitstring): bitstring. (* Addition operation *)
fun Inverse (bitstring): bitstring. (* inverse operation *)
The following four events are specified to check authentication between the user and server:
(*----------------Events---------------------*)
event beginUserUi (bitstring).
event endUserUi (bitstring).
event beginServerSj (bitstring).
event endServerSj (bitstring).
The processes UserUi, ServerSj, and RC represent U i , S j and RC, respectively.
(*----------------Processes---------------------*)
(*----------------User Ui---------------------*)
let UserUi =
(* Registration Phase *)
let PWB = Mod (h0 (CONCAT (CONCAT (Uid, PWi), bUi)), n) in
out (SEch, (Uid, PWB));
in (SEch, (gUi: bitstring, dUi:bitstring, vUi:bitstring, mUi:bitstring));
let kUi = Xor (dUi, h0(CONCAT (Uid, PWi))) in
let MUi = Xor (mUi, PWB) in
(*Login and Authentication Phase *)
event beginUserUi (Uid);
let PWB = Mod (h0 (CONCAT (CONCAT (Uid, PWi), bUi)), n) in
let dUi = Xor (kUi, h0 (CONCAT (Uid, PWi))) in
let vUi’ = h0 (CONCAT (PWB, dUi)) in
if vUi’ = vUi then
new rUi:bitstring;
let RUi = Smul (rUi, Padd (Ppub, Smul (h2 (Sid), P))) in
let x = Exp (g, rUi) in
let mUi = Xor (MUi, PWB) in
let XUi = Exp (x, mUi) in
let nUi = Xor (x, h0 (Uid)) in
out (Pch, (RUi, XUi, nUi));
in (Pch, (y:bitstring, aSj:bitstring ));
let aSj’ = h3 (RUi, x, y, nUi) in
if (aSj = aSj’) then
let oUi = h4 (Uid,RUi, x, y) in
let tUi = Xor (dUi, PWB) in
let aUi = Add (tUi, Mul (oUi, rUi)) in
let SKij = h5 (Uid,Sid, x, y, Exp (y, rUi)) in
let CUi = Xor (h6 (x), CONCAT (CONCAT (CONCAT (Uid, gUi), aUi), y)) in
out (Pch, CUi);
event endUserUi (Uid)
else
0.
(*----------------Server Sj---------------------*)
let ServerSj =
(* Registration Phase *)
out (SEch, Sid);
in (SEch, (DSj: bitstring, ht3: bitstring));
(* Login and Authentication Phase *)
event beginServerSj (Sid);
in (Pch, (RUi: bitstring, XUi:bitstring, nUi:bitstring));
let x = BPL (RUi, DSj) in
let mUi = h0 (CONCAT (Xor (nUi, x), ht3)) in
let XUi’ = Exp (x, mUi) in
if XUi’ = XUi then
new rSj: bitstring;
let y = Exp (g, rSj) in
let aSj = h3 (RUi, x, y, nUi) in
out (Pch, (y, aSj));
in (Pch, CUi:bitstring);
let aUi = Div2 (Div1 (Xor (h6 (x), CUi))) in
let gUi = Div2 (Div1 (Div1 (Xor (h6 (x), CUi)))) in
let Uid = Div1 (Div1 (Div1 (Xor (h6 (x), CUi)))) in
let fUi = h1 (Uid, gUi) in
let oUi = h4 (Uid, RUi, x, y) in
let gaUi = Exp (g, aUi) in
let gaUi’ = Mul (Mul (gUi, Exp (gpub, fUi)), Exp (x,oUi)) in
if gaUi = gaUi’ then
let SKij = h5 (Uid, Sid, x, y, Exp (x, rSj)) in
event endServerSj (Sid)
else
0.
(*----------------Registration Centre RC---------------------*)
let RC =
(* Registration with User *)
in (SEch, (Uid: bitstring, PWB: bitstring));
new wUi: bitstring;
let gUi = Exp (g, wUi) in
let fUi = h1 (Uid, gUi) in
let tUi = Add (wUi, Mul (t1, fUi)) in
let dUi = Xor (tUi, PWB) in
let vUi = Mod (h0 (CONCAT (PWB, dUi)), n) in
let mUi = h0 (CONCAT (h0 (Uid), h0(t3))) in
out (SEch, (gUi, dUi, vUi, mUi));
(*Registration with Servers*)
in (SEch, Sid: bitstring);
let DSj = Inverse (Add (t2, h2(Sid))) in
let ht3 = h0(t3) in
out (SEch, (DSj, ht3));
0.
We simulate our proposed protocol as unbounded parallel execution of the three processes mentioned:
process
((! UserUi) | (! RC) | (! ServerSj))
The following queries are used to test mutual authentication and session key security of the improved protocol.
(*-------------Queries-----------------*)
free SKij: bitstring [private].
query attacker (SKij).
query id: bitstring; inj-event (endUserUi (id)) = = > inj-event (beginUserUi (id)).
query id: bitstring; inj-event (endServerSj (id)) = = > inj-event (beginServerSj (id)).
At last, we get the simulation result:
Symmetry 12 00150 i001
According to RESULT 2 and RESULT 3, mutual authentication between U i and S j succeeded. Furthermore, RESULT 1 indicates that no adversary is capable of exposing the session key.

6.2. Formal Security Analysis Using BAN-Logic

Burrows–Abadi–Needham logic [26] is a modal logic based on belief, which is proposed by Burrows et al. We use BAN-logic to prove that user U i and server S j have succeeded in session key agreement. Table 3 is the BAN-logic notations and the basic BAN-logic rules are shown in Table 4.

6.2.1. Idealized Form

Message 1: U i S j :   R U i , X U i , ( I D U i ) U i x S j
Message 2: S j U i : y , ( R U i , y , n U i ) U i x S j
Message 3: U i S j : ( I D U i , g U i , a U i , y ) U i x S j

6.2.2. Verification Purposes

Purpose 1: U i | ( U i s k S j ) .
Purpose 2: U i | S j | ( U i s k S j ) .
Purpose 3: S j | ( U i s k S j ) .
Purpose 4: S j | U i | ( U i s k S j ) .

6.2.3. Assumptions about Initial State

Assumption 1: U i | ( r U i ) .
Assumption 2: S j | ( r S j ) .
Assumption 3: U i | ( U i x S j ) .
Assumption 4: S j | ( U i x S j ) .
Assumption 5: S j | U i | ( I D S j )
Assumption 6: U i | S j ( U i S x S j ) .
Assumption 7: S j | U i ( U i S x S j )

6.2.4. Proofs

1.
According to Message 2, we get the following: U i ( y , ( R U i ,   y , n U i ) U i x S j ) .
2.
According to Assumption 3 and the message-meaning rule, we get the following: U i | S j | ~ ( R U i ,   y , n U i ) .
3.
Based on Assumption 1 and the freshness–conjuncatenation rule, we can prove: U i | ( R U i ,   y , n U i ) .
4.
From Step 2, Step 3, and the nonce-verification rule, we obtain the following: U i | S j | ( R U i ,   y , n U i ) .
5.
According to Step 4 and believe rule, U i | S j | ( I D U i , I D S j ,   y , r U i ) .
6.
According to Step 5, Assumption 3 and s k   =   h 5   ( I D U i ,   I D S j ,   x ,   y ,   y r U i ) , we prove that: U i | S j | ( U i s k S j ) (Purpose 2).
7.
Based on Step 6, Assumption 6, and jurisdiction rule, we prove that: U i | ( U i s k S j ) (Purpose 1).
8.
From Message 3, we get: S j   ( I D U i , g U i , a U i ,   y ) U i x S j .
9.
Based on Assumption 4 and the message-meaning rule, we obtain the following: S j | U i | ~ ( I D U i , g U i , a U i , y ) .
10.
From Assumption 2 and the freshness-conjuncatenation rule, we can obtain: S j | ( I D U i , g U i , a U i , y ) .
11.
Based on Step 9, Step 10, and the nonce-verification rule, we obtain the following: S j | U i | ( I D U i , g U i , a U i , y ) .
12.
According to Assumption 5, Step 11, y   =   g r S j , and the believe rule, we obtain the following: S j | U i | ( I D U i , I D S j , r S j ,   y ) .
13.
According to Step 12, Assumption 4, and s k   =   h 5   ( I D U i ,   I D S j ,   x ,   y ,   x r S j ) , we prove that: S j | U i | ( U i s k S j ) (Purpose 4).
14.
According to Step 13, Assumption 7, and jurisdiction rule, we prove that: S j | ( U i s k S j ) (Purpose 3).
From Purposes 1–4, U i and S j believe that the session key has been established between them successfully.

6.3. Informal Security Analysis

6.3.1. Anonymity and Untraceability

In authentication phase, the adversary can intercept the login request information from users and the response information from cloud servers. The constructions of C U i , X U i and n U i are related to I D U i , C U i   =   h 6 ( x ) ( I D U i | | g U i | | a U i | | y ) ,   X U i   =   x m U i , n U i   =   x     h 0   ( I D U i ) . Obviously, under the protection of shared secret   x and hash function, the adversary is unable to obtain I D U i . On the other hand, the generation of x is affected by random number r U i , so the parameters C U i , X U i and n U i generated by U i in each session changes. Even if an adversary intercepts { C U i , X U i , n U i } and other information, he can’t judge whether two sessions come from the same user, and can’t track the user’s access behavior effectively.

6.3.2. Forward Secrecy

Suppose the adversary captured the private keys t 1 ,   t 2 ,   t 3   and intercepts ( R U i ,   X U i ,   n U i ,   y ,   a S j ,   C U i ) propagated in the public channel. The adversary can calculate x through the private key, but he can’t calculate y r U i and x r S j in polynomial time, so the adversary is unable to capture session key s k U i   =   h 5   ( I D U i ,   I D S j ,   x ,   y ,   y r U i )   =   h 5   ( I D U i ,   I D S j ,   x ,   y ,   x r S j )   =   s k S j .

6.3.3. Two-Factor Security

It is obviously less difficult for adversary to break through the user’s password than for smart cards. In the proposed scheme, the process of S C U i verification is a fuzzy verification process, v U i ?   =   h 0   ( ( h 0   ( I D U i | | P W U i | | b U i ) mod   n ) | | ( k U i h 0   ( I D U i | | P W U i ) ) ) mod   n . Even if ( I D U i * ,   P W U i * ) guessed by the adversary has passed the verification of the smart card, it still needs to go through the online login authentication process to determine whether it is correct. Specifically, an adversary needs to log in online | D i d | · | D p w | / 2 6 times to get the correct password, about 2 34 times, the cloud server can easily resist this attack.

6.3.4. Session Key Agreement

In the proposed scheme, U i and S j reach a session key for future communication after the login and authentication phase is completed, s k U i   =   h 5 ( I D U i ,   I D S j ,   x ,   y ,   y r U i )   =   h 5   ( I D U i ,   I D S j ,   x ,   y ,   x r S j )   =   s k S j .

6.3.5. Resistance of Other Attacks

Insider attack: In our proposed adversary model, an insider can acquire user’s registration information { I D U i ,   P W B } and smart card parameter { g U i ,   k U i ,   v U i ,   b U i } . Since PWB is generated by modulo operation, the insider adversary cannot directly acquire P W U i via offline password guessing. On the other hand, when the insider adversary wants to authenticate with the cloud server S j as U i , he cannot compute d U i   =   k U i h 0 ( I D U i | | P W U i ) . Therefore, no effective attack can be launched.
Cloud Server Spoofing Attack: If the adversary wants to complete authentication with user U i as cloud server S j , he needs to generate legal response information; however, only when the adversary gets D S j can he generate legal login request information. Therefore, the attack is unfeasible.
Replay attack: In the improved scheme, the change of random number r U i and r S j will affect the login request information and cloud server response information. As a result, the replay attack cannot be launched.
DoS attack: Different from He et al.’s scheme, S j verifies U i ’s login request before subsequent operations in the improved scheme X U i ?   =   x m U i . Only legitimate users could generate legitimate login information, so the improved scheme is capable of withstanding DoS attack.
According to the above analysis, we know that an insider adversary cannot guess the user’s password offline and impersonate a user, even if he obtains the user’s smart card and registration information. As a result, offline password guessing attack, stolen smart card attack, and user impersonation attack are unfeasible.

7. The Comparisons of Security and Performance

We compare the proposed protocol with [24] in terms of security features. The comparisons are demonstrated in Table 5.
We compare the proposed protocol with [24] in terms of time complexity. Since RC is usually regarded as a powerful device, our efficiency analysis focuses on users and servers. For the sake of convenience, we define T b p , T p m , T p a , T e x p , T h to represent time of bilinear paring operation, point scalar multiplication operation, point addition operation, exponentiation operation, and hash function respectively.
The XOR operation, concatenate operation, the modular multiplication, and modular operation are neglected while comparing with the related operation mentioned above. Based on the experiments conducted on a Quad-core 2.45G processor with 2 GB memory and an I5-4460S 2.90GHz processor with 4 GB memory in [24], we get the running time of above operations in Table 6.
All participants register with RC only once, and users do not change their passwords frequently. Therefore, the computation cost of registration phase and password modification phase is not discussed. Table 7 summarizes the results of efficiency comparison.

8. Conclusions

Numerous research efforts on authentication and key agreement scheme can be witnessed in recent years. In 2016, He et al. proposed an anonymous authentication protocol using asymmetric cryptography, which is looking promising. However, we discovered vulnerabilities of their scheme under our proposed adversary model. Furthermore, we propose an improved authentication and key agreement scheme for IoT-based cloud computing environment, and provide ProVerif tool verification and formal security analysis via BAN-logic. The comparisons of security and performance show that the computational cost of our proposed scheme is slightly higher but is much safer than the original scheme.

Author Contributions

Y.Y. and L.H. proposed the adversary model and designed the scheme; J.C. performed the security analysis. All authors have read and agreed to the published version of the manuscript.

Funding

This research is funded by: National Key R&D Plan of China under Grant No. 2017YFA0604500, and by National Sci-Tech Support Plan of China under Grant No. 2014BAH02F00, and by National Natural Science Foundation of China under Grant No. 61701190, and by Youth Science Foundation of Jilin Province of China under Grant No. 20160520011JH & 20180520021JH, and by Youth Sci-Tech Innovation Leader and Team Project of Jilin Province of China under Grant No. 20170519017JH, and by Key Technology Innovation Cooperation Project of Government and University for the whole Industry Demonstration under Grant No. SXGJSF2017-4, and by Key scientific and technological R&D Plan of Jilin Province of China under Grant No. 20180201103GX, Project of Jilin Province Development and Reform Commission No. 2019FGWTZC001.

Conflicts of Interest

The authors declare no conflict of interest.

References

  1. Yang, H.; Kumara, S.; Bukkapatnam, S.T.S.; Tsung, F. The internet of things for smart manufacturing: A review. IISE Trans. 2019, 51, 1190–1216. [Google Scholar] [CrossRef]
  2. Dang, L.M.; Piran, M.; Han, D.; Min, K.; Moon, H. A Survey on Internet of Things and Cloud Computing for Healthcare. Electronics 2019, 8, 768. [Google Scholar] [CrossRef]
  3. Grobauer, B.; Walloschek, T.; Stocker, E. Understanding cloud computing vulnerabilities. IEEE Secur. Priv. 2010, 9, 50–57. [Google Scholar] [CrossRef]
  4. Lamport, L. Password authentication with insecure communication. Commun. ACM 1981, 24, 770–772. [Google Scholar] [CrossRef]
  5. Wang, B.; Ma, M. A smart card based efficient and secured multi-server authentication scheme. Wirel. Pers. Commun. 2013, 68, 361–378. [Google Scholar] [CrossRef]
  6. Sahoo, J.; Das, A.K.; Goswami, A. An efficient approach for mining association rules from high utility itemsets. Expert Syst. Appl. 2015, 42, 5754–5778. [Google Scholar] [CrossRef]
  7. Lu, Y.; Li, L.; Yang, X.; Yang, Y. Robust biometrics based authentication and key agreement scheme for multi-server environments using smart cards. PLoS ONE 2015, 10, e0126323. [Google Scholar] [CrossRef]
  8. Zhou, L.; Li, X.; Yeh, K.H.; Su, C.; Chiu, W. Lightweight IoT-based authentication scheme in cloud computing circumstance. Future Gener. Comput. Syst. 2019, 91, 244–251. [Google Scholar] [CrossRef]
  9. Li, X.; Wen, Q.; Li, W.; Zhang, H.; Jin, Z. A biometric-based password authentication with key exchange scheme using mobile device for multi-server environment. Appl. Math. Inf. Sci. 2015, 9, 1123. [Google Scholar]
  10. Amin, R.; Islam, S.K.H.; Gope, P.; Choo, K.K.R.; Tapas, N. Anonymity preserving and lightweight multi-medical server authentication protocol for telecare medical information system. IEEE J. Biomed. Health Inform. 2018, 23, 1749–1759. [Google Scholar] [CrossRef]
  11. Lwamo, N.M.R.; Zhu, L.; Xu, C.; Sharif, K.; Liu, X.; Zhang, C. SUAA: A Secure User Authentication Scheme with Anonymity for the Single & Multi-server Environments. Inf. Sci. 2019, 477, 369–385. [Google Scholar]
  12. Cui, J.; Zhang, X.; Cao, N.; Zhang, D.; Ding, J.; Li, G. An improved authentication protocol–based dynamic identity for multi-server environments. Int. J. Distrib. Sens. Netw. 2018, 14, 1550147718777654. [Google Scholar] [CrossRef]
  13. Renuka, K.; Kumar, S.; Kumari, S.; Chen, C.M. Cryptanalysis and Improvement of a Privacy-Preserving Three-Factor Authentication Protocol for Wireless Sensor Networks. Sensors 2019, 19, 4625. [Google Scholar] [CrossRef] [PubMed]
  14. Amin, R.; Islam, S.K.H.; Kumar, N.; Choo, K.K.R. An untraceable and anonymous password authentication protocol for heterogeneous wireless sensor networks. J. Netw. Comput. Appl. 2018, 104, 133–144. [Google Scholar] [CrossRef]
  15. Mohit, P.; Amin, R.; Karati, A.; Biswas, G.P.; Khan, M.K. A standard mutual authentication protocol for cloud computing based health care system. J. Med. Syst. 2017, 41, 50. [Google Scholar] [CrossRef]
  16. Xu, G.; Qiu, S.; Ahmad, H.; Xu, G.; Guo, Y.; Zhang, M.; Xu, H. A multi-server two-factor authentication scheme with un-traceability using elliptic curve cryptography. Sensors 2018, 18, 2394. [Google Scholar] [CrossRef]
  17. Chandrakar, P.; Om, H. A secure and robust anonymous three-factor remote user authentication scheme for multi-server environment using ECC. Comput. Commun. 2017, 110, 26–34. [Google Scholar] [CrossRef]
  18. Ying, B.; Nayak, A. Lightweight remote user authentication protocol for multi-server 5G networks using self-certified public key cryptography. J. Netw. Comput. Appl. 2019, 131, 66–74. [Google Scholar] [CrossRef]
  19. Hou, J.L.; Yeh, K.H. Novel authentication schemes for IoT based healthcare systems. Int. J. Distrib. Sens. Netw. 2015, 11, 183659. [Google Scholar] [CrossRef]
  20. Tomar, A.; Dhar, J. An ECC Based Secure Authentication and Key Exchange Scheme in Multi-server Environment. Wirel. Pers. Commun. 2019, 107, 351–372. [Google Scholar] [CrossRef]
  21. Qi, M.; Chen, J. Anonymous biometrics-based authentication with key agreement scheme for multi-server environment using ECC. Multimed. Tools Appl. 2019, 78, 27553–27568. [Google Scholar] [CrossRef]
  22. Tseng, Y.M.; Huang, S.S.; Tsai, T.T.; Ke, J.H. List-free ID-based mutual authentication and key agreement protocol for multiserver architectures. IEEE Trans. Emerg. Top. Comput. 2015, 4, 102–112. [Google Scholar] [CrossRef]
  23. Wang, H.; Guo, D.; Zhang, H.; Wen, Q. Robust Multiple Servers Architecture Based Authentication Scheme Preserving Anonymity. Sensors 2019, 19, 3144. [Google Scholar] [CrossRef] [PubMed]
  24. He, D.; Zeadally, S.; Kumar, N.; Wu, W. Efficient and anonymous mobile user authentication protocol using self-certified public key cryptography for multi-server architectures. IEEE Trans. Inf. Forensics Secur. 2016, 11, 2052–2064. [Google Scholar] [CrossRef]
  25. Blanchet, B.; Smyth, B.; Cheval, V.; Sylvestre, M. ProVerif 2.00: Automatic Cryptographic Protocol Verifier, User Manual and Tutorial. 2018. Available online: https://prosecco.gforge.inria.fr/personal/bblanche/proverif (accessed on 9 January 2020).
  26. Burrows, M.; Abadi, M.; Needham, R.M. A logic of authentication. Proc. R. Soc. Lond. A Math. Phys. Sci. 1989, 426, 233–271. [Google Scholar] [CrossRef]
  27. Dolev, D.; Yao, A. On the security of public key protocols. IEEE Trans. Inf. Theory 1983, 29, 198–208. [Google Scholar] [CrossRef]
  28. Veyrat-Charvillon, N.; Standaert, F.X. Generic side-channel distinguishers: Improvements and limitations. In Proceedings of the Annual Cryptology Conference, Santa Barbara, CA, USA, 14–18 August 2011; Springer: Berlin/Heidelberg, Germany, 2011; pp. 354–372. [Google Scholar]
  29. Wang, D.; He, D.; Wang, P.; Chu, C.H. Anonymous two-factor authentication in distributed systems: Certain goals are beyond attainment. IEEE Trans. Dependable Secur. Comput. 2014, 12, 428–442. [Google Scholar] [CrossRef]
  30. Huang, X.; Xiang, Y.; Chonka, A.; Zhou, J.; Deng, R.H. A generic framework for three-factor authentication: Preserving security and privacy in distributed systems. IEEE Trans. Parallel Distrib. Syst. 2010, 22, 1390–1397. [Google Scholar] [CrossRef]
  31. Das, M.L.; Saxena, A.; Gulati, V.P. A dynamic ID-based remote user authentication scheme. IEEE Trans. Consum. Electron. 2004, 50, 629–631. [Google Scholar] [CrossRef]
  32. Das, M.L. Two-factor user authentication in wireless sensor networks. IEEE Trans. Wirel. Commun. 2009, 8, 1086–1090. [Google Scholar] [CrossRef]
  33. Wang, D.; Gu, Q.; Cheng, H.; Wang, P. The request for better measurement: A comparative evaluation of two-factor authentication schemes. In Proceedings of the 11th ACM on Asia Conference on Computer and Communications Security, Xi’an, China, 30 May–3 June 2016; ACM: New York, NY, USA, 2016; pp. 475–486. [Google Scholar]
Figure 1. Proposed model of an IoT-based cloud computing environment.
Figure 1. Proposed model of an IoT-based cloud computing environment.
Symmetry 12 00150 g001
Figure 2. The conceptual architecture of our proposed protocol.
Figure 2. The conceptual architecture of our proposed protocol.
Symmetry 12 00150 g002
Table 1. The capabilities of adversaries.
Table 1. The capabilities of adversaries.
SymbolDescription
Capability   1 .The adversary can enumerate all elements of | D I D | | D P W | offline.
Capability   2 .The adversary can obtain user ID (The user ID should be assumed to be sensitive information when evaluating the anonymity of the protocol).
Capability   3 .The adversary can eavesdrop, intercept, insert, delete, or block messages flowing through the public channel.
Capability   4 .For the n-factor protocol, the adversary can obtain n-1 of the n authentication factors simultaneously.
Capability   5 .The adversary has a chance to capture an expired session key.
Capability   6 .The adversary can obtain the long-term private keys of participants. (when evaluating forward secrecy).
Capability   7 .An insider adversary can obtain user’s registration information and capture user’s smartcard (when evaluating insider attack).
Table 2. Notations.
Table 2. Notations.
SymbolDescriptionSymbolDescription
R C Registration Center U i User
τ , τ ^ Private key of R C I D U i Identification of U i
P Large prime P W U i Password of U i
q prime order S C U i Smart card of U i
G 1 Additive group S j Cloud Server
G 2 Multiplicative group I D S j Identification of S j
g p u b , P p u b Public key of R C D S j Private key of S j
e ( * , * ) Bilinear pairing XOR operation
h 0 - h 6 Hash function s k U i , s k S j Session key of U i and S j
Table 3. BAN logic notations.
Table 3. BAN logic notations.
SymbolDescription
P | X P believes X .
P X P sees X .
P | ~ X P sends X .
P X P has jurisdiction over X .
( X ) X is fresh.
( X , Y ) X or Y is part of ( X , Y ) .
( X ) K Use key K to compute X .
P K Q P and Q achieve the shared key K for communication.
Table 4. Basic BAN-logic rules.
Table 4. Basic BAN-logic rules.
RuleDescription
Message-meaning rule P | ( P K Q ) , P ( X ) K P | Q | ~ X
Freshness-conjuncatenation rule P | ( X ) P | ( X , Y )
Nonce-verification rule P | ( X ) , P | Q | ~ X P | Q | X
Jurisdiction rule P | Q | X , P | Q | X P | X
Believe rule P | Q | ( X , Y ) P | Q | X , P | X , P | Y P | ( X , Y )  
Table 5. Comparison of security features.
Table 5. Comparison of security features.
Security Features and Defensible AttacksHe et al.’sOurs
Anonymity
Un-traceability
Two-factor security
Forward Secrecy
Session key agreement
Insider attack
Cloud server spoofing attack
Replay attack
DoS attack
User impersonation attack
Offline password guessing attack
Smart card stolen attack
Table 6. The running time of related operations based on [24].
Table 6. The running time of related operations based on [24].
UserCloud Server
T p m 13.405 ms2.165 ms
T p a 0.081 ms0.013 ms
T e x p 2.249 ms0.339 ms
T h 0.056 ms0.007 ms
T b p 32.713 ms5.427 ms
Table 7. Comparison of computation cost.
Table 7. Comparison of computation cost.
He et al.’sOurs
User 2   ×   T p m   +   T p a   +   2   ×   T e x p   +   7   ×   T h 31.781 m s 2   ×   T p m   +   T p a   +   3   ×   T e x p   +   9   ×   T h 34.142 m s
Cloud server T b p   +   5   ×   T e x p   +   5   ×   T h 7.157 m s T b p   +   6   ×   T e x p   +   6   ×   T h 7.503 m s
Back to TopTop