# New Authentication Scheme to Secure against the Phishing Attack in the Mobile Cloud Computing

Authors: Munivel E; Kannammal A
Journal: Security and Communication Networks
 (2019)

---

## Abstract

A phishing attack is one of the severe threats to the smartphone users. As per the recent lookout report, mobile phishing attack is increasing 85% year to year and going to become a significant threat to the smartphone users. This social engineering attack attempts to get the user’s password by disguising as trusted service provider. Most of the smartphone users are using the Internet services outside of the traditional firewall. Cloud-based documents are one of the primary targets of this phishing attack in mobile cloud computing. Also, most smartphone users are using the cloud storage in their device. To secure against this password attack in a mobile cloud environment, we propose a new authentication scheme to provide novel security to the mobile cloud services. This scheme will verify the user and service provider without transmitting the password using the Zero-knowledge proof based authentication protocol. Moreover, the proposed scheme will provide mutual authentication between the communication entities. The effectiveness of proposed scheme would be verified using protocol verification tool called Scyther.


---

## Body

## 1. Introduction

Mobile cloud is a hybrid computing technology, which combines the advantages of cloud computing and the cellular technology to develop new paradigm called mobile cloud computing (MCC) [1]. Figure 1 shows the general view of mobile cloud computing, MCC is the technology will help to exceed the hardware limitation like computation, storage, and networking in the end-user mobile devices [2–4].Figure 1
General view of mobile cloud computing.Authentication is one of the critical security challenges in mobile cloud environment. Authentication is an approach to verify the originality of user identity. In mobile cloud computing, user identity can be verified using mobile device and/or one or more other authentication approaches. In the recent scenario, maximum protocols are sharing or sending the password in the form of hash value or the encrypted form to the verifier or the authentication server [1, 5–7]. The transmitting password can get captured by the intruder. Hence, this will encourage the phishers to develop fake website or service to capture the user password.The objective of this paper is not to send the user password to the authentication server or cloud service providers during any stage of communication process. Hence, this paper aims to not allow delivering the user password out of end-user device, even to the trusted third party.


### 1.1. Related Work

Authentication is an essential security service in any system or network communications [8–10]. It is classified as user authentication, remote authentication, mutual authentication, message authentication, and implicit authentication [11, 12]. The current authentication review shows the different attributes, based on password, hash value, identity, digital signature, hierarchical model, mobile number, group key, and biometric [13].In 1981, Lamport et al. [3] proposed an authentication scheme to send the hash value of the password, instead of a real password to a remote server to verify the authentication process. In 2014, Chaurasia et al. [7] introduced an authentication as a service in cloud environment. In this method, Chaurasia et al. [7] uses two-factor authentication scheme to verify the users between different group of services. Also, the actual user identity is not sharing, instead shares the hash value of user identity between the communication entities. Recent years cloud and mobile computing gradually developed with the help of latest wireless technologies. Hence, in 2017, Roy et al. [14] proposed a new method to use mobile-based authentication in cloud computing. In this scheme, Roy et al. [14] introduced universal subscriber identity module (USIM) based identity verification method. This scheme used USIM as a primary identity to initiate the authentication process. However, when the mobile device gets stolen, authentication will get disabled, and the entire process will get revoked [10]. In 2012, Grzonkowski et al. [15] introduced improved authentication scheme based on the smart card based authentication protocol. This method entirely depends on the smart card generator (SCG). SCG working as a trusted third party and also this scheme was using the secure channel to share the session between the communication entities.In 2013, Mohil et al. [16] proposed a scheme based on PIN number and the preconfigured voice prints to verify the identity of authentication user. However, this method is proved to use more computation. Hence, it is not useful due to more computation and power usage in a mobile device.In 2015, Lin et al. [12] introduced secure method in the smart learning application in the cloud environment. This scheme registers the user with original user ID in the authentication server (AS). This scheme sends the hash value of password to the authentication server in the encrypted form. The AS decrypts and can get the hash value of the password. This scheme was secure against the man-in-the-middle attack, but not safe against the phishing attack due to password sharing between the communication entities.In 2016, Kalra et al. [17] and Huang et al. [18] proposed strong authentication based one-time password (OTP) and Message Digest value. This [17] scheme uses USIM with a secure channel to share the user identity. Hence, this scheme is not defined when the mobile device is missed or stolen. This [18] scheme uses the traditional password to verify the authentication phase, but the chance of cracking password in the server side. Hence, this is prone to phishing attack by the server side.Dynamic identity-based authentication technique is proposed by Li et al. [19] to secure the user identity. In this technique, real user identity is mapped with new dynamic identity in every communication. But, Li et al. [19] did not concentrate on the password security. Still user password is sharing as a hash value to the remote server in the registration phase. Also, in Stage II authentication, received hash value of the user is verified with the stored hash value from the remote server as Ramport et al. [3] authentication. Hence, in this scheme, the user password may prone to crack by the remote server.The new secure authentication was proposed by Zhou et al. [20] using the smart card generator. But, cloud service providers using the master key to verify the user and data owner. The initial authentication is based on validating the hash value of identity and password. This scheme is not sharing the identification of the communicating entities in all the stage of authentication. Also, the intruder may disturb the communication with fake hash value to make null every time to consume computation in a mobile device. All these findings may be prone to phishing attack along with replay attack and man-in-the-middle attack in a mobile device.To achieve mutual authentication in mobile cloud computing Grzonkowski et al. [21], He et al. [22], and Miler et al. [23] are proposed different authentication protocols in the mobile cloud service environment. According to the Miler et al. [23] scheme, the user ID is sharing using the secure channel, but the SCG generates the public key of the user and sends along with the randomly generated nonce to secure against the replay attack. However, the session key is not encrypting or not sending over a secure channel. Authentication phase not carrying the sender and receivers ID along with the session key. Hence, Miler et al. [23] scheme prone to man-in-the middle attack and phishing attack.Smart card based or the trusted third party based authentications are the most common technique to prevent illegal access in an insecure mobile cloud environment [6]. Many authentication protocols proposed [13, 18, 24–27] to verify the originality of end user. However, most of these protocols may not be satisfying the security against a phishing attack.Phishing attack is an essential problem in the current generation of mobile cloud authentication services [22]. Hence, to improve the security as noted earlier, mobile cloud authentication systems are vulnerable to various types of security attacks. Such attacks do not only affect the user’s identity, but also affect the device performance [28].In this paper, we endeavour to progress the mobile cloud computing security by introducing new authentication scheme based on Zero-knowledge proof technique.The proposed scheme is aimed to secure against the replay, man-in-the-middle, denial of service, server-side spoofing and phishing attacks, Malicious Insider, and other generic attacks in the mobile cloud environment without sharing the real username and password to the any of communication entities.


### 1.2. Our Contribution

In the paper, we present the outline of our proposed authentication protocol. To achieve the security against the phishing attack, we are not going to transfer the actual password to the authentication server or cloud service providers or any other communication entities during the registration and authentication stage. Here summarizing the significant contributions of our paper as follows.First, we review the He et al. [22] scheme in mobile cloud computing. In some cases, this scheme is compromising the phishing attack. Moreover, also we show that this scheme is not entirely satisfying the user anonymity. Hash value of the user password knew by the trusted third party or the authentication server.Second, we propose a new authentication scheme to secure against phishing attack without sharing the real username and password to the authentication server and cloud service providers. Moreover, the new scheme supports the mutual authentication with Zero-knowledge of proof.Finally, we provide detail security verification methods to prove our proposed scheme is secure and efficient and also meets the requirements of mobile cloud services.


### 1.3. Organization of the Paper

This paper is organized into six sections; the second section presents the preliminaries of proposed authentication scheme. The third section reviews the brief He et al. [22] scheme and presents its security problems. The fourth section presents the details of proposed mobile cloud authentication scheme with different phases like initial registration, user registration, and authentication phases. The fifth section presents the analysis of proposed security scheme nonformal verification. The sixth section compares with similar schemes, list the code, and display the formal verification result by the Scyther. And the last seventh section explains the performance analysis of the proposed scheme and its efficiency.


## 1.1. Related Work

Authentication is an essential security service in any system or network communications [8–10]. It is classified as user authentication, remote authentication, mutual authentication, message authentication, and implicit authentication [11, 12]. The current authentication review shows the different attributes, based on password, hash value, identity, digital signature, hierarchical model, mobile number, group key, and biometric [13].In 1981, Lamport et al. [3] proposed an authentication scheme to send the hash value of the password, instead of a real password to a remote server to verify the authentication process. In 2014, Chaurasia et al. [7] introduced an authentication as a service in cloud environment. In this method, Chaurasia et al. [7] uses two-factor authentication scheme to verify the users between different group of services. Also, the actual user identity is not sharing, instead shares the hash value of user identity between the communication entities. Recent years cloud and mobile computing gradually developed with the help of latest wireless technologies. Hence, in 2017, Roy et al. [14] proposed a new method to use mobile-based authentication in cloud computing. In this scheme, Roy et al. [14] introduced universal subscriber identity module (USIM) based identity verification method. This scheme used USIM as a primary identity to initiate the authentication process. However, when the mobile device gets stolen, authentication will get disabled, and the entire process will get revoked [10]. In 2012, Grzonkowski et al. [15] introduced improved authentication scheme based on the smart card based authentication protocol. This method entirely depends on the smart card generator (SCG). SCG working as a trusted third party and also this scheme was using the secure channel to share the session between the communication entities.In 2013, Mohil et al. [16] proposed a scheme based on PIN number and the preconfigured voice prints to verify the identity of authentication user. However, this method is proved to use more computation. Hence, it is not useful due to more computation and power usage in a mobile device.In 2015, Lin et al. [12] introduced secure method in the smart learning application in the cloud environment. This scheme registers the user with original user ID in the authentication server (AS). This scheme sends the hash value of password to the authentication server in the encrypted form. The AS decrypts and can get the hash value of the password. This scheme was secure against the man-in-the-middle attack, but not safe against the phishing attack due to password sharing between the communication entities.In 2016, Kalra et al. [17] and Huang et al. [18] proposed strong authentication based one-time password (OTP) and Message Digest value. This [17] scheme uses USIM with a secure channel to share the user identity. Hence, this scheme is not defined when the mobile device is missed or stolen. This [18] scheme uses the traditional password to verify the authentication phase, but the chance of cracking password in the server side. Hence, this is prone to phishing attack by the server side.Dynamic identity-based authentication technique is proposed by Li et al. [19] to secure the user identity. In this technique, real user identity is mapped with new dynamic identity in every communication. But, Li et al. [19] did not concentrate on the password security. Still user password is sharing as a hash value to the remote server in the registration phase. Also, in Stage II authentication, received hash value of the user is verified with the stored hash value from the remote server as Ramport et al. [3] authentication. Hence, in this scheme, the user password may prone to crack by the remote server.The new secure authentication was proposed by Zhou et al. [20] using the smart card generator. But, cloud service providers using the master key to verify the user and data owner. The initial authentication is based on validating the hash value of identity and password. This scheme is not sharing the identification of the communicating entities in all the stage of authentication. Also, the intruder may disturb the communication with fake hash value to make null every time to consume computation in a mobile device. All these findings may be prone to phishing attack along with replay attack and man-in-the-middle attack in a mobile device.To achieve mutual authentication in mobile cloud computing Grzonkowski et al. [21], He et al. [22], and Miler et al. [23] are proposed different authentication protocols in the mobile cloud service environment. According to the Miler et al. [23] scheme, the user ID is sharing using the secure channel, but the SCG generates the public key of the user and sends along with the randomly generated nonce to secure against the replay attack. However, the session key is not encrypting or not sending over a secure channel. Authentication phase not carrying the sender and receivers ID along with the session key. Hence, Miler et al. [23] scheme prone to man-in-the middle attack and phishing attack.Smart card based or the trusted third party based authentications are the most common technique to prevent illegal access in an insecure mobile cloud environment [6]. Many authentication protocols proposed [13, 18, 24–27] to verify the originality of end user. However, most of these protocols may not be satisfying the security against a phishing attack.Phishing attack is an essential problem in the current generation of mobile cloud authentication services [22]. Hence, to improve the security as noted earlier, mobile cloud authentication systems are vulnerable to various types of security attacks. Such attacks do not only affect the user’s identity, but also affect the device performance [28].In this paper, we endeavour to progress the mobile cloud computing security by introducing new authentication scheme based on Zero-knowledge proof technique.The proposed scheme is aimed to secure against the replay, man-in-the-middle, denial of service, server-side spoofing and phishing attacks, Malicious Insider, and other generic attacks in the mobile cloud environment without sharing the real username and password to the any of communication entities.


## 1.2. Our Contribution

In the paper, we present the outline of our proposed authentication protocol. To achieve the security against the phishing attack, we are not going to transfer the actual password to the authentication server or cloud service providers or any other communication entities during the registration and authentication stage. Here summarizing the significant contributions of our paper as follows.First, we review the He et al. [22] scheme in mobile cloud computing. In some cases, this scheme is compromising the phishing attack. Moreover, also we show that this scheme is not entirely satisfying the user anonymity. Hash value of the user password knew by the trusted third party or the authentication server.Second, we propose a new authentication scheme to secure against phishing attack without sharing the real username and password to the authentication server and cloud service providers. Moreover, the new scheme supports the mutual authentication with Zero-knowledge of proof.Finally, we provide detail security verification methods to prove our proposed scheme is secure and efficient and also meets the requirements of mobile cloud services.


## 1.3. Organization of the Paper

This paper is organized into six sections; the second section presents the preliminaries of proposed authentication scheme. The third section reviews the brief He et al. [22] scheme and presents its security problems. The fourth section presents the details of proposed mobile cloud authentication scheme with different phases like initial registration, user registration, and authentication phases. The fifth section presents the analysis of proposed security scheme nonformal verification. The sixth section compares with similar schemes, list the code, and display the formal verification result by the Scyther. And the last seventh section explains the performance analysis of the proposed scheme and its efficiency.


## 2. Preliminaries

### 2.1. Zero-Knowledge Proof

The Zero-knowledge protocol is a method based proof of verifying the originality of the prover without disclosing further knowledge about the prover to the verifier [23]. The Zero-knowledge protocol is based on Zero-knowledge proofs and can be classified as interactive Zero-knowledge and noninteractive Zero-knowledge based on the working methods [24]. The interactive Zero-knowledge protocol uses multiple authentication steps of communications between the prover and verifier. The noninteractive Zero-knowledge protocol uses only one communication message called proof between the prover and verifier [24]. The properties of Zero-knowledge proof can be distinguished as follows.(i) Completeness. “If the requested statement is correct, the honest verifier will prove that the requested statement is true to the honest verifier”.(ii) Soundness. “If the requested statement is false, there is no way to fake the result to the verifier that the requested statement is true”.(iii) Zero-Knowledge. “If the requested statement is right, the verifier may not know anything about the prover other than that the requested statement is true”.


### 2.2. System Model

A typical authentication network model of the proposed mobile cloud scheme is shown in Figure2. Here, we are using three participants in the proposed scheme.Figure 2
System model.(i) Cloud User (U). He/she is a mobile cloud user. He/she is registering as a new user with the TTP using one-time password to confirm the original identity. Then the user uses its user ID and password to generate the public key with using mobile application and then sends the mobile number, user ID, and public key with client URL to the TTP.(ii) Trusted Third Party (TTP). TTP is working as authentication server (AS), responsible for verifying requested user and the cloud service provider (CSP). After initial verification, it is receiving the public key from the cloud user.(iii) Cloud Service Provider (CSP). CSP provides services like storage, computation, and communication service to the mobile cloud user. It verifies the user request with its URI. If URI is on the approved list, it will ask the TTP for verification. Then TTP verifies the mobile number and the user ID. Finally the user ID, TTP nonce, and public key will send to CSP to confirm the cloud user.


## 2.1. Zero-Knowledge Proof

The Zero-knowledge protocol is a method based proof of verifying the originality of the prover without disclosing further knowledge about the prover to the verifier [23]. The Zero-knowledge protocol is based on Zero-knowledge proofs and can be classified as interactive Zero-knowledge and noninteractive Zero-knowledge based on the working methods [24]. The interactive Zero-knowledge protocol uses multiple authentication steps of communications between the prover and verifier. The noninteractive Zero-knowledge protocol uses only one communication message called proof between the prover and verifier [24]. The properties of Zero-knowledge proof can be distinguished as follows.(i) Completeness. “If the requested statement is correct, the honest verifier will prove that the requested statement is true to the honest verifier”.(ii) Soundness. “If the requested statement is false, there is no way to fake the result to the verifier that the requested statement is true”.(iii) Zero-Knowledge. “If the requested statement is right, the verifier may not know anything about the prover other than that the requested statement is true”.


## 2.2. System Model

A typical authentication network model of the proposed mobile cloud scheme is shown in Figure2. Here, we are using three participants in the proposed scheme.Figure 2
System model.(i) Cloud User (U). He/she is a mobile cloud user. He/she is registering as a new user with the TTP using one-time password to confirm the original identity. Then the user uses its user ID and password to generate the public key with using mobile application and then sends the mobile number, user ID, and public key with client URL to the TTP.(ii) Trusted Third Party (TTP). TTP is working as authentication server (AS), responsible for verifying requested user and the cloud service provider (CSP). After initial verification, it is receiving the public key from the cloud user.(iii) Cloud Service Provider (CSP). CSP provides services like storage, computation, and communication service to the mobile cloud user. It verifies the user request with its URI. If URI is on the approved list, it will ask the TTP for verification. Then TTP verifies the mobile number and the user ID. Finally the user ID, TTP nonce, and public key will send to CSP to confirm the cloud user.


## 3. Review of He et al. Scheme (2017)

This section describes the privacy aware authentication scheme in mobile cloud environment proposed by [22]. This protocol is developed based on identity-based signature scheme partially and also this scheme includes three phases: (1) system setup phase, (2) registration phase, and (3) authentication phase. Notations used in this protocol scheme are listed in Table 1.Table 1
Notation and Description.
Notation Description ∥ Concatenation ⊕ XOR Operation h(U) Hash Value of User ID h(PW) Hash Value of Password U Mobile Cloud User S Cloud Service Provider AS Authentication Server Uid Client URI with Mobile No sk(U) Private Key of User pk(U) Public Key of User sk(S) Private Key of CSP pk(S) Public Key of CSP Ns Fresh Authentication ID R Random Value Gen by User Na, Nu1, Nu2, Nu3 Fresh Nonce h() Hash Function


### 3.1. System Setup Phase

Smart card generator (SCG) is a trusted third party (TTP) in this scheme. SCG is generating its private and public keys using bilinear pairing.(1)
Smart card generator selects a random nonce s as a master key.(2)
Smart card generator generates the public key K+SCG based on the master key s.(3)
SCG selects five hash values based on the group G1 and G2.(4)
Finally it publishes its parameter by using public key and its hash values and also saves its secret key s.


### 3.2. Registration Phase

In this phase, user U and the cloud service provider (CSP), registering with the SCG to get their private key through the following steps over a secure channel.(1)
User U sends his user ID to the SCG.(2)
SCG generates the user’s private key by using its master key I and sends the private key K–U to the requested user through the secure channel.(3)
CSP sends its ID to SCG through the secure channel.(4)
SCG generates the CSP private key by using its master key s and sends the private key K–CSP to the requested user through the secure channel.


### 3.3. Authentication Phase

Step 1.
User enters a password only, and does not enter a username or user ID. However, client device calculates the hash value of user ID and password. Moreover, encrypts by using its session key and, finally, the user sends to the cloud service provider as follows:(1)U→CSP:IDUi,PWUiKSuiStep 2.
Cloud service provider (CSP) selects a random nonce a and computes A with nonce a and prime P, and A sends to the user.(2)CSP→U:AStep 3.
In this step, user Ui selects random nonce(3)b,r∈Zq∗and computes B as follows:(4)B=gbThe session key Kij and other functions are computed as follows:(5)Kij=h2A∥B∥Ab(6)K2=b.Ppub+h1IDCSPj.P(7)R=gr(8)ωUi=h3IDUi∥IDCSPj∥A∥B∥Kij∥K2∥R(9)ΞUi=r+ωUiSUi(10)Ci=h4B⊕IDUi∥ωUi∥ΞUiUser Ui sends K2,Ci to CSPj(11)U→CSP:K2,CiCloud service provider CSPj computes session key and other functions B,Kij,X and B,Kij,XR as follows: (12)B=K2,SCSPj(13)Kij=h2A∥B∥Ba(14)X=IDUi∥ωUi∥ΞUi(15)Y=h4B⊕C(16)X=Y(17)IDUi∥ωUi∥ΞUi=h4B⊕C(18)R=ΞUi,Ppub+h1IDui.P.g-ωUiCloud service providerCSPj verifies the following:(19)ωUi=h3IDUi∥IDcspj∥A∥B∥Kij∥K2∥RIf not matching, CSPj rejects the service request, or else cloud service provider CSPj computes Di as follows:(20)Di=h4IDCSPj∥IDUi∥A∥Kji∥K2∥B Finally CSPj sends Di to Ui(21)CSP→U:DiU i Checks whether Di is equal to h4(IDCSPj∥IDUi∥A∥Kji∥K2∥B) and Ui confirm the CSPj. Else Ui terminates the service.


### 3.4. Analysis of He et al. Scheme

In the login phase of this [22] scheme, the user enters the only username. As per (1) user encrypts the hash value username and password. However, this step does not have a precise definition of how the username is taken and may be taken from the secure memory of the mobile device.The first finding is, if the user is taking the encrypted hash value from the mobile device secure memory, then how this scheme will resist the stolen mobile device attack, because it does not have any method to verify that the username and password are entered by the user or malicious software.The second finding is that, in the login phase, the user sends the encrypted hash values of username and password to the cloud service provider (CSP), to verify the sender and the receiver, not mentioning anything in the communication. This may be prone to man-in-the-middle attack.(22)U→CSP:IDUi,PWUiKSuiThe third finding is that this scheme allows sending the password to the cloud service provider. Once the cloud service provider decrypts, it can know the hash value and may try to crack the password. Hence, the phishing attack remains open in this scheme.This [22] scheme uses smart card generator as trusted third party in the initial phase. However, it is not using the trusted party to ensure the mobile user and the cloud service provider in the authentication phase. The resistance of spoofed client attack and spoofed cloud service provider attack are unanswered in this scheme.


## 3.1. System Setup Phase

Smart card generator (SCG) is a trusted third party (TTP) in this scheme. SCG is generating its private and public keys using bilinear pairing.(1)
Smart card generator selects a random nonce s as a master key.(2)
Smart card generator generates the public key K+SCG based on the master key s.(3)
SCG selects five hash values based on the group G1 and G2.(4)
Finally it publishes its parameter by using public key and its hash values and also saves its secret key s.


## 3.2. Registration Phase

In this phase, user U and the cloud service provider (CSP), registering with the SCG to get their private key through the following steps over a secure channel.(1)
User U sends his user ID to the SCG.(2)
SCG generates the user’s private key by using its master key I and sends the private key K–U to the requested user through the secure channel.(3)
CSP sends its ID to SCG through the secure channel.(4)
SCG generates the CSP private key by using its master key s and sends the private key K–CSP to the requested user through the secure channel.


## 3.3. Authentication Phase

Step 1.
User enters a password only, and does not enter a username or user ID. However, client device calculates the hash value of user ID and password. Moreover, encrypts by using its session key and, finally, the user sends to the cloud service provider as follows:(1)U→CSP:IDUi,PWUiKSuiStep 2.
Cloud service provider (CSP) selects a random nonce a and computes A with nonce a and prime P, and A sends to the user.(2)CSP→U:AStep 3.
In this step, user Ui selects random nonce(3)b,r∈Zq∗and computes B as follows:(4)B=gbThe session key Kij and other functions are computed as follows:(5)Kij=h2A∥B∥Ab(6)K2=b.Ppub+h1IDCSPj.P(7)R=gr(8)ωUi=h3IDUi∥IDCSPj∥A∥B∥Kij∥K2∥R(9)ΞUi=r+ωUiSUi(10)Ci=h4B⊕IDUi∥ωUi∥ΞUiUser Ui sends K2,Ci to CSPj(11)U→CSP:K2,CiCloud service provider CSPj computes session key and other functions B,Kij,X and B,Kij,XR as follows: (12)B=K2,SCSPj(13)Kij=h2A∥B∥Ba(14)X=IDUi∥ωUi∥ΞUi(15)Y=h4B⊕C(16)X=Y(17)IDUi∥ωUi∥ΞUi=h4B⊕C(18)R=ΞUi,Ppub+h1IDui.P.g-ωUiCloud service providerCSPj verifies the following:(19)ωUi=h3IDUi∥IDcspj∥A∥B∥Kij∥K2∥RIf not matching, CSPj rejects the service request, or else cloud service provider CSPj computes Di as follows:(20)Di=h4IDCSPj∥IDUi∥A∥Kji∥K2∥B Finally CSPj sends Di to Ui(21)CSP→U:DiU i Checks whether Di is equal to h4(IDCSPj∥IDUi∥A∥Kji∥K2∥B) and Ui confirm the CSPj. Else Ui terminates the service.


## 3.4. Analysis of He et al. Scheme

In the login phase of this [22] scheme, the user enters the only username. As per (1) user encrypts the hash value username and password. However, this step does not have a precise definition of how the username is taken and may be taken from the secure memory of the mobile device.The first finding is, if the user is taking the encrypted hash value from the mobile device secure memory, then how this scheme will resist the stolen mobile device attack, because it does not have any method to verify that the username and password are entered by the user or malicious software.The second finding is that, in the login phase, the user sends the encrypted hash values of username and password to the cloud service provider (CSP), to verify the sender and the receiver, not mentioning anything in the communication. This may be prone to man-in-the-middle attack.(22)U→CSP:IDUi,PWUiKSuiThe third finding is that this scheme allows sending the password to the cloud service provider. Once the cloud service provider decrypts, it can know the hash value and may try to crack the password. Hence, the phishing attack remains open in this scheme.This [22] scheme uses smart card generator as trusted third party in the initial phase. However, it is not using the trusted party to ensure the mobile user and the cloud service provider in the authentication phase. The resistance of spoofed client attack and spoofed cloud service provider attack are unanswered in this scheme.


## 4. Proposed Scheme

The proposed authentication scheme has three phases. The first phase creates a group called G and its members. TTP shares the elements of the group to the communication entities. The second phase handles the registration of cloud user and CSP with the authentication server or a trusted third party. The third phase verifies the cloud user and the service provider to achieve the mutual authentication.


### 4.1. Initial Registration

The given group G is having set of values. G0, G1 are carrier set of random elements of group G [2, 23, 24, 29]. Hence, the public key may be the G, G0.Group G is a carrier set cordiality of the order of GroupG. Hence the digital payment like Bitcoin which uses the sec256k1 group, based on elliptic curve. Element size of this group is 256-bit strings, which is very hard in this type of group [21].


### 4.2. Registration Phase

The second phase accepts the registration of cloud user and cloud service provider by the authentication server.The new user generates a request with the authentication server (AS) with its mobile number being of original identity. AS verifies the available list of available registered mobile numbers. If the number is new, the AS sends the OTP or else terminates the communication. The entered OTP will get verified with AS. Once OTP is verified, then the user enters the new user ID and password; the mobile browser generates the hash value of the user ID as H1 and generates a hash value of password as H2. Client browser generates the public key P using the hash value of the user password H2. Finally, the user sends the hash value of user ID H1 and public key P along with mobile number (as Client URL ) to register in the trusted user list of AS over the secure channel as explained in Figure3. All the above communications are happening over the secure channel between user and AS. In Figure 4, cloud service provider, service and domain registration with authentication server (TTP), and new cloud service provider (CSP) generate a new request to AS. AS verifies the existence of the new domain in the existing list. If free, the AS accepts the request and generates the domain tag with the new unique one-time key. Domain tag sends to the CSP. Moreover, the CSP has to keep the tag in the document root of its domain and verifies with the AS. If AS verifies the domain tag, accepts the registration request, and stores the hash value of domain’s URI in the trusted list and shares the CSP public key to AS, all of the above communications are happening over the secure channel between AS and CSP.Figure 3
User registration with authentication server (TTP).Figure 4
Cloud service provider and service and domain registration with authentication server (TTP).


### 4.3. Authentication Phase

In this phase, authentication server (AS), mobile cloud user (U), and cloud service provider (CSP) are participating in verifying the user and CSP through the AS to achieve mutual authentication without revealing the real password between the communication entities. The proposed authentication is using the mobile number as an original identity to register the user. Once the user is registered successfully as per Section4.2, the AS will generate the unique link to the client as follows. User mobile number is 9xxx7; when this user registers with the authentication server myauth.in, they will get unique web URI called client URI as 9xxx7.myauth.in. The AS will maintain the mobile number, client URI, hash value of user ID, and public key of user as client profile like Table 2.Table 2
Sample Client Profile in AS.
Sl. No Mobile No Hash value Pub Key URI Allowed Services 1 9xxx7 0A 04 1B 94 User Pub-Key 9xxx7.myauth.in https://mobilecloudsr1.s3.amazonaws.comUser U sends the service request to CSP with his/her mobile identity to the Cloud service provider (CSP).Once the user’s public key is shared from the AS to CSP after verifying the user and CSP as per the communication explained in Figure5, second stage of protocol will work as per the following steps of equation and also is explained overall in Figure 6.Figure 5
Proposed Stage I authentication protocol.Figure 6
Proposed Stage II authentication protocol against phishing attack.Step 1.
User U requests the service or visits the service. Hence, the user enters the login and clicks the register button:(23)U->S:U,S,ReqStep 2.
Cloud service provider S sends the random token Ns as authentication ID to the user’s request after verifying the client’s URI.(24)S->U:S,U,NsStep 3.
User enters user ID and password in the client browser. Browser plug-in generates the hash value of user ID and password. Based on this hash values, the browser generates the value x as follows. Hence, the password is not leaving the client browser.(25)x=hPWuThen the user computes Pu (public key of user U) with using x and the shared group g0:(26)Pu=g0xThen the user generates the random value r∈g and calculates Q:(27)Q=g0rxBy using Q, user calculates the value C and Zx as follows:(28)C=hPu,Q,Ns(29)Zx=Rx-CxFinally, the user sends the C and Zx to the server.(30)U->S:C,Zx
The server S calculates the value Q as follows:
(1) Server receivesC and Zx.
(2) The server has the users Ns, public keyPu, and shared group element g0.The server calculates Q:(31)Q=PuCg0ZxThen the server S checks whether the C=h(Pu,Q,Ns).In this proposed protocol the random value is generated by the user, but this value is constructed by the server S with using above functions as follows.As per (27) and (29), Q=g0rx and Zx=Rx-Cx.We can prove the following with using simple substitution: (27) Q=g0rx and (31), Q=PuCg0ZxHence,g0rx=PuCg0Zx,(32)g0rx=g0xcg0rx-cx(33)g0rx=g0cxg0rx-cx(34)g0rx=g0cx+rx-cx(35)g0rx=g0rxNow user’s random value r is constructed by the server S to verify that the user is genuine and also user is proved that the server’s random value Ns is known by the user to achieve the mutual authentication.


## 4.1. Initial Registration

The given group G is having set of values. G0, G1 are carrier set of random elements of group G [2, 23, 24, 29]. Hence, the public key may be the G, G0.Group G is a carrier set cordiality of the order of GroupG. Hence the digital payment like Bitcoin which uses the sec256k1 group, based on elliptic curve. Element size of this group is 256-bit strings, which is very hard in this type of group [21].


## 4.2. Registration Phase

The second phase accepts the registration of cloud user and cloud service provider by the authentication server.The new user generates a request with the authentication server (AS) with its mobile number being of original identity. AS verifies the available list of available registered mobile numbers. If the number is new, the AS sends the OTP or else terminates the communication. The entered OTP will get verified with AS. Once OTP is verified, then the user enters the new user ID and password; the mobile browser generates the hash value of the user ID as H1 and generates a hash value of password as H2. Client browser generates the public key P using the hash value of the user password H2. Finally, the user sends the hash value of user ID H1 and public key P along with mobile number (as Client URL ) to register in the trusted user list of AS over the secure channel as explained in Figure3. All the above communications are happening over the secure channel between user and AS. In Figure 4, cloud service provider, service and domain registration with authentication server (TTP), and new cloud service provider (CSP) generate a new request to AS. AS verifies the existence of the new domain in the existing list. If free, the AS accepts the request and generates the domain tag with the new unique one-time key. Domain tag sends to the CSP. Moreover, the CSP has to keep the tag in the document root of its domain and verifies with the AS. If AS verifies the domain tag, accepts the registration request, and stores the hash value of domain’s URI in the trusted list and shares the CSP public key to AS, all of the above communications are happening over the secure channel between AS and CSP.Figure 3
User registration with authentication server (TTP).Figure 4
Cloud service provider and service and domain registration with authentication server (TTP).


## 4.3. Authentication Phase

In this phase, authentication server (AS), mobile cloud user (U), and cloud service provider (CSP) are participating in verifying the user and CSP through the AS to achieve mutual authentication without revealing the real password between the communication entities. The proposed authentication is using the mobile number as an original identity to register the user. Once the user is registered successfully as per Section4.2, the AS will generate the unique link to the client as follows. User mobile number is 9xxx7; when this user registers with the authentication server myauth.in, they will get unique web URI called client URI as 9xxx7.myauth.in. The AS will maintain the mobile number, client URI, hash value of user ID, and public key of user as client profile like Table 2.Table 2
Sample Client Profile in AS.
Sl. No Mobile No Hash value Pub Key URI Allowed Services 1 9xxx7 0A 04 1B 94 User Pub-Key 9xxx7.myauth.in https://mobilecloudsr1.s3.amazonaws.comUser U sends the service request to CSP with his/her mobile identity to the Cloud service provider (CSP).Once the user’s public key is shared from the AS to CSP after verifying the user and CSP as per the communication explained in Figure5, second stage of protocol will work as per the following steps of equation and also is explained overall in Figure 6.Figure 5
Proposed Stage I authentication protocol.Figure 6
Proposed Stage II authentication protocol against phishing attack.Step 1.
User U requests the service or visits the service. Hence, the user enters the login and clicks the register button:(23)U->S:U,S,ReqStep 2.
Cloud service provider S sends the random token Ns as authentication ID to the user’s request after verifying the client’s URI.(24)S->U:S,U,NsStep 3.
User enters user ID and password in the client browser. Browser plug-in generates the hash value of user ID and password. Based on this hash values, the browser generates the value x as follows. Hence, the password is not leaving the client browser.(25)x=hPWuThen the user computes Pu (public key of user U) with using x and the shared group g0:(26)Pu=g0xThen the user generates the random value r∈g and calculates Q:(27)Q=g0rxBy using Q, user calculates the value C and Zx as follows:(28)C=hPu,Q,Ns(29)Zx=Rx-CxFinally, the user sends the C and Zx to the server.(30)U->S:C,Zx
The server S calculates the value Q as follows:
(1) Server receivesC and Zx.
(2) The server has the users Ns, public keyPu, and shared group element g0.The server calculates Q:(31)Q=PuCg0ZxThen the server S checks whether the C=h(Pu,Q,Ns).In this proposed protocol the random value is generated by the user, but this value is constructed by the server S with using above functions as follows.As per (27) and (29), Q=g0rx and Zx=Rx-Cx.We can prove the following with using simple substitution: (27) Q=g0rx and (31), Q=PuCg0ZxHence,g0rx=PuCg0Zx,(32)g0rx=g0xcg0rx-cx(33)g0rx=g0cxg0rx-cx(34)g0rx=g0cx+rx-cx(35)g0rx=g0rxNow user’s random value r is constructed by the server S to verify that the user is genuine and also user is proved that the server’s random value Ns is known by the user to achieve the mutual authentication.


## 5. Security Analysis and Verification

The proposed scheme is nonformally proved to resist against the significant attacks like phishing attack, replay attack, impersonation attack and other generic attacks explained in the following subsections.


### 5.1. Phishing Attack

The proposed authentication scheme is not sending the password to the server. It is generating the public key by using the hash value of the password. As explained in (25) to (29), we compute the C and Zx values and send to the CSP. In the CSP side C and Zx construct and verify the user identity with available public key. Hence, this scheme is resistance against the phishing attack [22, 28].


### 5.2. Strong Replay Attack

In this proposed scheme, nonce Nu1, Nu2, Nu3, and Na are used to check that the communication is fresh in both the stages of authentication as well as shown in Figures5 and 6. The Ns is used as fresh authentication ID in Stage I authentication. For an example, in our Stage I authentication, user U sends Nu1 (nonce to avoid replay attack) and the hash value of actual user-identity h(Uid) (to avoid user anonymity attack) to the server S as (U,S,Nu1,h(Uid)) an authentication request to avoid the replay and user anonymity.


### 5.3. Server Impersonation Attack

The proposed scheme is resistance against the user impersonation attack. Not only is this scheme using the user ID but also it is using the user profile as URI, which includes the mobile number, and URI or user like 9xxx7.myauth.in. When a request comes from any user, the server verifies the client URI first. If the user URI is correct, then only the server accepts the request for impersonation and masquerade attack [10].


### 5.4. Generic Attacks

Also, the proposed scheme satisfies the generic attack like denial of service attack by specifying the active participants of each communication [21]. Man-in-the-middle attack is satisfying by every communication which is carrying the actual sender and the receiver identity [11, 15]. It is carrying the server URI and the client URI in every step and also its getting verified by the server using the user’s profile.


### 5.5. Forward Secrecy and Mutual Authentication

The proposed scheme is using the asymmetric key cryptosystem to verify the communication entities to maintain the forward secrecy and to achieve the mutual authentication [18, 20, 23, 30]. Even the key is generated by the end user to avoid the server impersonation attack (U,S,Nu3,U,S,h(Na)pk(S)sk(U)).


## 5.1. Phishing Attack

The proposed authentication scheme is not sending the password to the server. It is generating the public key by using the hash value of the password. As explained in (25) to (29), we compute the C and Zx values and send to the CSP. In the CSP side C and Zx construct and verify the user identity with available public key. Hence, this scheme is resistance against the phishing attack [22, 28].


## 5.2. Strong Replay Attack

In this proposed scheme, nonce Nu1, Nu2, Nu3, and Na are used to check that the communication is fresh in both the stages of authentication as well as shown in Figures5 and 6. The Ns is used as fresh authentication ID in Stage I authentication. For an example, in our Stage I authentication, user U sends Nu1 (nonce to avoid replay attack) and the hash value of actual user-identity h(Uid) (to avoid user anonymity attack) to the server S as (U,S,Nu1,h(Uid)) an authentication request to avoid the replay and user anonymity.


## 5.3. Server Impersonation Attack

The proposed scheme is resistance against the user impersonation attack. Not only is this scheme using the user ID but also it is using the user profile as URI, which includes the mobile number, and URI or user like 9xxx7.myauth.in. When a request comes from any user, the server verifies the client URI first. If the user URI is correct, then only the server accepts the request for impersonation and masquerade attack [10].


## 5.4. Generic Attacks

Also, the proposed scheme satisfies the generic attack like denial of service attack by specifying the active participants of each communication [21]. Man-in-the-middle attack is satisfying by every communication which is carrying the actual sender and the receiver identity [11, 15]. It is carrying the server URI and the client URI in every step and also its getting verified by the server using the user’s profile.


## 5.5. Forward Secrecy and Mutual Authentication

The proposed scheme is using the asymmetric key cryptosystem to verify the communication entities to maintain the forward secrecy and to achieve the mutual authentication [18, 20, 23, 30]. Even the key is generated by the end user to avoid the server impersonation attack (U,S,Nu3,U,S,h(Na)pk(S)sk(U)).


## 6. Comparison and Formal Verification

In this section, we compare the proposed authentication schemes with significant security protocols listed in Table3, and also the formal verification is done with Scyther [18, 31] to prove Stage I is secure against the significant attacks. Finally, Stage II authentication also is verified and listed.Table 3
Comparing Resistance of Attacks.
Sl. No Scheme [7] [1] [2] [8] [9] [10] [11] [12] [13] [15] Ours 1 Formal Security Proof No No Yes No No No Yes Yes Yes No Yes 2 Forward Secrecy Yes Yes Yes No Yes Yes Yes Yes Yes Yes Yes 3 Login Phase Efficiency Yes No Yes No Yes Yes Yes Yes Yes Yes Yes 4 Resistant to DoS Attack Yes No Yes No Yes Yes Yes Yes Yes Yes Yes 5 Resistant to Password Guessing Attack No No Yes Yes No No No Yes Yes Yes Yes 6 Resistant to Phishing Attack No No No No No No No No No Yes Yes 7 Resistant to Privileged Insider Attack Yes No No Yes Yes No Yes Yes Yes Yes Yes 8 Resistant to Server Impersonation Attack No Yes No Yes Yes No Yes Yes Yes Yes Yes 9 Resistant to Stolen Mobile Device Attack No No No No No No No Yes Yes Yes Yes 10 Resistant to Strong Reply Attack Yes No Yes Yes Yes Yes Yes Yes Yes Yes Yes 11 Resistant to Strong User Anonymity Yes No Yes Yes Yes Yes Yes Yes Yes Yes Yes 12 Resistant to User Impersonation Attack Yes Yes No Yes Yes Yes Yes Yes Yes Yes Yes 13 Secure Mutual Authentication Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes 14 Verification using Scyther or Other Tools No No No No No No Yes No No No Yes


### 6.1. Formal Verification

The proposed authentication protocol is verified using the automated protocol verification tool called Scyther, developed by Cremers et al. [31]. Scyther is having the features like unbounded verification, attack finding, and visualisation, also supporting the classical properties like secrecy, agreement, aliveness, and synchronisation [29, 31]. The proposed protocol can be written in security protocol description language. Mutual authentication between the user, AS, and CSP is verified in Scyther as follows./∗ Stage I Authentication Protocol ∗/const Fresh: Function;const hash: Function;hashfunction h;const pk: Function;const sk: Function;inversekeys (pk,sk);const h,Uid;protocol KeyShareProto (U,S,AS)role Ufresh Nu1,Nu2,Nu3: Nonce;fresh Ns1,Na:Nonce;​send_1 (U,S,Nu1,h(Uid));recv_2 (S,U,h(Nu1),U,S,AS,h(Uid)sk(S));send_3 (U,AS,Nu2,U,AS,Nu2,h(Uid),U,S,AS,  h(Uid)sk(S)sk(U));recv_4 (AS,U,S,AS,h(Nu2),U,S,  h(Na)pk(S)pk(U));send_5 (U,S,Nu3,U,S,h(Na)pk(S)sk(U));recv_8 (S,U,h(Nu3)pk(U));role Sfresh Nu1,Nu2,Nu3: Nonce;fresh Ns1,Na:Nonce;​recv_1 (U,S,Nu1,h(Uid));send_2 (S,U,h(Nu1),U,S,AS,h(Uid)sk(S));recv_5 (U,S,Nu3,U,S,h(Na)pk(S)sk(U));send_6 (S,AS,S,AS,U,h(Uid),h(Na),Ns1sk(S));recv_7 (AS,S,U,h(Uid),pk(U)pk(S));send_8 (S,U,h(Nu3)pk(U));role ASfresh Nu1,Nu2,Nu3: Nonce;fresh Ns1,Na:Nonce;​recv_3 (U,AS,Nu2,U,AS,Nu2,h(Uid),U,S,AS,  h(Uid)sk(S)sk(U));send_4 (AS,U,S,AS,h(Nu2),U,S,  h(Na)pk(S)pk(U));recv_6 (S,AS,S,AS,U,h(Uid),h(Na),Ns1sk(S));send_7 (AS,S,U,h(Uid),pk(U)pk(S));Our Stage I authentication protocol is verified by Scyther. The source code of Stage I is listed above and the output is shown in Figure7.Figure 7
Proposed Stage I authentication protocol autoverification using Scyther./∗ Stage II Authentication Protocol ∗ /const Fresh: Function;​protocol AuthProto (U,S)role Ufresh Ns:Nonce;const Req;const C;const Zx;​send_1 (U,S,Req);recv_2 (S,U,Ns);send_3 (U,S,C,Zx);​claim(U,Secret,C);claim(U,Secret,Zx);claim(U,Alive);claim(U,Weakagree);claim(U,Commit,S,Ns);claim(U,Niagree);claim(U,Nisynch);role Sfresh Ns:Nonce;const Req;const C;const Zx;​recv_1(U,S,Req);send_2 (S,U,Ns);recv_3 (U,S,C,Zx);​claim(S,Secret,C);claim(S,Secret,Zx);claim(S,Alive);claim(S,Weakagree);claim(S,Commit,U,Ns);claim(S,Niagree);claim(S,Nisynch);Stage II authentication protocol is also verified by Scyther verification tool. The source code of Stage II is also listed and the output is shown in Figure8.Figure 8
Proposed Stage II authentication protocol verification using Scyther.


## 6.1. Formal Verification

The proposed authentication protocol is verified using the automated protocol verification tool called Scyther, developed by Cremers et al. [31]. Scyther is having the features like unbounded verification, attack finding, and visualisation, also supporting the classical properties like secrecy, agreement, aliveness, and synchronisation [29, 31]. The proposed protocol can be written in security protocol description language. Mutual authentication between the user, AS, and CSP is verified in Scyther as follows./∗ Stage I Authentication Protocol ∗/const Fresh: Function;const hash: Function;hashfunction h;const pk: Function;const sk: Function;inversekeys (pk,sk);const h,Uid;protocol KeyShareProto (U,S,AS)role Ufresh Nu1,Nu2,Nu3: Nonce;fresh Ns1,Na:Nonce;​send_1 (U,S,Nu1,h(Uid));recv_2 (S,U,h(Nu1),U,S,AS,h(Uid)sk(S));send_3 (U,AS,Nu2,U,AS,Nu2,h(Uid),U,S,AS,  h(Uid)sk(S)sk(U));recv_4 (AS,U,S,AS,h(Nu2),U,S,  h(Na)pk(S)pk(U));send_5 (U,S,Nu3,U,S,h(Na)pk(S)sk(U));recv_8 (S,U,h(Nu3)pk(U));role Sfresh Nu1,Nu2,Nu3: Nonce;fresh Ns1,Na:Nonce;​recv_1 (U,S,Nu1,h(Uid));send_2 (S,U,h(Nu1),U,S,AS,h(Uid)sk(S));recv_5 (U,S,Nu3,U,S,h(Na)pk(S)sk(U));send_6 (S,AS,S,AS,U,h(Uid),h(Na),Ns1sk(S));recv_7 (AS,S,U,h(Uid),pk(U)pk(S));send_8 (S,U,h(Nu3)pk(U));role ASfresh Nu1,Nu2,Nu3: Nonce;fresh Ns1,Na:Nonce;​recv_3 (U,AS,Nu2,U,AS,Nu2,h(Uid),U,S,AS,  h(Uid)sk(S)sk(U));send_4 (AS,U,S,AS,h(Nu2),U,S,  h(Na)pk(S)pk(U));recv_6 (S,AS,S,AS,U,h(Uid),h(Na),Ns1sk(S));send_7 (AS,S,U,h(Uid),pk(U)pk(S));Our Stage I authentication protocol is verified by Scyther. The source code of Stage I is listed above and the output is shown in Figure7.Figure 7
Proposed Stage I authentication protocol autoverification using Scyther./∗ Stage II Authentication Protocol ∗ /const Fresh: Function;​protocol AuthProto (U,S)role Ufresh Ns:Nonce;const Req;const C;const Zx;​send_1 (U,S,Req);recv_2 (S,U,Ns);send_3 (U,S,C,Zx);​claim(U,Secret,C);claim(U,Secret,Zx);claim(U,Alive);claim(U,Weakagree);claim(U,Commit,S,Ns);claim(U,Niagree);claim(U,Nisynch);role Sfresh Ns:Nonce;const Req;const C;const Zx;​recv_1(U,S,Req);send_2 (S,U,Ns);recv_3 (U,S,C,Zx);​claim(S,Secret,C);claim(S,Secret,Zx);claim(S,Alive);claim(S,Weakagree);claim(S,Commit,U,Ns);claim(S,Niagree);claim(S,Nisynch);Stage II authentication protocol is also verified by Scyther verification tool. The source code of Stage II is also listed and the output is shown in Figure8.Figure 8
Proposed Stage II authentication protocol verification using Scyther.


## 7. Performance Analysis

In the trusted third party based authentication schemes, performance is one of the important factors to concentrate on. As we know, performance is having close relation with the security. Most of the third party based authentication protocols are using two-stage authentication process. Stage I is registration phase or initial authentication phase and Stage II is login and authentication phase. Mostly, the registration phase or Stage I authentication is a one-time process at the time of registering the user. Hence, to calculate the performance of our proposed authentication scheme in terms of computation and number of communications, we consider only Stage II authentication. In the proposed scheme, we assumed the size of identity is 32 bits and hash size is 160 bits (we use SHA-1). As we mentioned above, registration or Stage one authentication is happening only once. Hence, we consider only Stage two authentication (login and authentication phase) for calculating the computation and communication. During Stage two, Step 1, user sends the authentication request as mentioned in (23); the size of the identity and the request is 96 bits; Step 2, CSP verifies as mentioned in (24); the size of the user identity and fresh authentication ID is again 96 bits only; Step 3, user device calculates the values C and Zx as explained in (25) to (29) and then sends the C and Zx to CSP; size of the identity is 64 and the hash values of C,Zx are 160+160. Last communication message size is 384 (32+32+160+160) bits. Hence the total transmission size is 576 bits in 3 communications. Also, Table 4 shows the proposed scheme is more efficient than the recent similar authentication schemes.Table 4
Performance Analysis with Recent Schemes.
Sl. No Schemes No. of Bits No. of Messages 1 Lee et al. [2] 1184 7 2 Dey et al. [11] 1280 4 3 Lin et al. [12] 1536 4 4 Roy et al. [14] 864 2 5 Binu et al. [29] 2304 7 6 Our Scheme 576 3In the proposed authentication scheme performance analysis, we use few cryptographic operations and its notations as follows:(i)
Hash function asTh(ii)
Multiplication or key generation or verification asTmWe used SHA-1 to calculate hash functionTh, used ECC for multiplication, and used key generation and verification Tm to compute the C and Zx values. As per the equation numbers from (25) to (29), 5 equations are used to compute the values C and Zx. We use 2 Th, 2 Tm in mobile device. We ignored the cost of XOR operations due to negligible computation load. Table 5 explains and compares the computation cost of multiplication Tm and hash function Th with recent similar schemes.Table 5
Computation Cost Analysis with Recent Schemes.
Sl. No Scheme Cost of Computation 1 Lee et al. [2] 4Th+3Tm 2 Dey et al. [11] 5Th+4Tm 3 Lin et al. [12] 10Th+2Tm 4 Roy et al. [14] 9Th+1Tm 5 Binu et al. [29] 9Th+3Tm 6 Our Scheme 2Th+2TmAs we know, the computation capacity of smartphone is growing day by day. Nowadays octa-core processor with 3GB RAM smartphone cost is under $100. Moderate to high end smartphone is having 8GB RAM. Hence, our scheme is working good in recent smartphones. Also, we are testing our scheme to use Dynamic Computation Offloading technique in our future work to get best performance while using our scheme in the Low Powered Device. Due to this reason, we did not explain the execution time of recent similar schemes. Tables4 and 5 show that our scheme is using less number of message communications with tiny data between communication entities. Also, our scheme uses less number of mathematical functions to achieve best computation cost and efficient security in mobile devices.


## 8. Conclusion

The traditional authentication methods are not suitable for mobile cloud computing due to its dynamic nature and support of various cloud services. In this paper, we presented new authentication scheme to secure the user password from the phishing attack. The proposed authentication scheme is not sending the password in any form of the existing methods like hash value and encrypted key or a digital signature to verify the identity of mobile user and the cloud service provider. In this scheme, we have used the Zero-knowledge proof technique to satisfy the authentication process. Also, the proposed scheme verified by the University of Oxford developed protocol verification tool, Scyther. The security verification and the experimental result brought about an exhibit that the proposed scheme is more secure against the phishing attack in the mobile cloud computing. In the future, we would like to explore more attributes to provide efficient mobile cloud authentication in the multicloud environment with Dynamic Computational Offloading Technique.



---

*Source: 5141395-2019-05-09.xml*