Secure information storage

Transcription

1 Secure information storage in a private cloud built upon local network resources Student Project for Large Installation Administration Master of Science in System and Network Engineering Universiteit van Amsterdam Class of Vic Ding (vic.ding@os3.nl) Damir Musulin (damir.musulin@os3.nl) March 26, 2011 Version 1.0

2 Executive summary This project investigates how to securely store data in a private cloud where users can locally access data of each other since every user workstation is being used as storage node. Two approaches are illustrated on how to archive better security of data store. One is targeted distribution and the other one is on-the-fly cryptography. The first one focuses on store data with certain permission only in designated groups of computers. And the later one focuses on encrypt the data to prevent unauthorized access. These two methods can also be applied to public clouds. An open source implementation of private cloud storage, Swift 1 from OpenStack 2, is used to build our test environment. It is picked due to its openness and being generic. 1 storage solution from OpenStack 2 open source implementation of private cloud from NASA and RackSpace Version 1.0 2

3 Table of Contents Executive summary... 2 Chapter 1 Introduction...4 Chapter 2 Research and approach... 5 Chapter 3 Project environment...6 Chapter 3.1 What is Swift?... 7 Chapter 4 Targeted distribution... 8 Chapter 4.1 Setup for targeted distribution...9 Chapter 4.2 Operation of targeted distribution Chapter 5 Cryptography layer Chapter 5.1 Swift concept and place to inject cryptography Chapter 5.2 Revised server.py Chapter 6 Conclusion Chapter 7 Limitations & future study...17 Appendix A Cryptography methods in server.py for object storage node References Version 1.0 3

4 Chapter 1 Introduction With the evolve of the modern computer and network facilities, the power of these devices is enhanced remarkably. However, most computing power of the workstations are normally wasted when they are being idle or the CPU, memory and hard disk being only slightly used during the working hour. In order to utilize the already-paid-for equipments efficiently, a private cloud upon local network can be built to offload the burden of servers. It is not only comply with the trend of green IT but also can reduce cost for the organizations. Within the private cloud environment, data is stored across the whole network. It might then be the case that certain sensitive information get stored locally to a user who should never be able to access it or user can go around the file system to access each other's data. To address this issue, we carried out this project with the following research question: How can data be securely stored in a private cloud environment where user has local access to it? In this research two methods are discussed which can be used to mitigate the risk and secure the data stored in the private cloud Version 1.0 4

5 Chapter 2 Research and approach Based on the research question, two approaches are being investigated. The two approaches are: 1. Targeted distribution - Store the privileged data only on the computer of the privileged users. 2. Cryptography layer - Build extra layer to en/decrypt data upon read and write. The first approach deals with the problem of distribution of data in the cloud/network. If information is distributed in the cloud/network, there needs to be a way to control the distribution in the cloud/network so that information is stored in locations that are preferred. An example could be that information is stored in a network section that is more secure than the general network. The second approach deal with adding an cryptography to the private cloud software. Adding cryptography to the private cloud allows the uploader of information to encrypt the information when uploading the information to the cloud. This allows the information to be stored anywhere on the network, because the information is encrypted and you will need the password to decrypt the information. Once the user needs to retrieve the from the cloud, the user specify the information needed and gives the password to decrypt the information. With these two approaches there is a possibility two answer the research question in two different manners. The first possibility is securing data by storing it on a different part of the network thus denying access to ordinary users. The second possibility is to encrypt the data by adding an encryption layer thus the local user cannot access the information Version 1.0 5

6 Chapter 3 Project environment The research is focused on security in the private cloud. To do the research there is a need for private cloud software, so that the research approaches can be implemented on the private cloud software, when there is a possibility to do so. Because there are multiple implementations of private cloud software, the choice for a specific implementation of private cloud software is based on software with a liberal license, like GPL,BSD and the Apache license. Another criteria is that there is are problems with the private cloud software. an active community so that there is support when there For the project environment OpenStack software was chosen because of the liberal Apache license 3 and the strong community, with big companies/institutions like NASA 5 (National Aeronautics and Space Administration) and Cisco 6 supporting the project. For the research other private cloud software could be used but the liberal license and the strong community convinced us to use OpenStack in our project environment Version 1.0 6

7 Chapter 3.1 What is Swift? Swift is the object storage system for the OpenStack private cloud. OpenStack consists of individual components that together make up the OpenStack object storage. The components that make OpenStack object storage are: 1. OpenStack Swift Object storage nodes 2. OpenStack authentication system 3. OpenStack proxy system Figure 1 OpenStack Object Storage Figure 1 originated from the documentation webiste of Swift Version 1.0 7

8 Chapter 4 Targeted distribution The first approach to the security of data in the could be targeted distribution. With targeted distribution the user gets the possibility to decide to which part of the network the user data is distributed to. The idea behind targeted distribution is that a network consists of different segmented parts, with different security levels applied to the network segments. If the user has data that is mission critical then the user can decide to distribute the data over certain part of the network which is more secure that the general network. An example would be that information from company management is only distributed among the computers that meet a certain security standard of the company. Targeted distribution gives the possibility to the board of directors where to store the data and meanwhile maintaining high availability. Figure 2:logical network layout for targeted distribution In figure2 there are five logical network segments. If the company management wants to store mission critical data then the data can only be stored on computers that have a security standards that meet the needs of the data storage requirements of the company management. In this case the management can thrust their network and the network segment with elevated security standard. The management can target these computers to store the data of the management, this is the idea of targeted distribution Version 1.0 8

9 Chapter 4.1 Setup for targeted distribution To generate a network layout like figure2 for targeted distribution, the Swift object storage system needs to be modified to be aware of the different network segments. A way to make the object storage system aware of the different network segments is the use of LDAP. With the help of LDAP server and modification on Swift, it is possible to let the storage cloud be aware of different segments of the network. An issue with targeted distribution is that the scalability can be problematic. Swift storage nodes are pre-defined in the initial state of setup. In a later stage, addition of storage nodes to a network segment will require that every node in a network segment is redefined, to become aware of the addition of storage nodes. When adding nodes to a network segment, the configuration in LDAP needs to be manually changed to be able to adopt the changes Version 1.0 9

10 Chapter 4.2 Operation of targeted distribution Figure 3: LDAP operations In figure 3 node 12 requests information from the LDAP server. When node 12 receives the information from the LDAP server, node 12 can request all nodes in the same segment to become a segment with other nodes in the same segment Version

11 Chapter 5 Cryptography layer Cryptography is a common practice in securing data storage nowadays. It ensures that even the data is accessible to unauthorized person, it can still be kept safe. In our project, in order to leave the user environment as simple and independent as possible, we decide to implement the cryptography on the server side. To be more specific, we revised the code of storage node to let it encrypt and decrypt data during the upload and download of files. When user upload a file, the file contains original data without encryption. In the current version of Swift, user with local access can operate on it if he can locate the file on the local file system. We revised the code in the way that it encrypts the file during the upload time with Advanced Encryption Standard (AES) 8 using the Python Crypto library 9. In figure4, we can see the same text file before and after the encryption. Figure 4 The original file size is 2 bytes, and become 16 bytes after encryption. The file is padded by the implementation of AES, and 16 bytes is the minimum length of the file, due to the minimum key size being used. In figure5, we can see the encryption of a picture. Figure Advanced Encryption Standard Python crypto library project website Version

12 It shows clearly that users can upload any type of files, it will then be secured by encryption with the private key of the user. When user wants to download it, it will be automatically decrypted if the user can provide the same correct key. Hence, the data can be stored securely. The procedure will be elaborated in detail in next chapter Version

13 Chapter 5.1 Swift concept and place to inject cryptography First of all, according to the concept of Swift, everything must be put in a ring. Everything here includes, account, container and object. For object, there is an object ring. Since we are going to encrypt only the objects, the real file, so we choose to revised the object server, server.py. It implement the storage nodes which participate in the ring operation Figure The idea behind this file is simple. It reassembles a Web Server Gateway Interface (WSGI) 11 to handle all the requests from users. When user submits a request, it will be converted to a HTTPS request, handled by the WSGI then communicated internally with the storage nodes where the real file is being stored. The WSGI class defined in server.py for objects is the single point where both download and upload are handled. It is the ideal place to inject the cryptography codes without over altering the original Swift system. Figure Origin of figure 6 in the installation document of Swift on its official website 11 Web site of WSGI (Web Server Gateway Interface) which is a Python standard PEP Version

14 However, there is no central point of editing. As illustrated from the above Figure 6, each storage node is purposely separated from each other to maintain high scalability. Meaning to say that the WSGI is implemented on each of the server. The revised server file has to be propagated to every server. In order to save manual labour, automation tool, like CFengine 12 can be used to mitigate this problem CFengine is a powerful data center configuration automation tool Version

15 Chapter 5.2 Revised server.py Below is the code snippet we inserted into the WSGI implementation. def encrypt_file(chunk, key, IV, blocksize=64*1024): def decrypt_file(chunk, key, IV, blocksize=64*1024): These two functions serve the purpose of encryption and decryption. The hashed key of the operator's account will be used as key. The reason of hashing the key besides improved security is that the Python library we use is quite low level, it is efficient but requires pre-padded fixed length key of either 16, 24 or 32 bytes. And the product of such a Secure Hash Algorithm 256 (SHA256) 13 is just 32 bytes long 14. The Initial Vector (IV) could be 16 bytes random string. We can store the IV as the first 16 bytes of the encrypted file, and let the server read from it each time upon downloading request. The quality of IV has high impact on the quality of cryptography and does not expose information to cracker by itself. That is why we can store it together with the encrypted file and have it randomly generated each time. The block size is the size of the data chunk we are going to operate on each time. The size of the network buffer is (64 * 1024). We set here the chunk size to the same to avoid unnecessary split or merge of the chunks which will save the computational power of computer and hence leverage the efficiency. The file level operation is handled by the Swift system. What we have to do is only pass the encrypted chunk to the handler or get the encrypted chunk from the handler. The whole revised code can be found in Appendix A Secure Hash Algorithm 14 In section Comparism of SHA functions, there it indicates the length of product of SHA Version

16 Chapter 6 Conclusion The conducted research concludes a positive answer to the research question, so that by using both of the presented methods, data can be secured in the private cloud where user has local access rights. However, there are advantages and disadvantages concerning each of them. With targeted distribution, the number of computers which can be used to store data is limited by the fact that some of them fall in a lower security group. Hence the utilization of the resource is again suboptimal. But the security level can be leveraged largely as one can argue that there is no way to break the system if the cracker do not even get the system. The highly secured data are only accessible to the ones who should have the right to access it. With the cryptography layer, the number of computers which can be used to store data is only limited by the total amount of available computers in the organization. In this case, it is making optimal usage of the available resources. However, the cryptography can impulse large performance penalty especially in the case of encrypting large amount of data. Though there are still limitations and disadvantages to each of the approach, they can be possibly covered by the future studies recommended in the later chapter on limitations and future studies. During the project, investigation on the CAP (Consistency, Availability and Performance) of the storage nodes before and after modification is also being carried out. From the overview 15 of Swift, it says that the consistency is sacrificed to archive better availability and performance. The same symptom can be observed after our modification to the software package. The consistency of the files is inheritably low. In the real use cases, even after days, there are still different versions of the same file on different storage nodes even when the synchronous timer is set to every one hour. The availability is generally high in case of cryptography approach. But it is highly dependent on the amount of machines in certain group when targeted distribution is used. The performance is depending on the active machines which are handling the request Version

17 Chapter 7 Limitations & future study There are two limitations in our project: 1. There is no implementation of targeted distribution. Instead, only a proof of concept is illustrated in the report. 2. Storage node is accessible from other networks. It takes long time to implement such a targeted distribution in Swift. The distribution of the replications is controlled by the combination of the corresponding ring file and rsync which lies on the bottom layer of the software package. In order to change the behaviour of distribution, it will require modification to both the ring file and rsync. The time expected to archive such modification clearly falls out of our study scope. We only made a proof of concept as a show case instead of making a working system. In the manual 16 of Swift, it mentioned that the storage nodes contains the data and should be put into a separate network which is only accessible to local network. However, in our settings it is not the case. We ran seven virtual machines on two lab servers. One for proxy server, one for authentication server and five storage nodes. We have to simulate the situation that the storage nodes are accessible to local users. To be able to archive that effect, we use each other storage nodes as the access terminal to access the local data of other nodes. To be able to let us get into the "terminals", we have to enable the access to outside. These are the two limitations we faced and dealt during the study. We would like to recommend for limitation one a future study, implementation of targeted distribution. It is interesting to see in reality how the behaviour of the distribution can be controlled and the replications are arranged in the way that comply to organizational security policies. In addition to that, a very interesting and important further step can be taken to extend this study and make it more useful. We would like to see what is the possibility and effect to pull away the authentication server, where the keys are located, to customer side. Now many organizations' concern is if they use external storage their keys are out of their control since the authentication or key server will be located on the supplier side. If the further study can show that the keys can be kept within the organization and only communicated with the service provider in a secured way, it will certainly enhance the confidence level of customers, and can then make better use of the technology Version

18 Appendix A Cryptography methods in server.py for object storage node def encrypt_file(chunk, key, iv, blocksize=64*1024): iv = ''.join(chr(0) for i in range(16)) encryptor = AES.new(key, AES.MODE_CBC, iv) if len(chunk) % 16!= 0: chunk += ' ' * (16 - len(chunk) % 16) return encryptor.encrypt(chunk) def decrypt_file(chunk, key, iv, blocksize=64*1024): iv = ''.join(chr(0) for i in range(16)) decryptor = AES.new(key, AES.MODE_CBC, iv) return decryptor.decrypt(chunk) Version

19 References 1. storage solution from OpenStack 2. open source implementation of private cloud from NASA and RackSpace sou/ Figure 1 originated from the documentation webiste of Swift Advanced Encryption Standard Python crypto library project website 9. Origin of figure 6 in the installation document of Swift on its official website Web site of WSGI (Web Server Gateway Interface) which is a Python standard PEP CFengine is a powerful data center configuration automation tool Secure Hash Algorithm In section Comparism of SHA functions, there it indicates the length of product of SHA Version