A simple and secure framework for protecting sensitive data stored on the cloud
Authors: Yaacoub Elias , Sakr Ali , Noura Hassan 
Published: June 2019

In the past decade, Cloud-Computing emerged as a new computing concept with a distributed nature using virtual network and systems. Many businesses rely on this technology to keep their systems running but concerns are rising about security breaches in cloud computing. This work presents a secure approach for storing data on the cloud. the proposed methodology is described as follows: 1) The client who wants to store data on the cloud subscribes with n cloud providers (CPs). 2) A file F to be stored on the cloud is subdivided into n parts, or subfiles: F1, F2,.... Fn. 3) Each part is encrypted with an encryption key Kf. The encrypted parts are denoted by F1*, F2*,…, Fn*. 4) A random permutation vector P(f) is generated. 5) The encrypted parts are stored on the n clouds according to P(F); in other words, due to P(F), F1* could be stored on CP3 for example F2* on CPn, etc. 6) In order to be able to retrieve his files, the client needs to maintain some information related to the distribution of the various parts and to the encryption of the file. Thus, he maintains two tables. 7) The first table contains a hash of the file name H(F_name), and the key Kf. 8) The second table contains a hash of the file name H(F_name), a hash of the file content itself (unencrypted) H(F), a hash of the encrypted file content H(F*), and the permutation vector P(F), encrypted with Kf. 9) The two tables are stored on different servers protected by advanced security measures, and preferably located at different locations. 10) In order to obtain the file, the client enters the file name. Then the system computes the hash value of the name, finds the corresponding entry in Table 1, and obtains the key. Then, the corresponding entry in Table 2 is found. The key, obtained from Table 1, is used to decrypt the permutation vector P(f). Then, the encrypted parts are downloaded from the different cloud providers. Afterwards, they are assembled in the correct order and decrypted. The hash values of the encrypted and unencrypted versions are then computed and compared to their corresponding values stored in Table2 in order to check for the integrity of the file downloaded from the cloud. This approach allows the client to use the same storage space on the cloud: Instead of using a single cloud provider to store a file of size S bits, the client is using n cloud providers, where he stores S/n bits with each cloud provider. Thus, the storage costs of the two methods are comparable. If the client wishes to introduce redundancy in the file, such that he can recover the whole file from j parts instead of n parts, with j&lt; = n, then redundancy can be added to the original file as appropriate. In this case, the storage costs will increase accordingly, but this is an added enhancement that can be used with or without the proposed approach. On the other hand, the overhead due to the proposed approach consists of maintaining two tables containing the information relevant to the file. The storage required to maintain the entry corresponding to each file in these two tables is small compared to a typical file size: in fact, we only need to store a few hash values (of fixed size), along with the encryption key. This seems a reasonable price to pay for a client that has sensitive data that he cannot post unencrypted on the cloud, or even posting it encrypted with a single provider is risky in case a security breach occurs at the provider»s premises.