Wireless Communications and Mobile Computing

Wireless Communications and Mobile Computing / 2018 / Article
Special Issue

Rethinking Authentication on Smart Mobile Devices

View this Special Issue

Research Article | Open Access

Volume 2018 |Article ID 3048697 | 13 pages | https://doi.org/10.1155/2018/3048697

An Enhanced User Authentication Protocol Based on Elliptic Curve Cryptosystem in Cloud Computing Environment

Academic Editor: Jian Shen
Received13 Apr 2018
Revised24 Jun 2018
Accepted12 Jul 2018
Published01 Oct 2018

Abstract

With the popularity of cloud computing, information security issues in the cloud environment are becoming more and more prominent. As the first line of defense to ensure cloud computing security, user authentication has attracted extensive attention. Though considerable efforts have been paid for a secure and practical authentication scheme in cloud computing environment, most attempts ended in failure. The design of a secure and efficient user authentication scheme for cloud computing remains a challenge on the one hand and user’s smart card or mobile devices are of limited resource; on the other hand, with the combination of cloud computing and the Internet of Things, applications in cloud environments often need to meet various security requirements and are vulnerable to more attacks. In 2018, Amin et al. proposed an enhanced user authentication scheme in cloud computing, hoping to overcome the identified security flaws of two previous schemes. However, after a scrutinization of their scheme, we revealed that it still suffers from the same attacks (such as no user anonymity, no forward secrecy, and being vulnerable to offline dictionary attack) as the two schemes they compromised. Consequently, we take the scheme of Amin et al. (2018) as a study case, we discussed the inherent reason and the corresponding solutions to authentication schemes for cloud computing environment in detail. Next, we not only proposed an enhanced secure and efficient scheme, but also explained the design rationales for a secure cloud environment protocol. Finally, we applied BAN logic and heuristic analysis to show the security of the protocol and compared our scheme with related schemes. The results manifest the superiority of our scheme.

1. Introduction

With the development of IT technology, cloud computing has become one of the hottest research directions in recent years. As a new type of service, cloud computing is rapidly integrated into our daily lives with its high scalability, high service efficiency, and low-cost charge [1]. It fundamentally changed the traditional model of service providers providing services and consumers’ access to resources: as a service provider (such as Google, Microsoft, Amazon) of cloud computing, it effectively improves the utilization of resources by centralizing the demands; consumers not only gain the convenience of using resources, but also reduce the using cost through paying on demand. Therefore, more and more big firms build their own cloud platforms and provide services, including Google App Engine, Amazon Web services, and IBM SmartCloud [2]. Furthermore, both the individuals and small companies enjoy the benefits of cloud services. Generally speaking, there are three kinds of cloud services: Iaas, Infrastructure as a Service, which means providing user with the infrastructure such as storage and networks to use; Paas, Platform as a Service, which means providing user with the platform to develop various applications; Saas, Software as a Service, which means providing user with software applications [3, 4].

However, with the increasing popularity of the cloud services, the security issues have become more prominent, how to protect user privacy and restrict data from being illegally accessed has become a challenging problem and research hotspot. The first step to solve these issues is user authentication which can verify the authenticity of communication participants. A secure user authentication scheme will firstly verify the authenticity of the user when he/she applies to access the cloud data; then to prevent a malicious cloud server trick users, the validity of the cloud server should be checked; once confirming the identity of the user and the cloud server, a session key will be established to encrypt the communication messages.

Generally speaking, there are three ways to authenticate a user, which are based on the following: what you know (such as the password); what you have (such as the smart card); who you are (such as the biometric characteristic: fingerprint and iris). Due to its simplicity and practicality, passwords have been used more widely. While a password-based authentication protocol has natural flaws, it cannot resist against offline dictionary guessing attacks. Consequently, as a factor to help enhance security, the smart card gets used [59]. A scheme combined two factors (such as the password and the smart card) is called two-factor user authentication scheme. The participants of the two-factor authentication scheme in cloud computing environment involves a user, a cloud server and a register authority. Note that among the three participants, only the register authority is trusted. At first, the user and the cloud server register to the register authority, respectively. Then the cloud server will send the user a smart card with some sensitive information and negotiate a shared secret parameter with the cloud server. Later on, when the user initiates an access request to the cloud server in login phase, the three participants will authenticate themselves to each other. If they all are authenticated, the user will be allowed to access the cloud server.

Motivations. In 2013, Yang et al. [10] devoted to design a secure authentication scheme for cloud computing environment, while their scheme is vulnerable to dictionary attack. Then Yang et al. [11] proposed a new scheme; unfortunately, Chen et al. [12] then showed this scheme is not secure to insider attack and impersonation attack and proposed a new version which once again is broken by Wang et al. [13]. Wang et al. [13] pointed out that Chen et al.’s scheme [12] is subject to offline dictionary attack and impersonation attack. Most recently, Amin et al. [3] identified the security weaknesses in the schemes of Xue et al. [14] and Chuang et al. [15] by revealing the two schemes fail to provide user anonymity and forward secrecy while being not able to resist against offline password guessing attack and so on. Therefore, they designed a new scheme that claims to overcome the security flaws of the two schemes and be secure to various attacks. However, after a scrutinization of Amin et al.’s scheme, we found their scheme still cannot overcome their identified security threats.

In these years, considerable efforts have been paid for a secure and practical authentication scheme in cloud computing environment, some typical schemes including [1619], yet most of them are found having security flaws more or less. Designing of a secure authentication scheme for cloud computing environment is still a challenge. With the widespread use of cloud computing, the potential security threats will lead to greater harm. This unsatisfactory situation motivates us to explore the inherent reasons of the failure in those schemes, find the basic method to fix the security flaws, and design a robust and efficient user authentication protocol for cloud computing environment.

Our contributions. Amin et al.’s scheme [3] is a very typical scheme which suffers from the common attacks, while the scheme’s structure is widely accepted. So we take Amin et al.’s protocol as a study case to elaborate the common issues (and its corresponding solutions) in most authentication schemes and provide rationales for designing a secure cloud environment protocol. In addition, based on the analysis, we design a secure authentication protocol. In a short, our contributions can be summarized as follows:(1)We demonstrated that Amin et al.’s scheme [3] fails to achieve user anonymity and forward secrecy while being not able to resist against offline dictionary attack.(2)We discussed the inherent reasons of the identified flaws and its corresponding solutions; furthermore, we realized the way of deploying a public key algorithm rightly is challenging. Therefore, we showed the essential points for deploying public key algorithms.(3)We improved Amin et al.’s scheme from security and effectiveness two aspects, proved the security of our scheme via BAN logic and heuristic analysis and, finally, compared our scheme with other related schemes. The results show that our scheme is more suitable for cloud computing environment.

The remainder of this paper is organized as follows: Section 2 sketches complexity assumptions and extends adversary model; then, Amin et al.’s scheme is reviewed and analyzed in Section 3; in Section 4, we propose a secure scheme and elaborate on design rationales; Section 5 proves the security of our scheme; in Section 6, we compare our scheme with other related schemes; finally, the conclusion is drawn in Section 7.

2. Preliminary

This section introduces the preliminary of the whole paper, including complexity assumptions in designing a scheme and some notations and abbreviations.

2.1. Computational Problems

Given two large primes and , let be a finite field, be an elliptic curve over , and be a -order subgroup of . For and a point in , we can define the discrete logarithm problem as follows:(1)Elliptic curve discrete logarithm (ECDL) problem: given (, ), it is impossible to compute within polynomial time.(2)Elliptic curve computational Diffie-Hellman (ECCDH) problem: given (,), it is impossible to compute within polynomial time.

2.2. Adversary Models

Understanding the adversary models is the most basic step to design and analyze a protocol. In 2015, Wang et al. [20] proposed the capabilities of adversary in distributed systems: exhaust passwords and identities; learn when evaluating security strength; control of the open communication channel; learn or extract information in the smart card; acquire previous session keys; know the long-term secret key when considering forward secrecy. As both the distributed systems and the cloud computing systems have similar network environment, their adversary models are also similar too. Therefore, we adopt Wang et al.’s adversary models [20] which have been accepted by various schemes [2123].

2.3. Notations and Abbreviations

As shown in Table 1, we summarize the notations and abbreviations used in this paper.


Symbol Description

user
cloud server
the register authority
the adversary
the long term secret key of
the secret key of
identity of
password of
identity of
shared key between and
bitwise XOR operation
concatenation operation
one-way hash function
a common channel
a secure channel

3. Cryptanalysis of Amin et al.’s Scheme

After identifying the security pitfalls in other two user authentication schemes, Amin et al. [3] attempted to design a new light weight protocol in cloud computing environment. After analyzing their scheme using AVISPA tool, they claimed the new scheme achieves forward security while being resistant to various attacks. However, this section will show that, under the assumptions on adversary capabilities in Section 2.2, their scheme cannot provide forward security while being subject to two kinds of offline dictionary attacks [27] and so on. Thus their scheme is not a truly two-factor scheme. To address these issues, this section first reviews the scheme of Amin et al. and then analyzes Amin et al.’s scheme [3].

3.1. Review of Amin et al.’s Scheme

This section briefly reviews the scheme of Amin et al. [3]; their scheme consists of five phases. As the password change phase and identity update phase have little relevance, we omit them. Furthermore, we adjust some symbols of their scheme for the ease of reading and the unity of the paper.

Registration Phase

(1) Cloud Server Registration Phase

Step 1. : .   is a random number.

Step 2. : .   computes = , = .

Step 3. keeps .

(2) User Registration Phase

Step 1. : . = , = , = where , are two random number chosen by .

Step 2. : smart card . calculates = , = , = .

Step 3. inputs into the card where = .

Login and Authentication Phase

Step 1. : . After inputs and , the card computes = , = , = , = , = . If , the card produces a random number (128 bit) and computes = , = , = , = .

Step 2. : . first checks , then selects a 128 bit random number , and computes = , = .

Step 3. : . checks and computes = , = , = , = .
If , compute = , = , .
If , compute = , = , = , = , =

Step 4. : . computes = , , = , = . If , send to .

Step 5. computes = , = , = , = . If , the whole authentication phase finishes successfully.

3.2. Cryptanalysis of Amin et al.’s Scheme

Amin et al.’s scheme [3] does not point out the adversarial model, while, according to their attack on the scheme of Xue et al. [14] and Chuang et al. [15], we can infer their adversary model which is included into our model (see Section 2.2). Although Amin et al.’s scheme [3] provides many admirable features, such as changing password locally and high efficiency, it still suffers from various attacks like most authentication protocol in cloud computing environment. Therefore, their scheme is a typical case to show the security threat in cloud environment. Through Amin et al.’s scheme, we can get insight into the inherent reasons of the failure in other authentication protocols for cloud and, based on it, learn to design a secure one. In brief, this section, on one hand, demonstrates that Amin et al.’s scheme [3] is vulnerable to various attacks and, on the other hand, indicates the failure reasons of their scheme.

Off-Line Dictionary Attack I. (i) The adversary’s capability: it obtains the message in ’s smart card.

(ii) The attack steps:the steps are as follows.

Step 1. Guess to be , to be . Note that, it is quite realistic for to obtain the password and identity simultaneously, because their spaces are limited [28].

Step 2. Compute = .

Step 3. Compute = .

Step 4. Compute = .

Step 5. Compute = .

Step 6. Compute = .

Step 7. Verify the correctness of and by checking if .

Step 8. Repeat steps until the correct values of and are found.

(iii) The time complexity: , where is the time of hash-function.

Remark. Generally speaking, achieving two-factor security is the most essential requirement of a two-factor authentication protocol; that is, any one of the factors being broken will not trigger the security of another factor, which in turn threatens the entire system. In recent years, many protocols have tried to propose a secure two-factor security protocol, but most have failed. It was not until the work of Ma et al. [29] and Wang et al. [20, 30] did such a stagnant situation completely changed. In 2012, Ma et al. [29] pointed out that public key algorithm is necessary to design a secure two-factor authentication scheme; in 2015, Wang et al. [20] found that there is a conflict between changing password locally and resisting against smart card loss attack under the current technique; therefore, Wang et al. [30] put forward a way of “honeywords”+“fuzzy-verifier” to solve the conflict; in 2016, Wang et al. [27] further pointed out that there are two offline dictionary attacks and then combined with the results of [29, 30] and matched the corresponding solutions for each attack.

In this paper, we follow the classification method of Wang et al. [27] and demonstrate that Amin et al.’s scheme [3] cannot resist against the two kinds of dictionary attack. Looking back at the above attack process, we can find that the key to the problem is that can find the verification value to check the correctness of the guessed result. According to Wang et al. [30], this issue can be settled with the integration of “fuzzy-verifier” and “honeywords”: let = mod where is a integer (). The detailed explanation on this method can be found in Section IV of [30] or Section 5.2 of this paper.

Off-Line Dictionary Attack II. (i) The adversary’s capability: it eavesdrops on one of ’s login requests and (2) obtains the message in ’s smart card.

(ii) The attack steps:the steps are as follows.

Step 1. Guess to be , to be .

Step 2. Compute = .

Step 3. Compute = .

Step 4. Compute = .

Step 5. Compute = .

Step 6. Compute = . Note that Amin et al. [3] view as a secret only known to the legitimate user. However, it not practical: at least can register as a legitimate user to get .

Step 7. Verify the correctness of and by checking if == .

Step 8. Repeat steps until the correct values of and are found.

(iii) The time complexity: .

Remark. In this attack, the pivotal parameter is . To adversary , the only challenge in computing is the value of which can be derived from , so once guesses the value of , he/she can check the correctness of them via . Now considering a situation where consists of the secret shared and an another nonpublic dynamic parameter which should not be derived from . In this situation, cannot use to check the guessed value anymore, since there is another uncertain parameter besides . Consequently, constructing such a dynamic parameter which is known to and is our critical step to address this attack. Taking into account the fact that Ma et al.’s emphasizes [29] on the necessity of lightweight public-key algorithm in designing a secure authentication protocol, we then apply a lightweight public-key algorithm to construct such a dynamic parameter. In addition, our specific ideas on solving this attack are shown in Section 4.

User anonymity: these days user anonymity has become one of the security issues that people are widely concerned about, especially in the case of cloud computing and the Internet of Things that involve massive data. The adversary can acquire people’s sensitive personal information via various ways including analyzing the session transcript in the open channel when the services are accessed [31]. Moreover, with the development of the technology, the adversary may even trace users’ movement and learn the location of their home or company, which triggers a huge potential threat [32]. Under these circumstances, user anonymity is a pivotal attribute of the authentication scheme to protect user privacy.

Generally speaking, user anonymity covers two aspects [31]: user identity protection; user untraceability. The former requires the scheme does not expose users’ identity; and the latter prevents an adversary from linking the session transcripts to a specific user or distinguishes the sessions sent by different users. This definition on user anonymity is widely applied in most authentication schemes [8, 24, 33, 34]. Unfortunately, in Amin et al.’s scheme, the parameter that identifies the user identity is a static value exposed in the insure channel, which means the adversary can trace via . Consequently, Amin et al.’s scheme cannot provide user anonymity. As we can see, one of the keys to achieve user anonymity is concealing the real identity with a dynamic parameter. The way to implement this is called dynamic-ID technique [20]. According to Wang et al.’s suggestion [31], we can employ the dynamic-ID technique to protect user anonymity via applying a lightweight public-key algorithm to the authentication schemes as described in Section 4.

Forward Secrecy. (i) The adversary’s capability: it eavesdrops on and and obtains the long-term key .

(ii) The attack steps:the steps are as follows.

Step 1. Compute = .

Step 2. Compute = .

Step 3. Compute = .

Step 4. Compute = .

Step 5. Compute = .

(iii) The time complexity:  .

Remark. In Amin et al.’ scheme [3], there are two secret keys in the register authority. We have shown that the leakage of the long-term key will lead to the exposure of previous sessions key. In the following attack, we can see that the leakage of leading to the same question too. As a result, the use of two system parameters is of little significance but consumes resource.

(i) The adversary’s capability: it eavesdrops on and and obtains the secret key .

(ii) The attack steps:the steps are as follows.

Step 1. Compute = .

Step 2. Compute = .

Step 3. Compute = .

Step 4. Compute = .

Step 5. Compute = .

(iii) The time complexity:  .

Remark. When considering the forward secrecy, the adversary almost has the same capacity with except that does not know the verifier-table. As a result, if can compute the session key according to the processes of the scheme, then is very likely to break the session key. For the above considerations, we do not recommend that have the ability to calculate session keys. To achieve this, a public-key algorithm is suggested too [29]. In addition, the more concrete improved methods will be explained in Section 4.

Other flaws: using timestamps to resist replay attack is not recommended. As we all know, due to the network congestion, network latency, or other issues, maintaining a consistent network clock between different systems is very difficult, which often results in the desynchronization attacks. As a matter of fact, many papers [20, 30] in their evaluation criteria pointed out that a protocol using timestamps cannot resist against desynchronization attacks. Furthermore, determining an appropriate value of always faces many challenges in practice: if this value is too big, a replay attack occurs; if it is too small, a valid participant may be stopped. Therefore, in protocol design, the use of random numbers is usually a more recommended way. Unfortunately, the timestamps method was applied in Amin et al.’s scheme.

Insecure identity update phase: similar to the process in “offline dictionary attack II” of Section 3.2, an adversary can carry out an offline dictionary attack via using or as the verification parameter when tries to update his/her identity.

4. The Proposed Scheme

In this section, we design a secure, simple, and efficient user authentication scheme for cloud computing environment (as shown in Figures 1 and 2) which overcomes all the flaws of Amin et al.’s scheme [3] but provides more attractive attributes, such as updating password and identity and user reregistering with same identity. As a matter of fact, we improve Amin et al.’s scheme from two aspects, efficiency and security. The designing rationales are sketched as follows.

(i) Improvements in Security. According to our discussion in Section 3.2, the public-key algorithm is indispensable to a secure two-factor user authentication scheme [20, 29, 31]. As a matter of fact, this theory has been widely accepted by massive new authentication schemes [26, 30, 35, 36], while the main difficulty lies in deploying the public key algorithm properly. Consequently, we will show the subtleties of deploying a public key algorithm in detail as follows.

Note that, as its high efficiency, the elliptic curve cryptosystem has been used widely in authentication schemes [21, 3739]. Therefore, our scheme deploys the elliptic curve algorithm to achieve our secure authentication scheme. Under this circumstance, compared with Amin et al.’s scheme [3], our scheme adds a parameter initialization process to set the parameters of elliptic curve cryptosystem.(1)Apply public-key algorithm to resist against offline dictionary guessing attack II. In Section 3.2, we have shown the pivotal point in addressing such an attack is to add a dynamic nonpublic parameter in . Here we show the ideas about the way of achieving that, to , the shared parameter between and is an outcome derived by . So any parameter based on the transform of is futile, as such an parameter is equivalent to . While, with the help of the public-key algorithm, and can share a new parameter in every session. More specifically, can choose a random number , compute = , = where = , then let be the dynamic parameter concealed in . Note that, to and , it is easy to compute , yet to , there is another uncertain parameter in , which stops carrying out the offline dictionary attack II.(2)Apply public-key algorithm to provide user anonymity. With the help of , we conceal the identity related parameter in as . Since is changed with , user anonymity is provided. Note that is the dynamic parameter we mention in “user anonymity” of Section 3.2.(3)Apply public-key algorithm to achieve forward secrecy. We set the ECCDH problem in session key to achieve forward secrecy as follows: let consist of / where / = = = , = . As a result, to the one (including ) who does not know /, computing is equivalent to solve the ECCDH problem which cannot be solve in the polynomial time. Therefore, the forward secrecy is achieved.(4)Following Wang et al.’s way [30] of resisting against offline dictionary attack I, as the detailed explanation on this method can be found in Section IV of [30], Section of [24], or Section 5.2 of this paper, we do not repeat here.

(ii) Improvements in Efficiency. Note that Amin et al.’s scheme [3] only involves some hash operation, while our scheme deploys a public-key algorithm, so the performance of our scheme is certainly not as efficient as Amin et al.’s scheme. However, except the increased cost of the public-key algorithm, we try to optimize other aspects of the performance in Amin et al.’s scheme through reducing unnecessary parameters or calculations as follows:(1)Reduce the number of random numbers selected by to one during the user registration process. In Amin et al.’ scheme, there are two random numbers in the smart card. While they actually can derive from each other, in addition, the “ability” of computing them is the same, which means they are “equivalent”. As a result, using one random number is enough, which saves the storage space and computing resources.(2)Reduce the number of secret keys in . As we see in Section 3.2, the secret key is of little effect in improving the security. Furthermore, it makes the register phase of and the authentication of more complex. Therefore, we only set one system secret parameter and simplify the register phase of . Such changes also bring other improvements on computing performance.

4.1. Registration

selects two large primes and a medium integer (). Let be a finite field, be an elliptic curve over , and be a -order subgroup of , then chooses a point in and a long-term secret key and computes its public key as . In our cloud computing environment, the cloud server and the user registration phases are conducted as follows.

For the Cloud Server

Step 1. : .

Step 2. : = .

Step 3. stores as a secret key.

For the User

Step 1. : . A new user firstly selects the password , identity , and a random number as his/her personal information and then computes the registration parameters as follows: = , = , and it initiates the registration phase via submitting the request to .

Step 2. : a smart card with . To guarantee the uniqueness of user identity, will firstly check whether the has been used via traverse . If it is available, chooses a unique random number for and computes = , = mod , = , then inputs related parameters into . Note that will record the number of login failures. Finally accepts ’s registration through issuing him/she a smart card with .

Step 3. inputs into the card where = .

4.2. Login phase

As shown in Figure 1, if the user wants to access a cloud server, will submit the information to prove his/her legitimacy in login phase. If the smart card has verified ’s legality, it initiates the access request to for . In short, our login phase involves two aspects: (1) verifying the validity of ; (2) initiating the access request.

Step 1. : login request . enters , then the smart card computes = , = , = , = , = mod . The card compares with the stored to verify the valid . If , exit the session.

Step 2. Otherwise, the card accepts ’s legitimacy and initiates an access request for : select a random number , computes = , = , = , = , = , finally transmits to .

4.3. Authentication Phase

Once getting the access request, the will do some calculation to embed its unique parameters and transmit the request to for it is unable to check the authenticity of the request. Then will check the validity of the user and the cloud server, respectively, and help them to negotiate the session key. The whole authentication steps are as follows.

Step 1. : . selects a random number , computes = , = , = , = , then it sends to .

Step 2. : . will firstly verify via computing the predefined shared parameter and potential shared secret parameters : = , = , = where is retrieved from the through , = . If ’s exceeds a predetermined secure value or the received , views as an adversary and let = (if it exceeds the preset value, will suspend the card till reregisters), then rejects the request.
Otherwise, will continue to verify the authenticity of the cloud server as follows: calculate = , = . If , exit ( thinks is not the server which actually desires to access); otherwise, continue to compute = , = . Finally, tests the authenticity of by checking whether . If they are not equal, does not pass ’s authentication, the session will be terminated.
Otherwise, authenticates and then help them to establish the session key as follows: computes = , = , then responds to .
Note that and are used to and , respectively. They are used to verify the authenticity of and then convince / that / is truly generated by /.

Step 3. : . computes = , then check whether . If the equation is not satisfied, rejects ’s request. Otherwise, believes that is a legitimate user who generates , then computes the session key as = where = . Finally, transmits to .

Step 4. On receiving this message, will firstly check the valid of via comparing with the received . If they are equal, trusts and , then he/she computes their shared session key as = (= = ), = . Till now, the authentication phase finishes successfully.

4.4. Password Change Phase

Considering the security and user friendliness, our password change phase is conducted locally, which guarantees the efficiency. In other words, the user can change his/her password freely even when he/she does not connect the Internet. All in all, our password change phase is performed as follows.

Step 1. enters , , and new password .

Step 2. The smart card verified ’s authenticity as step 1 of Section 4.2. If is authenticated, the card will carry out the password change process as step 3; otherwise, the card will reject this request.

Step 3. The smart card computes some new parameters for new password as follows: = , = , = , = mod . Note that is acquired in step 2. Finally, replace with .

4.5. Identity Update Phase

Considering the following occasions, a user sets the phone number as his/her identity, then when the phone number is changed, the user may also want to update the identity. Therefore, similar to password change, the user also needs to change the identity in practice, although it happens less often. Thus we provide the identity update phase as follows.

Step 1. enters , , and new password .

Step 2. The smart card verified ’s authenticity as step 1 of Section 4.2. If is not authenticated, the card will reject the request; otherwise the identity update process proceeds.

Step 3. As the stored in is related to , the identity update phase involves the interaction with . On this occasion, the smart card submits to for requesting update identity, where is a random number, = , = , = , = , = , = .

Step 4. shall verify the valid of as follows: compute = , = , = where is from , = . If the exceeds a predetermined value or the received , rejects the request and sets = . Once it exceeds the preset value, suspend the card.
Otherwise, updates with in and sends to where = , = , = .

Step 5. After receiving from , the smart card authenticates via testing . If the equation does not hold, exit the session; otherwise, finish the identity update process: = , = , = , = mod . Finally, replace with .

4.6. Re-Register Phase

If ’s smart card is suspended, then he/she shall reregister to :

Step 1. : .

Step 2. firstly finds in and checks whether ’s card is suspended. If so, accepts the request and performs the register phase as Section 4.1.

5. Security Analysis

In this section, we analyze the security of our scheme via two popular methods. The results demonstrate that our protocol is secure and effective for the cloud computing environment.

5.1. Formal Analysis Based on BAN Logic

In this section, we apply the BAN logic [40] which is a widely accepted way to analyze the design logic and security of the authentication scheme. Its particular notions to depict protocols are shown in Table 2.


believes , i.e., the principal believes the statement is true.

sees , i.e., the principal receives a message that contains .

has jurisdiction over , i.e., the principal can generates or computes .

said , i.e., the principal has sent a message containing .

is fresh, i.e., is sent in a message only at the current run of the protocol, it is usually a timestamp or a random number.

is the shared key for and .

is the secret known only to and or some principals trusted by them.

combined with , and usually is a secret.

encrypted with .

or : the message-meaning rule.
This rule will be used in the proving process.

: the nonce-verification rule.
This rule will be used in the proving process.

: the jurisdiction rule.
This rule will be used in the proving process.

: the freshness-conjuncatenation rule.
This rule will be used in the proving process.

In BAN logic, the goals of our authentication scheme are defined as follows:(i)Goal 1: .(ii)Goal 2: .(iii)Goal 3: .(iv)Goal 4: .

According to the proof steps in BAN logic, we redescribe our scheme into an idealized form:(i): : .(ii): : .(iii): : .(iv): : .

Then, some assumptions are defined as follows:(i): .(ii): .(iii): .(iv): .(v): .(vi): .(vii): .(viii): .(ix): .(x): .

Based on the definition above, we perform the BAN logic proof as follows:

From ( includes ), it is easy to get : .

Then according to , , , we get : .

According to and , we get : .

And according to , and , we get : .

From the Message, we also get : .

Then according to , , , we get : .

According to and , we get : .

And according to , and , we get : .

From , it is easy to get : .

Then according to , , , we get : .

According to and , we get : .

And according to , and , we get : .

From , it is easy to get : .

Then according to , , , we get : .

According to and , we get : .

And according to , and , we get : .

As = , and combining , , we get: : (Goal 1).

Similarly, as = , with , , we get : (Goal 3).

Finally, according to , , and , we get : (Goal 2).

And according to , , and , we get : (Goal 4).

In conclusion, our scheme achieves Goals 14, which promises and have got authenticated mutually and they negotiate the same session key .

5.2. Informal Analysis

Looking at the history of protocol designing, due to its simplicity and effectiveness, the heuristic method “still plays an important role” in cryptanalysis of protocols [20], though it does not have a theoretical form and relies on human experience heavily. Therefore, this section gives the security analysis via the heuristic method.

User Anonymity. As we mentioned in Section 3.2, user anonymity contains two aspects, we prove our user anonymity attribute from two points.

   has no chance to acquire