Abstract
Recently, a number of authentication protocols integrated with the Internet of Things (IoT) and cloud computing have been proposed for secure access control on large-scale IoT networks. In this paper, we carefully analyze Amin et al.’s authentication protocol for IoT-enabled devices in distributed cloud computing environment and find that Amin et al.’s protocol is vulnerable to several weaknesses. The main shortcoming of Amin et al.’s protocol is in authentication phase; a malicious cloud server can counterfeit the cloud server chosen by a user, and the control server cannot find this counterfeit. To overcome the shortcomings of Amin et al.’s protocol, we propose an improved protocol. In the registration phase of the improved protocol, the pseudoidentity and real identity of a user or a cloud server are bundled up with the control server’s secret numbers. This measure can effectively prevent impersonation attack. We also compare the improved protocol with several existing authentication protocols in security and computational efficiency.
1. Introduction
With the development of the Internet technology, people’s life and production have been greatly improved by Internet of Things (IoT) [1]. But, IoT also faces problems of efficiency due to its sensors with low memory and low power. Using powerful cloud services [2] can improve the efficiency of IoT. Now, authentication protocols integrated with the IoT and cloud computing attract people’s attention.
The first suggested authentication protocol was proposed by Lamport [3]. Then, many password-based authentication protocols were proposed [4–8]. Recently, people discuss authentication protocols for multiserver in IoT and cloud environment [9–16]. Amin et al. [13] showed security vulnerabilities of two authentication protocols in multiserver cloud environment proposed by Xue et al. [11] and Chuang and Chen [12]. Then, Amin et al. [13] proposed an authentication protocol for IoT-enabled devices in distributed cloud computing environment. They claimed that the proposed protocol is protected against all possible security threats. However, in this paper, we find that Amin et al.’s protocol is vulnerable to several weaknesses. Firstly, during the registration phase of Amin et al.’s protocol, it is unreasonable for a user to register with a pseudoidentity. Secondly, the main shortcoming of Amin et al.’s protocol is that, in its authentication and key agreement phase, although the control server can identify a cloud server is legal, the control server cannot tell if this cloud server is the one chosen by a user. So, in Amin et al.’s protocol, a malicious server can counterfeit the server chosen by a user.
On the basis of analyzing the shortcomings of Amin et al.’s protocol, we propose an improvement on Amin et al.’s protocol. In the registration phase of the improved protocol, the pseudoidentity and real identity of a user or a cloud server are bundled up with the control server’s secret numbers. This measure can effectively prevent impersonation attacks. We also compare the improved protocol with two existing protocols [11, 12] in security and computational efficiency.
The rest of the paper is organized as follows. In Section 2, we briefly review Amin et al.’s protocol and analyze its weaknesses. The improved protocol is proposed in Section 3. Security cryptanalysis and comparisons are given in Section 4. Finally, the article is concluded in Section 5.
2. Amin et al.’s Protocol and Its Weaknesses
This section briefly reviews the Amin et al.’s protocol [13] and shows its weaknesses. In Amin et al.’s protocol, there are three types of entity such as user , service provider server , and control server (CS). The CS is a trusted third party responsible for registration and authentication of users and service providing servers. The provides set of services to . The notations used in this article are recorded in Table 1.
2.1. Amin et al.’s Protocol
Amin et al.’s protocol [13] contains five phases: registration, login, authentication and key agreement, password change, and identity update. For the sake of brevity, password change and identity update phases are not revised.
2.1.1. Registration Phase
During cloud server registration, the cloud server sends to CS. After receiving it, the CS computes and and sends to securely. Finally, stores secret parameter into his memory.
During user registration, the user computes and and sends to the CS securely. On getting , the CS calculates , , and . Finally, the CS prepares and delivers a smartcard for each after recording in the smartcard and transports it to through private communication. After getting it, records in the smartcard, where . Finally, the smartcard holds .
2.1.2. Login Phase
For accessing server resources, a legal user first punches the smartcard into card reader and inputs and to the terminal. Then, the card reader calculates , , , , and . Then, the card reader checks the condition . If , it means that and . The card reader produces a random number and computes , , , and , where is the cloud server’s identity chosen by the user . Then, the CR transmits the login messages to publicly.
2.1.3. Authentication and Key Agreement Phase
This phase is necessary for performing mutual authentication as well as key agreement among , , and CS. The detail explanation of this phase is as follows: Step 1: the first checks the condition whether holds or not on receiving the login message, where and are the cloud server’s current timestamp and expected valid time interval for transmission delay, respectively. If the condition is not true, the terminates the connection; otherwise, the produces a random number and computes and . Finally, sends to the CS publicly. Step 2: on getting messages from , CS first checks the time interval, i.e., , where are the CS’s current timestamp and expected valid time interval for transmission delay, respectively. If the verification holds, CS computes , , , and . After that, the CS checks the condition . If , the CS thinks that the is legal; otherwise, the procedures are terminated. After that, the CS computes , , and . Again, the CS checks the condition . If , the CS thinks that is legal; otherwise, the procedure is terminated. After that, the CS chooses a random number and computes , , , , and , where is the secret session key. Finally, the CS sends to for achieving mutual authentication of the protocol through public communication. Step 3: on getting reply messages from CS, computes , ,, and . Then, the checks the condition or not. If , the session is terminated; otherwise, messages are sent to the publicly. Step 4: on obtaining messages from , the calculates , , , and . Then, the checks the condition , and if , it proves the authenticity of and CS. Finally, the proposed protocol achieves mutual authentication among , , and CS. Now, the and the can exchange their secret information securely using .
2.2. The Weaknesses of Amin et al.’s Protocol
This section shows that Amin et al.’s protocol [13] has some security drawbacks.
2.2.1. Weaknesses in User Registration Phase
During registration in CS, the user sends to the CS. But, and .
is just a pseudoidentity. It is unreasonable for a user to register with a pseudoidentity.
2.2.2. Weaknesses in Authentication and Key Agreement Phase
In authentication and key agreement phase, when the CS receives messages from the cloud server , although CS can know the identity of the server chosen by the user from following calculation,and verifying .
CS also can know the server with pseudoidentity , and the secret value is a legal server by following calculation:and verifying .
But, the CS cannot tell if the server with pseudoidentity and the secret value is the one the user chose with real identity .
Due to the above weaknesses, a malicious server can counterfeit the server chosen by the user, and the CS cannot see through him.
2.2.3. Puzzling Question of the User
Due to the weaknesses in Section 2.2.2, the user cannot be convinced that the session key is shared with his chosen server.
3. The Improved Protocol
To overcome the shortcomings of Amin et al.’s protocol, in this section, an improved protocol is proposed. Also, for the sake of brevity, only the registration, login, and authentication key agreement phases are described.
3.1. Registration Phase
Suppose the control server CS is a trusted third party responsible for registration and authentication of users and cloud servers. CS chooses two random secret numbers x and y.
In registration phase, any cloud server and user can register with CS. When one cloud server wants register with CS, it chooses its identity and a random number . Then, it sends to the control server CS. After CS receives , CS computesand sends to the cloud server through the secure channel. Once receives , stores secret parameters .
When one user registers with CS, chooses his identity and password . Then, calculates . Here, is his biometric. Finally, submits to the CS through the secure channel. On receiving the message, CS chooses a random number and computesand issues a smart card containing the information to the user .
3.2. Login Phase
After punching his smart card, a user provides , , and to the card reader. The card reader computes
Then, the card reader checks whether or not. When , , , and , . Then, the card reader chooses a random number and computeswhere is the identity of the cloud server chosen by the user . Then, the card reader sends the login messages to the cloud server publicly. is the ’s current timestamp.
3.3. Authentication Key Agreement Phase
This phase includes four steps. It is also illustrated in Figure 1. Step 1: once receives the login message, checks the condition whether holds or not. If the condition is true, chooses a random number and computes Then, the submits to the CS. Here, and are the cloud server’s current timestamp and expected time interval for transmission delay, respectively. Step 2: on receiving the messages from , CS first checks whether holds or not, where are the similar meanings mentioned before. If the verification holds, CS calculates Then, the CS checks whether holds or not. If , the CS believes the with real identity is legal. Then, the CS computes Then, the CS checks the condition . If , the CS believes with real is legal and chosen by the user . Then, the CS produces a random number and computes Then, the CS sends to the publicly. Step 3: on receiving the reply messages from CS, computes Then, the checks the condition . If , sends messages to the publicly. Step 4: on receiving messages from , the calculates Next, the checks whether . If , believes the authenticity of and CS and shares a session key with the cloud server .
4. Security Analysis and Comparisons
4.1. Security Analysis
This section shows that the improved protocol is well protected against relevant security threats. Firstly, like Amin et al.’s protocol [13], the improved protocol is user anonymous and protected against password guessing attack, replay attack, insider attack, and session key discloser attack. For the shortcomings of Amin et al.’s protocol, the following analysis is focused on the improved protocol against impersonation attack.
In cloud server registration phase of the improved protocol, the cloud server with identity and pseudoidentity has secret valuecomputed by the control server CS. So, in the authentication phase, if one cloud server not chosen by the user counterfeits , intercepts the login messages from and computeswhere . Then, sendsto the CS publicly. But, CS obtains the identity of the cloud server chosen by the user from and computes
Obviously, due to , then . So, cannot pass the CS’s verification.
If wants to tamper by computing , since and , also cannot pass the CS’s verification.
Therefore, the improved protocol is protected against cloud server impersonation attack.
In Amin et al.’s protocol, CS does not know the real identities of the user. But, in improved protocol, we use to show the real identities of the user. Also, is used in the improved protocol, and the user cannot pass CS’s verification if he uses false identity.
In summary, the improved protocol completely overcomes the shortcomings of Amin et al.’s protocol. In the improved protocol, neither the user nor the cloud server can launch impersonation attacks. In the improved protocol, the user and the cloud server can use the shared session key between them with trust.
4.2. Comparisons
In this section, the comparison of the improved protocol with other protocols [11,13] is shown. The comparison results of the security features and computation costs are shown, respectively, in Tables 2 and 3.
From Table 2, the improved protocol is superior to the protocols [11,13] in terms of security. Furthermore, in Table 3, the comparison of computation costs is shown between the improved protocol and the relatively good protocol [11]. From Table 3, the total computation cost of the protocol [11] is 37H + 32X, but the total computational cost of the improved scheme is 30H + 30X. The computation cost of the improved protocol is significantly less than the protocol [11].
5. Conclusion
In this paper, we find that Amin et al.’s authentication protocol is vulnerable to several weaknesses. To overcome the shortcomings of Amin et al.’s protocol, we propose an improved protocol. We also compare the improved protocol with several existing authentication protocols in security and computational efficiency. The improved protocol not only completely overcomes the shortcomings of Amin et al.’s protocol but also has less computation cost.
Data Availability
The data used to support the findings of this study are available from the corresponding author upon request.
Conflicts of Interest
The authors declare that there are no conflicts of interest regarding the publication of this paper.
Acknowledgments
This work was supported by the Applied Basic and Advanced Technology Research Programs of Tianjin (no. 15JCYBJC15900) and the National Natural Science Foundation of China (no. 61972456).