A Secure IoT-Based Authentication System in Cloud Computing Environment

Abstract

The Internet of Things (IoT) is currently the most popular field in communication and information techniques. However, designing a secure and reliable authentication scheme for IoT-based architectures is still a challenge. In 2019, Zhou et al. showed that schemes pro-posed by Amin et al. and Maitra et al. are vulnerable to off-line guessing attacks, user tracking attacks, etc. On this basis, a lightweight authentication scheme based on IoT is proposed, and an authentication scheme based on IoT is proposed, which can resist various types of attacks and realize key security features such as user audit, mutual authentication, and session security. However, we found weaknesses in the scheme upon evaluation. Hence, we proposed an enhanced scheme based on their mechanism, thus achieving the security requirements and resisting well-known attacks.

1. Introduction

With the rapid development of computer science and network technology, the concept of the Internet of Things (IoT) has become a hot topic for research. A scientist named Ashton introduced this concept in 1991. In IoT, numerous sensors have the capability of collecting data and communicating with each other or providing data for human beings through the Internet.

Therefore, technology can be widely used in the smart power grid, smart home, and other fields. In a smart grid, sensors monitor electric energy consumption and time-of-use rates for power stations. Then, the stations can optimize power supply. In the intelligent transportation system, sensors monitor traffic to optimize navigation. In the smart home, users can control, monitor, and access items remotely. Though IoT is close to our lives, it suffers from security challenges due to the wireless nature of the communication channel [1].

In order to protect against those security challenges in IoT, authentication is indispensable. Authentication guarantees that the messages received by the receiver are from a legal message sender. It serves as the first line of defense against potential attackers. Authentication is considered the key requirement for IoT [2]. The cryptography in authentication falls into two broad categories: symmetric encryption and asymmetric encryption. Common asymmetric encryption includes elliptic-curve cryptography (ECC) and RSA encryption.

Asymmetric encryption uses pairs of keys, i.e., public key and private key. Although, asymmetric encryption is generally considered to have higher security, it requires a higher computational cost. On the other hand, common symmetric encryption, e.g., the advanced encryption standard (AES) and data encryption standard (DES), use a shared key between two or more parties. Symmetric encryption has the advantages of low computational cost and fast encryption speed. Some authentication schemes have been recently presented by using asymmetric encryptions [3,4,5,6,7,8,9,10]. However, traditional asymmetric encryptions do not suit IoT devices due to limited resources of most IoT devices, which gives rise to lightweight authentication schemes [11,12,13,14,15,16,17,18,19,20,21].

To solve security disadvantages, many lightweight authentication schemes have been proposed. In 1981, Lamport [22] first suggested lightweight authentication using a password. The scheme also uses hash chains to go through unsafe communication channel for remote user authentication. However, the scheme relies on a password table, which makes it very easy to steal personal data. After that, many user authentications with a password and key negotiation techniques have been put forward [23,24,25,26,27,28,29,30]. In 2007, Liao et al. [31] proposed an authentication scheme based on a hash function for a multi-server environment. Further, Hsiang et al. [32] pointed out that Liao et al.’s scheme [31] is subject to multiple security threats, e.g., insider attack, masquerade attack, and user/server forgery attacks. Hsiang et al. [32] then proposed a new authentication scheme and claimed their scheme has fewer computations and higher security. In 2011, Sood et al. [33] proposed an authentication scheme using a dynamic identity for multi-server circumstances and criticized Hsiang et al.’s scheme [32] for having a wrong password change phase and not resisting replay and impersonation attacks. In the same year, Lee et al. [34] assessed Sood et al.’s programme [33] and concluded that it was not safe. In 2014, Xue et al. [35] pointed out that Lee et al.’s scheme [34] failed under the circumstances of pseudonym attack and offline password guessing attack. Later, Amin et al. [36] criticized the scheme in [35], saying that it lacked identity hiding features and could not resist offline password guessing attack. Recently, some authentication schemes are also used in vehicular ad-hoc networks (VANETs) [37,38,39,40] or smart grid [41]. It shows the universality of authentication. In 2019, Zhou and other [42] proposed their scheme based on a hash function and exclusive or operation of the two-factor authentication scheme, claiming their authentication scheme has been proven safe and could resist various attacks.

We reviewed the scheme of Zhou et al. [42] and pointed out the weaknesses such as the inability of replay attacks to achieve user anonymity and provide mutual authentication. We proposed an improved scheme that has a better balance between efficiency and security. Therefore, the scheme is more suitable for IoT based environment. The contribution of this paper is to enhance the resistance to replay attack, thus improving user anonymity and providing mutual authentication based on Zhou et al.’s scheme [42].

The rest of this article is arranged as follows: Section 2 provides an overview of Zhou et al. ‘s scheme, focusing on its registration and certification phases. Then, the security analysis of the scheme proposed by Zhou et al. [42] was conducted. Section 3 introduces the scheme we proposed. Safety analysis and performance evaluation are described in Section 4 and Section 5. Section 6 gives the conclusion.

2. Related Works

In Section 2.1., we will introduce the authentication scheme proposed by Zhou et al. [42]. In addition, we will present the security issues of Zhou et al.’s scheme in Section 2.2.

2.1. Review of Zhou et al.’s Scheme

Zhou et al.’s scheme is divided into three stages: registration, authentication, and password modification. Here, we introduce the first two phases.

2.1.1. Registration Phase

There are two parts in this phase: user registration and cloud server registration.

User Registration

First, user U_i selects four values (i.e., identity ID_i, pseudo-identity PID_i, password PW_i, and a random number b_i to calculate HP_i = h(PW_i ||b_i). The U_i then sends the ID_i and PID_i to the control server CS. When CS receives (ID_i, PID_i), CS will check whether or not ID_i is in the database. If not, CS uses secret key x to calculate C₁^* = h(PID_i||IDcs||x) and C₂^* = h(ID_i||x); otherwise, CS will stop the authentication. CS stores ID_i in its database and sends (C₁^*, C₂^*, IDcs) to U_i. When U_i receives (C₁^*, C₂^*, IDcs), U_i calculates three values, C₁ = C₁^*⊕HP_i, C₂ = C₂^*⊕h(ID_i||HP_i), and C₃ = b_i⊕h(ID_i||PW_i), then stores (C₁, C₂, C₃, PID_i, ID_cs) in a smart card.

Cloud Server Registration

Cloud server S_j sends (SID_j, PSID_j) to CS, where SID_j is the identity of S_j and PSID_j is the pseudo-identity of S_j. When CS receives (SID_j, PSID_j), CS calculates B₁ = h(PSID_j||ID_cs||x) and B₂ = h(SID_j||x). Finally, CS stores SID_j in a database and sends (B₁, B₂, ID_cs) to S_j, and S_j stores (B₁, B₂, SID_j, PSID_j, ID_cs) in a memory.

2.1.2. Authentication Phase

When user U_i wants to connect with a cloud server, the user will perform the following five steps with the cloud server (S_j) and the control server (CS).

Step 1: User inputs his ID_i and PW_i. A smart card will select a random number r_u and new pseudo-identity PID_i^new; then, it calculates b_i = C₃⊕h(ID_i||PW_i), HP_i = h(PW_i||b_i), C₁^* = C₁⊕HP_i, and C₂^* = C₂⊕h(ID_i||HP_i). The smart card then calculates D₁ = C₁^*⊕r_u, D₂ = h(r_u||PID_i||ID_cs)⊕ID_i, D₃ = C₂^*⊕h(ID_i||HP_i)⊕ PID_i^new⊕h(r_u||ID_i), and D₄ = h(ID_i||PID_i||PID_i^new||r_u||D₃). U_i sends the message M₁ = {PID_i, D₁, D₂, D₃, D₄} to S_j.

Step 2: When S_j receives M₁, S_j selects a new pseudo-identity PSID_j^new and a random number r_s to calculate D₅ = B₁⊕r_s, D₆ = h(r_s||PSID_j||ID_cs)⊕SID_j, D₇ = B₂⊕PSID_j^new⊕h(r_s||PSID_j), and D₈ = h(SID_j||PSID_j||PSID_j^new||r_s||D₇). S_j sends the message M₂ = {M₁, PSID_j, D₅, D₆, D₇, D₈} to CS.

Step 3: When CS receives M₂, CS calculates r_u = D₁⊕h(PID_i||ID_cs||x), ID_i = D₂⊕h(r_u||PID_i||ID_cs), and PIDi^new = D₃⊕h(ID_i||x)⊕h(r_u||ID_i). CS checks whether ID_i in the database and D₄? = h(ID_i||PID_i||PIDi^new||r_u||D₃). If ID_i is in the database and D₄ = h(ID_i||PID_i||PIDi^new||r_u||D₃), it means that CS confirms U_i is a legal user. Otherwise, the authentication process will be terminated. Then, CS calculates r_s = D₅⊕h(PSID_j||ID_cs||x), SID_j = D₆⊕h(r_s||PSID_j||ID_cs), and PSID_j = D₇⊕h(SID_j||x)⊕h(r_s||SID_j). CS checks whether SID_j is in database and D₈ = h(SID_j||PSID_j||PSID_j^new||r_s||D₇). If SID_j is in the database and D₈ = h(SID_j||PSID_j||PSID_j^new||r_s||D₇), it means that CS confirms the S_j is legal. Then, CS selects a random number r_cs to calculate the session key SK = h(r_u⊕r_s⊕r_cs), D₉ = h(PSID_j^new||ID_cs||x)⊕h(r_s||PSID_j^new), D₁₀ = h(PSID_j^new||r_s||PSID_j)⊕(r_u⊕r_cs), D₁₁ = h(SK_cs||D₉||D₁₀||h(SID_j||x)), D₁₂ = h(PID_i^new||ID_cs||x)⊕h(r_u||PID_i^new), D₁₃ = h(PID_i^new||r_u||PID_i)⊕(r_s⊕r_cs), and D₁₄ = h(SK_cs||D₁₂||D₁₃||h(ID_i||x)). CS sends the message M₃ = {D₉, D₁₀, D₁₁, D₁₂, D₁₃, D₁₄} to S_j.

Step 4: When S_j receives M₃, S_j calculates (r_u⊕r_cs = D₁₀⊕h(PSID_j^new||r_s||PSID_j). Hence, S_j can compute SK = h(r_u⊕r_s⊕r_cs). Then, S_j checks D₁₁? = h(SK_s||D₉||D₁₀||B₂) to confirm that CS is a legal control server or not. If CS is a legal control server, S_j calculates B₁^new = D₉⊕h(r_s||PSID_j^new), updates B₁ and PSID_j as B₁^new and PSID_j^new in memory. S_j sends message M₄ = {D₁₂, D₁₃, D₁₄} to U_i.

When U_i receives M₄, U_i calculates (r_s⊕r_cs) = D₁₃⊕h(PID_i^new||r_u||PID_i) and SK = h(r_u⊕r_s⊕r_cs). Then, U_i checks D₁₄? = h(SK_u||D₁₂||D₁₃||C₂^*) to confirm that CS is a legal control server or not. U_i calculates C₁^new = D₁₂⊕h(r_u||PID_i^new)⊕HP_i, updates C₁ and PID_i in memory to C₁^new and PID_i^new.

2.2. Analysis of Zhou et al.’s Scheme

We found three weaknesses in Zhou et al.’s scheme at the certification stage. First, Zhou et al.’s scheme cannot achieve mutual authentication. Second, Zhou et al.’s scheme cannot work against a replay attack. Third, Zhou et al.’s scheme cannot guarantee anonymity in the authentication phase.

2.2.1. Zhou et al.’s Scheme Cannot Achieve Mutual Authentication

Mutual authentication refers to the mutual verification between two entities. In Zhou et al.’s scheme, CS verifies U_i by checking D₄? = h(ID_i||PID_i||PID_i^new||r_u||D₃) in Step 3 of the authentication phase. We know D₃ = C₂^*⊕h(ID_i||HP_i)⊕PID_i^new⊕h(r_u||ID_i) and C₂^* = h(ID_i||x) from Step 1 of the authentication phase and the user registration. When CS computes D₃⊕h(ID_i||x)⊕h(r_u||ID_i), CS only can obtain h(ID_i||HP_i)⊕PID_i^new, where the parameter HP_i is only known by U_i. CS cannot successfully calculate PID_i^new from D₃⊕h(ID_i||x)⊕h(r_u||ID_i), even if the message M₁ = {PID_i, D₁, D₂, D₃, D₄} is sent from a legal user U_i. Therefore, Zhou et al.’s scheme was unable to complete mutual authentication.

2.2.2. Zhou et al.’s Scheme Cannot Guarantee Anonymity in Authentication Phase

A solution that provides anonymity must ensure that no one except the server knows the user’s personal information. We assume that the attacker U_A is a legitimate user. Hence, U_A will obtain ( $\overline{C_1^{*}}$ = h(PID_A||ID_cs||x), $\overline{C_2^{*}}$ = h(ID_A||x), ID_cs) from CS in the user registration phase. Once U_A intercepts the message M₁ = {PID_i, D₁, D₂, D₃, D₄} from U_i and uses PID_i as new pseudo-identity to restart an authentication session, U_A can obtain the ID_i of the user U_i. Details of the process are as follows.

Step 1: First, U_A chooses a random number r_A to calculate $\overline{D_1}$ = C₁^*⊕r_A, $\overline{D_2}$ = h(r_A||PID_A||ID_cs)⊕ID_A, $\overline{D_3}$ = C₂^*⊕h(ID_A||HP_A)⊕PID_i⊕h(r_A||ID_A), and $\overline{D_4}$ = h(ID_A||PID_A||PID_i||r_u|| $\overline{D_3}$). U_A sends the message $\overline{M_1}$ = {PID_A, $\overline{D_1}$, $\overline{D_2}$, $\overline{D_3}$, $\overline{D_4}$} to S_j.

Step 2: When U_A receives $\overline{M_4}$ = { $\overline{D_{12}}$, $\overline{D_{13}}$, $\overline{D_{14}}$}, U_A can compute ID_i = D₂⊕h(D₁⊕ $\overline{D_{12}}$⊕h(r_A||PID_i) ||PID_i||ID_cs), where D₁ = h(PID_i||ID_cs||x)⊕r_u, D₂ = h(r_u||PID_i||ID_cs)⊕ID_i, and $\overline{D_{12}}$ = h(PID_i||ID_cs||x)⊕h(r_A||PID_i).

Therefore, Zhou et al.’s scheme cannot guarantee anonymity in the authentication phase.

3. Proposed Scheme

After we reviewed the shortcomings of Zhou et al.’s scheme, an improved scheme is put forward. The improvements include registration, authentication, and password modification.

3.1. Notations

The following is the introduction to the notations that will be used in our scheme.

U_i is the ith user.

ID_i is the ith user’s identity.

PW_i is the ith user’s password.

n_i is a random number.

CS is the control server.

PID_i is the ith user’s pseudo-identity.

ID_cs is the control server’s identity.

SID_j is the jth server’s identity.

PSID_j is the jth server’s pseudo-identity.

x is the secret key of CS.

h () is a one-way hash function.

r_u, r_s, r_cs are the random numbers selected by U_i, S_j, and CS.

SK_u, SK_s, SK_cs are the session keys for U_i, S_j, and CS.

M₁, M₂, M₃, M₄ are the messages in the authentication.

3.2. Registration Phase

This phase is divided into two parts: user registration and cloud server registration. When a user or a cloud server wants to join this system, he/she must run this phase first. After the user and the cloud server successfully finish this phase, they can connect with each other to start the authentication phase.

3.2.1. User Registration

User U_i selects their own id ID_i, password PW_i, random number n_i. He/she sends ID_i to CS by the secure channel. When CS receives ID_i, CS checks it for its validity. If it is invalid, CS will stop this phase; otherwise, CS selects a pseudo-identity PID_i for U_i and uses the secret key x to compute A_i = h(PID_i||ID_cs||x) and B_i = h(ID_i||x). CS stores ID_i in its database and sends (A_i, B_i, PID_i, ID_cs) to U_i by the secure channel. Once U_i obtains these parameters, U_i calculates C₁ = A_i⊕h(ID_i||n_i), C₂ = B_i⊕h(PW_i||n_i), C₃ = n_i⊕h(ID_i||PW_i), and C₄ = h(ID_i||PW_i||n_i) and then stores (C₁, C₂, C₃, C₄, PID_i, ID_cs) in a smart card. The flowchart for user registration is shown in Figure 1.

3.2.2. Cloud Server Registration

A cloud server S_j sends its identity SID_j and a pseudo-identity PSID_j to CS by a secure channel. Then, CS uses the secret key x to compute A_j = h(PSID_j||ID_cs||x) and B_j = h(SID_j||x), stores SID_j in its database, and sends (A_j, B_j, ID_cs) to S_j by a secure channel. When S_j receives these parameters, S_j stores (A_j, B_j, SID_j, SPID_j, ID_cs) in its memory. The flowchart of the cloud server registration phase is shown in Figure 2.

3.3. Authentication Phase

When the user U_i needs to retrieve services from the cloud server S_j, this authentication must start to make sure of the legitimacy of both the user and the cloud server. After the authentication phase is completed, the user will negotiate a session key SK. By this session key, U_i can connect with S_j securely. The processes of the authentication phase are shown as follows and Figure 3.

Step 1: When user U_i attempts to connect to cloud server S_j, he/she inserts the smart card into a reader machine and keys in ID_i and PW_i. Then, the smart card selects a random number r_u and calculates n_i = C₃⊕h(ID_i||PW_i). Then, the smart card checks h(ID_i||PW_i||n_i)? = C₄ to verify the identity and password. If the verification passed, the smart card will calculate A_i = C₁⊕h(ID_i||n_i), B_i = C₂⊕h(PW_i||n_i), D₁ = A_i⊕r_u, D₂ = h(r_u||PID_i||ID_cs)⊕ID_i, and D₃ = h(ID_i||PID_i||r_u). Finally, the smart card sends M₁ = {PID_i, D₁, D₂, D₃} to S_j.

Step 2: When S_j receives M₁, S_j selects a new pseudo-identity $PSI{D}_j^{\prime }$ and a random number r_s to calculate D₄ = A_j⊕r_s, D₅ = h(r_s||PSID_j||ID_cs)⊕SID_j, D₆ = B_j⊕ $PSI{D}_j^{\prime }$⊕h(r_s||PSID_j), and D₇ = h(SID_j||PSID_j|| $PSI{D}_j^{\prime }$||r_s||D₆). Then, S_j sends message M₂ = {M₁, PSID_j, D₄, D₅, D₆, D₇} to CS.

Step 3: Once CS receives M₂, CS uses the secret key x to compute r_u = D₁⊕h(PID_i||ID_cs||x) and ID_i = D₂⊕h(r_u||PID_i||ID_cs) and then checks whether ID_i is valid and D₃? = h(ID_i||PID_i||r_u) or not. If the ID_i is in its database and D₃ = h(ID_i||PID_i||r_u), it means that U_i is legal. For the cloud server S_j, CS uses the sccret key x to compute r_s = D₄⊕h(PSID_j||ID_cs||x), SID_j = D₅⊕h(r_s||PSID_j||ID_cs), $PSI{D}_j^{\prime }$=D₆⊕h(SID_j||x)⊕h(r_s||SID_j), and then checks whether SID_j is in the database and D₇ = h(SID_j||PSID_j|| $PSI{D}_j^{\prime }$||r_s||D₆). If both conditions hold, it means that S_j is legal. The processes of authentication phase will be stopped when any verification is wrong; otherwise, CS selects a random number r_cs to compute the session key SK_cs = h(r_u⊕r_s⊕r_cs) for this round. Subsequently, for S_j, CS computes D₈ = h( $PSI{D}_j^{\prime }$||ID_cs||x)⊕h(r_s||$PSI{D}_j^{\prime }$), D₉ = h( $PSI{D}_j^{\prime }$||r_s||PSID_j)⊕(r_u⊕r_cs), and D₁₀ = h(SK_cs||D₈||D₉||h(SID_j||x)). For U_i, CS selects a new pseudo-identity $PI{D}_i^{\prime }$ to compute D₁₁= $PI{D}_i^{\prime }$⊕h(ID_i||x)⊕h(r_u||ID_i), D₁₂ = h($PI{D}_i^{\prime }$||ID_cs||x)⊕h(r_u||$PI{D}_i^{\prime }$), D₁₃ = h($PI{D}_i^{\prime }$||r_u||PID_i)⊕(r_s⊕r_cs), and D₁₄ = h(SK_cs||D₁₂||D₁₃||h(ID_i||x)). Finally, CS sends the message M₃ = {D₈, D₉, D₁₀, D₁₁, D₁₂, D₁₃, D₁₄} to S_j.

Step 4: While S_j receives M₃, S_j uses $PSI{D}_j^{\prime }$ and r_s to extract (r_u⊕r_cs) from D₉, i.e., r_u⊕r_cs = D₉⊕h( $PSI{D}_j^{\prime }$||r_s||PSID_j). Then, S_j checks D₁₀? = h(SK_s||D₈||D₉||B_j), where SK_s = h(r_u⊕r_s⊕r_cs). If this equation holds, it means that CS is legal; otherwise, this authentication process will be terminated. S_j continues to calculate $A_j^{\prime }$ = D₈⊕h(r_s|| $PSI{D}_j^{\prime }$) and updates A_j and PSID_j as $A_j^{\prime }$ and $PSI{D}_j^{\prime }$ in the memory. At the end of this step, S_j sends the message M₄ = {D₁₁, D₁₂, D₁₃, D₁₄} to U_i.

Step 4: Once the smart card receives M₄, the smart card uses B_i, r_u, and ID_i to extract $PI{D}_i^{\prime }$ and (r_s⊕r_cs) from D₁₁ and D₁₃, respectively, i.e., $PI{D}_i^{\prime }$ = B_i⊕D₁₁⊕h(r_u||ID_i) and (r_s⊕r_cs) = D₁₃⊕h( $PI{D}_i^{\prime }$||r_u||PID_i). The smart card will check whether or not D₁₄? = h(SK_u||D₁₂||D₁₃||B_i), where SK_u = h(r_u⊕r_s⊕r_cs). If this equation holds, it means that CS is legal; otherwise, this authentication process will be terminated. The smart card uses the new pseudo-identity $PI{D}_i^{\prime }$ to calculate $C_1^{\prime }$ = D₁₂⊕h(r_u|| $PI{D}_i^{\prime }$)⊕h(ID_i||n_i) and updates C₁ and PID_i as $C_1^{\prime }$ and $PI{D}_i^{\prime }$. Finally, the smart card sends h(SK_u) to S_j.

Step 5: When S_j receives h(SK_u), S_j will check h(SK_u)? = h(SK_s). If h(SK_u) = h(SK_s), this means that they already correctly negotiate the session key.

3.4. Password Change Phase

If the user U_i needs to change the password, you may need to start the password change phase. First, we assume that the smart card of U_i contains ( $C_1^{\prime }$, C₂, C₃, C₄, $PI{D}_i^{\prime }$, ID_cs). The U_i inserts the smart card into the card reader for key verification in identity ID_i and the original password PW_i. The smart card will calculate n_i = C₃⊕h(ID_i||PW_i) and check h(ID_i||PW_i||n_i)? = C₄. If the equation holds, U_i can input the new password $P{W}_i^{\prime }$. The smart card calculates $C_2^{\prime }$ = C₂⊕h(PW_i||n_i)⊕h( $P{W}_i^{\prime }$||n_i), $C_3^{\prime }$ = C₃⊕h(ID_i||PW_i)⊕h(ID_i|| $P{W}_i^{\prime }$), and $C_4^{\prime }$ = C₄⊕h(ID_i||PW_i||n_i)⊕h(ID_i|| $P{W}_i^{\prime }$||n_i) and replaces (C₂, C₃, C₄) with ($C_2^{\prime }$, $C_3^{\prime }$, $C_4^{\prime }$). Finally, there are ($C_1^{\prime }$, $C_2^{\prime }$, $C_3^{\prime }$, $C_4^{\prime }$, $PI{D}_i^{\prime }$, ID_cs) in the smart card, and U_i can use the new password $P{W}_i^{\prime }$ to perform the authentication phase in the next round. The flowchart of password modification phase is shown in Figure 4.

4. Security Analysis

In this section, we will analyze nine fundamental security requirements in which an authentication scheme should be achieved.

4.1. Mutual Authentication

As we discussed in Section 2.2.1., mutual authentication means that the identities of the two entities should be recognized before they connect. In our scheme, CS can be mutually authenticated with U_i and S_j, respectively.

4.1.1. CS Verifies the Identity of Ui through Checking D3? = h(IDi‖PIDi‖ru)

In the user registration phase, CS computes A_i = h(PID_i||ID_cs||x) and B_i = h(ID_i||x) for U_i, and two parameters are only known by CS and U_i. When U_i uses A_i to hide the random number r_u in the authentication phase, i.e., D₁ = A_i⊕r_u, CS can use h(PID_i||ID_cs||x) to extract r_u. Finally, CS can verify the identity of U_i by equation D₃ = h(ID_i‖PID_i‖r_u).

4.1.2. CS Verifies the Identity of Sj through Checking D7? = h(SIDj‖PSIDj‖PSIDj’‖rs‖D6)

In the cloud server registration phase, CS computes A_j = h(PSID_j||ID_cs||x) and B_j = h(SID_j||x) for S_j, and two parameters are only known by CS and S_j. When S_j uses A_j to hide the random number r_s in the authentication phase, i.e., D₄ = A_j⊕r_s, CS can use h(PSID_j||ID_cs||x) to extract r_s. Finally, CS can verify the identity of S_j by equation D₇ = h(SID_j‖PSID_j‖PSID_j^’‖r_s‖D₆).

4.1.3. Sj Verifies the Identity of CS through Checking D10? = h(SKs‖D8‖D9‖Bj)

Because B_j is only shared between S_j and CS, they only have the capability of computing h(SK_s‖D₈‖D₉‖B_j). Therefore, S_j can verify the identity of CS by equation D₁₀ = h(SK_s‖D₈‖D₉‖B_j).

4.1.4. Ui Verifies the Identity of CS through Checking D14? = h(SKu‖D12‖D13‖Bi)

Because B_i only shares between U_i and CS, they only have the capability of computing h(SK_u‖D₁₂‖D₁₃‖B_i). Therefore, U_i can verify the identity of CS by equation D₁₄ = h(SK_u‖D₁₂‖D₁₃‖B_i).

4.2. Session Key for All Entities

In the authentication phase, U_i, S_j, and CS generate r_u, r_s, and r_cs, respectively. In addition, U_i, S_j, and CS obtain (r_s⊕r_cs), (r_u⊕r_cs), and (r_u, r_s) from D₁₃, D₉, and (D₁, D₄), respectively. Therefore, all entities can compute one same session key SK = SK_cs = SK_s = SK_u = (r_u⊕r_s⊕r_cs) in one session.

4.3. User Anonymity

The attacker’s use of user anonymity means that the user U_i cannot be identified through the messages in the communication session [43]. In our authentication phase, U_i’s identity ID_i is protected by a hash function D₂ = h(r_u||PID_i||ID_cs)⊕ID_i. Therefore, if an attacker wants to obtain U_i’s identity, he/she must compute h(r_u||PID_i||ID_cs). However, he/she cannot acquire the r_u because he/she does not have the secret key x of CS to derive r_u from D₁ = A_i⊕r_u, where A_i = h(PSID_j||ID_cs||x). Even if the attacker is a legal user, he/she still cannot obtain h(r_u||PID_i||ID_cs) by adopting the strategy shown in Section 2.2.2. Therefore, the attacker cannot identify U_i’s identity; furthermore, it shows that our proposed scheme has user anonymity.

4.4. Resistance to Off-Line Guessing Attack

Off-line guesswork attacks happen when an attacker obtains all the information stolen from the user, pass through insecure channels, and store in smart CARDS. The attacker can use the information held to guess the user’s identity and password.

We assume that an attacker gets (C₁, C₂, C₃, C₄, PID_i, ID_cs) that is stored in the user U_i’s smart card and all messages (M₁, M₂, M₃, M₄) that pass by a nonsecure channel in the last session. Then, the attacker wants to guess a pair (ID_i, PW_i) from information. He/she can use the equation D₂ = h(r_u||PID_i||ID_cs)⊕ID_i to confirm her/his guess ID_i. According to the above hypothesis, the attacker has PID_i and D₂ from M₂; ID_cs is from the smart card. Therefore, he/she needs to get r_u. Then, r_u can be derived by rearranging D₁ = A_i⊕r_u to r_u = A_i⊕D₁. However, the attacker cannot compute A_i = h(PSID_j||ID_cs||x) without the secret key x of CS. Therefore, he/she cannot successfully guess ID_i. In addition, PW_i only appears on C₂ = h(ID_i||x)⊕h(PW_i||n_i), C₃ = n_i⊕h(ID_i||PW_i), and C₄ = h(ID_i||PW_i||n_i). If the attacker wants to guess it, he/she needs to obtain ID_i, x or n_i first. However, the attacker cannot extract those values from intercepted messages. Therefore, he/she cannot successfully guess PW_i. The results show that the scheme can resist offline guessing attack.

4.5. Resistance to Insider Attack

An insider attack means that an attacker is an inside member of the company of CS. He has the right to access the data stored in the CS’s database, e.g., the registered users’ identities and passwords. Then, he/she can use the information to simulate a legitimate user or cloud server. In our proposed scheme, only ID_i and SID_j are stored in CS for registration. There is no any other information for authentication stored in CS, i.e., A_i, B_i, A_j, B_j. Therefore, even if the inside attacker accesses the database of CS, he/she only can obtain the identity ID_i of U_i and SID_j of S_j; besides, the inside attacker still cannot impersonate the user U_i or the cloud server S_j. Thus, the scheme is able to resist internal attack.

4.6. Resistance to Stolen Smart Card Attack

Stolen card attack points to an attacker who steals the user’s smart card and extracts data stored in a smart card. Then, he/she uses these data to impersonate the user whose smart card was stolen. Here, we assume that an attacker already extracts the data (C₁, C₂, C₃, C₄, PID_i, ID_cs) from user U_i’s smart card. In our proposed scheme, if the attacker wants to impersonate user U_i, he/she needs to perform the authentication phase. According to the description of Step 1 in Section 3.2., the attacker needs to key in the correct ID_i and PW_i for checking the equation h(ID_i||PW_i||n_i)? = C₄. However, he/she does not have ID_i and PW_i. Therefore, when the attacker initiates an authentication run, he/she cannot pass the check h(ID_i||PW_i||n_i)? = C₄ in this step, then his/her authentication process will be terminated. The results show that the scheme can resist the attack of stolen smart cards.

4.7. Resistance to De-Synchronization Attack

An anti-synchronization attack means that an attacker interrupts and modifies the response message from the control server during the authentication phase, so that the authentication data between the client and the database of the control server are not synchronized [44]. Then, even if he/she is a legitimate user passing through the controlled server, all future authentication processes will fail.

In our proposed scheme, only users’ identities are stored in the control server’s database. In addition, those identities will not be changed in any phases, i.e., the authentication and password change phases. For the user, data changes occurred in the authentication stage and the last step of the password change phase. However, password change only needs to be involved on the user side; thus, the attacker cannot interfere. In the last step of the authentication phase, the data in the user’s smart card will be updated (C₁, PID_i) to ($C_1^{\prime }$, $PI{D}_i^{\prime }$) when authentication processes are successfully finished. If the update was interrupted, the user can still use the old data (C₁, PID_i) to run a successful authentication process. It can be concluded that the scheme can resist synchronous attack.

4.8. Resistance to Forgery Attack

Counterfeit attack points to the attacker in the session is sent to the user, the cloud server and control server message, then the receiver will believe these messages are sent from a legal user, a cloud server, or the control server.

In our scenario, if an attacker wants to forge a user Ui, he/she would need to forge a message M1 to pass the equation D3? = h(IDi‖PIDi‖ru). However, the attacker cannot forge D₁ = A_i⊕r_u because A_i = h(PID_i||ID_cs||x) contains the secret key x of a control server. If the attacker wants to forge a cloud server, he/she needs to fabricate two messages, M₂ and M₄. To pass the equation D₇? = h(SID_j‖PSID_j‖PSID_j^’‖r_s‖D₆) and D₁₄? = h(SK_u‖D₁₂‖D₁₃‖B_i); however, he/she cannot forge D₄ = A_j⊕r_s, D₆ = B_j⊕ $PSI{D}_j^{\prime }$⊕h(r_s||PSID_j) and D₁₄ = h(SK_cs||D₁₂||D₁₃||h(ID_i||x)) because A_j and B_j both contain the secret key x of control server. If the attacker wants to forge the control server, he/she needs to make up a message M₃ to pass the equation D₁₀? = h(SK_s‖D₈‖D₉‖B_j). However, he/she cannot forge D₈ = h( $PSI{D}_j^{\prime }$||ID_cs||x)⊕h(r_s|| $PSI{D}_j^{\prime }$) and D₁₀ = h(SK_cs||D₈||D₉||h(SID_j||x)) because those messages contain the secret key x of the control server. As a result, we provide a solution to staying away from forgery attacks.

4.9. Resistance to User Tracking Attack

In terms of user tracking attacks, when an attacker eavesdrops on the delivered messages in different sessions, and then the attacker can confirm that two messages are from a fixed user according to a stable pseudo-identity being used. In our proposed scenario, the user Ui’s pseudo-identity would change in different sessions. Therefore, the attacker cannot ensure that any two messages are from the same user. The results show that the scheme can resist the user tracking attack.

5. Performance Evaluation

In this section, we will present the schemes of Maitra et al. [45], Amin et al. [36], Zhou et al. [42], and the performance evaluation of our schemes. Four authentication schemes only use a one-way hash operation, exclusive or operation, and concatenate operation. By comparing the execution time of an exclusive or operation to that of a one-way hash function or a symmetric algorithm, we ignored the execution time of an exclusive or operation., We chose SHA-2(256 bits) and AES as one-way hash functions and symmetric encryption/decryption algorithms, two of which are the most commonly used encryption methods in secure communications.

Table 1. Comparison of Security Properties among Four Authentication Schemes.

Property	R1	R2	R3	R4	R5	R6	R7	R8	R9
Amin et al.’s scheme [36]	O	O	O	X	O	O	O	O	X
Maitra et al.’s scheme [45]	O	X	O	X	O	O	O	O	X
Zhou et al.’s [42]	X	O	X	O	O	O	O	O	O
Ours	O	O	O	O	O	O	O	O	O

R1: Mutual authentication. R2: Session key for all entities. R3: User anonymity. R4: Resistance to off-line guessing attack. R5: Resistance to insider attack. R6: Resistance to stolen smart card attack. R7: Resistance to de-synchronization attack. R8: Resistance to forgery attack. R9: Resistance to user tracking attack.

,

Table 2. Calculation cost comparison of four certification schemes.

	Entities	Registration Phase	Login Phase	Authentication Phase	Password Change Phase	Total Operations of Login and Authentication
Amin et al.’s scheme [36]	Ui	2 Th	6 Th	3 Th	7 Th	23 Th
	Sj	0 Th	0 Th	4 Th	0 Th
	CS	4 Th	0 Th	10 Th	0 Th
Maitra et al.’s scheme [45]	Ui	3 Th	6 Th	4 Th	9 Th	19 Th + 6 Ts
	Sj	0 Th	0 Th + 1 Ts	4 Th + 2 Ts	0 Th
	CS	3 Th + 1 Ts	0 Th	5 Th + 3 Ts	2 Th + 2 Ts
Zhou et al.’s [42]	Ui	3 Th	0 Th	10 Th	11 Th	36 Th
	Sj	0 Th	0 Th	7 Th	0 Th
	CS	4 Th	0 Th	19 Th	8 Th
Ours	Ui	4 Th	0 Th	12 Th	6 Th	39 Th
	Sj	0 Th	0 Th	8 Th	0 Th
	CS	4 Th	0 Th	19 Th	0 Th

and

Table 3. Communication cost comparison of four authentication schemes.

Schemes	Communication Cost of L and A
Amin et al.’s scheme [36]	4736 bits
Maitra et al.’s scheme [45]	3072 bits
Zhou et al.’s [42]	5760 bits
Ours	6016 bits

show a comparison of the security properties, computation cost, and communication cost among four respective authentication schemes. In Table 1, “O” means that the scheme can achieve a security requirement or resist the attack; “X” means that the scheme cannot achieve a security requirement or resist the attack. In Table 2, “T_h” is one computation time of one-way hash function operation, and “T_s” is one computation time of symmetric encryption/decryption. The “T_h” and “T_s” s’ values are 0.00517 ms and 0.02148 ms, respectively according to Zhou et al. [42].

Table 2 shows that our proposed scheme is in the middle regarding calculating costs. However, it is important to consider the trade-off between security and efficiency when we were designing a secure communication scheme. As can be seen from Table 1, the scheme proposed by us has better security than other schemes. We also assessed the communication costs of our scheme and other schemes, as shown in Table 3. The communication costs are the bits of parameters which passed during authentication. The Figure 5 shows the bar chart of the comparison of total calculation cost. Our scheme gets more cost than Zhou et al.’s [42] because we add an additional step at the last of the authentication phase to achieve mutual authentication. We only calculate the communication cost in the login and authentication phases due to the use of fewer number of times in the registration phase and password change phase. Therefore, in terms of security and efficiency, we can argue that our proposed scheme is more suitable for the Internet of Things environment than other related schemes.

Note that the outputs of the one-way hash function and the AES algorithm are 256 bits, and identities, pseudo-identities, and random numbers are 128 bits.

6. Conclusions

In this paper, we demonstrated that Zhou et al.’s scheme is not fully secure. Mutual authentication and anonymity cannot be guaranteed in the authentication phase. Then, we designed a new certification scheme to compensate for Zhou et al.’s scheme. The proposed scheme can resist common attacks and provide important features such as user anonymity and mutual authentication. We also added a new parameter in the first step of the authentication phase; moreover, it can detect whether or not the input identity and password are right at an early stage. Improved IoT-based authentication for cloud computing is also proposed, and the performance evaluation results show that the scheme has acceptable computation and good security. Therefore, we believe that this authentication scheme is applicable to real-world IoT devices.

In the future, we will investigate how to apply our IoT-based authentication mechanism in different computing environments, such as mobile environment and grid computing environment, etc. Furthermore, we are investigating how to make our system lightweight so that it can be widely used in the mobile computing world.