Secure Store of User Authentication Tokens in Multi-cloud Storage System

(1)

Available at http://www.Jofcis.com

Secure Store of User Authentication Tokens in

Multi-cloud Storage System

?

Jinjin SUN

1,

∗

,

Ming XU

1

, Shifang FENG

1

, Zhongwei LI

2

, Gang WANG

1

,

Xiaoguang LIU

1

1_{Nankai-Baidu Joint Lab, College of Computer and Control Engineering, Nankai University, Tianjin}

300071, China

2_{College of Software, Nankai University, Tianjin 300071, China}

Abstract

To solve the security problems in single-cloud storage, multi-cloud storage system has been put forward in some literatures. However, when using multi-cloud, a user needs to be authenticated by different cloud storage services, which is a time-consuming and tedious process. To avoid this, we propose a framework to store the authentication tokens of multiple cloud services securely. When the first time a user uses the multi-cloud storage system and finishes authorization to all cloud storage services involved, the encrypted tokens are entrusted to the framework. When the user using the multi-cloud storage system again, the tokens are retrieved and decrypted and then used to complete authentication to the cloud storage services. By this way, user experience is enhanced without loss of security. We design and implement a local secure token management scheme and a server-based scheme, and verify the two schemes in a multi-cloud storage system.

Keywords: Cloud Storage Security; User Authentication; Kerberos Protocol; Token Management

1 Introduction

Although cloud storage is very popular, none of the today’s cloud storage services can guarantee satisfactory security, which hinders the development of cloud storage.

When users put their data on one server, it will face the risks of data leaks, data tamper, and returning inconsistent data to different users. For example, data corruption happened on Amazon’s popular Simple Storage Service (S3) [1] and data security violation happened on Google Docs [2]. Because of the shortcomings of Single-cloud storage system, secure cloud storage systems become more eagerly needed. So the multi-cloud storage comes into being.

?_{Project supported by NSF of China (61373018, 11301288), Program for New Century Excellent Talents in}

University (NCET130301) and the Fundamental Research Funds for the Central Universities (65141021).

∗_{Corresponding author.}

Email address: sunjj@nbjl.nankai.edu.cn(Jinjin SUN).

(2)

However, the new problem that users have to be authenticated by different cloud storage services arises. To avoid this process, we design a secure token store framework. A user must complete authentication to all cloud storage services when he uses the system first time. The tokens issued by the cloud services are stored locally or on a server securely. The user can just send the tokens to the cloud storage services to gain access to his data when he gets data from the multi-cloud storage system at any time. This framework simplifies the authentication process without loss security so that enhances user experience.

The existing authentication technologies are not satisfactory when directly used in our frame-work. So we design a new authentication mechanism to store and access tokens securely. We design and implement the token management framework base on this mechanism in a multi-cloud storage system. The experimental results show that the framework achieves the goal of securely storing the user authentication tokens in the multi-cloud storage system and introduces a little overhead.

2 Related Work

2.1 Threat model of cloud storage

When talking about the security properties of cloud storage, we take account of the security factors that integrity, confidentiality, service availability and vendor lock-in.

When transmitted to the cloud storage servers, data may be corrupted or tempered, which leads to bad data on the server at the beginning. In addition, the misoperations by administrator ([3] is an example) and the attacks committed on servers may also lead to data corruption (like in [2, 4, 5]). We define the data integrity as each read returns the content put on the cloud by the legitimate users.

Confidentiality means that the data on the cloud cannot be leaked to others and read by the cloud. However, once data is put on the cloud, the user has to trust the cloud storage providers [6]. Moreover, apart from the threat from the provider, hackers could attack the servers and leak the privacy data [7].

Due to the unexpected downtime of server, service shutdown, natural disaster and so on, the service may be unavailable. Service availability holds that, no matter what happens, the service can continue and the user can get the data anytime.

Vendor lock-in means users cannot change the server provider recklessly. Abu-Libdeh et al. have suggested there is risk (mainly means vendor lock-in) when enjoying the service provided by the single-cloud storage [2].

2.2 Multi-cloud storage systems

To achieve the goal of improving the security of cloud, many multi-cloud storage systems have been put forward, such as DepSky [8], RACS [9], ICStore [10], HAIL [11], and so on. Of course, they are not on the same security level due to the different designs and protocols in the system. AlZain et al. address three security factors and they consider only DepSky system addresses all of those [12]. The security analysis and the details of DepSky architecture can be found in [8, 12].

(3)

And it summarizes the security of these multi-cloud storage systems that arose recently years. However, in these multi-cloud storage systems, token storage has never been mentioned. Mul-tiple authorizations will bring bad experience to the users. This is the contribution of our frame-work, which achieves the goal of securely storing the user authentication tokens in the multi-cloud storage system and introduces small overhead.

2.3 Existing authentication technology

We put forward to design a new user authentication mechanism to manage the tokens, based on the kerberos protocol and Challenge/Response mechanism. By using this mechanism, the multi-cloud client can complete authentication using the tokens.

In July 2005, the Massachusetts Institute of Technology put forwards the new standard of kerberos protocol [14], which is the improvement of the version of kerberos V4 [15]. There are three parts in kerberos, Key Distribution Center (KDC) which includes Authentication Service (AS) and Ticket Granting Server (TGS), Client and Server. But there must be some operations in the Server to conduct the protocol, which limits its application on the multi-cloud storage because we cannot control the cloud providers.

Challenge/Response is a dynamic identity authentication scheme based on the DES encryption algorithm. In the whole process of authentication, the user information is never been transmitted. The Server makes a random and sends it to the user, and then the user responses according to his key. By this way, it can guarantee the security of the secret information, which can be for reference.

3 Design and Implementation

The design of the mechanism consists of two parts: user authentication and token management. The user can choose to store the tokens on the local computer or the server we provide. Based on the choice, we have two schemes for each part.

Fig. 1 shows the process of the tokens storage on the server in CloudS [19, 20] (the CloudS can use not only three services shown in Fig. 1). First, the user authorizes all cloud storage services; second, the client gets tokens from the services; finally, the tokens are stored on the server. If the user chooses another scheme, the Step 3 is needless. The tokens are just stored on the local computer.

Fig. 2 shows the process that the user gets tokens from the token server, and uses them to access the data on the cloud services (If he or she chooses the local, Step 1 and Step 2 are needless. The client can get the tokens from the local). If the user passes the authentication of the server, the client can get the tokens. Then, it sends the tokens to the cloud storage services. If the tokens are legal, the services will return the data to the client.

3.1 User authentication

Note that, the encryption algorithm that we used in the implementation is AES [16], and the hashing function is MD5 [17, 18].

(4)

1 1 1 2 ₂ 2 3

Vdisk Skydrive Dropbox

CloudS

Fig. 1: The process of token storage

2 2 2 3 ₃ 3 1

Vdisk Skydrive Dropbox

CloudS

Fig. 2: The process of token read

Scheme 1: The user chooses to store tokens on the local computer.

For the choice, the process of user authentication is none of the business of the network trans-mission.

When the user uses the system at the first time, we will create a XML file to store the Account, the hash of Password and the token encrypted with the Password. We build a mapping relation between them and the Account is the main key. If passing the verification next time, he will get the encrypted tokens. By decrypting them with his password and sending each of them to the corresponding cloud, he can get the access to the clouds, which is executed on the Client.

The goal of the scheme is to avoid illegal users to crack the password by means of speculation and others.

Scheme 2: The user chooses to store token on the server provided.

The scheme learns from the kerberos protocol and the Challenge/Response mechanism. Take the validator technique of the former and no transmitting secret key during the communication of the latter for reference.

The authentication process as follows:

Step 1: The user logins in the system and the client sends the Account to the server. If there doesn’t exist the Account, the server returns “Error”. Otherwise, it generates a random R and encrypts it with Hash (password) (namely Secret). Finally, the server sends the encrypted message to the client.

Step 2: If the client receives “Error”, it will be asked to login again. Otherwise, it decrypts the message and gets R. Then, it generates a random R1, and encrypts it withR. Finally, the client sends the encrypted R1 and R1 to the server.

Step 3: The server decrypts the received message with theR and compares it with R1. If they completely match, the user passes the verification and gets the encrypted token; else, it gets the Error return.

Step 4: If the client receives the Error return, the user can choose to login again or quit; else, it sends “OK” to the server.

(5)

The scheme avoids the transmission of the secret information, except the encrypted token which is inevitable. Moreover, the changing random number and the timeliness of information prevent the attack effectively.

3.2 Token management mechanism

Similarly, there are two schemes in the design of the token management mechanism.

Scheme1: The token is stored on the local computer. The specific process is shown in Fig. 3. When the user registers, the authentication information would be stored on the local computer.

First use? Login

Account exists and Password matches? No No Token exists？ Yes Decryption successful? Registration successful? Yes No Authorization to cloud storage providers

successful?

Cloud storage services

Encrypt the new Token and store it in the local computer

Yes Yes Yes Yes Start No No

Fig. 3: Token management based on the local computer

Because we appoint the Account as the main key mapping to the encrypted password and tokens, the duplicate Account is forbidden. If the Account is legal, the user should authenticate to the chosen cloud storage providers, and then store the encrypted token.

When the user logs to the system and he passes the authentication, the system will return the tokens. If the tokens do not exist or cannot been used after being decrypted, the user has to reauthenticate to all the cloud services he has chosen and the new encrypted token will be stored locally.

Scheme2: The token is stored on the server. There is a little difference, compared to the local token management. When registering on the server, the user needs to fill in the information according to the website, and then the information and the tokens will be stored on the server after being encrypted.

3.3 Implementation

While implementing our schemes in CloudS [19, 20], a multi-cloud storage system, there are two important things should be addressed, data structure and timer.

(6)

Data structure is used to mark the messages during the user authentication. Each message has a header which means the type of message. This mark together with the timer is against the attacks from hackers.

4 Experimental Results

4.1 Experimental environment

The experimental environment is shown in Table 1.

Table 1: The experimental environment configuration

CPU Intel Core i3-390M (dual-core system)

Memory 2GB

Hard Disk WDC WD5000BEVT-24A0RT0

Network 10Mbps

Operating System Windows 7 professional SP1 32bit

4.2 The security and correctness of the framework

We do a series of experiments to verify the security and correctness of the framework. Table 2 shows the results. After the user authorizes all cloud storage services, the token will be uploaded on the server or stored on the local computer. When logging in the system again, he can get the stored token successfully. After one cycle time, the token will be updated. But when the token is expired, the user has to reauthorize.

Table 2: The result of function experiment

Goal Function Scenarios Result

correctness Token Upload After authorization Successful Token Update After one cycle Successful Token Download Log in the system Successful Reauthorization Token expired Successful security Authentication False Password Get token failed

Token protect

Server Attack the Server Get encrypted token Local Maliciously stolen Ditto

If the illegal user logs in the system, he cannot pass the authentication and cannot get the token successfully.

(7)

When the illegal user attacks the server or maliciously steal token from the local computer, he can get the encrypted token. However, he or she cannot pass the authentication of the clouds without the password.

The functional experiment is related to the comprehensiveness of the token management. Through the experiment, we find that all cases are to be carried out as expected.

4.3 Performance results

The performance experiment is about the time that uploading the token to the server or down-loading from server takes. It is conducted in CloudS. There are eight cloud storage services on CloudS, including Kuaipan, Dropbox, DBank, Kanbox, Vdisk, SkyDrive, Box, GoogleDrive; and in the experiment, we add services by the order. Along with the increase number of services, the total size of tokens increases gradually. According to the results shown in Fig. 4, we can make summaries: 400 500 600 700 800 900 1000 441B 736B 1KB 1.23KB 1.46KB 2.84KB 3.10KB 3.38KB Ti me （ ms ） Token Size Upload time Download time

Fig. 4: The time of uploading the token to the server and downloading from the server

(1) The upload time and down time are very short, which makes no bad effects on the user experience because this overhead only happens once when logging in;

(2) The time is no more than one second;

(3) The time is depended on the network condition.

5 Conclusion

In this paper, we mainly concern the security of the user authentication and the comprehensiveness of the token management. It’s a tradeoff between security, ease of use and performance. We design a framework to securely store the tokens, which is based on a newly designed user authentication mechanism and a token management mechanism. The framework is implemented on a multi-cloud storage system, and its effectiveness and performance is tested. Through the experimental results, we can see the performance and the functions both conform to the expected results.

(8)

In the future work, we will design a generalized token interface with new parameters which are used to add the security. Learning more about the key management technology, such as PGP, we will improve our framework to achieve better security. All in all, we will do more efforts to design the secure cloud storage system and to design more secure user authentication.

References

[1] Oracle, https://blogs.oracle.com/gbrunett/entry/amazon s3 silent data corruption.

[2] C. Cachin, I. Keidar and A. Shraer, Trusting the cloud, ACM SIGACT News, 40 (2), 2009, pp. 81-86.

[3] R. A. Popa, J. R. Lorch, D. Molnar, et al. Enabling security in cloud storage SLAs with CloudProof [C]. Proceedings of 2011 USENIX Annual Technical Conference, Portland, OR. 2011.

[4] RedHat, https://rhn.redhat.com/errata/RHSA-2008-0855.html.

[5] Sun, http://blogs.sun.com /gbrunett/entry/ amazon s3 silent data corruption.

[6] GroβS, Schill A. Towards user centric data governance and control in the cloud [J]. Open Problems in Network Security, 2012, pp. 132-144.

[7] Dancho Danchev. How many people fall victim to phishing attacks? http://www.zdnet.com/blog/s ecurity/how-many-people-fall-victim-to-phishing-attacks/5084. 2009.

[8] A. Bessani, M. Correia, B. Quaresma, F. Andr´e and P. Sousa, DepSky: dependable and secure storage in a cloud-of-clouds, EuroSys ’11: Proc. 6th Conf. on Computer systems, 2011, pp. 31-46. [9] H. Abu-Libdeh, L. Princehouse and H. Weatherspoon, RACS: a case for cloud storage diversity,

SoCC ’10: Proc. 1st ACM symposium on Cloud computing, 2010, pp. 229-240.

[10] C. Cachin, R. Haas and M. Vukolic, Dependable storage in the Intercloud, Research Report RZ, 3783, 2010.

[11] K. D. Bowers, A. Juels and A. Oprea, HAIL: A high-availability and integrity layer for cloud storage, CCS ’09: Proc. 16th ACM Conf. on Computer and communications security, 2009, pp. 187-198.

[12] M. A. AlZain, E. Pardede, B. Soh, J. A. Thom, Clouding Computing Security: From Single to Multi-Clouds, 45th Hawaii International Conference on System Sciences, 2012.

[13] L. Lamport, R. Shostak and M. Pease, The Byzantine generals problem, ACM Transactions on Programming Languages and Systems, 4 (3), 1982, pp. 382-401.

[14] C. Neuman, T. Yu, S. Hartman, K. Raeburn, The Kerberos network authentication service (V5), Internet RFC 4120, July 2005.

[15] C. Neuman, The Kerberos network authentication service (V4), Internet RFC 1510, September 1993.

[16] FIPS PUB 197, Advanced encryption standard (AES), National Institute of Standards and Tech-nology, U.S. Department of Commerce, 2001.

[17] R. Rivest, The MD5 message-digest algorithm, RFC 1321, Internet Engineering Task Force, 1992. [18] Xiaoyun Wang, Hongbo Yu, How to Break MD5 and Other Hash Functions, Lecture Notes in

Computer Science 3494, 2005, pp. 19-35.

[19] Ming Xu, Reliable cloud storage technology escaping vendor lock-in [Undergraduate Thesis], Tian-jin: Nankai University, 2013.

[20] Bin Zhang, Multi-cloud storage based on non-systematic code [Master Thesis], Tianjin: Nankai University, 2013.