An efficient authentication and key agreement protocol for IoT-enabled devices in distributed cloud computing architecture

With the widespread use of Internet of Things and cloud computing in smart cities, various security and privacy challenges may be encountered.The most basic problem is authentication between each application, such as participating users, IoT devices, distributed servers, authentication centers, etc. In 2020, Kang et al. improved an authentication protocol for IoT-Enabled devices in a distributed cloud computing environment and its main purpose was in order to prevent counterfeiting attacks in Amin et al.’ protocol, which was published in 2018. However, We found that the Kang et al.’s protocol still has a fatal vulnerability, that is, it is attacked by offline password guessing, and malicious users can easily obtain the master key of the control server. In this article, we extend their work to design a lightweight pseudonym identity based authentication and key agreement protocol using smart card. For illustrating the security of our protocol, we used the security protocol analysis tools of AVISPA and Scyther to prove that the protocol can defend against various existing attacks. We will further analyze the interaction between participants authentication path to ensure security protection from simulated attacks detailedly. In addition, based on the comparison of security functions and computing performance, our protocol is superior to the other two related protocols. As a result, the enhanced protocol will be efficient and secure in distributed cloud computing architecture for smart city.


Introduction
In recent years, Internet of things (IoT) devices, such as sensor devices, RFID tags, actuators and smart objects, has become one of the most popular applications in emerging smart cities.The main functions of IoT-enable devices are interconnected and interlinked in a heterogeneous wireless environment, in which the devices can continuously monitor and analyze sensor data from multifarious applications to achieve real-time automation of smart decision-making processes in smart city.However, as we all know, IoT devices are resource-constrained and data-intensive.Thus, there should be a standard platform that can handle efficiently large amount of heterogeneity data and devices, as the data and devices are growing exponentially [1].To process such a large database repository generated from various IoT devices, Cloud Computing has emerged as a key technology [2][3][4].In current days, there are several types of cloud services provided by the cloud provider such as Software as a Service (SaaS) cloud (Ex.IBM LotusLive), Platform as a Service (PaaS) (Ex.Google AppEngine) and Infrastructure as a Service (IaaS) (Ex.Amazon Web

Internet
Figure 1 IoT-enabled distributed cloud architecture in smart city.
Services) [13].However, there is a basic problem that how the private distributed cloud server authenticates the connected IoT devices.For example, the private information from IoT devices is stored in distributed private cloud server, so that only legitimate users are allowed to access the sensitive information.Recently, many authentication protocols integrated with IoT and distributed cloud computing have been proposed for secure access control on large-scale IoT networks [9][10][11][12][13][14][15][16][17].In 2018, Amin et al. [13] proposed an authentication protocol for IoT-enabled devices in distributed cloud computing environment, which showed many security vulnerabilities of two authentication protocols proposed by Xue et al. [11] and Chuang et al. [12].However, Kang et al. [14] find that Amin et al.'s [13] protocol is vulnerable to counterfeit attack and improved the protocol.Unfortunately, by studying a large number of authentication protocols,we further discover that Kang et al.'s [14] protocol contains an off-line password guessing attack, which an malicious user can easily get the secret number of the master control server.This is a fatal vulnerability to the entire system.Thus, we extend upon their work to design a lightweight dynamic pseudonym identity based authentication and key agreement protocol using smart-card, which is efficient and secure in distributed cloud architecture for smart city with provably.
In this paper, we give a scenario: Assumed a cloud computing service provider has built a distributed private cloud environment covering the entire smart city.There are many IoT devices that should interconnected to each other via the nearest private cloud service which records confidential information.Then, the distributed cloud service can realize high-speed computing and real-time communication with each IoT-enable device to provide high-quality services.This scenario involves three main entities: the cloud computing provider, which is regarded as the server control CS, a single distributed private cloud server namely S m and each IoT-enabled device, which belong to the user U i in smart city.We briefly describe this scenario as shown in Fig. 1.
The rest of paper is organized as follows.In Section 2, we review the Kang et al.'s protocol and point out the security weaknesses in details.The enhanced protocol is proposed in Section 3. Security cryptanalysis and comparisons are given in Section 4. Finally, the article is concluded in Section 5.

Kang et al.'s protocol and its weaknesses
In this section, we give the overview of Kang et al.'s [14] protocol and some security drawbacks of their protocl are described carefully.In Kang et al.'s protocol, there are 3 participants: an ordinary user U i , mth cloud providing servers S m , and the control server (CS ).The server CS is a trusted third party responsible for registration and authentication of users and cloud servers.The notations used in this article are showed in Table 1.In the phase of user registration, the user U i computes A i = P i ⊕ h (B i ) , where B i is the biometric of U i , and sends ID i , A i to the CS securely.On getting it, CS chooses a random number b i and calculates the following operations:

Login phase
When wanting to access the information of the cloud server S m , U i provides ID * i , P * i and B * i to a card reader (CR).Then, CR calculates produces a random number N i and current timestamp T S i to compute the following operations: After that, CR submits the login message G i , F i , Z i , O i , P ID i , T S i to the cloud server S m over an public channel.

Authentication key agreement phase
This phase describes mutual authentication and key agreement among the participants, which can be divided into four steps as follows.
Step 1: When receiving the login message from U i , S m first checks the time interval condition T S m −T S i <?∆T , where T S m is S m 's current timestamp and ∆T is expected time interval during message transmission.If T S m −T S i ≥ ∆T , S m terminates the connection; otherwise, S m takes a random number N m to calculate Then, CS checks the condition G * i =?G i .If G * i = G i , CS thinks that the user U i is legal; otherwise, it terminates the session.After that, CS calculates for authenticating the cloud server S m .If K * i = K i , CS thinks the cloud server S m is illegal and terminates the session; otherwise, CS randomly selects a number N CS and computes where K CS is the secret session key between U i and S m .Finally, CS sends P CS , Q CS , R CS , V CS to S m through public communication.
Step 3: When obtaining the message from CS, S m calculates Next, S m checks whether Step 4: On receiving the reply message from S m , U i computes Then, the U i checks the condition Q * CS =?Q CS .If the condition is true, U i confirms CS and S m are authentic.

Cryptanalysis of Kang et al.'s protocol
In this section, we make cryptanalysis of the protocol proposed by Kang et al. [14] in details.For analysis, there are some valid assumptions can been found in [5][6][7][8].

Off-line password guessing attack
The authors in [14] stated that their protocol is protected against off-line password guessing attack.However, we discover that a malicious attacker can obtains the master secret key of CS after launching the above attack.The details are described as below: Step Go to 1 until correct key is obtained; Although the algorithm may take a long time to execute, Eve will be willing to keep trying because the control server CS uses the key x for authenticate all the user U i , which is crucial parameter to the whole system.Thus, the protocol proposed by Kang et al.'s is vulnerable to the above attack.

Design redundant in the user registration phase
In order to avoid the impersonation attack in Amin er al.'s [13] protocol, the authors compute BS m = h (P SID m SID m y), which indicates the identity SID m and pseudoidentity P SID m of S m are bundled up with the secret key y of CS by hash function.As proved in the section of security analysis in [14], this technique can be effective against the cloud server impersonation attack.Similarly, the authors claim that the operation ∆ i = h (P ID i ID i x) is aslo used to avoid that the user cheats CS with a false identity.Unfortunately, we further research discover that this design is redundant in the user registration phase.
AS described in [11], the authentication scheme using smart card is mainly to resolve the problem, which the remote servers must store a verification table containing user identities and passwords.In the login phase of Kang et al.'s [14] protocol, only legal U i with the real identity ID i , password P i and biometric B i can access the card reader.Moreover, the operation P ID i = h (ID i b i ) makes clear that pseudoidentity P ID i is also bound to the real identity ID i by hash function during the subsequent login phase, and the value b i is protected in the smart card.So, if U i can login into the card reader, the control server CS can authenticate U i .That's why the smart card is used in this authentication protocol.Therefore, the operation ∆ i = h (P ID i ID i x) is designed redundant in Amin et al.'s protocol.The detailed description will be presented in the section 4.2.

Inconvenient for password change
Generally, it is essential to update password for the legal U i .However, for the sake of brevity, the password change phase is not introduced in [14].Furthermore, we further discover that even if this phase is designed according to the Kang et al.'s protocol [14], U i has to re-register to the control server CS via a secure channel.CS should deliver a new smartcard for the U i or requires the U i to mail the original smart card for replacement.Our following description will demonstrate that an existing U i could not change password with his/her smart card locally.Assumed that, U i can renew password with smart card during the login phase.Then the following these steps will be performed: Step 1: After punching the smart card, U i provides ID * i , P * i and B * i to the card reader(CR).
Step 2: CR computes Step 3: U i enters a new password P new i to CR.
Step 4: When U i logins to the card reader normally, CR executes the following operations according to the login phase of Kang et al's protocol: , where b i is produced by CS ; so P ID new i = P ID i , where P ID i = h (ID i b i ).What's more, since ∆ i = h (P ID i ID i x), the value ∆ i is also change.If U i does not register again for substituting the recorded values C i , Ω i , ∆ i , E i , h (•) in the smart card, CS could not authenticate U i in the subsequent communication phase.Therefore, it is inconvenient for password change in Kang et al.'s improved protocol.

Our Protocol
This section introduces an enhanced authentication and key agreement protocol for the IoT-enabled devices in distributed cloud computing environment, as figure 1 is showing in smart city.The current scenario involves 3 main entities: the server control CS, the cloud server S m and each IoT-enabled device, which belong to the user U i .There are 5 phases in our enhanced protocol: (1) Registration phase, (2) login phase, (3) authentication and key agreement phase, (4) password change phase, (5) Identity update phase.The detailed implementation of the first three phases is showed in Fig. 3.

Registration phase
Firstly, the control server CS randomly produces two high-entropy mumbers x and y, which x is used as the secret key only known to CS for authenticate all U i and y is used as another secret key only known to CS for authenticate all S m , respectively.Then, any cloud server and user can register with CS.In addition, the secure channel referred to in this phase can be the Internet Key Exchange Protocol version 2(IKEv2) [17] or Secure Socket Layer Protocol (SSL) [18].

Cloud server registration phase
During the cloud server registration, S m sends the message SID m , d to CS, where SID m is its identity and d is a random number.On receiving the message, CS calculates P SID m = h (SID m d), BS m = h (P SID m SID m y) and sends BS m back to S m via a secure channel.Finally, S m stores secret parameter BS m , d into the memory.

User registration phase
When a user U i wishes to register with CS, U i selects desired identity ID i and password P i to enter his/her IoT-enabled device such as a card reader.Then, the device collects U i 's biometric B i and generates a random number b to compute CS in a secure channel.After receiving the message, CS verifies the authenticity of the user's identity Then, CS writes the data C i , E i , h (•) to a smart card and delivers it to U i through private communication.When obtains the smart card, U i inserts it to IoT-enabled device and inputs ID i and P i to the device again.Then, the device writes Ω i to the smart card.Finally, the smart card records the informations

Login phase
If U i wants to get information from the private cloud server S m , U i inserts the smart cart into the IoT-enabled device and provides ID * i ,P * i and and B * i .The device computes the device authenticates the real U i ; otherwise, it rejects this login of U i .Next, the device generates an at least 128 bits random number N i and executes the follow operations: where T S i is the current timestamp of the device, SID m is the private server S m 's identity.After that, the device transmits G i , F i , Z i , P ID i , T S i to S m via a public channel.

Authentication and key agreement phase
In this phase, the mutual authentication and key agreement among three parties is mainly achieved through four-way handshake.In the first handshake, after receiving U i 's login message, S m calculates its own verification condition to append with the login message and sends them to CS.In the second handshake, on receiving the message from S m , CS verifies the legitimacy of U i and S m .If they are legit, S m produces itself authentication conditions for U i and S m respectively, and sends the conditions to S m .In the third handshake, S m selects verification conditions related to itself to verify CS and sends the remaining message to U i .In the fourth handshake, U i verifies the legitimacy of CS.If any party fails to pass the authentication, the session will be ended in this phase.As a result, the entire authentication path In the meantime, a shared secret key SK is negotiated to encrypt the subsequent communication traffic between U i and S m .The detailed description is as follows: Step 1: On receiving the login message, S m first checks the condition whether T S m − T S i <?∆T holds or not, If T S m − T S i < ∆T , S m terminates the connection; otherwise, S m produce a 128 bits random number N m and calculates Step 2: After getting the message, CS also checks authenticates the U i is legal; otherwise, CS terminates the session.After that, CS calculates CS thinks S m is illegal and terminates the session; otherwise, CS randomly selects a 128 bits number N CS and computes where, SK CS is the secret session key which can encrypt the following communicate message between U i and S m .Finally, CS sends P CS , Q CS , R CS , V CS to S m through public channel.Step 3: When obtaining the messge from CS, the S m calculates Next, S m checks whether V * CS =?V CS or not.If V * CS = V CS , S m authenticates CS and sends P CS , Q CS to U i .
Step 4: On receiving the reply message from S m , U i computes CS and S m are authentic.At last, the 3 participants of U i , S m and CS negotiate a shared secret key

Password change phase
This phase is invoked whenever U i wants to update his/her password without communicate with the control server CS.After inserting the smart card into the IoT-enabled device, U i enters ID * i ,P * i and and B * i .Then, the device executes in the smart card respectively.So, it is very convenient and fast for U i to update password using smart card locally in our protocol.

Identity update phase
It is practical that a legal U i updates his identity ID i , such as the identity has expired.However,because the control server CS need to verify the authenticity of the user's ID i , U i should re-register to CS through the secure channel in this pase.

Security analysis and comparisons
In this section, we makes discussion on security analysis of our protocol.Firstly, we use the security protocol analysis tools of AVISPA(Automated Validation of Infinite-State Systems) and Scyther to prove the protocol can defend the various existing attacks.Then, we detailedly analyze the authentication paths among the three participators to ensure security protection from the most common vulnerabilities of impersonation attack.Finally, the performance comparisons of our protocol with others are described briefly.

Simulation of our protocol using security protocol analysis tools
This section presents simulation of our protocol using security protocol analysis tools of AVISPA and Scyther, both of which are a complete and standard formal automatic analysis tools.The detailed instructions of AVISPA can refer to [32][33][34][35] and Scyther to [36][37][38].

Simulation code description
The first step in the use of simulation tools is to describe the target protocol in a formal language.This section introduces the AVISPA tool formal language HLPSL(High Level Protocol Specification Language) and the Scyther tool formal language SPDL(Security Protocol Description Language) to formally simulate our agreement.
(1)The HLPSL simulation code of our protocol: In the HLPSL modeling of the our protocol, we regard the registration phase as the negotiation process of symmetric secret key encryption between the two parties.What means, the value BS m = h (P SID m SID m y) is regarded as the symmetric secret key between S m and CS in the cloud server registration phase; the smart card delivered by the control server in the user registration phase is regarded as the symmetric secret key between U i and CS.The HLPSL simulation code of our protocol involves 5 roles: "role user" simulates real user U i ; "role server" simulates the cloude server S m ; "role concrolserver" simulates the server control CS ; "role session" represent the role of the four interactive handshake; "role environment" represent high-level corner with intruder; "role goal" represents the purpose of simulation.Below we only briefly introduce the part HLPSL description of user roles, environmental roles and security goals, as showing in Fig. 4.
In Fig. 4 of (a), the user role process describes the parameters, initial states and transition that using at the beginning.The "transition" represents the acceptance of information and the sending of response information."Channel (dy)" means that the attack mode is the Dolev-Yao attack model [30], in which the attacker can control of the network of the protocol.For example, an attacker can intercept, steal, modify, and replay the information transmitted on the channel in the protocol and even pretends to be a legal role in the protocol to perform operations to initiate an attack.
The Fig. 4 of (b) presents the role environment and the security goals.The highlevel role process includes global constants and a mixed role process of one or more sessions.Among them, the intruder may pretend to be a legitimate user and run certain role processes.There are also some sentences that describe the knowledge known to the intruder in initial state, generally including the name of the agent, all the keys shared by other agents, and all known functions.For the HLPSL modeling of security goals, we only give the confidentiality goal of HLPSL supporting one of the two goals of confidentiality and authentication.For confidentiality, the target instance indicates which values are kept secret among the declared roles.If it cannot be achieved, it means that the intruder has obtained a confidential value and can successfully attack the protocol.For authentication, the main purpose is to verify identity masquerading attacks.Although Amin et.al [13] claimed that their protocol can reach the three authentication security goals (the authentication on alice server ni, the authentication on server aserver ncs, the authentication on aserver alice nm) [13], kang et al. [14] pointed out the server cannot guarantee the cloude server chosen by the user, which is vulnerable to counterfeit attack.We will specifically demonstrate how our protocol resist this common attack in section 4.2.
(2)The SPDL simulation code of our protocol: It is similar to HLPSL that the SPDL simulation code of our protocol includes 3 roles: "role U" simulates real user U i ; "role S" simulates the cloude server S m ; "role CS" simulates the server control CS.Here, we take the control server CS role as an example to introduce the SPDL code, which is presented in Fig. 5.After defining the variables required for session protocol, the full implementation of our protocol is represented by the collection of events that occur in CS.The "send" and "recv" events indicate that CS sends a message and receives one respectively.One of the advantages of the Scyther tool is that it flexibly describe target attributes, whether it is the confidentiality of a variable or the authentication of a certain subject to another subject.The Scyther tool can analyze and verify the security attributes that users are interested in.The description of the target attribute is completed through the "claim" event, which can be used to describe the authentication of roles and the confidentiality of variables.

Simulation results
This section presents the simulation results of our protocol using two formal analysis tools.We personally build the AVISPA (Version of 2006/02/13) and Scyther(v1.1.3) in a virtual machine of an ubuntu operating system.The Fig. 6 presents the results of all the four back-end analysis tools provided by AVISPA to simulate the proposed protocols for all entities.The test results of OFMC, CL-AtSe, and SATMC modules show that our protocol is safe (SUMMARY SAFE), which means it can achieve the expected security goals; the TA4SP verification model represents INCONCLUSIVE, as the current TA4SP module does not support one-way hash function and the result of No ATTACK TRACE can be provided with the current version.When using the Scyter tool to simulate the protocol, we also use the Dolev-Yao attack model and the minimum number of execution rounds in the analysis parameters is set to 3. The simulation results of the Scyther tool is present in Fig. 7.The Fig. 7. of (a) shows the attack path of the Scyther tool's formal analysis under the Dolev-Yao model for our protocol.The reachability analysis report of our protocol messages is presented Fig. 7. of (b).The test results show that our proposed protocol does not have any threat of attack under this model.Therefore, we can assert that our protocol can resist the various attacks, such as repaly attack, weak password guessing attack, man-in-the-middle attack, session key discloser attack and so on.

Security analysis
In the following, we mainly use cryptography knowledge to analyze in detail the authentication paths among U i , S m , and CS in our proposed, so as to protecting against the most common attacks of impersonation attack.
(1)Mutual authentication between S m and CS : In the cloud server registration phase, S m negotiates with CS to produce a value BS m = h (P SID m SID m y), which can be regarded as the symmetric secret key for S m and CS, since the value BS m only can be calculate by S m and CS.Therefore, S m and CS can achieve mutual authentication through the symmetric secret key BS m in the authentication phase, such as Kerberos protocol authentication.Moreover, since the identity SID m and pseudoidentity P SID m of S m all bind up with the secret number y of the control server CS, CS will authenticate both identities of S m .Thus, our protocol can realize mutual authentication between S m and CS in the authentication phase.Based on [13], we mark it with the following symbols: In the authentication phase: (2)Mutual authentication between U i and CS : As discussed in Chapter 2.2.2, in order to avoid recording the U i 's identity and password information on the control serverCS, CS distributes a smart card to U i during the registration phase.The smart card records the values C i , E i , h (•) in our protocol.
Firstly, as the only U i that knows ID i ,B i and P i can computes C i = h (ID i A i ), and A i = P i ⊕h (B i ) for logging into the IoT-enabled device, the value C i recording in the smart card is mainly used to verify U i .So, we mark it with the following symbols: In the user logined phase: The above symbol means that: with the help of value C i recording in the smart card, IoT-enabled device can authenticate U i .On the other hand, the user trusts the IoT-enabled device obviously.Secondly, when U i logins into the device, the device will computeb = Ω i ⊕ A i ,P The value E i recording in the smart card can be regarded as an intermediate data in the process of authentication between the IoT-enabled device and CS.On the one hand, only the IoT-enabled device can compute D i = E i ⊕ A i with the dataE i , if U i logined into the device with B i and P i .On the other hand, only CS that knows x and P ID i can compute D i = h (P ID i x), then computes A i = D i ⊕ E i with the data E i .Thus, IoTenabled device and CS can realize mutual authentication in the help of the smart card in the user login phase.So, we mark it with the following symbols: During the user login phase: IoT-enabled device Thirdly, as U i logined into the IoT-enabled device, the device can compute D i with the value E i .Then, the value D i can be the symmetric secret key for the IoT-enabled device and CS in the authentication, since only the IoT-enabled device and CS can calculate the value D i .Therefore, the IoT-enabled device and CS can achieve mutual authentication through the symmetric secret key D i in the authentication phase.So, we mark it with the following symbols: In the authentication phase: IoT-enabled device Based on the symbol (2), symbol (3) and symbol (4), we can deduce with the following symbol: In the authentication phase: The above symbol means that: with the help of the smart card, U i with the identity ID i can authenticate each other with CS in the authentication phase.In addtion, after receiving U i registration message, CS should verify the authenticity of U i 's identity ID i .When the identity ID i is confirmed to be legal, CS will perform subsequent operations and delivers a smart card to U i .Then, while U i logined into the IoT-enabled device, the device computes P ID i = h (ID i b i ) , which makes clear that pseudoidentity P ID i is bound with the real identity ID i by hash function, and the value b i is protected by Ω i recording in the smart card.So, the U i 's identity ID i is indirectly controlled by U i 's pseudoidentity P ID i , which is bound with the secret number x of the control server CS with operation D i = h (P ID i x).Thus, we mark it with the following symbol: In the authentication phase: (3)Mutual authentication between U i and S m : Just like the above part (2) analysis, we can mark with the following symbols in this part: In the authentication phase: Since the values N i and SID m are encrypted and transmitted by the symmetric secret key D i ,where In the authentication phase: S m (P SID m ) Since the value N m is encrypted and transmitted by the symmetric secret key BS m , where In the authentication phase: Since the value N m ⊕ N CS is encrypted and transmitted by the secret value N i and D i , where In the authentication phase:S m (P SID m ) Since the value N i ⊕ N CS is encrypted and transmitted by the secret value BS m and N m , where Therefore,we we can deduce with the following symbol: In the authentication phase: As the symbol (11) shows, our protocol realize mutual authentication between U i and S m through the mediator of CS.What's more, the 3 parties share the same session key SK = h (N m N CS N i ).As a result, we can assert that our protocol can effectively resist impersonation attacks.

Performance comparisons
In the following, we concretely compare our protocol with the other two protocols [13,14] in terms of resistance to security functionality and computational performance.In the table 2, we list the 9 general security requirements of a robust authentication protocol for IoT-enabled devices and cloud servers.The results in Table 2 show the superiorities of our protocol are User auditability, simple and secure password change, resist off-line password guessing attack, resist impersonation attack and protection of the biometric.
Moreover, the table 3 shows the number of times the hash function and XOR operation are cost in each phase of our protocol with other related protocol.From the total count in the last line, we can see that our protocol uses the hash function and XOR the least number of times.Thus, it is more suitable for the environment in which the applications are resource-constrained and data-intensive, such as IoTenabled devices in the smart city.

Concluding remarks
In this paper, we deeply researched the authentication protocols for IoT-enabled devices in distributed cloud computing environment.We discover that Kang et al.'s protocol has 3 security drawbacks, such as vulnerabled to off-line password guessing attack, designed redundant in the user registration phase and inconvenient for password change.Then, we introdced a lightweight pseudonym identity based authentication and key agreement protocol using smart card.To illustrate the security of our protocol, the security protocol analysis tools of AVISPA and Scyther is used to prove the proposed protocol can defend the various existing attacks, such as repaly attack, weak password guessing attack, man-in-the-middle attack, session key discloser attack and so on.We further analyze the authentication paths among participants in our proposed with cryptography knowledge,so as to avoid the most common attacks of impersonation attack.Moreover, we concretely compare our protocol with the other two protocols in terms of resistance to security requirements and computational performance.The both result shows that our protocl is superior to the other two related protocols.As a result, the enhanced protocol will be applicable in distributed cloud computing architecture for smart city.

Figure 2
Figure 2 Implementation of Kang et al.'s protocol.

Figure 3
Figure 3 Implementation of our protocol.
the device prompts U i for a new password P new i and generates a random number b new i ; otherwise, it rejects U i 's password change.Then, it computes the following operations

Figure 4
Figure 4 Part HLPSL simulation code of our protocol

Figure 5
Figure 5 Control server CS role in SPDL.

Figure 6 Figure 7
Figure 6 Simulation results of the AVISPA tool under the four backends analysis

Table 1
Notations used in this paper.SID m SID m d) and sends BS m to S m via a secure channel.Finally, S m stores secret parameter BS m , d into the memory.
[13]3]protocol, as their protocol only includes the three parts.To facilitate analysis, the full implementation of Kang et al.'s protocol is shown in Fig.2.2.1.1RegistrationphaseDuring server registration, the cloud server S m sends the message BS m , d to CS.After receiving it, CS computes P SID m = h (SID m d) , BS m = h (P T S m to the control server CS via an public channel.Step 2: After getting the message, CS checks time interval T S CS − T S m <?∆T , where T S CS is CS 's current timestamp.If T S CS − T S m < ∆T , CS computes 1: A attacker namely Eve first registers in the control server CS with identity ID Eve like a normal user.Next, he logins in and sends the message G Eve , F Eve , Z Eve , O Eve , P ID Eve , T S Eve to S m .Because the message is transmitted publicly, he can easily obtains the values O Eve and P ID Eve . For example, using the wireshark tool to capture the packets locally.Step 2: According to the description in the login phase, Eve computes D Eve = O Eve ⊕ ID Eve , where has been shown the "First flaw" in the Fig.2.Step 3: Since D i = h (P ID i x), the off-line password guessing attack can be implemented by Algorithm 1. Algorithm 1: Off-line Password Guessing Attack Input: input parameters D Eve , P ID Eve , h(•).Output: output x , which is the secret key only known to CS. 1 Eve generates a random number and takes it as key x tmp ; 2 Eve Computes D tmp = h (P ID Eve x tmp ); 3 if D tmp = D Eve then 4 Return (x t mp ); 5 else 6

Table 2
Security functionality comparison of our protocol with the related protocols

Table 3
Operations comparison among our scheme with other related schemes