Secure Overlay Cloud Storage with AccessControl and Assured Deletion
Yang Tang, Patrick P. C. Lee, John C. S. Lui, Radia Perlman
Abstract—We can now outsource data backups off-site to third-party cloud storage services so as to reduce data management costs.However, we must provide security guarantees for the outsourced data, which is now maintained by third parties. We design andimplement FADE, a secure overlay cloud storage system that achieves fine-grained, policy-based access control and file assureddeletion. It associates outsourced files with file access policies, and assuredly deletes files to make them unrecoverable to anyoneupon revocations of file access policies. To achieve such security goals, FADE is built upon a set of cryptographic key operations thatare self-maintained by a quorum of key managers that are independent of third-party clouds. In particular, FADE acts as an overlaysystem that works seamlessly atop today’s cloud storage services. We implement a proof-of-concept prototype of FADE atop AmazonS3, one of today’s cloud storage services. We conduct extensive empirical studies, and demonstrate that FADE provides securityprotection for outsourced data, while introducing only minimal performance and monetary cost overhead. Our work provides insightsof how to incorporate value-added security features into today’s cloud storage services.
Cloud storage is a new business solution for remotebackup outsourcing, as it offers an abstraction of infinitestorage space for clients to host data backups in a pay-as-you-go manner [5]. It helps enterprises and governmentagencies significantly reduce their financial overhead ofdata management, since they can now archive their databackups remotely to third-party cloud storage providersrather than maintain data centers on their own. Forexample, SmugMug [30], a photo sharing website, choseto host terabytes of photos on Amazon S3 in 2006 andsaved thousands of dollars on maintaining storage de-vices [3]. More case studies of using cloud storage for re-mote backup can be found in [2]. Apart from enterprisesand government agencies, individuals can also archivetheir personal data to the cloud using tools like Dropbox[10]. In particular, with the advent of smartphones, weexpect that more people will use Dropbox-like tools tomove audio/video files from their smartphones to thecloud, given that smartphones typically have limitedstorage resources.
However, security concerns become relevant as wenow outsource the storage of possibly sensitive data tothird parities. In this paper, we are particularly interestedin two security issues. First, we need to provide guaran-tees of access control, in which we must ensure that onlyauthorized parties can access the outsourced data on thecloud. In particular, we must prohibit third-party cloudstorage providers from mining any sensitive information
• Y. Tang, P. P. C. Lee, and J. C. S. Lui are with the Department of ComputerScience and Engineering, The Chinese University of Hong Kong, Shatin,N.T., Hong Kong (emails: {tangyang,pclee,cslui}@cse.cuhk.edu.hk).
• Radia Perlman is with Intel Labs (email: [email protected]).• An earlier conference version appeared in [33].
of their clients’ data for their own marketing purposes.Second, it is important to provide guarantees of assureddeletion, meaning that outsourced data is permanentlyinaccessible to anybody (including the data owner) uponrequests of deletion of data. Keeping data permanentlyis undesirable, as data may be unexpectedly disclosedin the future due to malicious attacks on the cloud orcareless management of cloud operators. The challengeof achieving assured deletion is that we have to trustcloud storage providers to actually delete data, but theymay be reluctant in doing so [28]. Also, cloud storageproviders typically keep multiple backup copies of datafor fault-tolerance reasons. It is uncertain, from cloudclients’ perspectives, whether cloud providers reliablyremove all backup copies upon requests of deletion.
The security concerns motivate us, as cloud clients,to have a system that can enforce access control andassured deletion of outsourced data on the cloud in afine-grained manner. However, building such a system isa difficult task, especially when it involves protocol orhardware changes in cloud storage infrastructures thatare externally owned and managed by third-party cloudproviders. Thus, it is necessary to design a secure overlaycloud storage system that can be overlaid and workseamlessly atop existing cloud storage services.
In this paper, we present FADE, a secure overlay cloudstorage system that provides fine-grained access control andassured deletion for outsourced data on the cloud, while work-ing seamlessly atop today’s cloud storage services. In FADE,active data files that remain on the cloud are associatedwith a set of user-defined file access policies (e.g., timeexpiration, read/write permissions of authorized users),such that data files are accessible only to users whosatisfy the file access policies. In addition, FADE gen-eralizes time-based file assured deletion [12], [23] (i.e.,
IEEE TRANSACTIONS ON DEPEDABLE AND SECURE COMPUTINGThis article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication.
2
data files are assuredly deleted upon time expiration)into a more fine-grained approach called policy-based fileassured deletion, in which data files are assuredly deletedwhen the associated file access policies are revokedand become obsolete. The design intuition of FADE isto decouple the management of encrypted data andcryptographic keys, such that encrypted data remainson third-party (untrusted) cloud storage providers, whilecryptographic keys are independently maintained andoperated by a quorum of key managers that altogetherform trustworthiness. To provide guarantees of accesscontrol and assured deletion, FADE leverages off-the-shelf cryptographic schemes including threshold secretsharing [29] and attribute-based encryption [7], [13],[25], [27], and performs various cryptographic key op-erations that provide security protection for basic fileupload/download operations. We implement a proof-of-concept prototype of FADE to justify its feasibility,and export a set of library APIs that can be used, asa value-added security service, to enhance the securityproperties of general data outsourcing applications.
We point out that the design of FADE is based on thethin-cloud interface [35], meaning that it only requires thecloud to support the basic data access operations such asput and get. Thus, FADE is applicable for general typesof storage backends, as long as such backends providethe interface for uploading and downloading data. Onthe other hand, in the context of cloud storage, we needto specifically consider the performance metrics that areinherent to cloud storage, including data transmissionperformance (given that a cloud is deployed over theInternet) and monetary cost overhead (given that a cloudcharges clients for data outsourcing). Thus, we empiri-cally evaluate FADE according to the specific features ofcloud storage, so as to justify that FADE is actually afeasible solution for secure cloud storage.
Our contributions are summarized as follows.• We propose a new policy-based file assured deletion
scheme that reliably deletes files with regard torevoked file access policies. In this context, we de-sign the key management schemes for various filemanipulation operations, with the emphasis on fine-grained security protection.
• On top of policy-based file assured deletion, wedesign and implement two new features: (i) fine-grained access control based on attribute-based en-cryption and (ii) fault-tolerant key managementwith a quorum of key managers based on thresholdsecret sharing.
• We implement a working prototype of FADE atopAmazon S3. Our implementation of FADE exportsa set of APIs that can be adapted into different dataoutsourcing applications.
• We empirically evaluate the performance overheadof FADE atop Amazon S3. Using experiments in arealistic network environment, we show the feasi-bility of FADE in improving the security protectionof data storage on the cloud in practice. We also
analyze the monetary cost overhead of FADE undera practical cloud backup scenario.
In summary, our work seeks to address the accesscontrol and assured deletion problems from a practi-cal perspective. Our FADE implementation characterizesand evaluates the performance and monetary cost impli-cations of applying access control and assured deletionin a real-life cloud storage environment.
The remainder of the paper proceeds as follows. InSection 2, we describe and motivate the concept ofpolicy-based file assured deletion, a major building blockof FADE. In Section 3, we overview the design of FADE,and define our design goals. In Section 4, we explain thedesign of FADE in achieving access control and assureddeletion. In Section 5, we describe the implementationdetails of FADE. In Section 6, we evaluate FADE atopAmazon S3. Section 7 reviews related work on securingoutsourced data storage. Finally, Section 8 concludes.
2 POLICY-BASED FILE ASSURED DELETION
FADE seeks to achieve both access control and assureddeletion for outsourced data. The design of FADE iscentered around the concept of policy-based file assureddeletion. We first review time-based file assured deletionproposed in earlier work. We then explain the moregeneral concept policy-based file assured deletion andmotivate why it is important in certain scenarios.
2.1 Background
Time-based file assured deletion, which is first intro-duced in [23], means that files can be securely deletedand remain permanently inaccessible after a pre-definedduration. The main idea is that a file is encrypted witha data key by the owner of the file, and this data key isfurther encrypted with a control key by a separate keymanager (known as Ephemerizer [23]). The key manageris a server that is responsible for cryptographic key man-agement. In [23], the control key is time-based, meaningthat it will be completely removed by the key managerwhen an expiration time is reached, where the expirationtime is specified when the file is first declared. Withoutthe control key, the data key and hence the data fileremain encrypted and are deemed to be inaccessible.Thus, the main security property of file assured deletionis that even if a cloud provider does not remove expiredfile copies from its storage, those files remain encryptedand unrecoverable.
An open issue in the work [23] is that it is uncertainthat whether time-based file assured deletion is feasiblein practice, as there is no empirical evaluation. Later, theidea of time-based file assured deletion is prototypedin Vanish [12]. Vanish divides a data key into multiplekey shares, which are then stored in different nodes ofa public Peer-to-Peer Distributed Hash Table (P2P DHT)system. Nodes remove the key shares that reside in theircaches for a fixed time period. If a file needs to remain
IEEE TRANSACTIONS ON DEPEDABLE AND SECURE COMPUTINGThis article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication.
3
accessible after the time period, then the file owner needsto update the key shares in node caches. Since Vanish isbuilt on the cache-aging mechanism in the P2P DHT, it isdifficult to generalize the idea from time-based deletionto a fine-grained control of assured deletion with respectto different file access policies. We elaborate this issue inthe following section.
2.2 Policy-based Deletion
We now generalize time-based deletion to policy-baseddeletion as follows. We associate each file with a singleatomic file access policy (or policy for short), or moregenerally, a Boolean combination of atomic policies. Each(atomic) policy is associated with a control key, and allthe control keys are maintained by the key manager.Suppose now that a file is associated with a single policy.Then similar to time-based deletion, the file content isencrypted with a data key, and the data key is furtherencrypted with the control key corresponding to thepolicy. When the policy is revoked, the correspondingcontrol key will be removed from the key manager. Thus,when the policy associated with a file is revoked andno longer holds, the data key and hence the encryptedcontent of the file cannot be recovered with the controlkey of the policy. In this case, we say the file is assuredlydeleted. The main idea of policy-based deletion is todelete files that are associated with revoked policies.
The definition of a policy varies across applications.In fact, time-based deletion is a special case under ourframework. In general, policies with other access rightscan be defined. To motivate the use of policy-baseddeletion, let us consider a scenario where a companyoutsources its data to the cloud. We consider four prac-tical cases where policy-based deletion will be useful.
Storing files for tenured employees. For each em-ployee (e.g., Alice), we can define a user-based policy “P :Alice is an employee”, and associate this policy with allfiles of Alice. If Alice quits her job, then the key managerwill expunge the control key of policy P . Thus, nobodyincluding Alice can access the files associated with P onthe cloud, and those files are said to be deleted.
Storing files for contract-based employees. An em-ployee may be affiliated with the company for only afixed length of time. Then we can form a combinationof the user-based and time-based policies for employees’files. For example, for a contract-based employee Bobwhose contract expires on 2010-01-01, we have twopolicies “P1: Bob is an employee” and “P2: valid before 2010-01-01”. Then all files of Bob are associated with the policycombination P1 ∧ P2. If either P1 or P2 is revoked, thenBob’s files are deleted.
Storing files for a team of employees. The companymay have different teams, each of which has more thanone employee. As in above, we can assign each employeei a policy combination Pi1 ∧ Pi2, where Pi1 and Pi2 de-note the user-based and time-based policies, respectively.We then associate the team’s files with the disjunctive
datasource
...
Cloud
Keymanager
1...
Keymanager
2
Keymanager
N
File(encrypted)
Metadata...
...
File(encrypted)
Metadata
...
File
File
FADEclient
datasource
Fig. 1: The FADE system. Each client (deployed locallywith its own data source) interacts with one or mul-tiple key managers and uploads/downloads data filesto/from the cloud.
combination (P11 ∧P12)∨ (P21 ∧P22)∨ · · · ∨ (PN1 ∧PN2)for employees 1, 2, . . . , N . Thus, the team’s files can beaccessed by any one of the employees, and will bedeleted when the policies of all employees of the teamare revoked.
Switching a cloud provider. The company can definea customer-based policy “P : a customer of cloud providerX”, and all files that are stored on cloud X are tiedwith policy P . If the company switches to a new cloudprovider, then it can revoke policy P . Thus, all fileson cloud X will be deleted. We argue that switchingcloud providers has its potential application, such as inavoiding vendor lock-ins [1].
3 FADE OVERVIEW
We now overview the design of FADE, a system thatprovides guarantees of access control and assured dele-tion for outsourced data in cloud storage. We present thenecessary components of FADE, and state the design andsecurity goals that it seeks to achieve.
Figure 1 illustrates an overview of the FADE system.The cloud hosts data files on behalf of a group of FADEusers who want to outsource data files to the cloud basedon their definitions of file access policies. FADE can beviewed as an overlay system atop the underlying cloud.It applies security protection to the outsourced data filesbefore they are hosted on the cloud.
3.1 Entities
As shown in Figure 1, the FADE system is composed oftwo main entities:
• FADE clients. A FADE client (or client for short)is an interface that bridges the data source (e.g.,filesystem) and the cloud. It applies encryption(decryption) to the outsourced data files uploadedto (downloaded from) the cloud. It also interactswith the key managers to perform the necessarycryptographic key operations.
• Key managers. FADE is built on a quorum of keymanagers [29], each of which is a stand-alone entitythat maintains policy-based keys for access controland assured deletion (see Sections 3.3 and 3.4).
IEEE TRANSACTIONS ON DEPEDABLE AND SECURE COMPUTINGThis article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication.
4
The cloud, maintained by a third-party provider, pro-vides storage space for hosting data files on behalf ofdifferent FADE clients in a pay-as-you-go manner. Eachof the data files is associated with a combination of fileaccess policies. FADE is built on the thin-cloud interface[35], and assumes only the basic cloud operations foruploading and downloading data files. We emphasizethat we do not require any protocol and implementationchanges on the cloud to support FADE.
3.2 Deployment
In our current design, a FADE client is deployed locallywith its corresponding data source as a local driver ordaemon. Note that it is also possible to deploy the FADEclient as a cloud storage proxy [1], so that it can intercon-nect multiple data sources. In proxy deployment, we canuse standard TLS/SSL [9] to protect the communicationbetween each data source and the proxy.
In FADE, the set of key managers is deployed asa centralized trusted service, whose trustworthiness isenforced through a quorum scheme. We assume that thekey managers are centrally maintained, for example, bythe system administrators of an enterprise that deploysFADE for its employees. We note that this centralizedcontrol is opposed to the core design of Vanish [12],which proposes to use decentralized key managementon top of existing P2P DHT systems. However, as dis-cussed in Section 2, there is no straightforward solutionto develop fine-grained cryptographic key managementoperations over a decentralized P2P DHT system. Also,the Vanish implementation that was published in [12]is subject to Sybil attacks [38], which particularly targetDHT systems. In view of this, we propose to deploy acentralized key management service, and use a quorumscheme to improve its robustness.
3.3 Cryptographic Keys
FADE defines three types of cryptographic keys to pro-tect data files stored on the cloud:
• Data key. A data key is a random secret that isgenerated and maintained by a FADE client. It isused for encrypting or decrypting data files viasymmetric-key encryption (e.g., AES).
• Control key. A control key is associated with a par-ticular policy. It is represented by a public-privatekey pair, and the private control key is maintainedby the quorum of key managers. It is used toencrypt/decrypt the data keys of the files protectedwith the same policy. The control key forms the basisof policy-based assured deletion.
• Access key. Similar to the control key, an accesskey is associated with a particular policy, and isrepresented by a public-private key pair. However,unlike the control key, the private access key ismaintained by a FADE client that is authorized toaccess files of the associated policy. The access key
is built on attribute-based encryption [7], and formsthe basis of policy-based access control.
Intuitively, to successfully decrypt an encrypted filestored on the cloud, we require the correct data key,control key, and access key. Without any of these keys, itis computationally infeasible to recover an outsourcedfile being protected by FADE. The following explainshow we manage such keys to achieve our security goals.
3.4 Security Goals
We formally state the security goals that FADE seeks toachieve in order to protect the outsourced data files.
Threat model. Here, we consider an adversary thatseeks to compromise the privacy of two types of filesthat are outsourced and stored on the cloud: (i) activefiles, i.e., the data files that the adversary is unauthorizedto access and (ii) deleted files, i.e., the data files that havebeen requested to be deleted by the authorized parties.Clearly, FADE needs to properly encrypt outsourced datafiles to ensure that their information is not disclosed tounauthorized parties. The underlying assumption is thatthe encryption mechanism is secure, such that it is com-putationally infeasible to recover the encrypted contentwithout knowing the cryptographic key for decryption.
Security properties. Given our threat model, we focuson two specific security goals that FADE seeks to achievefor fine-grained security control:
• Policy-based access control. A FADE client is au-thorized to access only the files whose associatedpolicies are active and are satisfied by the client.
• Policy-based assured deletion. A file is deleted (orpermanently inaccessible) if its associated policiesare revoked and become obsolete. That is, even ifa file copy that is associated with revoked policiesexists, it remains encrypted and we cannot retrievethe corresponding cryptographic keys to recover thefile. Thus, the file copy becomes unrecoverable byanyone (including the owner of the file).
Assumptions. To achieve the above security goals,we make the following assumptions regarding the keymanagement in FADE. FADE is built on a quorum ofkey managers based on Shamir’s (M,N) threshold secretsharing [29], in which we create N key shares for a key,such that any M ≤ N of the key shares can be usedto recover the key. First, to access files associated withactive policies, we require at least M out of N key man-agers keep the key shares of the required control keysand correctly perform the cryptographic key operations.Second, to assuredly delete files, at least N−M+1 out ofN key managers must securely erase the correspondingcontrol keys of the revoked policies, such as via secureoverwriting [14], which we believe is feasible for smaller-size keys as opposed to larger-size data files.
The parameters M and N determine the trade-off be-tween the fault tolerance assumptions of key managerswhen accessing and deleting files. If M is small (large),then we need fewer (more) key managers to be active
IEEE TRANSACTIONS ON DEPEDABLE AND SECURE COMPUTINGThis article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication.
5
in order to access a file, but we need more (fewer) keymanagers to purge the revoked control keys in orderto delete a file. How to adjust the trade-off depends ondifferent application needs.
We assume that a key manager is subject to onlyfail-stop failures (e.g., system crashes, data losses), sothe quorum scheme enables our key management tobe robust against fail-stop failures. On the other hand,we do not consider the case of arbitrary (or Byzantine)failures in key managers (e.g., tampering with controlkeys or policies), where the security threats are beyondthe scope of this work. We pose the protection againstarbitrary failures in future studies.
In addition, we require that each FADE client doesnot keep the raw copy of the data key that is usedto protect a data file. Once it successfully encrypts ordecrypts a data file, it must discard the raw copy ofthe corresponding data key; otherwise, the file may berecoverable should the raw copy of the data key bedisclosed. Only the encrypted copy of the data key,together with the encrypted data files, will be kept andstored on the cloud.
In our threat model, we only focus on protecting thedata files stored on the cloud. Therefore, we do notconsider the case where the FADE client discloses thesuccessfully decrypted data files that are retrieved fromthe cloud, as such files are outside our protection scope.
4 FADE DESIGN
In this section, we present the design of FADE. In par-ticular, we propose several cryptographic key operationsthat enable FADE to achieve our security goals.
4.1 Basic Operations of FADE
We start with the basic design of FADE. To simplify ourdiscussion, we make two assumptions. First, only a sin-gle key manager is used. Second, before accessing a file,a client needs to present authentication credentials (e.g.,based on public key infrastructure certificates) to thekey manager to show that it satisfies the proper policiesassociated with the files, so that the key manager willperform cryptographic key operations. We explain inSection 4.2 how to relax both of the assumptions throughmultiple key managers with threshold secret sharing andaccess control with attribute-based encryption.
4.1.1 File Upload/DownloadWe now introduce the basic operations of how a clientuploads/downloads files to/from the cloud. We startwith the case where each file is associated with a singlepolicy, and then explain how a file is associated withmultiple policies in Section 4.1.3.
Our design is based on blinded RSA [32] (or blindeddecryption [23]), in which the client requests the keymanager to decrypt a blinded version of the encrypteddata key. If the associated policy is satisfied, then the keymanager will decrypt and return the blinded version of
Notation Description
F Data file generated by the clientK Data key used to encrypt file F
Pi Policy with index i
pi, qi RSA prime numbers for policy Pi (kept secret by thekey manager)
ni ni = piqi, known to the public(ei, di) RSA public/private control key pair for policy Pi
Si Secret key corresponding to policy Pi
{.}KEY Symmetric-key encryption with key KEY
R The random number used for blinded RSA
TABLE 1: Notation used in this paper.
Pi
ei , ni
Pi , {K}Si , Si
ei, {F}K
Cloud Client Key manager
Fig. 2: File upload.
the original data key. The client can then recover the datakey. The motivation of using this blinded decryptionapproach is that the actual content of the data keyremains confidential to the key manager as well as toany attacker that sniffs the communication between theclient and the key manager.
Table 1 summarizes the notation used in this paper. Wefirst summarize the major notation used throughout thepaper. For each policy i, the key manager generates twosecret large RSA prime numbers pi and qi and computesthe product ni = piqi
1. The key manager then randomlychooses the RSA public-private control key pair (ei, di).The parameters (ni, ei) will be publicized, while di issecurely stored in the key manager. On the other hand,when the client encrypts a file F , it randomly generatesa data key K, and a secret key Si that correspondsto policy Pi. We let {.}KEY denote the symmetric-keyencryption operation (e.g., AES) with key KEY . We letR be the blinded component when we use blinded RSAfor the exchanges of cryptographic keys.
Suppose that F is associated with policy Pi. Our goalhere is to ensure that K, and hence F , are accessible onlywhen policy Pi is satisfied. Note that we only presentthe operations on cryptographic keys, while the imple-mentation subtleties, such as the metadata that storesthe policy information, will be discussed in Section 5.Also, when we raise some number to exponents ei or di,it must be done over modulo ni. For brevity, we drop“mod ni” in our discussion.
File upload. Figure 2 shows the file upload operation.The client first requests the public control key (ni, ei)of policy Pi from the key manager, and caches (ni, ei)
1. We require that each policy i uses a distinct ni to avoid thecommon modulus attack on RSA [19].
IEEE TRANSACTIONS ON DEPEDABLE AND SECURE COMPUTINGThis article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication.
6
Pi , SieiRei
SiR
Pi , {K}Si , Si
ei, {F}K
Cloud Client Key manager
Fig. 3: File download.
for subsequent uses if the same policy Pi is associatedwith other files. Then the client generates two randomkeys K and Si, and sends {K}Si
, Seii , and {F}K to
the cloud2. Then the client must discard K and Si (seeSection 3.4 for justifications). To protect the integrity ofa file, the client computes an HMAC signature on everyencrypted file and stores the HMAC signature togetherwith the encrypted file in the cloud. We assume that theclient has a long-term private secret value for the HMACcomputation.
File download. Figure 3 shows the file downloadoperation. The client fetches {K}Si
, Seii , and {F}K from
the cloud. The client will first check whether the HMACsignature is valid before decrypting the file. Then theclient generates a secret random number R, computesRei , and sends Sei
i ·Rei = (SiR)ei to the key manager torequest for decryption. The key manager then computesand returns ((SiR)ei)di = SiR to the client, which cannow remove R and obtain Si, and decrypt {K}Si
andhence {F}K .
4.1.2 Policy Revocation for File Assured DeletionIf a policy Pi is revoked, then the key manager com-pletely removes the private control key di and the secretprime numbers pi and qi. Thus, we cannot recover Si
from Seii , and hence cannot recover K and file F . We
say that file F , which is tied to policy Pi, is assuredlydeleted. Note that the policy revocation operations donot involve interactions with the cloud.
4.1.3 Multiple PoliciesFADE supports a Boolean combination of multiple poli-cies. We mainly focus on two kinds of logical connec-tives: (i) the conjunction (AND), which means the data isaccessible only when every policy is satisfied; and (ii) thedisjunction (OR), which means if any policy is satisfied,then the data is accessible. Our following operationson a Boolean combination of policies are similar tothose in [24], while the focus of [24] is on digital rightsmanagement rather than file assured deletion.
• Conjunctive Policies. Suppose that F is associ-ated with conjunctive policies P1 ∧ P2 ∧ · · · ∧ Pm.To upload F to the cloud, the client first ran-domly generates a data key K, and different secret
2. We point out that the encrypted keys (i.e., {K}Si, S
eii
) canbe stored in the cloud without creating risks of leaking confidentialinformation.
keys S1, S2, . . . , Sm. It then sends the following tothe cloud: {{K}S1
}S2· · ·Sm
, Se11
, Se22
, . . ., Semm , and
{F}K . On the other hand, to recover F , the clientgenerates a random number R and sends (S1R)e1 ,(S2R)e2 , . . ., (SmR)em to the key manager, whichthen returns S1R,S2R, . . . , SmR. The client can thenrecover S1, S2, . . . , Sm, and hence K and F .
• Disjunctive Policies. Suppose that F is associatedwith disjunctive policies Pi1 ∨ Pi2 ∨ · · · ∨ Pim . Toupload F to the cloud, the client will send the fol-lowing: {K}S1
, {K}S2, . . ., {K}Sm
, Se11
, Se22
, . . ., Semm ,
and {F}K . Therefore, the client needs to compute m
different encrypted copies of K. On the other hand,to recover F , we can use any one of the policies todecrypt the file, as in the above operations.
To delete a file associated with conjunctive policies,we simply revoke any of the policies (say, Pj). Thus, wecannot recover Sj and hence the data key K and fileF . On the other hand, to delete a file associated withdisjunctive policies, we need to revoke all policies, sothat S
ejj cannot be recovered for all j. Note that for
any Boolean combination of policies, we can expressit in canonical form, e.g., in the disjunction (OR) ofconjunctive (AND) policies.
4.1.4 Policy Renewal
We conclude this section with the discussion of policyrenewal. Policy renewal means to associate a file witha new policy (or combination of policies). For example,if a user wants to extend the expiration time of a file,then the user can update the old policy that specifies anearlier expiration time to the new policy that specifies alater expiration time.
In FADE, policy renewal merely operates on keys,without retrieving the encrypted file from the cloud. Theprocedures can be summarized as follows: (i) downloadall encrypted keys (including the data key for the fileand the set of control keys for the associated Booleancombination of policies) from the cloud, (ii) send themto the key manager for decryption, (iii) recover the datakey, (iv) re-encrypt the data key with the control keys ofthe new Boolean combination of policies, and finally (v)send the newly encrypted keys back to the cloud.
In some special cases, we can simplify the key op-erations of policy renewal. Suppose that the Booleancombination structure of policies remains unchanged,but one of the atomic policies Pi is changed to Pj . Forexample, when we extend the contract date of Bob (seeSection 2.2), we may need to update the particular time-based policy of Bob without changing other policies.Then instead of decrypting and re-encrypting the datakey with the control keys that correspond to the newBoolean combination of policies, we can simply updatethe control key that corresponds to the particular atomicpolicy. Figure 4 illustrates this special case of policyrenewal. In this case, the client simply sends the blindedversion Si
eiRei to the key manager, which then returns
IEEE TRANSACTIONS ON DEPEDABLE AND SECURE COMPUTINGThis article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication.
7
Pi , SieiRei, Pj
SiR, ej , nj
Pi , Siei
Cloud Client Key manager
Pj , Siej
Fig. 4: A special case of policy renewal - when policy Pi
is renewed to policy Pj .
SiR. The client then recovers Si. Now, the client re-encrypts Si into S
eji (mod nj), where (nj , ej) is the
public control key of policy Pj , and sends it to the cloud.Note that the encrypted data key K remains intact.
4.2 Extensions of FADE
We now discuss two extensions to the basic design ofFADE. The first extension is to use attribute-based encryp-tion (ABE) [27], [7], [13], [25] in order to authenticateclients through policy-based access control. The secondextension is to use threshold secret sharing [29] in orderto achieve better reliability for key management.
By no means do we claim the protocol designs of ABE-based access control and threshold secret sharing areour contributions. Instead, our contribution here is todemonstrate a proof of applicability of existing securitymechanisms in a real-life cloud storage environment,and characterize their performance overheads via ourempirical experiments (see Section 6).
4.2.1 Access Control with ABE
To recover a file from the cloud, a client needs torequest the key manager (assuming that only a singlekey manager is deployed) to decrypt the data key. Theclient needs to present authentication credentials to thekey manager to show that it indeed satisfies the policiesassociated with the files. One implementation approachfor this authentication process is based on the public-keyinfrastructure (PKI). However, this client-based authen-tication requires the key manager to have accesses to theassociation of every client and its satisfied policies. Thislimits the scalability and flexibility if we scale up thenumber of supported clients and their associations withpolicies.
To resolve the scalability issue, attribute-based encryp-tion (ABE) [27], [7], [13], [25] turns out to be the mostappropriate solution (see Section 2.2). In particular, ourapproach is based on Ciphertext-Policy Attribute-BasedEncryption (CP-ABE) [7]. We summarize the essentialideas of ABE that are sufficient for our FADE design,while we refer readers to [7] for details. Each clientfirst obtains, from the key issuing authority of the ABEsystem, an ABE-based private access key that corresponds
Pi
[r]ABE
Cloud Client Key manager
hash(r)
ACKrevoke controlkey of Pi
Fig. 5: Policy revocation with ABE.
to a set of attributes3 the client satisfies. This can be doneby having the client present authentication credentialsto the key issuing authority, but we emphasize thatthis authentication is only a one-time bootstrap process.Later, when a client requests the key manager to decryptthe data key of a file on the cloud, the key managerwill encrypt the response messages using the ABE-basedpublic access key that corresponds to the combinationof policies associated with the file. If the client indeedsatisfies the policy combination, then it can use its ABE-based private access key to recover the data key. Notethat the key manager does not have to know exactly eachindividual client who requests decryption of a data key.
FADE uses two independent keys for each policy. Thefirst one is the private control key that is maintained bythe key manager for assured deletion. If the control keyis removed from the key manager, then the client cannotrecover the files associated with the corresponding pol-icy. Another one is the ABE-based access key that is usedfor access control. The ABE-based private access key isdistributed to the clients who satisfy the correspondingpolicy, as in the ABE approach, while the key managerholds the ABE-based public access key and uses it toencrypt the response messages returned to the clients.The use of the two sets of keys for the same policyenables FADE to achieve both access control and assureddeletion.
We now modify the FADE operations to include theABE feature as follows. We assume that we operate ona file that is associated with a single policy.
File Upload. The file upload operation remains un-changed, since we only need the public parameters fromthe key manager for this operation, and hence we do notneed to authenticate the client.
File Download. The file download operation requiresauthentication of the client. When the client requeststhe key manager to decrypt Sei
i Rei , the key managerencrypts its answer SiR with ABE based on the policyof the file. Therefore, if the client satisfies the policy, thenit can decrypt the response message and get SiR.
Policy Renewal. Similar to above, the key managerencrypts SiR with ABE when the client requests it todecrypt the old policy. For the re-encryption with thenew policy, there is no need to enforce access controlsince we only need the public parameters.
3. An attribute is equivalent to an atomic policy that we define forpolicy-based file assured deletion (see Section 2).
IEEE TRANSACTIONS ON DEPEDABLE AND SECURE COMPUTINGThis article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication.
8
Pi
ei1 , ni1
Pi , {K}Si , Sei1
i1 , ..., SeiN
iN , {F}K
Cloud Client Key manager 1
Pi
eiN , niN
Key manager N...
...
...
Fig. 6: File upload with multiple key managers.
Policy Revocation. Here we use a challenge-responsemechanism in order for the key manager to authenticatethe client. Figure 5 shows the revised policy revocationprotocol. In the first round, the client tells the keymanager that it wants to revoke policy Pi. The key man-ager then generates a random number r as a challenge,encrypts it with ABE that corresponds to policy Pi, andgives it to the client. Next, if the client is genuine, thenit can decrypt r and send its hash to the key manager asthe response to that challenge. Finally, the key managerrevokes the policy and acknowledges the client.
4.2.2 Multiple Key ManagersWe point out that the use of a single key manager willlead to the single-point-of-failure problem. An untrust-worthy key manager may either prematurely removesthe keys before the client requests to revoke them, orfail to remove the keys when it is requested to. Theformer case may prevent the client from getting its databack, while the latter case may subvert assured deletion.Therefore, it is important to improve the robustness ofthe key management service to minimize its chance ofbeing compromised. Here, we apply Shamir’s (M,N)threshold secret sharing scheme [29], where M ≤ N (seeSection 3.4). Using Shamir’s scheme, we divide a secretinto N shares and distribute them over N independentkey managers, such that we must obtain the correctshares from at least M out of N key managers in orderto reconstruct the original secret.
In FADE, we need to address the challenge of howto manage the control keys with N > 1 key managers.For each policy Pi, the jth key manager (where 1 ≤j ≤ N ) will independently generate and maintain an RSApublic/private control key pair (eij , dij) correspondingto a modulus nij . We point out that this key pair isindependent of the key pairs generated by other keymanagers, although all such key pairs correspond to thesame policy Pi. Also, each key manager keeps its ownkey pair and will not release it to other key managers.
Let us consider a file F that is associated with policyPi. We now describe the file/policy operations of FADEusing multiple key managers.
File Upload. Figure 6 shows the file upload operationwith multiple key managers. Instead of storing Sei
i onthe cloud as in the case of using a single key manager,the client now splits Si into N shares, Si1, Si2, . . . , SiN
using Shamir’s scheme. Next, the client requests each
Pi , Sei1
i1Rei1
[Si1R]ABE
Cloud Client
Pi , {K}Si , Sei1
i1 , ..., SeiN
iN , {F}K
Key manager 1 Key manager N
...
...
...
[SiNR]ABE
Pi , SeiN
iNReiN
Fig. 7: File download with multiple key managers andABE.
Pi , Sei1
i1 , ..., SeiN
iN
Cloud Client Key manager 1 Key manager N...
Pi , Sei1
i1Rei1, Pj...
...
Pi , SeiN
iNReiN, Pj
Pj, Sej1
i1 , ..., SejN
iN
[Si1R]ABE , ej1, nj1
[SiNR]ABE , ejN, njN
Fig. 8: A special case of policy renewal with multiplekey managers and ABE - when policy Pi is renewed topolicy Pj .
key manager j for the public control key (nij , eij). Thenthe client computes S
eijij (mod nij) for each j, and
sends {K}Si, Sei1
i1 , Sei2i2 , . . . , SeiN
iN , and {F}K to the cloud.Finally, the client discards K, Si, and Si1, Si2, . . . , SiN .
File Download. Figure 7 shows the file downloadoperation with multiple key managers. After retrievingthe encrypted key shares Sei1
i1 , Sei2i2 , . . . , SeiN
iN from thecloud, the client needs to request each key manager todecrypt a share. For the jth share S
eijij (j = 1, 2, . . . , N),
the client blinds it with a randomly generated number R,and sends Seij
ij Reij to key manager j. Then, key managerj responds the client with SijR. It also encrypts theresponse with ABE. After unblinding, the client knowsSij . After collecting M decrypted shares of Sij , the clientcan combine them into S, and hence decrypts K and F .
Policy Renewal. The policy renewal operation is sim-ilar to our original operation discussed in Section 4.1.4.The only difference is that the client needs to renewevery share of Si. Note that in this operation we do notneed to combine or split the shares. Figure 8 shows aspecial case of renewing a policy Pi to another Pj (cf.Figure 4 in Section 4).
Policy Revocation. The client needs to ask every keymanager to revoke the policy. As long as at least (N −M + 1) key managers remove the private control keyscorresponding to the policy, all files associated with thispolicy become assuredly deleted.
4.3 Security Analysis
FADE is designed to protect outsourced data from unau-thorized access and to assuredly delete outsourced data.
IEEE TRANSACTIONS ON DEPEDABLE AND SECURE COMPUTINGThis article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication.
9
We now briefly summarize how FADE achieves its se-curity properties as described in Section 3.4.
In our context, the cloud storage is untrusted andinsecure. The cloud may still keep backup copies of anyoutsourced file after it is requested for deletion. Supposethat an attacker gains access to the cloud storage andobtains the (encrypted) copies of all active and deletedfiles. Now we argue that the attacker cannot recover anydata from those files protected with FADE.
Active files. An active file on the cloud is encryptedwith a data key, which can only be decrypted by thekey manager. In order to reveal the original data, theattacker has to request the key manager to decrypt thedata key. As discussed in Section 4.2.1, the response fromthe key manager is protected with the ABE-based accesskey. As long as the attacker does not have the access key,it cannot decrypt the data key, and hence cannot decryptthe original data.
Deleted files. A file becomes deleted when its associ-ated policy is revoked. A deleted file is still encryptedwith a data key. However, since the key manager haspurged the control key for the revoked policy per-manently, it loses the ability to decrypt the data key.Therefore, the attacker cannot recover the original data.Moreover, even if the attacker is powerful enough to getthe ABE access key or compromise the key manager toget all control keys, the original data of the deleted fileis still unrecoverable as the corresponding control key isalready disposed.
5 IMPLEMENTATION
We implement a working prototype of FADE using C++on Linux. Our implementation is built on off-the-shelflibrary APIs. Specifically, we use the OpenSSL library[22] for the cryptographic operations, the cpabe library[34] for the ABE-based access control, and the sssslibrary [31] for sharing control keys to a quorum ofkey managers. The ssss library is originally designedas a command-line utility to deal with keys in ASCIIformat. We slightly modify ssss and add two functionsto split and combine keys in binary format, so as to makeit compatible with other libraries. In addition, we useAmazon S3 [4] as our cloud storage backend.
In the following, we define the metadata of FADEbeing attached to individual data files. We then describehow we implement the client and a quorum of keymanagers and how the client interacts with the cloud.
5.1 Representation of Metadata
For each data file protected by FADE, we include themetadata that describes the policies associated with thefile as well as a set of cryptographic keys. More precisely,the metadata contains the specification of the Booleancombination of policies, and the corresponding crypto-graphic keys including the encrypted data key of the fileand the control keys associated with the policies. Here,we assume that each (atomic) policy is specified by a
unique 4-byte integer identifier. To represent a Booleancombination of policies, we express it in disjunctive canon-ical form, i.e., the disjunction (OR) of conjunctive policies,and use the characters ‘*’ and ‘+’ to denote the AND andOR operators. We upload the metadata as a separate fileto the cloud. This enables us to renew policies directlyon the metadata file without retrieving the entire datafile from the cloud.
In our implementation, individual data files have theirown metadata, each specifying its own data key. Toreduce the metadata overhead as compared to the datafile size, we can form a tarball of multiple files underthe same policy combination and have all files protectedwith the same data key.
5.2 ClientOur client implementation uses four function calls toenable end users to interact with the cloud:
• Upload(file, policy). The client encrypts theinput file according to the specified policy (or aBoolean combination of policies). Here, the file isencrypted using the 128-bit AES algorithm withthe cipher block chaining (CBC) mode. After en-cryption, the client also appends the encrypted filesize (8 bytes long) and the HMAC-SHA1 signature(20 bytes long) to the end of encrypted file forintegrity checking in later downloads. It then sendsthe encrypted file and the metadata onto the cloud.
• Download(file). The client retrieves the file andpolicy metadata from the cloud. It then checks theintegrity of the encrypted file, and decrypts the file.
• Revoke(policy). The client tells the key man-agers to permanently revoke the specified policy.All files associated with the policy will be assuredlydeleted. If a file is associated with the conjunctivepolicy combination that contains the revoked policy,then it will be assuredly deleted as well.
• Renew(file, new_policy). The client firstfetches the metadata of the given file from thecloud. It updates the metadata with the new policy.Finally, it sends the metadata back to the cloud.Note that the operation does not involve transferof the input file.
We export the above function calls exported as libraryAPIs. Thus, different implementations of the client cancall the library APIs and have the protection offered byFADE. In our current prototype, we implement the clientas a user-level program that can access files under aspecified folder.
The above interfaces wrap the third-party APIs forinteracting with the cloud. As an example, we useLibAWS++ [18], a C++ library for interfacing with Ama-zon S3 using plain HTTP.
5.3 Key ManagersWe implement a quorum of key managers, each of whichsupports two major types of functions: (i) policy manage-ment, in which a key manager creates or revokes policies,
IEEE TRANSACTIONS ON DEPEDABLE AND SECURE COMPUTINGThis article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication.
10
as well as their associated control keys (for assureddeletion) and access keys (for access control), and (ii)key management, in which a key manager performs theencryption or decryption on the (blinded) data key.
We implement the basic functionalities of a key man-ager so that it can perform the required operationson the cryptographic keys. In particular, all the policycontrol keys are built upon 1024-bit blinded RSA (seeSection 4.1.1). Besides, each individual key managersupports ABE for access control.
6 EVALUATION
We now evaluate the empirical performance of ourimplemented prototype of FADE atop Amazon S3. Itis crucial that FADE does not introduce substantialperformance or monetary overhead that will lead to abig increase in data management costs. In addition, thecryptographic operations of FADE should only bringinsignificant computational overhead. Therefore, our ex-periments aim to answer the following questions: Whatis the performance and monetary overhead of FADE? Isit feasible to use FADE to provide file assured deletionfor cloud storage?
Our experiments use Amazon S3 APAC servers thatreside in Singapore for our cloud storage backend. Also,we deploy the client and the key managers within a uni-versity department network in Hong Kong. We evaluateFADE on a per-file basis, that is, when it operates on anindividual file of different sizes. We can proportionallyscale our results for the case of multiple files.
6.1 Time Performance of FADE
We first measure the time performance of our FADEprototype. In order to identify the time overhead ofFADE, we divide the running time of each measurementinto three components:
• file transmission time, the uploading/downloadingtime for the data file between the client and thecloud.
• metadata transmission time, the time for upload-ing/downloading the metadata, which contains thepolicy information and the cryptographic keys as-sociated with the file, between the client and thecloud.
• cryptographic operation time, the total time for crypto-graphic operations, which includes the total compu-tational time used for performing AES and HMACon the file, and the time for the client to coordinatewith the quorum of key managers on operating thecryptographic keys.
We average each of our measurement results over 10different trials.
6.1.1 Evaluation of Basic DesignWe first evaluate the time performance of the basicdesign of FADE (see Section 4), in which we use a singlekey manager and do not involve ABE.
0.001
0.01
0.1
1
10
100
1 10 100 1000 10000
Tim
e (s
)
File size (KB)
File transmissionMetadata transmission
Crypto operations
(a) Upload
0.001
0.01
0.1
1
10
100
1 10 100 1000 10000
Tim
e (s
)
File size (KB)
File transmissionMetadata transmission
Crypto operations
(b) Download
Fig. 9: Experiment A.1 (Performance of file upload anddownload operations).
Experiment A.1 (Performance of file upload anddownload operations). We first measure the runningtime of the file upload and download operations fordifferent file sizes (including 1KB, 3KB, 10KB, 30KB,100KB, 300KB, 1MB, 3MB, and 10MB).
Figure 9 shows the results. First, the cryptographicoperation time increases with the file size, mainly dueto the symmetric-key encryption applied to a largerfile. Nevertheless, we find that in all cases of file up-load/download operations, the time of cryptographicoperations is no more than 0.2s (for a file size within10MB), and accounts for no more than 2.6% of the filetransmission time. We expect that FADE only introducesa small time overhead in cryptographic operations ascompared to the file transmission time, where the latteris inevitable even without FADE.
Also, the metadata transmission time is always around0.2s, regardless of the file size. This is expected, sincethe metadata file only stores the policy information andcryptographic keys, both of which are independent ofthe data files. The file transmission time is comparable tothe metadata transmission time for small files. However,for files larger than 100KB, the file transmission timebecomes the dominant factor. For instance, to uploador download a 10MB file, the sum of the metadatatransmission time and the cryptographic operation time(both are due to FADE) account for 4.1% and 0.7% of thetotal time, respectively.
Note that the upload and download operations areasymmetric and use different times to complete the oper-ations. Nevertheless, the performance overhead of FADEdrops when the size of the data file being protected islarge enough, for example, on the megabyte scale.
Experiment A.2 (Performance of policy updates).Table 2 shows the time used for renewing a single policyof a file (see Figure 4 in Section 4.1.4), in which weupdate the policy metadata on the cloud with the newset of cryptographic keys. We conduct the experiment onvarious file sizes ranging from 1KB to 10MB. Our exper-iments show that the total time is generally small (about0.3 seconds) regardless of the file size, since we operateon the policy metadata only. Also, the cryptographicoperation time only takes about 0.004s in renewing apolicy, and this value is independent of the file size.
Experiment A.3 (Performance of multiple policies).
IEEE TRANSACTIONS ON DEPEDABLE AND SECURE COMPUTINGThis article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication.
11
File size Total timeMetadata transmission Crypto operations
TABLE 2: Experiment A.2 (Performance of policy updates).
0.001
0.01
0.1
1
10
1 2 3 4 5
Tim
e of
cry
pto
oper
atio
ns (
s)
Number of conjunctive policies
1KB10KB
100KB1000KB
10000KB
(a) Conjunctive policies
0.001
0.01
0.1
1
10
1 2 3 4 5
Tim
e of
cry
pto
oper
atio
ns (
s)
Number of disjunctive policies
1KB10KB
100KB1000KB
10000KB
(b) Disjunctive policies
Fig. 10: Experiment A.3 (Performance of multiple poli-cies).
We now evaluate the performance of FADE when multi-ple policies are associated with a file (see Section 4.1.3).Here, we focus on the file upload operation, as we havesimilar observation for the file download operation. Welook at two specific combinations of policies, one on theconjunctive case and one on the disjunctive case.
Figure 10a shows the cryptographic operations timefor different numbers of conjunctive policies, and Fig-ure 10b shows the case for disjunctive policies. A keyobservation is that for each file size, the cryptographicoperation time is more or less constant (less than 0.22s)within five policies. It is reasonable to argue that the timewill increase when a file is associated with a significantlylarge number of policies. On the other hand, we expectthat in practical applications, a file is associated withonly a few policies, and the overhead of cryptographicoperations is still minimal.
6.1.2 Evaluation of Extensions
We now evaluate the time performance of the extensionsthat we add to FADE (see Section 4.2). This includes theuse of ABE and a quorum of key managers.
Experiment B.1 (Performance of CP-ABE). In the filedownload operations, the key manager encrypts the de-crypted keys with the ABE-based key of the correspond-ing policy (or combination of policies) (see Section 4.2).In this experiment, we examine the overhead of thisadditional encryption. We focus on downloading a filethat is associated with a single policy, assuming that asingle key manager is used.
Figure 11 shows the cryptographic operation time fordownloading a file with CP-ABE and without CP-ABE.We find that CP-ABE introduces a constant overhead of0.06-0.07 seconds, which is reasonable. This shows thetrade-off between better performance and better security.
0 0.02 0.04 0.06 0.08
0.1 0.12 0.14 0.16 0.18
0.2
1 10 100 1000 10000
Tim
e (s
)
File size (KB)
crypto operation time without CP-ABEcrypto operation time with CP-ABE
Fig. 11: Experiment B.1 (Performance of CP-ABE).
0.001
0.01
0.1
1
10
1 2 3 4 5
Tim
e of
cry
pto
oper
atio
ns (
s)
Number of key managers
1KB10KB
100KB1000KB
10000KB
(a) Upload
0.001
0.01
0.1
1
10
1 2 3 4 5
Tim
e of
cry
pto
oper
atio
ns (
s)
Number of key managers
1KB10KB
100KB1000KB
10000KB
(b) Download
Fig. 12: Experiment B.2 (Performance of multiple keymanagers).
Experiment B.2 (Performance of multiple key man-agers). We now analyze the performance of using multi-ple key managers. Here, we do not enforce access controlwith ABE, in order to focus on the overhead introducedby multiple key managers. In particular, we use the N -out-of-N scheme for key sharing, i.e., the client needs toretrieve key shares from all key managers. This puts themaximum load on the key managers.
Figure 12 shows the cryptographic operation timeusing different number of key managers. For the fileupload operation, the cryptographic operation time staysnearly constant (less than 0.22s) when the number ofkey managers increases. For the file download operation,the cryptographic operation time only increases by about0.01s when the number of key managers increases fromone to five. Again, this value is less significant foruploading/downloading larger data files.
Experiment B.3 (Combining everything together).Lastly, we combine multiple policies, CP-ABE, and mul-tiple key managers together. The enables us to under-stand the maximum load of FADE with all the availablesecurity protection schemes. In this experiment, we mea-sure the time overhead when downloading a 10MB filewith different number of policies and key managers. Weconsider the case where all policies are conjunctive. Forthe multiple key managers, we use the N -out-of-N keysharing scheme.
IEEE TRANSACTIONS ON DEPEDABLE AND SECURE COMPUTINGThis article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication.
Fig. 13: Experiment B.3 (Performance of multiple policiesand multiple key managers with CP-ABE).
Figure 13 shows the cryptographic operation time foreach case. We find that when turning on CP-ABE, thetime of cryptographic operations increases almost lin-early with both the number of policies and the number ofkey managers. Even for the worst case (five policies andfive key managers), the cryptographic operation time isstill less than two seconds, which is small compared withthe file transmission time.
6.2 Cost Model
We now evaluate the monetary overhead of FADE us-ing a simple pricing model. Here, we use a simplifiedpricing scheme of Amazon S3 in Singapore, in whichwe assume that our storage usage is less than 1TBand our monthly data outbound transfer size is lessthan 10TB. We estimate the cost of FADE based onCumulus [35], a snapshot-based backup system. In [1],it is shown that a typical compressed snapshot consistsof hundreds of segments, each of which is around fivemegabytes. Here, we assume that our data source hass files (segments) and each file is f bytes. Suppose thateach segment is associated with p policies4, and thereare N key managers. We evaluate the cost when eachfile is uploaded u times and downloaded d times. Wedenote by meta(p,N) the size of the metadata, which isa function of p (number of policies) and N (number ofkey managers).
Table 3 shows our simplified pricing scheme (as of July2011) and the corresponding cost results. To illustrate,we plug in some example values as follows. We let s =300 and f = 5MB, for a total of 1.5GB data. We use 3conjunctive policies and 3 key managers. We assume thateach file is uploaded once and downloaded once. Fromthe table, we can see that the extra cost that FADE incursis less than 1.3% per month.
6.3 Lessons Learned
In this section, we evaluate the performance of FADE interms of running time overhead and monetary cost. It isimportant to note that the performance results dependon the deployment environment. For instance, if theclient and the key manager all reside in the same regionas Amazon S3, then the transmission times for files and
4. In Cumulus, each segment may be composed of multiple smallfiles. We assume the simplest case that all the files are associated withthe same combination of policies.
metadata will significantly reduce; or if the metadatacontains more descriptive information, the overhead willincrease. Nevertheless, we emphasize that our experi-ments can show the feasibility of FADE in providing anadditional level of security protection for today’s cloudstorage.
We note that the performance overhead of FADEbecomes less significant when the size of the actual datafile content increases (e.g. on the order of megabytes oreven bigger). Thus, FADE is more suitable for enterprisesthat need to archive large files with a substantial amountof data. On the other hand, individuals may generallymanipulate small files on the order of kilobytes. In thiscase, we may consider associating the same metadatawith a tarball of multiple files (see Section 5) to reducethe overhead of FADE.
7 RELATED WORK
In this section, we review other related work on how toapply security protection to outsourced data storage.
Cryptographic protection on outsourced storage. Re-cent studies (see survey in [17]) propose to protectoutsourced storage via cryptographic techniques. Plutus[16] is a cryptographic storage system that allows securefile sharing over untrusted file servers. Ateniese et al.[6] and Wang et al. [36] propose an auditing systemthat verifies the integrity of outsourced data. Wang etal. [37] propose a secure outsourced data access mech-anism that supports changes in user access rights andoutsourced data. However, all the above systems requirenew protocol support on the cloud infrastructure, andsuch additional functionalities may make deploymentmore challenging.
Secure storage solutions for public clouds. Securesolutions that are compatible with existing public cloudstorage services have been proposed. Yun et al. [40]propose a cryptographic file system that provides pri-vacy and integrity guarantees for outsourced data usinga universal-hash based MAC tree. They prototype asystem that can interact with an untrusted storage servervia a modified file system. JungleDisk [15] and Cumulus[35] protect the privacy of outsourced data, and their im-plementation use Amazon S3 [4] as the storage backend.Specifically, Cumulus focuses on making effective use ofstorage space while providing essential encryption onoutsourced data. On the other hand, such systems donot consider file assured deletion in their designs.
Access control. One approach to apply access controlto outsourced data is by attribute-based encryption (ABE),which associates fine-grained attributes with data. ABEis first introduced in [27], in which attributes are associ-ated with encrypted data. Goyal et al. [13] extend the ideato key-policy ABE, in which attributes are associatedwith private keys, and encrypted data can be decryptedonly when a threshold of attributes are satisfied. Pirrettiet al. [25] implement ABE and conduct empirical studies,and also point out th. Nair et al. [20] consider a similar
IEEE TRANSACTIONS ON DEPEDABLE AND SECURE COMPUTINGThis article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication.
13
Pricing Without FADE With FADE
Storage (cs) $0.14 per GB cs · s · f = $0.210 cs · s · (f + 28 +meta(p,N)) = $0.210
Data transfer in (ci) $0.00 per GB ci · s · f · u = $0.000 ci · s · (f + 28 +meta(p,N)) · u = $0.000
Data transfer out (co) $0.19 per GB with first 1GB free co · s · f · d = $0.095 co · s · (f + 28 +meta(p,N)) · d = $0.095
PUT requests (cp) $0.01 per 1,000 requests cp · s · u = $0.003 cp · s · 2u = $0.006
GET requests (cg) $0.01 per 10,000 requests cg · s · d = $0.000 cg · s · 2d = $0.001
Total cost $0.308 $0.312
TABLE 3: A simplified pricing scheme of Amazon S3 in Singapore and the corresponding cost report (in US dollars).All numbers are rounded off to 3 decimal places. Note that FADE only adds very small overheads to the storageand data transfer costs, which are rounded off to the same values as in without FADE.
idea of ABE, and they seek to enforce a fine-grainedaccess control of files based on identity-based public keycryptography.
Policy-based deletion follows the similar notion ofABE, in which data can be accessed only if the corre-sponding attributes (i.e., atomic policies in our case) aresatisfied. However, policy-based deletion has a differentdesign objective from ABE. Policy-based deletion focuseson how to delete data, while ABE focuses on how toaccess data based on attributes. A major feature of ABEis to issue users the decryption keys of the associatedattributes so that they can access files that satisfy theattributes, and hence existing studies of ABE seek toensure that no two users can collude if they are tiedwith different sets of attributes.
On the other hand, in policy-based deletion, sinceeach policy is possessed by multiple users, revoking apolicy requires a centralized administrator to managethe revocation [25]. Boldyreva et al. [8] and Yu et al. [39]combine ABE with attribute revocation, and both of thestudies require the use of some centralized key server tomanage the attributes and the corresponding keys (i.e.,policy-based control keys in our case). For example, in[39], there is a semi-trustable on-line proxy server, inwhich data is re-encrypted with new keys upon attributerevocation.
In FADE, each policy is associated with two keys.One is the access key, which is issued to users, andanother is the control key, which is maintained by thekey server. Both access and control keys are required todecrypt a file. This type of separation is similar to theapproaches in [8], [39]. On the other hand, the main focusof our work is to empirically evaluate the feasibility ofour system via practical implementation, while [8], [39]mainly focus on security analysis.
Assured deletion. In Section 2.1, we discuss time-based deletion in [12], [23], which we generalize intopolicy-based deletion. There are several related systemson assured deletion (which come after our conferenceversion of the paper [33]). Keypad [11] protects data intheft-prone devices (e.g., laptops, USB sticks) by encrypt-ing such data and maintaining keys in an independent,centralized key server, similar to FADE. It removes alldata of a protected device upon requests of deletion,and does not consider fine-grained deletion as in FADE.Nasuni announced the support of assured deletion in
backup snapshots in March 2011 [21]. However, thereis no formal study about their implementation method-ologies and performance evaluation. In our recent work[26], we extend the idea of assured deletion to cloudbackup systems with version control, but the work [26]does not consider access control and the use of multiplekey managers for key management.
8 CONCLUSIONS
We propose a practical cloud storage system calledFADE, which aims to provide access control assureddeletion for files that are hosted by today’s cloud storageservices. We associate files with file access policies thatcontrol how files can be accessed. We then presentpolicy-based file assured deletion, in which files areassuredly deleted and made unrecoverable by anyonewhen their associated file access policies are revoked.We describe the essential operations on cryptographickeys so as to achieve access control and assured deletion.FADE also leverages existing cryptographic techniques,including attribute-based encryption (ABE) and a quo-rum of key managers based on threshold secret sharing.We implement a prototype of FADE to demonstrate itspracticality, and empirically study its performance over-head when it works with Amazon S3. Our experimentalresults provide insights into the performance-securitytrade-off when FADE is deployed in practice.
Source code of FADE (including the newfeatures of this journal paper) is available athttp://ansrlab.cse.cuhk.edu.hk/software/fade.
ACKNOWLEDGMENTS
The work of Patrick P. C. Lee was supported by project#MMT-p1-10 of the Shun Hing Institute of AdvancedEngineering, The Chinese University of Hong Kong.
REFERENCES[1] H. Abu-Libdeh, L. Princehouse, and H. Weatherspoon. RACS: A
Case for Cloud Storage Diversity. In Proc. of ACM SoCC, 2010.[2] Amazon. Case Studies. http://aws.amazon.com/solutions/case-
studies/#backup.[3] Amazon. SmugMug Case Study: Amazon Web Services. http:
//aws.amazon.com/solutions/case-studies/smugmug/, 2006.[4] Amazon S3. http://aws.amazon.com/s3, 2010.[5] M. Armbrust, A. Fox, R. Griffith, A. D. Joseph, R. Katz, A. Kon-
winski, G. Lee, D. Patterson, A. Rabkin, I. Stoica, and M. Zaharia.A View of Cloud Computing. Comm. of the ACM, 53(4):50–58, Apr2010.
IEEE TRANSACTIONS ON DEPEDABLE AND SECURE COMPUTINGThis article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication.
14
[6] G. Ateniese, R. D. Pietro, L. V. Mancini, and G. Tsudik. Scalableand Efficient Provable Data Possession. In Proc. of SecureComm,2008.
[7] J. Bethencourt, A. Sahai, and B. Waters. Ciphertext-PolicyAttribute-Based Encryption. In Proc. of IEEE Symp. on Securityand Privacy, May 2006.
[8] A. Boldyreva, V. Goyal, and V. Kumar. Identity-based Encryptionwith Efficient Revocation. In Proc. of ACM CCS, 2008.
[9] T. Dierks and E. Rescorla. The transport layer security (tls)protocol version 1.2, Aug 2008. RFC 5246.
[10] Dropbox. http://www.dropbox.com, 2010.[11] R. Geambasu, J. P. John, S. D. Gribble, T. Kohno, and H. M. Levy.
Keypad: Auditing File System for Mobile Devices. In Proc. ofEuroSys, April 2011.
[12] R. Geambasu, T. Kohno, A. Levy, and H. M. Levy. Vanish:Increasing Data Privacy with Self-Destructing Data. In Proc. ofUSENIX Security Symp., Aug 2009.
[13] V. Goyal, O. Pandey, A. Sahai, and B. Waters. Attribute-BasedEncryption for Fine-Grained Access Control of Encrypted Data.In Proc. of ACM CCS, 2006.
[14] P. Gutmann. Secure deletion of data from magnetic and solid-statememory. In Proc. of USENIX Security Symp., 1996.
[15] JungleDisk. http://www.jungledisk.com/, 2010.[16] M. Kallahalla, E. Riedel, R. Swaminathan, Q. Wang, and K. Fu.
Plutus: Scalable Secure File Sharing on Untrusted Storage. In Proc.of USENIX FAST, 2003.
[17] S. Kamara and K. Lauter. Cryptographic Cloud Storage. InProc. of Financial Cryptography: Workshop on Real-Life CryptographicProtocols and Standardization, 2010.
[18] LibAWS++. http://aws.28msec.com/, 2010.[19] A. J. Menezes, P. C. van Oorschot, and S. A.Vanstone. Handbook
of Applied Cryptography. CRC Press, Oct 1996.[20] S. Nair, M. T. Dashti, B. Crispo, and A. S. Tanenbaum. A Hybrid
PKI-IBC Based Ephemerizer System. IFIP International Federationfor Information Processing, 232:241–252, 2007.
[21] Nasuni. Nasuni Announces New Snapshot Retention Functional-ity in Nasuni Filer; Enables Fail-Safe File Deletion in the Cloud,Mar 2011. http://www.nasuni.com/news/press-releases/nasuni-announces-new-snapshot-retention-functionality-in-nasuni-filer-enables-fail-safe-file-deletion-in-the-cloud/.
[22] OpenSSL. http://www.openssl.org/, 2010.[23] R. Perlman. File System Design with Assured Delete. In ISOC
NDSS, 2007.[24] R. Perlman, C. Kaufman, and R. Perlner. Privacy-Preserving DRM.
In IDtrust, 2010.[25] M. Pirretti, P. Traynor, P. McDaniel, and B. Waters. Secure
Attribute-Based Systems. In Proc. of ACM CCS, 2006.[26] A. Rahumed, H. C. H. Chen, Y. Tang, P. P. C. Lee, and J. C. S.
Lui. A Secure Cloud Backup System with Assured Deletion andVersion Control. In 3rd International Workshop on Security in CloudComputing, 2011.
[27] A. Sahai and B. Waters. Fuzzy Identity-Based Encryption. InEUROCRYPT, 2005.
[28] B. Schneier. File Deletion. http://www.schneier.com/blog/archives/2009/09/file deletion.html, Sep 2009.
[29] A. Shamir. How to Share a Secret. CACM, 22(11):612–613, Nov1979.
[30] SmugMug. http://www.smugmug.com/, 2010.[31] ssss. http://point-at-infinity.org/ssss/, 2006.[32] W. Stallings. Cryptography and Network Security. Prentice Hall,
2006.[33] Y. Tang, P. P. C. Lee, J. C. S. Lui, and R. Perlman. FADE: Secure
Overlay Cloud Storage with File Assured Deletion. In Proc. ofICST SecureComm, 2010.
[34] The CPABE Toolkit. http://acsc.cs.utexas.edu/cpabe/, 2010.[35] M. Vrable, S. Savage, and G. M. Voelker. Cumulus: Filesystem
backup to the cloud. ACM Trans. on Storage, 5(4), Dec 2009.[36] C. Wang, Q. Wang, K. Ren, and W. Lou. Privacy-preserving public
auditing for storage security in cloud computing. In Proc. of IEEEINFOCOM, Mar 2010.
[37] W. Wang, Z. Li, R. Owens, and B. Bhargava. Secure and EfficientAccess to Outsourced Data. In ACM CCSW, Nov 2009.
[38] S. Wolchok, O. S. Hofmann, N. Heninger, E. W. Felten, J. A.Halderman, C. J. Rossbach, B. Waters, and E. Witchel. DefeatingVanish with Low-Cost Sybil Attacks Against Large DHTs. In Proc.of NDSS, 2010.
[39] S. Yu, C. Wang, K. Ren, and W. Lou. Attribute Based Data Sharingwith Attribute Revocation. In Proc. of ACM ASIACCS, Apr 2010.
[40] A. Yun, C. Shi, and Y. Kim. On Protecting Integrity and Confi-dentiality of Cryptographic File System for Outsourced Storage.In ACM CCSW, Nov 2009.
Yang Tang received the B.Eng. degree in Com-puter Science and Technology from TsinghuaUniversity in 2009 and the M.Phil. degree inComputer Science and Engineering from theChinese University of Hong Kong in 2011. Heis currently working toward the Ph.D. degree inComputer Science at Columbia University. Hisresearch interests are in reliability/security ofsoftware systems (including network and mobilesystems) and program analysis/verification.
Patrick P. C. Lee received the B.Eng. degree(first-class honors) in Information Engineeringfrom the Chinese University of Hong Kong in2001, the M.Phil. degree in Computer Scienceand Engineering from the Chinese Universityof Hong Kong in 2003, and the Ph.D. degreein Computer Science from Columbia Universityin 2008. He is now an assistant professor ofthe Department of Computer Science and En-gineering at the Chinese University of HongKong. His research interests are in various ap-
plied/systems topics including cloud computing and storage, distributedsystems and networks, operating systems, and security/resilience.
John C. S. Lui received his Ph.D. in ComputerScience from UCLA. He is currently a Professorwith the Department of Computer Science andEngineering at the Chinese University of HongKong. He was the chairman of the Departmentfrom 2005 to 2011. His current research inter-ests are in data networks, system and appliedsecurity, multimedia systems, network sciencesand cloud computing. He is a Fellow of theAssociation for Computing Machinery (ACM), aFellow of IEEE, a Croucher Senior Research
Fellow, and an elected member of the IFIP WG 7.3.
Radia Perlman is a Fellow at Intel Labs andAdjunct Professor in the Department of Infor-mation Engineering, at the Chinese Universityof Hong Kong. Her contributions to the industryinclude innovations that make link state routingprotocols robust and scalable, the spanning treealgorithm upon which Ethernet was based fordecades, and most recently, TRILL, which elimi-nates the path restrictions of spanning tree whileremaining compatible with both existing Ethernetswitches and endnodes. She also made contri-
butions in security including assured delete of data, strong passwordprotocols, and PKI models. She is the author of the textbook “Intercon-nections: Bridges, Routers, Switches, and Internetworking Protocols”,and coauthor of “Network Security: Private Communication in a PublicWorld”. She holds over 100 patents, a PhD in computer science fromMIT, and various awards, including lifetime achievement awards fromACM SIGCOMM and Usenix, and an honorary doctorate from KTH.
IEEE TRANSACTIONS ON DEPEDABLE AND SECURE COMPUTINGThis article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication.
