A robust cloud access scheme with mutual authentication

. Due to the progress of network technology, we can access some information through remote servers


Background
Due to the rapid development of hardware net-work environment, a variety of services and applications began to attract personal attention in today's social environment. In earlier, because of the smaller scale of services, fewer numbers of users, a single server is sufficient to provide all the necessary services.
With the rise of integrated services, single company can provide diverse services, and even operate as crossindustry alliance type. User can use single account to access various services. On the other hand, the huge amount of users is impossible to use single server to satisfy various services. Therefore, we need multi-server to handle these services, and that's a concept of cloud. [7,8,11]

Cloud architecture
There are three kinds of architectures about user and server in cloud architecture [9].

All users connect to a single server for authentication and communication
This service model is simple and easy to set up. But the number of users provided service con-tents increasingly, it will be no longer a single server can handle it, and such architecture is vulnerable to be braked by malicious people.

All users through the gateway and lead to a different server
Such service model can effectively solve the excessive burden of a single server problem, but this will significantly reduce the reliability of the system architecture, and it is also vulnerable to be braked by malicious people.

All users process identity verification with front server and backend server
Such service mode can also effectively solve the excessive burden of a single server problem, and the user's real identity is stored in the backend server. It's hard to be braked by malicious peo-ple, the architecture is similar to HDFS (Hadoop Distributed File System). [6,10]  in its database securely.

Authentication stage of Nivethitha et al.'s scheme
Step 1: User inputs his/her identity D I c , then sends it to register server. Register server forwards the same message D I c to backend server.
Step 2: Backend server checks its database to get ) 3 , ( C ID , which stored during registration stage, and then sends 3 C to register server. Register server forwards the same message 3 C to user. Step 5: Backend server checks 3 4 . If pass the verification, the backend server gets ID which stored in registration stage, and then sends ID to register server. in its database securely for next access.
Later, Mrudula et al. [4] pointed out that Nivethitha et al.'s scheme can't prevent offline password guessing attack. When an attacker intercepts the messages D I c , 3 C and P OT c which transferred between user and register server during authentication stage, he/she can perform dictionary attack to guess a password W P c , and calculate OT c , it means he/she gets the correct password successfully, and can be a legal user for future access.

Registration stage of Mrudula et al.'s scheme
Step Step 4: Register server generates a random number ru , in its database securely, and then sends ru to user through secure channel.

Authentication stage of Mrudula et al.'s scheme
Step 1: User inputs his/her identity D I c , then sends it to register server. Register server forwards the same message D I c to backend server.
Step 2: Backend server checks its database to get which stored during registration stage, and then sends 3 C to register server. Register server forwards the same message 3 C to user.
Step 3: User calculates ) , and then sends 4 C to register server.
Step 4: Register server calculates ) , and then sends 5 C to backend server.
Step 5: Backend server checks 3 5 . If pass, backend server gets ID from ) 3 , ( C ID , which stored during registration stage, and then sends ID to register server. Mrudula et al.'s scheme solves offline password guessing attack successfully due to they use a random number ru between user and register server during authentication stage. The random number ru changes after a success round, so an attacker can't perform offline password guessing attack simply. We find that their scheme exists another problem that is asynchronous issue.
When an attacker intercepts the final message between user and register server during authentication stage, they can't communicate anymore in the future. User and register server hold different random number ru , and which is decided from register server, there is no way to let user gets another random number again.

Authentication stage
Step 1: User inputs his/her identity D I c , and then sends it to register server. Register server forwards the same message D I c to backend server.
Step 2: Backend server checks its database to get ) 3 , ( C ID which stored during registration stage, and then sends 3 C to register server. Register server forwards the same message 3 C to user. Step 3: After receiving the message, user calculates )

Achieve mutual authentication
During the login phase, the user, register server and backend server authenticate each other to make sure the legality of each roles. Register server uses to authenticate register server and backend server. The proposed scheme achieves mutual authentication.

Prevent replay attack
During login phase, an attacker may intercept the message ) ( ) ( x ID h HID that sent to register server, and sends it again in the future. The attacker can't success because of includes a random value ru is changed in every round.

Solve asynchronous issue
To prevent replay attack, user and register server update a new random value after a successful authentication for next round. When an attacker intercepts the final message between user and register server, it will cause asynchronous problem. Because of user and register server hold different random value, they can't communicate anymore.
In the previous scheme, the random value decided by register server, the asynchronous problem will happen, and there's no way to solve this situation. In our proposed scheme, even the final message 9 C has been intercepted by an attacker, user can run the registration phase to send ) , , ( ru HPW ID again to solve the asynchronous issue.

Prevent offline password guessing attack
When an attacker intercepts the messages D I c , between user and register server, he/she still can't do anything to get the password. The proposed scheme uses hash function and exclusive-or calculation to protect all the messages. It is computationally impossible to get the password HPW , the proposed scheme can prevent offline password guessing attack.

Security and complexity comparison
The following table 1 and table 2 are security comparison and complexity comparison respectively. Although the proposed scheme has higher complexity of calculation, it's not a problem for today's hardware and network environment. The proposed scheme achieves more security requirements than the previous schemes, especially mutual authentication.

Conclusions
In the cloud environment, lots of users' sensitive data are stored in the remote servers. Besides legal users, malicious people also want to get these data. There must have a robust authentication protocol to protect these data. Some previous researchers proposed the authentication protocol for HDFS cloud architecture, but they still get some security defects. The proposed protocol solves these defects successfully, and also satisfies more security requirements.