Evaluation of Security Supporting Mechanisms in Cloud Storage

Abdullah A. Albahdal, Fahad Alsolami, and Fawaz Alsaadi

Department of Computer ScienceUniversity of Colorado at Colorado Springs

Colorado Springs, Colorado{aalbahda, falsolam, falsaadi}@uccs.edu

Abstract—Cloud storage is one of the most promising ser-vices of cloud computing. It holds promise for unlimited,scalable, flexible, and low cost data storage. However, securityof data stored at the cloud is the main concern that hindersthe adoption of cloud storage model. In the literature, thereare many proposed mechanisms to improve the security ofcloud storage. These proposed mechanisms differ in manyaspects and provide different levels of security. In this paper, weevaluate five different mechanisms for supporting the securityof the cloud storage. We begin with a brief description of thesemechanisms. Then we evaluate these mechanisms based on thefollowing criteria: security, support of writing serializabilityand reading freshness, workload distribution between the clientand cloud, performance, financial cost, support of account-ability between the client and cloud, support of file sharingbetween users, and ease of deployment. The evaluation sectionof this paper forms a guide for individuals and organizations toselect or design an appropriate mechanism that satisfies theirrequirements for securing cloud storage.

Keywords-Cloud Computing; Cloud Storage; Cloud Security;

I. INTRODUCTION

The promising features of cloud computing attract many

individuals and organizations to leverage the cloud. These

features include but not limited to: scalability, accessibility,

on-demand model of services, and low cost. However, the

cloud has its security limitations which have prevented many

individuals and organizations from leveraging the cloud [1].

Many security incidents for many cloud storage providers

make clients think twice before migrating their data to the

cloud. For example, in June 2011, an update to the Dropbox

system affected the authentication mechanism and made all

clients’ files accessible with wrong passwords [2]. Another

example, a deployment of a new faulty load balancer in

Amazon S3 data center has resulted in corrupting customers’

data, which resulted in making the data does not match with

its hashes used to verify files’ integrity. Amazon announced

that the load balancer was corrupting a single byte in the

byte stream for more than 36 hours [3].

Moreover, none of today’s popular cloud storage

providers; such as Amazon S3, Google Drive, Microsoft

Azure, and others; provide security guarantees in their

service level agreement [4]. For example, Amazon states

in its service level agreement for Amazon Cloud Drive:

”We do not guarantee that Your Files will not be subject to

misappropriation, loss or damage and we will not be liable

if they are. You are responsible for maintaining appropriate

security, protection and backup of Your Files” [5].

In order to protect cloud’s clients against such incidents,

the literature contains many proposed mechanisms to support

the security of data stored in the cloud. These mechanisms

can be divided into two categories. Firstly, mechanisms have

been designed for protecting data stored on remote files

systems and have been deployed to support data security on

the cloud such as Cryptographic File System (CFS) [6] and

Securing Remote Untrusted Storage (SiRiUS) [7]. Secondly,

mechanisms have been designed specifically for supporting

the data security on the cloud such as CloudProof [4],

CloudSeal [8], and DepSky [9].

In this paper, we evaluate five of the security supporting

mechanisms for cloud storage. Our evaluation depends on

the following criteria: security, support of writing serializ-

ability and reading freshness, workload distribution between

the client and cloud, performance, financial cost, support of

accountability between the client and cloud, support of file

sharing between users, and ease of deployment.

The rest of this paper is organized as follows. Section II

contains a brief description of two common used crypto-

graphic file systems which have been leveraged to support

data security for cloud storage. These cryptographic file sys-

tems are CFS [6] and SiRiUS [7]. Section III describes three

mechanisms for supporting the security of cloud storage

including CloudProof [4], CloudSeal [8], and DepSky [9].

Section IV evaluates these different mechanisms in details.

This evaluation can form a guide for individuals and organi-

zation to select or design an appropriate mechanism which

satisfies their security requirements.

II. CRYPTOGRAPHIC FILE SYSTEMS

In this section, we present an overview of two crypto-

graphic file systems: CFS [6] and SiRiUS [7]. These secure

files systems have been adopted for enhancing the cloud

security.

A. Cryptographic File System for Unix

The cryptographic file system (CFS) [6] is a crypto-

graphic module located at the file system itself responsible

for encrypting/decrypting files. Placing CFS at this level

2014 11th International Conference on Information Technology: New Generations

978-1-4799-3187-3/14 $31.00 © 2014 IEEE

DOI 10.1109/ITNG.2014.110

285

overcomes the weakness of user-level and system-level file

encryption modules. For the user-level file encryption mod-

ules (i.e. Unix crypt), they require users to interact frequently

to encrypt/decrypt files or to provide encryption keys. This

approaches is vulnerable to users errors since it does not

perform the encryption/decryption automatically and relies

directly on the user interaction (i.e. user may forget to

encrypt a file and leave it as a plaintext after decrypting it).

For the system-level file encryption modules, they require

users to identify the trusted system components which can

be trusted with the files plaintexts and requires a special

hardware that support cryptographic tools.

CFS requires the minimum interaction from users. Users

only need to enter the encryption keys once per session.

Also, CFS works in a seamless manner similar to the under-

lying file system (i.e. using the file system calls). Moreover,

CFS does not require any changes to the underlying file

system and the underlying file system operations (i.e. backup

and restore) can be performed normally.

When a user requires opening an encrypted file, CFS asks

the user to enter the decryption key (once a session). Then,

CFS creates a virtual file system mounted on /crypt and put

the plaintext of the requested file under /crypt. The original

encrypted files remain unchanged until a user request to

perform a writing operation.

For encryption, CFS uses double encryption to protect

against attacking the encryption keys by identifying two

identical files which produces the same ciphertext if ECB

mode (Electronic Code Book mode) is used. CFS does

not consider chaining mode since CFS requires arbitrary

access to files and using changing will severely decrease the

encryption and decryption performance. Hence, CFS follows

the following way to encrypt files. Firstly, CFS creates a

pseudorandom bit stream using half of the user’s passphrase

with DES Output Feedback mode (OFB mode). Secondly, a

first encryption is performed by XOR the file to be encrypted

with the generated pseudorandom bit stream. Thirdly, the

resulted bit stream is encrypted using the second half of the

user’s passphrase with DES in ECB mode.

B. SiRiUS: Securing Remote Untrusted Storage

Securing Remote Untrusted Storage (SiRiUS) [7] is a

security mechanism to enhance the security of remote file

systems. SiRiUS can be applied without changing the un-

derlying remote file system or the remote server which has

two main advantages. Firstly, it makes it easy for users to

use and install SiRiUS. Secondly, SiRiUS can be applied on

the top of any network file system (i.e. NFS, CIFS, or P2P).

SiRiUS is designed to support file sharing between users

with different access permissions (i.e. read-only or read-

write). Also, SiRiUS supports both data confidentiality and

integrity (i.e. detecting unauthorized modification of files).

In addition, SiRiUS is designed to guarantees both the date

Figure 1. The structure of the meta-data file for SiRiUS [7].

Figure 2. The structure of the encrypted key block for SiRiUS [7]. (a)illustrates the structure of the key block for users with read-write accesspermissions, while (b) illustrates the structure of the key block for userswith read-only access permission.

and meta-data freshness to ensure that the latest version of

the file is returned upon request.

To achieve these objectives, SiRiUS leverages the follow-

ing cryptographic techniques: symmetric encryption, asym-

metric encryption, hash functions, and digital signatures.

Figure 1 shows the format of the meta-data file which

is attached to each file stored in the system. The meta-

date file contains encrypted key blocks for the file’s owner

and each user with read or write permissions on the file.

Figure 2 shows the structure of the encrypted key block for

users with read-only and write permissions. If the user has

writing permission on the file, his encrypted key block will

contain a key of decrypting and re-encrypting the file and a

private key for signing the file after writing to it. If the user

only has read-only permission, his encrypted key block will

contain only a key for decrypting the file. Each encrypted

key block is encrypted with its user’s public key. The meta-

date file also contains the file’s public key, timestamp of last

modification, file name, and the owner’s signature using his

private key.

SiRiUS provides the confidentiality as follows: no users

can access a file unless he/she has an encrypted key block in

the file’s meta-data file. For Integrity, SiRiUS provides the

integrity as follows: each user accessing the file can check

the integrity of the file by checking the signature attached

to the file itself using the file public key in the meta-data

file. The integrity of the file’s public key can be ensured be

checking the signature attached to the meta-data file using

the owner public key. Finally, the meta-data file freshness is

ensured by implementing a hash tree which contains hashes

of all the user meta-data files. Users use this hash tree

structure every time they access a file to ensure the freshness

of the meta-data file. Freshness is used as a countermeasure

286

Figure 3. The structure of attestations of CloudProof [4].

Figure 4. The structure of data block and family key block for Cloud-Proof [4].

against rollback attack, which allows an attacker to mislead

users to access a fake file.

III. SECURITY SUPPORTING MECHANISMS FOR CLOUD

STORAGE

In this section, we present an overview of three security

supporting mechanisms for cloud storage: CloudProof [4],

CloudSeal [8], and DepSky [9]. These mechanisms have

been designed especially for securing the cloud storage.

A. CloudProof

CloudProof [4] is a security supporting mechanism for

cloud storage. It is designed to provide the following ob-

jectives: Confidentiality, Integrity, freshness, and writing

serializability. CloudProof can also detect any violation

of Integrity, freshness, and writing serializability and the

violation can be proved for a third party. Such a proof can

allow the client the cloud provider to agree on a contract (i.e.

SLA) which states that the client will be compensated in case

of integrity, freshness, or writing serializability violations.

CloudProof uses attestations as a building block to provide

proofs in case of violations. Attestations are messages signed

by either the client or the cloud and exchanged between them

for different requests. Figure 3 shows the structure of the

client writing (put), cloud writing (put), and cloud reading

(get) attestations. For reading a data block, the client is not

required to sign an attestation. Also, CloudProof relies on

Broadcast Encryption and Key Rolling for managing access

control and key distribution.

CloudProof groups data blocks into family blocks. Each

family block contains the data blocks with the same ac-

cess control permissions (i.e. same users with the same

permissions). Each family block has one family key block

that contains the following: encryption key encrypted us-

ing broadcast encryption according to users with read-

only permissions in the ACL, the signing key encrypted

using the broadcast encryption according to users with write

permissions in the ACL, verification key that belongs to the

signing key, version of the encryption key, and the version

of the verification key. The family key block is signed with

the owner private key. Figure 4 shows the structure of the

data blocks and family key blocks.

CloudProof provides data confidentiality as follows: no

user can decrypt a data block unless the user is listed in the

ACL (belongs to the data block) with read-only or write

permissions. The user can access the data by decrypting

the encryption key in the family key block (using the key

given using the broadcast encryption) and decrypting the

data block using the obtained key. For Integrity, any user

can verify the integrity of the data by checking the signature

attached to the data block. The cloud also required to check

the signature of the written data block before writing it to

the cloud.

Before describing how CloudProof can provide a proof

for the different violations, let’s describe how and when

attestations are exchanged. When a client requires a data

block, he sends the data block ID along with a nonce (to

prevent the cloud from pre-computing the get attestations).

the cloud returns the data block along with an attestation

which contains the block ID, the version of family key block,

the version of data block, hash value of the data block, chain

hash (i.e. the hash value of the data block concatenated of

the previous chain hash), and a nonce. When a user wants to

write to a specific data block, the user signs the block and

sends it along with a put attestation containing the following:

block ID, the version of family key block, the version of

new data block, hash value of the new data block. The

cloud checks the signature of data block, the hash of the

new data block, and the version of the new data block is

the version of the current data block incremented by one.

If all the previous conditions hold, the cloud responds with

the cloud put attestation containing the data block ID, the

version of family key block, the version of data block, hash

value of the new data block, and chain hash.

Now let’s consider how a client can detect and prove

violations of integrity, writing serializability, and freshness.

Firstly, a client can detect violations of integrity when the

signature attached to a data block cannot be verified against

the data block. The client can proof this violation using the

data block and the cloud get attestation. Secondly, a client

can detect violations of writing serializability if there is

more than one put attestation with the same version number

between the smallest and largest versions in the sequence or

the version number is incremented by more than one. The

user can proof this violation using the sequence of the put

attestations along with the cloud attestations for the current

family key block. Finally, the client can detect violations

287

of freshness if a writing serializability violation is detected,

one of the hashes in the read attestations does not equal to

the new hash to the put attestation with the same version

number, or the chain hash of two consecutive attestations

form a correct chain hash. The user can proof this violation

by proofing a violation of writing serializability as we

described earlier, by presenting one get attestation and one

put attestation with the same version number having two dif-

ferent hashes, or by presenting two consecutive attestations

that do not form a correct chain hash.

CloudProof divides the time into epochs, at the end of

each epoch the user audit the operation of the cloud looking

for any violations of writing serializability or freshness. For

decreasing the time required to audit all the operations,

a client can assign auditing probability depending on the

importance of the data blocks (i.e. probability of 1 for

the sensitive data blocks and probability of 0.5 for less

sensitive data blocks). The auditing operation does not look

for violations of confidentiality or integrity since users can

detect such violations when reading or writing data blocks.

B. CloudSeal

CloudSeal [8] is a security supporting mechanism that

leverages the Content Delivery Networks (i.e. Akamai) to

share and distribute data stored in the cloud. CloudSeal

mainly provides confidentiality of data and flexible au-

thorization policies (i.e. flexibility in enrolling or revok-

ing users). CloudSeal contains the following components:

content provider (the only user with writing permission),

subscribers, content delivery service, and the cloud provider

(which provides both virtual infrastructure and storage).

CloudSeal can be configured to support forward security

(i.e. a user cannot access files published before joining the

group) and/or backward security (i.e. user cannot access files

published after leaving the group).

CloudSeal archives its objectives using the following

building blocks: symmetric encryption, proxy-based re-

encryption [10], k out of n secret sharing [11], and broadcast

encryption [12] [13]. Now, we describe in brief how Cloud-

Seal put these building blocks together to achieve its goals.

Before the content provider publishes content, he performs a

dual encryption by using symmetric encryption and proxy-

based encryption. Then the content provider publishes the

content to the application service in the cloud along with

the proxy-based re-encryption key. The application service

in turn re-encrypts the message using the re-encryption key

received from the cloud. The resulting ciphertext is separated

into two parts: a small part is stored in the cloud and the

rest is cached in the content delivery network. Both parts

can be decrypted by users with the shared key. When a

change happens in subscribers (i.e. a user joins or leaves

the group), the content provider issues a new proxy-based

re-encryption key and publishes it to the application service.

The application service then re-encrypts the contents using

the new re-encryption key to allow the new changes to take

effect. Only the small part of the ciphertext needs to be

updated while the large part cached in the content delivery

network is not affected.

For user and key management, CloudSeal has two main

operations: user subscription and user revocation. CloudSeal

relies on k out of n secret sharing to share the secret key

and to perform the user subscription and user revocation

operation. When a user joins a group, the content provider

issues his share of the secret. On the other hand, when

is revoked from the group, the content provider broadcast

his share to other users to allow them to compute the new

decryption key.

C. DepSky

DepSky [9] is a security supporting mechanism designed

mainly to improve the availability of data stored in the cloud.

It also supports the data confidentiality and integrity. DepSky

achieves a high level of data availability by dividing the data

into many clouds instead of one. Hence, the data is available

when only a subset of the data divided between clouds can

be retrieved. DepSky uses Byzantine fault-tolerant in order

to maintain a high level of availability of data.

DepSky has two operation modes: Available Dep-

Sky (DepSky-A) and Confidential and Available DepSky

(DepSky- CA). Both of DepSky operation modes provide the

data integrity. For Available DepSky, it simply replicates the

data and stores them in n cloud. Hence, the storage required

to store m size of data is m× n. When the client reads the

data, he requests the data from all the n clouds and stop

when he received the first response. Hence, it is expected

that the performance of the available DepSky will be high

since its response time relies on the fastest response among

n cloud.

For the Confidential and Available DepSky (DepSky-CA),

it provides confidentiality by leveraging the k out of n secret

sharing [11], which is used to securely divide the encryp-

tion/decryption keys among n clouds. DepSky-CA divides

data into n data blocks using Erasure Coding [14], and

these data blocks are distributed over n clouds. To decrease

the required storage, DepSky leverages the information-

efficient secret sharing scheme [15], which combine the kout of n secret sharing [11], the information-optimal erasure

code [14], and symmetric encryption. Instead of requiring

m × n data storage to store data of size m, DepSky-CA

requires m×nk of storage, where k is the threshold of the

required number of shares to recover the secret. When the

client reads the data, he requests all the shares from all the

clouds and stops when he receives k shares.

DepSky achieves its required objectives of availability,

confidentiality, and integrity as follows. Firstly, DepSky

achieves a high level of availability since it relies on n cloud

instead of one. DepSky-A requires one available cloud out

of n clouds to be available. Whereas DepSky-CA requires k

288

available clouds out of n clouds to be available. Secondly,

DepSky-CA provides confidentiality by dividing data to ndata blocks (i.e. by erasure coding), and the original data can

be only recovered when there are k data blocks available to

the client. It is worth to mention that DepSky reuses the

access control mechanisms provided by the clouds to allow

clients to access their stored data on the clouds. Thirdly,

DepSky provides integrity by attaching a hash value to each

share (or data block in case of DepSky-A) stored on the

clouds. Clients are able to verify the integrity of the retrieved

data by hashing the received data and comparing the received

hashes with the computed hashes.

IV. EVALUATION OF THE SELECTED SECURITY

SUPPORTING MECHANISMS IN CLOUD STORAGE

In this section, we evaluate the previously described

security supporting mechanisms for the cloud storage. Our

evaluation is based on the following criteria: security, sup-

porting writing serializability, supporting reading freshness,

workload distribution between the client and cloud, perfor-

mance, financial cost, supporting accountability, supporting

file sharing between users, and ease of deployment.

A. Security

For evaluating the security of the five mechanisms, we

evaluate each mechanism for its provision of the main

security objectives: confidentiality, integrity, and availability.

1) Confidentiality: All the five mechanisms are designed

to provide the confidentiality of the data stored in the cloud.

The level of confidentiality for these mechanisms relies on

the cryptographic primitive used to encrypt the messages

(i.e. the security of the encryption algorithm itself and the

size of the encryption key). In the rest of this section, we

evaluate the confidentiality provided by each mechanism.

CFS applies double encryption on the plaintext files.

Firstly, CFS generates a pseudorandom bit stream using

the first half of the user’s passphrase. The first level of

encryption is applied by XOR the generated pseudorandom

bit stream with the first block of the plaintext. Secondly, CFS

uses DES with 64-bit block size and 56-bit encryption key to

encrypt the resulted bit stream. From the used cryptographic

primitives, we can see that DES is no longer proving high

security. This encryption scheme is vulnerable to known

plaintext attack, in which an attacker can try to launch brute

force attacks from two sides. More specifically, an attacker

can perform brute force attach on the plaintext using the

65-bit key from one side and brute force attack on the DES

OFB pseudorandom number generator using the 65-bit key

from the other side.

SiRiUS uses AES in the ECB mode to encrypt files.

All the AES keys are generated randomly for each file.

One AES key will be used of encrypting one file only.

However, SiRiUS has a weakness when two identical blocks

within the same file are encrypted with the same key which

results in two identical ciphertexts. An attacker can take

advantage to these two blocks in order to speed up the

process of recovering the plaintext or compromising the AES

key. This weakness can be overcome by applying chaining

in the encryption algorithm (i.e. CBC mode). For the AES

encryption keys, they are stored in the meta-data file attached

to files and encrypted using the user’s private key using RSA

which is still proving a high level of security with large keys

(i.e. 1024 or 2048 bit keys).

CloudProof uses either a symmetric block cipher (i.e. AES

in counter mode) or stream cipher to encrypt data blocks.

The decryption keys are stored in the family key blocks

encrypted using broadcast encryption. Hence, data blocks

within the same family blocks will be encrypted with the

same key. However, using AES in the counter mode will pre-

vent producing the same ciphertexts for identical plaintexts

using the same key. In general, we believe the CloudProof

achieves a high level of confidentiality comparing with the

other evaluated mechanisms.

CloudSeal applies dual encryption on the content before

publishing it to the application service (in the cloud) by

using AES symmetric encryption in the Cipher Feedback

mode (CFB mode) then proxy-based encryption [10]. The

application service then re-encrypts the content using a re-

encryption key provided by the content provider. Subscribers

are able to get the original content by using the shared key

that is shared using the k out of n secret sharing scheme [11].

To achieve a higher level of confidentiality, CloudSeal can

be configured to support both forward security (i.e. a user

cannot access files published before joining the group) and

backward security (i.e. user cannot access files published

after leaving the group). In general, we believe CloudSeal

provides a high level of confidentiality by using high secure

cryptographic primitives and configuring them correctly.

DepSky-CA leverages the information-efficient secret

sharing scheme [15] to provide data confidentiality. The

information-efficient secret sharing scheme combines the kout of n secret sharing [11], the information-optimal erasure

code [14], and symmetric encryption. After encrypting the

data, the data is encoded using the information-optimal

erasure code to produce n data blocks. These data blocks

are distributed over the clouds. Along with each data block,

a share of the decryption key, resulted from applying the

k out of n secret sharing, is also stored in the cloud.

When the client reads the data, he requests all the erasure

encoded data blocks and key shares from all the clouds

and stops when he receives k data blocks and key shares.

Then the client reconstructs the decryption key by combining

the k key shares using the k out of n secret sharing.

This decryption key is used to decrypt the encrypted data

that is obtained by decoding the k data blocks using the

information-optimal erasure code. The cloud providers or

any attackers cannot recover the original files without having

k data blocks and key shares. It is worth to mention that

289

DepSky reuses the access control mechanisms provided by

the cloud. Hence, DepSky has a weakness if an attacker can

obtains k data blocks and key shares from different clouds by

compromising clouds with weak access control mechanisms.

Also, DepSky does not protect clients from cheating clouds

(i.e. clouds cheating together to recover the client’s sensitive

data). Hence, clients should consider the clouds are trusted

to some extent.

2) Integrity: CFS and Cloudseal do not provide data

integrity. SiRiUS provides data integrity of files by attaching

digital signatures to the meta-data file and the file itself.

The meta-data file is signed by the owner private key where

the file itself is signed by the file’s private key (which is

created for each file upon its creation). Clients can verify

the integrity of meta-data files and the files themselves by

validating the attached signatures with the corresponding

public keys. Similarly, CloudProof provides data integrity of

data blocks by attaching digital signatures to the data blocks

and family key blocks. The family key block is signed with

the owner’s private key where the data block is signed by the

family block’s private key (which is shared between all data

blocks within the same family block). Clients can verify

the integrity of the family key blocks and data block by

validating the attached signatures using the corresponding

public keys. Finally, DepSky provides data integrity by

attaching a signed SHA-1 hash value to the meta-data file

for each share (or data unit in case of DepSky-A). Since

SHA -1 is no longer provide a high level of security [16],

DepSky is vulnerable to an attack where an attacker can find

a new file that produces the same hash value (i.e. collision).

3) Availability: Availability of all the evaluated mech-

anisms relies on the availability of a single cloud except

DepSky. DepSky is designed with a main goal of enhancing

the data availability of the data stored in the cloud. DepSky

achieves a high level of availability by distributing the data

over n clouds. For DepSky-A, the requested data is available

when only one of the n clouds is available. For DepSky-CA,

the requested data is available when k out of n clouds are

available, where k is the threshold of the k out of n secret

sharing scheme.

B. Writing Serializability

CFS and SiRiUS do not provide writing serializability.

This may lead a client to update an old file while he is

not aware of its new versions. CloudSeal does not need

support for writing serializability since it does not support

multiple writers. CloudProof provides writing serializability

by using clients put attestations. More specifically, the cloud

checks every client put attestation before perform the writing

process to verify that the old version field in the attestation

is the current version of the data block. For DepSky, it

leverages a low contention lock mechanism to lock the file

for a writer for a certain time. This lock mechanism has a

disadvantage when several writers try to write at the same

time, they all can be refused.

C. Reading Freshness

CFS and CloudSeal are not designed to support reading

freshness. SiRiUS ensures reading freshness by using hash

tree and meta-data freshness file. The meta-data freshness

file contains the hash of the meta-data file. A client can

verify the freshness of the file and the meta-data file using

the hash tree structure. CloudProof leverages the hash chains

to ensure that the clients are given the latest version of the

data block. These hash chains are included in each cloud get

and put attestations. For DepSky, it ensures that the client

requesting a data unit is giving the latest version by adding

the last version number to the meta-data file attached to each

file. Before retrieving a file, a user enquires about the latest

version of the file then requests it from the clouds.

D. Workload Distribution Between the Client and Cloud

CFS and SiRiUS are not designed specifically for the

cloud. Instead, they are designed to securely store clients’

file on an untrusted remote file server. Hence, both CFS and

SiRiUS are designed to offload the files server as much as

possible. That is because the file server is usually serving

clients within the same organization. Hence, putting the load

on the client side ensures that the file server is less loaded

and then it can perform faster.

On the other hand, the cloud has a different model. The

cloud provider is a separate organization that serves clients

(i.e. individuals and organization) and is paid for this service.

In this case, clients are willing to offload their side and

load the cloud as much as possible. That is because some

clients either lake of computational resources (i.e. processing

power) or they completely rely on the cloud’s computational

resources. However, since the cloud is considered untrusted,

it cannot be loaded with security-critical computational pro-

cesses such as encrypting or decrypting data. Therefor, the

client-side is still loaded with these computational processes

for ensuring the security of the data.

E. Performance

In our evaluation of the performance of the evaluated

mechanisms, the comparison between these mechanisms

is approximate since each mechanism was evaluated with

different testbeds. Evaluating these mechanisms using the

same testbed is beyond the scope of this paper. Instead,

we rely on the evaluations performed by authors of the

mechanisms.

For CFS, its performance with NFS as underlying storage

was less than the underlying system by a factor of four. This

benchmark is done by writing a file and the read it back.

CFS performs slightly better when it comes to reading. It

performs less than the underlying system by roughly a factor

of three. This poor performance caused by the encryption,

systems calls, and context switching overhead.

290

For SiRiUS and NFS as its underlying storage, reading

and writing were approximately 20 times slower than the

underlying system for small files. For large files, reading is

3 times faster than writing, that is because of recalculating

the hash value and signing. It performs 2.3 times slower

than the underlying system for large files. For writing, the

overhead is introduced by encryption, verifying signatures,

and signing. For reading, the overhead is only introduced by

decryption and verifying signatures.

CloudProof produces approximately 15% latency over-

head comparing to using the same cloud storage without

applying CloudProof. It only decreases the throughput of the

cloud storage by around 10%. For auditing the attestations

against any violations of reading freshness, it takes only

4 minutes to audit 108 attestations. Hence, and comparing

to the benefits of applying CloudProof, this degrade of

performance can be tolerated.

CloudSeal relies on content delivery networks. Hence, it

is expected to have a high performance in terms of network

latency since the large part of the content is cached on the

content delivery network which is closer to clients. The

usage of content delivery network has decreased the time

of content delivery by a factor of 10. However, the time

was required for cryptographic algorithms were 40 times

less than the time required for delivering content.

DepSky achieved a high performance regarding the net-

work throughput and latency. That is because it requires the

data from n clouds instead of one. For example, DepSky-

A achieves the better reading throughput comparing to

DepSky- CA and Amazon S3 because it requests the data

from n clouds and waits for the fastest response. However,

writing in DepSky is much worse than reading since the data

should be written to n clouds instead of one.

F. Financial Cost

In our evaluation for the financial cost for each mech-

anism, we only consider the cost of data storage. Costs

related to processing, communication, and other costs are not

considered for this evaluation. CFS only encrypts files and

stores them in the cloud. It only requires more storage when

a file is decrypted, which produces a new file containing the

plaintext while the decrypted file is kept in the cloud as well.

SiRiUS costs more than CFS because SiRiUS creates a

meta-data file and meta-data freshness file for each file. The

meta-data file contains encrypted key block format for each

user with either read-only or write permissions, which means

that the storage cost is increased relatively with the number

of users with access permission on a single file.

CloudProof improves the problem of having a meta-

data file for each file. It groups all files with the same

access control permission into a family. All files belong

to the same family block share a single family key block.

Moreover, the size of the family key block remains the same

regardless the number of users having access to the family.

On the other hand, CloudProof introduces attestations that

exchanged by the client and cloud for each read or write

operation. However, the cloud attestations are distributed

among readers and writers (i.e. not stored in the cloud

or stored in the owner side). Also, these attestations can

be deleted if they have been audited (i.e. at maximum,

they are only stored for one epoch). For the clients put

attestations, the cloud provider does not need to store them

after verifying them and performing the write operation. In

general, CloudProof maintains less storage cost than SiRiUS.

CloudSeal stores only the encrypted content in the cloud.

It does not store additional data such meta-data files or ac-

cess permission files. However, CloudSeal relies on content

delivery networks where the content is cached on many

servers that are closer to the clients. But this cannot be

considered as a data storage. Another point, CloudSeal can

only store a small part of the content (i.e. media file) in the

cloud where the larger part is cached in the content delivery

network. This setting may reduce the cost of storage for

some extend.

Regarding the cost of storage, DepSky is the most ex-

pensive mechanism among the evaluated mechanisms. That

is mainly because DepSky distribute the data over n clouds

instead of one. For DepSky-A, it required n times the storage

required to store original data (i.e. for n = 4, 1GB files

require 4GB of storage). DepSky-CA improves this overhead

by applying optimal erasure codes to partition that data to

blocks, which makes the storage required 50% less than

DepSky-A. Also, DepSky stores meta-data along with each

data unit which also increase the storage cost.

Finally, it is worth to mention that cloud storage prices is

cheap and other factors such as access requests and data

transfer may significantly increase the cost of the cloud

storage services. For example, as in January 2014, the cost

of data storage at Amazon S3 is as cheap as $0.085 per GB

per month for the first TB. Moreover, Amazon S3 storage

prices can be as cheap as $0.043 per GB per month for the

first 5000 TB. However, Amazon charges $0.005 per 1,000

requests for put, copy, post, or list requests. Also, Amazon

charges $0.120 per GB for data transfer to the Internet for

the first 10 TB. Hence, these additional prices should be

taken into account when designing a secure cloud storage.

G. Accountability

Cloud proof is the only mechanism among the evaluated

mechanisms that enable establishing accountability between

the cloud and its clients. Using CloudProof, the client can

proof violations of integrity, reading freshness, and writing

serializability for a third party. Hence, the cloud provider is

hold accountable on all the operations that it performs to

the client. This form of accountability, allows the client and

cloud to agree on a contract that states that the client will

be compensated in case of integrity, freshness, or writing

serializability violations.

291

H. Support of Files Sharing

CFS does not provide file sharing for clients. Only the

user how know the decryption key can access the file.

CloudSeal only supports file sharing with one writer (i.e.

content provider) and multiple readers. SiRiUS, CloudProof,

and DepSky are designed to support full file sharing where

multiple readers can read a file and multiple writers can

write the same file.

I. Ease of Deployment

Applying CFS and SiRiUS only require installing their

software on the clients’ machines. This software will form

a software layer above the file system of the operating

system. Each call from the user’s level to the file system

is intercepted by this layer. This layer is responsible for

encrypting or decrypting files requested by the user. The

file system can store the files locally or on a remote file

server. Deploying CFS and SiRiUS does not required any

changes in the cloud side. But it might need mappings from

the network file system calls to the cloud storage interface

if it is not supported by the cloud.

CloudProof requires the cloud to perform additional com-

putation beside the read and write operations. The cloud

must create attestations and check clients put attestations

before commit any writing operations. Hence, CloudProof

requires that the cloud storage provider apply CloudProof

scheme in order to provide it to its clients.

CloudSeal requires the cloud to provide both virtual in-

frastructure and storage. The virtual infrastructure is required

to deploy an application servers that handle both clients

and content provider requests. Hence, CloudSeal cannot be

applied on clouds that only provide cloud storage services

(or it must rely on other cloud service provider for the

virtual infrastructure). Moreover, CloudSeal relies on content

delivery network for delivering content to the clients.

Finally, DepSky can be applied on any cloud storage

providers the provide access control mechanism for multiple

users. In DepSky, the clouds are not required to perform any

additional computation rather than reading and writing. The

client side is responsible for writing the data along with its

meta data to n clouds. Also, the client side is responsible

on reading and checking the integrity of the data from nclouds.

V. CONCLUSION

In this paper, we have described five mechanisms for the

supporting the security of cloud storage. These mechanisms

include CFS [6], SiRiUS [7], CloudProof [4], CloudSeal [8],

and DepSky [9]. Then we have evaluated these mecha-

nisms based on the following factors: security, supporting

the writing serializability, supporting the reading freshness,

workload distribution between the client and cloud, perfor-

mance, financial cost, supporting of accountability between

the client and cloud, supporting of file sharing between

users, and ease of deployment. The evaluation section of

this paper can be used by individuals and organization as a

guide for selecting or designing an appropriate secure cloud

storage scheme.

REFERENCES

[1] S. Subashini and V. Kavitha, “A survey on security issuesin service delivery models of cloud computing,” Journal ofNetwork and Computer Applications, vol. 34, no. 1, pp. 1–11,2011.

[2] A. Ferdowsi, “Yesterday’s Authentication Bug,” 2011.[Online]. Available: https://blog.dropbox.com/2011/06/yesterdays-authentication-bug/

[3] A. Ferdowsi, “Amazon Discussion Forums: S3 datacorruption?” 2008. [Online]. Available: https://forums.aws.amazon.com/thread.jspa?threadID=22709#

[4] R. A. Popa, J. R. Lorch, D. Molnar, H. J. Wang, andL. Zhuang, “Enabling security in cloud storage SLAs withCloudProof,” Microsoft TechReport MSR-TR-2010, vol. 46,pp. 1–12, 2010.

[5] “Amazon Cloud Drive-Service Level Agreement,” 2012. [On-line]. Available: http://www.amazon.com/gp/help/customer/display.html/ref=hp left sib?ie=UTF8&nodeId=200557360

[6] M. Blaze, “A cryptographic file system for UNIX,” inProceedings of the 1st ACM conference on Computer andcommunications security. ACM, 1993, pp. 9–16.

[7] E.-J. Goh, H. Shacham, N. Modadugu, and D. Boneh, “SiR-iUS: Securing Remote Untrusted Storage.” in NDSS, vol. 3,2003, pp. 131–145.

[8] H. Xiong, X. Zhang, D. Yao, X. Wu, and Y. Wen, “Towardsend-to-end secure content storage and delivery with publiccloud,” in Proceedings of the second ACM conference on Dataand Application Security and Privacy. ACM, 2012, pp. 257–266.

[9] A. Bessani, M. Correia, B. Quaresma, F. Andre, and P. Sousa,“DepSky: dependable and secure storage in a cloud-of-clouds,” in Proceedings of the sixth conference on Computersystems. ACM, 2011, pp. 31–46.

[10] G. Ateniese, K. Fu, M. Green, and S. Hohenberger, “Improvedproxy re-encryption schemes with applications to securedistributed storage,” ACM Transactions on Information andSystem Security (TISSEC), vol. 9, no. 1, pp. 1–30, 2006.

[11] A. Shamir, “How to share a secret,” Communications of theACM, vol. 22, no. 11, pp. 612–613, 1979.

[12] A. Fiat and M. Naor, “Broadcast encryption,” in Advances inCryptology-CRYPTO’93. Springer, 1994, pp. 480–491.

[13] D. Boneh, C. Gentry, and B. Waters, “Collusion resistantbroadcast encryption with short ciphertexts and private keys,”in Advances in Cryptology-CRYPTO 2005. Springer, 2005,pp. 258–275.

[14] M. O. Rabin, “Efficient dispersal of information for security,load balancing, and fault tolerance,” Journal of the ACM(JACM), vol. 36, no. 2, pp. 335–348, 1989.

[15] H. Krawczyk, “Secret sharing made short,” in Advances inCryptology-CRYPTO’93. Springer, 1994, pp. 136–146.

[16] C. De Canniere and C. Rechberger, “Finding sha-1 charac-teristics: General results and applications,” in Advances inCryptology–ASIACRYPT 2006. Springer, 2006, pp. 1–20.

292