Crypt-DAC: Cryptographically Enforced DynamicAccess Control in the Cloud

Saiyu QiState Key Laboratory of Integrated Service Networks (ISN)

Xidian University, ChinaThe State Key Laboratory of Cryptology, PO Box 5159, Beijing 100878, China

syqi@xidian.edu.cn

Yuanqing ZhengDepartment of Computing

The Hong Kong Polytechnic University, Chinacsyqzheng@comp.polyu.edu.hk

Abstract—Enabling cryptographically enforced access controlsfor data hosted in untrusted cloud is attractive for many usersand organizations. However, designing efficient cryptographicallyenforced dynamic access control system in the cloud is stillchallenging. In this paper, we propose Crypt-DAC, a system thatprovides practical cryptographic enforcement of dynamic accesscontrol. Crypt-DAC revokes access permissions by delegating thecloud to update encrypted data. In Crypt-DAC, a file is encryptedby a symmetric key list which records a file key and a sequenceof revocation keys. In each revocation, a dedicated administratoruploads a new revocation key to the cloud and requests it toencrypt the file with a new layer of encryption and update theencrypted key list accordingly. Crypt-DAC proposes three keytechniques to constrain the size of key list and encryption layers.As a result, Crypt-DAC enforces dynamic access control thatprovides efficiency, as it does not require expensive decryption/re-encryption and uploading/re-uploading of large data at theadministrator side, and security, as it immediately revokes ac-cess permissions. We use formalization framework and systemimplementation to demonstrate the security and efficiency of ourconstruction.

Index Terms—access control, cloud, revocation

I. INTRODUCTION

With the considerable advancements in cloud computing,users and organizations are finding it increasingly appealingto store and share data through cloud services. Cloud serviceproviders (such as Amazon, Microsoft, Apple, etc.) provideabundant cloud based services, ranging from small-scale per-sonal services to large-scale industrial services. However,recent data breaches, such as releases of private photos [10],have raised concerns regarding the privacy of cloud-manageddata. Actually, a cloud service provider is usually not securedue to design drawbacks of software and system vulnerability[2], [3]. As such, a critical issue is how to enforce data accesscontrol on the potentially untrusted cloud.

In response to these security issues, numerous works [1],[4]–[9] have been proposed to support access control on un-trusted cloud services by leveraging cryptographic primitives.Advanced cryptographic primitives are applied for enforc-ing many access control paradigms. For example, attribute-based encryption (ABE) [5] is a cryptographic counterpart ofattribute-based access control (ABAC) model [11]. However,previous works mainly consider static scenarios in which

access control policies rarely change. The previous worksincur high overhead when access control policies need to bechanged in practice. At a first glance, the revocation of a user’spermission can be done by revoking his access to the keyswith which the files are encrypted. This solution, however,is not secure as the user can keep a local copy of the keysbefore the revocation. To prevent such a problem, files haveto be re-encrypted with new keys. This requires the file ownerto download the file, re-encrypt the file, and upload it backfor the cloud to update the previous encrypted file, incurringprohibitive communication overhead at the file owner side.

Currently, only a few works investigated the problem ofdynamic data access control. Garrison et al. [12] proposed tworevocation schemes. The first scheme requires an administratorto re-encrypt file with new keys as discussed above. Thisscheme incurs a considerable communication overhead. In-stead, the second scheme delegates users to re-encrypt the filewhen they need to modify the file, relieving the administratorfrom re-encrypting file data by itself. This scheme, however,comes with a security penalty as the revocation operationis delayed to the next user’s modification to the file. As aresult, a newly revoked user can still access the file beforethe next writing operation. Wang et al. [23] proposed anotherrevocation scheme, in which the symmetric homomorphicencryption scheme [24] is used to encrypt the file. Sucha design enables the cloud to directly re-encrypt file with-out decryption. However, this scheme incurs expensive fileread/write overhead as the encryption/decryption operationinvolves comparable overhead with the public key encryptionschemes.

To overcome these problems, we present Crypt-DAC, acryptographically enforced dynamic access control system onuntrusted cloud. Crypt-DAC delegates the cloud to updateencrypted files in permission revocations. In Crypt-DAC, afile is encrypted by a symmetric key list which records afile key and a sequence of revocation keys. In a revocation,the administrator uploads a new revocation key to the cloud,which encrypts the file with a new layer of encryption andupdates the encrypted key list accordingly. Same as previousworks [12], [23], we assume a honest-but-curious cloud, i.e.,the cloud is honest to perform the required commends (such asre-encryption of files and properly update previous encrypted

files) but is curious to passively gathering sensitive informa-tion. Although the basic idea of layered encryption is simple,it entails tremendous technical challenges. For instance, thesize of key list and encryption layers would increase asthe number of revocation operations, which incurs additionaldecryption overhead for users to access files. To overcomesuch a problem, Crypt-DAC proposes three key techniques asfollows.

First, Crypt-DAC proposes delegation-aware encryption s-trategy to delegate the cloud to update policy data. For a file,the administrator appends a new revocation key at the end ofits key list and requests the cloud to update this key list in thepolicy data. The size of the key list however increases with therevocation operations, and a user has to download and decrypta large key list in each file access. To overcome this problem,we adopt the key rotation technique [15] to compactly encryptthe key list in the policy data. As a result, the size of the keylist remains constant regardless of revocation operations.

Second, Crypt-DAC proposes adjustable onion encryptionstrategy to delegate the cloud to update file data. For afile, the administrator requests the cloud to encrypt the filewith a new layer of encryption. Similarly, the size of theencryption layers increases with the revocation operations, anda user has to decrypt multiple times in each file access. Toovercome this problem, we enable the administrator to define atolerable bound for the file. Once the size of encryption layersreaches the bound, it can be made to not increase anymore bydelegating encryption operations to the cloud. As a result, theadministrator can flexibly adjust a tolerable bound for eachfile (according to file type, access pattern, etc.) to achieve abalance between efficiency and security.

During the life cycle of a file, its encryption layers contin-uously increase until a pre-defined bound is reached. Crypt-DAC proposes delayed de-onion encryption strategy to period-ically refresh the symmetric key list of the file and remove thebounded encryption layers over it through writing operations.In specific, the next user to write to the file encrypts the writingcontent by a new symmetric key list only containing a newfile key, and updates the key list in the policy data. Withthis strategy, Crypt-DAC periodically removes the boundedencryption layers of files while amortizing the burden to alarge number of writing users.

Altogether, Crypt-DAC achieves efficient revocation, effi-cient file access and immediate revocation simultaneously. Forrevocation efficiency, Crypt-DAC incurs lightweight commu-nication overhead at the administrator side as it does notneed to download and re-upload file data. For immediaterevocation, the permissions of users are immediately revokedas the files are re-encrypted. For file access efficiency, the filesare still encrypted by symmetric keys. We have implementedCrypt-DAC as well as several recent works [12], [23] onAlicloud. Real experiments suggest that Crypt-DAC is threeorders of magnitude more efficient in communication in accessrevocation compared with the first scheme in [12], and isnearly two orders of magnitude more efficient in computationin file access compared with the scheme in [23]. Finally,

Policy data

Organization Cloud

AdminFile data

Users……

Policy data

File data

……

……

Access policy update

File data read/write

Fig. 1. Cloud enabled data access control.

Crypt-DAC is able to immediately revoke access permissionscompared with the second scheme in [12].

The remainder of this paper is organized as follows. InSection II, we introduce our system model and assumptions,background on RBAC0 and the cryptographic techniques usedin our system design. Section III identifies several criticalissues for cryptographically enforced dynamic access control,from which we derive the principles of Crypt-DAC. Section IVdescribes the design details of Crypt-DAC. In Section V, weformally analyze the security of Crypt-DAC. In Section VI, wecompare the performance of Crypt-DAC through experiments.In Section VII, we discuss related works. Section VIII detailsour conclusions.

II. BACKGROUND AND ASSUMPTIONS

In this section, we first define the system and threat models.We then define the classes of cryptographic primitives uponwhich Crypt-DAC is based.

A. System model

Our system model is depicted in Figure 1. We consid-er a scenario where companies contract with a commercialcloud provider (e.g., Alicloud, Microsoft Azure) to outsourceenterprise storage. There are three types of entities in oursystem model: a cloud provider, an access control admin-istrator, and a large number of users. The cloud provideris responsible for the data storage and management. Thedata includes file data of users in the company, as well aspolicy data regulating access policies for these files. Boththe policy/file data are encrypted prior to being uploadedto the cloud provider. The access control administrator isresponsible for managing access policies of the file data. Itassigns/revokes access permissions by creating, updating, anddistributing cryptographic keys used to encrypt files. Usersmay download any policy/file data from the cloud, but areonly allowed to decrypt and read files according to their accesspermissions. We do not consider data deduplication issue. IFneeded, secure data deduplication technique [14] can be usedhere. We also assume that all parties communicate via pairwisesecure channels (e.g., SSL/TLS tunnels).

B. Threat model

In our threat model, we consider that the administrator ishonest. The users may try to access the file data out of their

access permissions by compromising the cloud provider. Sameas previous works [12], [23], we assume a honest-but-curiouscloud provider. Honest means that the cloud provider honestlyfollows the commands of the administrator/users such as re-encryption of policy/file data and properly update previous pol-icy/file data. Since any errors due to the provider’s misbehaviorwill harm its reputation, we believe that the cloud provider hasincentive to follow the commands required by its customers.However, the cloud provider may be curious to passivelygathering sensitive information to acquire commercial benefitsas it is hard to be detected.

We notice that the honest-but-curious assumption is crit-ical to resist collusion between the cloud provider and re-voked users. Generally, state of the art works fall in twoways to revoke access privileges. The first is for a dataowner/administrator to download, re-encrypt, and upload thepolicy/file data to the cloud provider (e.g. [12]). The secondis to delegate the cloud provider to directly re-encrypt thepolicy/file data (e.g. [23]). In both cases, if a malicious cloudprovider does not properly update the previous policy/file dataand retains a copy of it before the re-encryption, then therevoked users can continuously access the files. As policy/filedata is fully managed by the cloud provider, how to resist suchcollusion attack without the honest-but-curious assumption isstill an open problem.

C. Security goals

We aim to provide confidentiality and access control for thecloud-hosted file data.

Confidentiality: our system stores encrypted data on thecloud, but never reveals the decryption keys to the cloud. Thisprotects the confidentiality of the file data.

Read access control: our system uses cryptography toenforce access control so that users can only read file dataaccording to their access permissions.

Write access control: for writing permission enforcement,our system relies on the cloud provider to validate writeprivileges of users prior to file updates.

D. Role based access control

We design and analyze Crypt-DAC based on the role-based access control model named (RBAC0) [13], which iswidely used in practical applications. RBAC0 model describespermission management through the use of abstraction: rolesdescribe the access permissions associated with a particular(class of) job function, users are assigned to the set of rolesentailed by their job responsibilities, and a user is grantedaccess to an object if they are assigned to a role that ispermitted to access that object. More formally, the state ofan RBAC0 model can be described as follows:

– U: a set of users– R: a set of roles– P: a set of permissions (e.g., (file, op))– PA ⊆ R × P: a permission assignment relation– UR ⊆ U × R: a user assignment relation

– auth(u, p) = ∃ r: [(u, r) ∈ UR] ∧ [(r, p) ∈ PA]: theauthorization predicate auth: U × P → B determines whetheruser u has permission p

E. Cryptographic tools

Symmetric/Asymmetric cryptography: Our constructionmakes use of symmetric-key encryption scheme (GenSym,EncSym, DecSym), public-key encryption scheme (GenPub,EncPub, DecPub) and digital signature scheme (GenSig, Sign,Ver).

Key rotation scheme: Key rotation [15] is a scheme(GenRo, B-Dri, F-Dri) in which a sequence of keys can beproduced from an initial key and a secret key. Only the ownerof the secret key can derive the next key in the sequence, butany user knowing a key in the sequence can derive all previousversions of the key. We next describe the algorithms of thisscheme:

GenRo(1n) → (rsk, rpk): On input a security parameter1n, this algorithm outputs a secret-public key pair (rsk, rpk).

B-Dri(ki, rsk) → (ki+1): On input a key ki in a keysequence (ki)ti=1 and a secret key rsk, this algorithm outputsthe next key ki+1 in the sequence.

F-Dri(ki, rpk) → ((kj)i−1j=1): On input a key ki in a keysequence (ki)ti=1 and a public key rpk, this algorithm outputsall previous versions of the key (kj)i−1j=1 in the sequence.

III. DESIGN PRINCIPLE

In this section, we begin with a basic construction ofcryptographic access control enforcement, from which wederive a variety of issues for access revocation that must beaddressed. We then give an overview of our system, Crypt-DAC, which addresses these issues.

A. Basic construction

In a cryptographically enforced RBAC0 system, a user uis associated with a user read key (eku, dku) ← GenPub(1n)and a user write key (sku, vku) ← GenSig(1n). A role r isassociated with a role key (ekr, dkr) ← GenPub(1n). A file isassociated with a file key k ← GenSym(1n).

Access enforcement: For each user u, the administratordistributes a certificate for the user write key of u througha user (U) tuple:

〈U, (u, vku), δSU 〉

This tuple contains a user name u, a verification key vku, anda signature of the administrator δSU signed over (u, vku). Foreach (u, r) ∈ UR in the RBAC0 state (i.e., there exists a useru that is a member of r), the administrator distributes the rolekey of r to u through a role key (RK) tuple:

〈RK, u, r, EncPubeku(dkr)〉

This tuple provides u with cryptographically-enforced accessto the decryption key dkr of r. For each (r, (f, op)) ∈ PA inthe RBAC0 state (i.e., there exists a role r with permission tof ), the administrator distributes the file key of f to r througha file key (FK) tuple:

〈FK, r, (fn, op), EncPubekr(k)〉

This tuple provides r with cryptographically-enforced accessto the file key k for f. For each file f, the administratordistributes f through a file (F) tuple:

〈F, fn, EncSymk (f )〉

This tuple contains a file name fn of f and a ciphertext of f.File access: If a user u with authorization to read a file f

(i.e., ∃r: (u, r) ∈ UR ∧ (r, f, Read) ∈ PA) wishes to do so, udownloads an RK tuple for the role r to decrypt the decryptionkey dkr by dku. u also downloads an FK tuple for the file f todecrypt the file key k by dkr. Finally, u downloads a F tupleto decrypt the file f by k.

If a user u with authorization to write to a file f viamembership in role r (i.e., ∃r: (u, r) ∈ UR ∧ (r, f, RW) ∈ PA)wishes to do so, u uploads a F tuple encrypting the new filecontent f ’ as well as a signature δu over the F tuple signed bythe user write key of u. On the other hand, the cloud providerchecks (1) if there is an RK tuple assigning u as a memberof r and an FK tuple assigning r with permission RW to f ;and (2) if there is a U tuple containing vku that verifies δu asa valid signature over the F tuple. If both checks passed, thecloud provider executes the writing operation.

Access revocation: The administrator may need to revokea permission of a role, or revoke a membership of a user. Weonly describe the user revocation case as the role revocationcase is analogous. Removing a user u∗ from a role r entails:(1) re-encrypting a new role key of r stored in RK tuples, (2)re-encrypting new file keys stored in FK tuples accessible byr, and (3) re-encrypting files stored in F tuples by the new filekeys. All these steps must be carried out by an administratoras only the administrator can modify the access authorization.

In the first step, a new role key of r is generated. This keyis then encrypted into a new RK tuple for each remainingmember u of r to replace the old RK tuple. This step preventsu∗ from accessing the new role key of r. In the second step, anew file key is generated for each file f accessible by r. Thiskey is then encrypted into a new FK tuple for each role r’(including r) that has access to f, and the new FK tuple isuploaded to replace the old FK tuple. This step prevents u∗

from accessing the new file keys. In the third step, each file towhich r has access is re-encrypted into a new F tuple by thenew file key. The new F tuple is then uploaded to replace theold F tuple. This step prevents u∗ from accessing the files byusing cached old file keys. An illustrative example is shownin Figure 2.

We emphasize that it is important to re-encrypt the filesby the new file keys as u∗ may cache the old file keys ofthese files and try to access them after the revocation. Forexample, suppose u∗ is assigned to three roles and can access200 files. u∗ can first access all of these files to cache theirfile keys when he join the system. Later, u∗ is revoked fromone of its three roles and cannot access some of the 200 filesanymore. However, u∗ can still use the cached file keys toaccess these files if they are not re-encrypted by new file keys

u RK tuple

RK tuple

fFK tuple

F tuple

r FK tuple

r

u*

Fig. 2. An illustrative example of removing a user u∗ from a role r. The blackarrows present the access relationships among users, roles and files before therevocation, and the red rectangles include the RK, FK, and F tuples that needto be re-generated in the revocation. In the first step, a new role key of r isgenerated. This key is then encrypted into a new RK tuple for u, which is aremaining member of r. In the second step, a new file key is generated for f,which is accessible by r. This key is then encrypted into two new FK tuplesfor r’ and r respectively that both have access to f. In the third step, f isre-encrypted into a new F tuple by the new file key.

in the revocation.

B. Design issues for revocation

The revocation in this basic construction is not suitable forrealistic dynamic access control scenario due to its prohibitiveoverhead in file data re-encryption. Due to the multi-to-one property of access permission relations among users,roles, and files in RBAC0 model, the administrator needs todownload, decrypt, re-encrypt, and upload a large number ofF tuples, incurring potentially high bandwidth consumptions.For example, suppose the administrator needs to revoke themembership of u∗ from r and r has permission to 100 files.Then, the administrator needs to re-encrypt all of the 100 filesin the revocation.

Previous designs: In response, Garrison et al. [12] pro-posed two revocation schemes. The first scheme requires theadministrator to re-encrypt file data by itself in a revocation.This scheme completes the revocation immediately with apotentially high communication overhead. Differently, thesecond scheme relies on next users writing to the F tuplesto re-encrypt the F tuples. This scheme, however, comes withsecurity penalty as it delays the revocation to the next writing,creating a vulnerability window in which revoked users cancontinuously access the F tuples which they have accessedpreviously and cached the file keys.

To alleviate the overhead of file data re-encryption, Wanget al. [23] proposed another revocation scheme, in which thesymmetric homomorphic encryption scheme [24] is used toencrypt the file data. Instead by re-encrypting the file data byitself, the scheme enables the administrator to delegate thecloud to update F tuples from old file keys to new file keyswithout decryption. The problem, however, is that the cost ofhomomorphic symmetric encryption is comparable with publickey encryption schemes, incurring prohibitive computationoverhead during file reading/writing.

C. Our design

To overcome these limitations, Crypt-DAC develops newtechniques using lightweight symmetric encryption scheme.

F F F F

1st revocation 2nd revocation 3th revocation

k0 k1 k2 k3

Fig. 3. An illustrative example of encryption evolution of a F tuple. The Ftuple is encrypted by a symmetric key list (k0, k1, k2, k3) which records afile key k0 and a sequence of revocation keys k1, k2, k3. In the ith revocation(i ∈ (1, 2, 3)), the administrator uploads a new revocation key ki to the cloud,which encrypts the file with a new layer of encryption.

In Crypt-DAC, a F tuple (file) is encrypted by a symmetrickey list (k0, k1,..., kt) which records a file key k0 and asequence of revocation keys k1,..., kt. Crypt-DAC uses theinnermost encryption layer to protect the file against the cloudprovider and the outermost encryption layer to protect the fileagainst revoked users. In the ith revocation, the administratoruploads a new revocation key ki to the cloud, which encryptsthe file with a new layer of encryption. After this procedure,the revoked user cannot access the file as he cannot access ki.An illustrative example is shown in Figure 3.

Compared with previous designs, Crypt-DAC achieves effi-cient revocation, immediate revocation, and efficient file accesssimultaneously. For revocation efficiency, Crypt-DAC incurslightweight communication overhead at the administrator sideas it does not need to download and re-upload file data but onlyneeds to upload keys to the cloud. For immediate revocation,the permissions of users are immediately revoked as the filesare re-encrypted. For file access efficiency, the files are stillencrypted by symmetric keys. To further avoid users to decryptmultiple encryption layers in file access operations, Crypt-DAC proposes three key techniques to constrain the size ofkey list and encryption layers for files as follows.

1) Delegation-aware encryption: Delegation-aware encryp-tion enables the administrator to delegate the cloud providerto update RK and FK tuples instead of creating and uploadingnew RK and FK tuples by itself. To constrain the size of thekey lists, delegation-aware encryption adopts the key rotationtechnique [15] to compactly encrypt each key list in oneencryption in a FK tuple. As a result, the administrator onlyneeds to upload one encryption for the cloud to update a keylist. This design also improves file access efficiency as usersonly need to download and decrypt compact FK tuples toaccess files.

To revoke a user u∗ from a role r, Crypt-DAC uses thedelegation-aware encryption strategy to update the involvedRK and FK tuples as shown in Figure 4. The administratorgenerates a new role key (ek∗r , dk∗r ) of r. The administratorfirst delegates the cloud provider to update RK tuples. Supposethere are n users remaining in r. For each of these users u, theadministrator delegates the cloud provider to update the RKtuple of u. To do so, the administrator uploads an encryptionof EncPubeku

(dk∗r ). With this encryption, the cloud updates the

Cloud

dkr eku

Cloud

For each of the n users u:

RKu, r

dkr eku

RKu, r

dkr eku

For each of the m files fn:

FKr , ( fn, op )

FK

(k0, kt, rpk , t) ekr

1

2

*

ekr

r , ( fn, op )

*

fn (k0, kt+1, rpk , t+1)fn

ekr(k0, kt+1, rpk , t+1)fn

For each of the n roles r :

message transfer

message update

updated part

message transfer

message update

updated part

Fig. 4. To revoke a user u∗ from a role r, the delegation-aware encryptionstrategy updates the involved RK and FK tuples in two steps. The administra-tor first delegates the cloud provider to update RK tuples. Suppose there aren users remaining in r. For each of the n users u, the administrator uploadsan encryption of a new role key to the cloud provider for it to update theRK tuple of u. The administrator next delegates the cloud provider to updateFK tuples. Assume that there are m files to which r has permissions, and nroles with permissions to each of the m files. For each of the m×n roles r’,the administrator uploads an encryption of a new revocation key to the cloudprovider for it to update the FK tuple of r’.

RK tuple as:

〈RK, u, r, EncPubeku(dk∗r )〉

The updated RK tuple encrypts the new role key of r.The administrator next delegates the cloud provider to

update FK tuples. An FK tuple contains an encryption of asymmetric key list (k0, k1,..., kt) for a file fn. With the keyrotation scheme, the administrator can use a key rotation keypair (rskfn , rpkfn ) to generate the revocation key sequence,and compactly represent this key list as (k0, kt). Given (k0,kt), the next revocation key kt+1 can be derived by kt+1 ←B-Dri(kt, rskfn ) and the whole revocation key sequence k1,...,kt can be recovered by ki−1 ← F-Dri(ki, rpkfn ) (2≤i≤t). Asa result, the complete format of an FK tuple is:

〈FK, r, (fn, op), c〉

c = EncPubekr(k0, kt, rpkfn , t)

Assume that there are m files to which r has permissions. Forsimplicity, we assume that there are n roles with permissions toeach of the m files. For each of the m files fn, the administratorgenerates a new revocation key kt+1 ← B-Dri(kt, rskfn ). Foreach of the n roles r’ with permissions to fn, the administratoruses the role key of it to encrypt (k0, kt+1, rpkfn , t + 1)and uploads the encryption to the cloud. Upon receiving theencryptions, the cloud provider updates the key lists in the FKtuples of the n roles as:

〈FK, r’, (fn, op), c〉

If r’ = r: c = EncPubek∗r(k0, kt+1, rpkfn , t+ 1)

If r’ 6= r: c = EncPubekr′(k0, kt+1, rpkfn , t+ 1)

Cloud

kt||kt+1

F fn

F

c EncSym(DecSym(c))fn

= EncSym((EncSym(f))c k0kt

kt+1

Cloud

kt+1

F fn

F

c EncSym(c)fn

For each of the m files fn:

= EncSym(...EncSym(EncSym(f))...)c k0k1kt

kt+1Security mode

Efficiency mode

kt

For each of the m files fn:

Fig. 5. To complete the revocation of the user u∗ from the role r, the ad-justable onion encryption strategy provides a security mode and an efficiencymode to update the involved F tuples. In the security mode, the encryptionlayers of an F tuple increase as the revocations increase. For each of the mfiles fn to which r has permissions, the administrator uploads a revocationkey to the cloud provider for it to directly encrypt the F tuple of fn. In theefficiency mode, the encryption layers of an F tuple are constant regardlessof the revocations. For each of the m files fn to which r has permissions, theadministrator uploads two revocation keys to the cloud provider for it to firstdecrypt and then encrypt the F tuple of fn.

After the updating, the new FK tuples compactly encrypt thenew symmetric key list (k0, k1,..., kt+1).

2) Adjustable onion encryption: Adjustable onion encryp-tion enables the administrator to delegate the cloud providerto update F tuples. The administrator only needs to uploada new revocation key to the cloud provider. Upon receivingthe key, the cloud provider uses it to encrypt the files witha new layer of encryption and then deletes it. To constrainthe size of the encryption layers, adjustable onion encryptionprovides two modes: security mode and efficiency mode. Sucha design enables the administrator to define a tolerable boundfor a file. Initially, the strategy works in the security mode andthe encryption layers increase as revocations happen. Once thesize of the encryption layers reaches the bound, it turns to theefficiency mode to constrain the encryption layers by puttingmore trust on the cloud. As a result, the administrator canflexibly adjust a tolerable bound for each file according tofile type, access pattern, etc., to achieve a balance betweenefficiency and security.

To complete the revocation of the user u∗ from the roler, Crypt-DAC uses the adjustable onion encryption strategy toupdate the involved F tuples as shown in Figure 5. The strategyprovides two modes: security mode and efficiency mode to doso as follows.

Security mode: In this mode, a file fn is encrypted in a Ftuple by a symmetric key list (k0, k1,..., kt) as follows:

〈F, fn, c〉

c = EncSymkt (...EncSymk1 (EncSymk0 (f )))

When a user u accesses fn, u decrypts (k0, kt, rpkfn , t) fromone of these FK tuples, recovers the revocation key sequence:

Cloud

F fn

F

c EncSym (f')fn

For the F tuple of fn:

1

F

EncSym (f')fn

k'0

k'0

Cloud

For each of the m roles r:

FKr, (fn, op)

FK

c EncPub (k'0)n

EncPub (k'0)

2

r, (fn, op)ekr

ekr

user u

administrator

Fig. 6. The delayed de-onion encryption strategy periodically refreshes thesymmetric key list of files and removes the encryption layers of F tuplesthrough file writing operations. With the strategy, a user u writes to a file fnin two steps. u first updates the F tuple of fn. To do so, u generates a F tupleto encrypt fn with a new key list containing a single key, and uploads theF tuple to the cloud provider for it to replace the current F tuple of fn. unext delegates the administrator to update the key list of fn. Assuming thatthere are m roles having permissions to fn. For each of the m roles r, theadministrator uploads an encryption of the new key list for the cloud providerto update the FK tuple of r.

ki−1←F-Dri(ki, rpkfn ) (2≤i≤t), and uses (k0, k1,..., kt) todecrypt the F tuple.

To complete the revocation, for each of the m files fnto which r has permissions, the administrator derives a newrevocation key kt+1 ← B-Dri(kt, rskfn ) and uploads kt+1

to the cloud provider. Upon receiving it, the cloud providerupdates the F tuples of the m files as:

〈F, fn, EncSymkt+1 (c)〉

Efficiency mode: In this mode, a file fn in a F tuple isencrypted by a symmetric key list (k0, k1,..., kt) as follows:

〈F, fn, c〉

c = EncSymkt (EncSymk0 (f ))

When a user u accesses fn, u decrypts (k0, kt, rpkfn , t) fromone of these FK tuples and uses (k0, kt) to decrypt the Ftuple.

To complete the revocation, for each of the m files fnto which r has permissions, the administrator derives a newrevocation key kt+1← B-Dri(kt, rskfn ) and uploads (kt, kt+1)to the cloud provider. Upon receiving it, the cloud providerupdates the F tuples of the m files as:

〈F, fn, EncSymkt+1 (DecSymkt (c))〉

Comparing with the security mode, the efficiency mode en-crypts an F tuple with two layers instead of t layers, enablingmore efficient file access. The security tradeoff, however, isthat the efficiency mode puts more trust on the cloud asit requires the cloud to correctly execute more operations

(first decrypt and then encrypt) to update F tuples in eachrevocation.

Adjustable bound: The combination of the above twomodes enables the administrator to define a bound T oftolerable encryption layers for a file. T means that when a fileis encrypted by less than T encryption layers, the file accessefficiency is tolerable. In this case, the administrator prefers tominimize the trust on the cloud and uses the security mode inrevocations. Once the file is encrypted by T encryption layers,the administrator prefers file access efficiency and turns to usethe efficiency mode in revocations by putting more trust on thecloud.

Considering a sequence of revocations happened in the lifecycle of an F tuple. In the ith revocation, if i ≤ T, theadministrator uses the security mode to update the F tuple. Toaccess the F tuple in this case, a user recovers a symmetrickey list (k0, k1,..., ki) from an FK tuple to decrypt the F tuple.Otherwise, the administrator turns to use the efficiency modeto update the F tuple. To access the F tuple in this case, auser recovers a symmetric key list (k0, k1,..., kT−1, ki) froman FK tuple to decrypt the F tuple.

3) Delayed de-onion encryption: During the life cycle of afile, its encryption layers continuously increase until a pre-defined bound is reached. To further improve file accessefficiency, Crypt-DAC periodically refreshes the symmetrickey list of the file and removes the bounded encryption layers.A direct solution is for the administrator to periodically re-encrypts the F tuple with a new key list which only containsa new file key. This solution however, incurs large commu-nication and computation overhead at the administrator side.Instead, Crypt-DAC proposes delayed de-onion encryptionstrategy to do so through writing operations. In specific, auser writing to an F tuple encrypts the writing content by anew symmetric key list, and updates the symmetric key listaccordingly. In this way, Crypt-DAC amortizes the updatingburden to a large number of writing users.

The work flow of the delayed de-onion encryption strategyis shown in Figure 6. Suppose a user u wants to write toa file fn. To do so, u first updates the F tuple of fn. ugenerates a new file key k′0 ← GenSym(1n) and creates aF tuple encrypting the writing content f ’ by a new symmetrickey list (k′0):

〈F, fn, EncSymk′0 (f ’)〉

u uploads the F tuple to the cloud provider for it to replacethe existing F tuple.

u next updates the key list of fn. To alleviate the overhead,u delegates the administrator to do so. Assume that there arem roles having permissions to fn. u uploads the new key list(k′0) to the administrator and delegates it to update the keylist in the FK tuples of the m roles. For each of the m rolesr, the administrator encrypts k′0 by the encryption key ekr ofr, and uploads the encryption for the cloud provider to updatethe FK tuple of r as:

〈FK, r, (fn, op), EncPubekr(k′0)〉

After the writing operation, the symmetric key list is refreshedand the multiple encryption layers over the F tuple is removed.

IV. DESIGN DETAILS

In Crypt-DAC, users add files to the cloud provider bycreating F tuples. The administrator assigns file permissionsto roles by distributing file keys using FK tuples, and assignsusers to roles by distributing role keys to users using RKtuples. We next describe the various operations in Crypt-DAC.There are three types of operations in Crypt-DAC: permissionrevocation, permission assignment, and file operation. Ourdesign uses the following notation: u is a user, r is a role, p is apermission, fn is a file name of a file f, c is a ciphertext (eithersymmetric or public encryption), and v is a version number.SU is the superuser identity owned by the administrator. Weuse – to represent a wildcard.

A. File management

We use three types of files to store metadata for filemanagement. We introduce them as follows.

USERS: We use a file named USERS to store records forall the users. A record (u, eku) contains a user identity u andthe encryption key eku of u.

ROLES: We use a file named ROLES to store records forall the roles, which is publicly viewable and can only bechanged by the administrator. A record (r, ekvr ) contains arole identity r and the encryption key ekvr of r.

FILES: We use a file named FILES to store records for allthe files, which is publicly viewable and can only be changedby the cloud provider. A record (fn) contains the file namefn of a file.

B. Key management

In our system, the administrator, roles and users are associ-ated with cryptographic keys. We introduce them as follows.

Administrator keys: The administrator plays a role ofsuper user in the system. It has an encryption key pair (ekSU ,dkSU ) of a public key encryption scheme and a signaturekey pair (skSU , vkSU ) of a digital signature scheme. Theencryption key pair is used by the administrator to create aspecial RK tuple when adding a new role into the system.The RK tuple means that the administrator is a super userwho can access the keys of the role. With this RK tuple, theadministrator can assign a user to the role by distributing therole keys using another RK tuple. The encryption key pairis also used by a user to create a special FK tuple whenadding a new file into the system. The FK tuple means that theadministrator is a super user who can access the symmetrickey list of the file. With this FK tuple, the administrator canassign a permission to a role by distributing the symmetric keylist using another FK tuple. On the other hand, the signaturekey pair is used to assign U tuples to users.

User keys: A user read key of u is an encryption key pair(eku, dku) of a public key encryption scheme. This key isused to encrypt/decrypt RK tuples for u. A user write key of u

Algorithm 1 revokeUser(u)1: For each role r that u is assigned to:2: REVOKEU(u, r);3: Req C.P. to delete 〈U, (u, vku), δSU 〉;4:5: procedure REVOKEU(u, r)6: DAE-RK(r);7: DAE-FK(r);8: For each fn with 〈FK, r, (fn, op), c〉:9: ONION-ENCRYPTION(fn);

10:11: procedure DAE-RK(r)12: Generate a new role key (ekr , dkr) for r;13: For each 〈RK, u’, r, c〉 with u’ 6= u:14: Admin:15: Send EncPub

eku′

(dkr) to C.P.;16: C.P.:17: Update 〈RK, u’, r, c〉 as 〈RK, u’, r, EncPub

eku′

(dkr)〉;18:19: procedure DAE-FK(r)20: For each fn with 〈FK, r, (fn, op), c〉:21: Admin:22: Generate a new revocation key kt+1 ← D-Dri(kt, rskfn );23: For each role r’ with permission to fn:24: Compute c′ = EncPub

ekr′

(k0, kt+1, rpkfn , t+ 1);25: Send c′ to C.P.;26: C.P.:27: For each role r’ with permission to fn:28: Update 〈FK, r’, (fn, op), c〉 as 〈FK, r’, (fn, op), c’〉;29:30: procedure ONION-ENC(fn)31: Admin:32: Compute k̂t+1 ← hash(kt+1, t+1);33: Send (k̂t+1/k̂t+1, k̂t) to C.P.;34: C.P.: 〈F, fn, c〉:35: Compute c ← EncSym

k̂t+1 (c)/c ← EncSym

k̂t+1 (DecSym

k̂t (c));

is a digital signature key pair (eku, dku) of a digital signaturescheme. This key is used to sign/verify F tuples written by u.

Role keys: A role key of r is an encryption key pair (ekr,dkr) of a public key encryption scheme. This key pair is usedto encrypt/decrypt FK tuples for r.

File keys: A file key of fn is a symmetric key list (k0, k1,...kt) of a symmetric key encryption scheme and a rotation keypair (rskfn , rpkfn ) of a key rotation scheme. (k0, k1,... kt) isused by users to encrypt the F tuple of fn, and (rskfn , rpkfn )is used by the administrator to compactly store (k0, k1,... kt)in the FK tuple of fn.

C. Operations

Permission revocation: Permission revocation includes re-voking the permission of a user revokeUser(u) (as describedin Algorithm 1) and revoking the permission of a rolerevokeRole(r) (as described in Algorithm 2).

The administrator uses revokeUser(u) to revoke the permis-sion of a user u from all of its assigned roles. The algorithminvokes DAE-RK(r) and DAE-FK(r), which implements thedelegation-aware encryption strategy, to update the involvedRK and FK tuples respectively. The algorithm also invokesONION-ENC(fn), which implements the adjustable onionencryption strategy, to update the involved F tuples. Also, theadministrator can directly use REVOKEU(u, r) to revoke themembership of u from a certain role r.

The administrator uses revokeRole(r) to revoke the per-mission of a role r from all of its assigned files. The al-gorithm invokes VDAE-FK(r), which partly implements the

Algorithm 2 revokeRole(r)1: Remove (r, ekr) from ROLES;2: For each permission p = 〈fn, op〉 that r has access to:3: REVOKEP(r, 〈fn, Read〉);4:5: procedure REVOKEP(r, 〈fn, RW〉)6: Admin:7: Send 〈FK, r, (fn, Read), c〉 to C.P.;8: C.P.:9: Update 〈FK, r, (fn, RW), c〉 as 〈FK, r, (fn, Read), c〉;

10:11: procedure REVOKEP(r, 〈fn, Read〉)12: Req C.P. to delete all 〈RK, –, r, – 〉;13: Req C.P. to delete 〈FK, r, (fn, –), –〉;14: VDAE-FK(fn);15: ONION-ENCRYPTION(fn);16:17: procedure VDAE-FK(fn)18: Admin:19: Generate a new revocation key kt+1 ← D-Dri(kt, rskfn );20: For each role r’ 6= r with permission to fn:21: Compute c′ = EncPub

ek′r(k0, kt+1, rpkfn , t+ 1);

22: Send c′ to C.P.;23: C.P.:24: For each role r’ 6= r with permission to fn:25: Update 〈FK, r’, (fn, op), c〉 as 〈FK, r’, (fn, op), c’〉;

delegation-aware encryption strategy, to update the involvedFK tuples. The algorithm also invokes ONION-ENC(fn) toupdate the involved F tuples. revokeRole(r) can be slightlymodified to revoke the permission of r from a single file fn.There are two cases. First, the administrator can directly useREVOKEP(r, 〈fn, RW〉) to revoke a permission of r from 〈fn,RW〉 to 〈fn, Read〉. Second, the administrator can directly useREVOKEP(r, 〈fn, Read〉) to totally revoke a permission 〈fn,op〉 of r.

Permission assignment: Permission assignment includesadding a new user addUser(u), adding a new role addRole(r),assigning a user to a role assignU(u, r), and assigning a roleto a file with Read/RW permission assignP(r, 〈fn, op〉). Due tothe space constraint, we omit the algorithm details of theseoperations. A user u uses addUser(u) to join the system. Theadministrator uses addRole(r) to add a new role r into thesystem, uses assignU(u, r) to assign a user u with a role r,and uses assignP(r, 〈fn, op〉) to assign a role to a file withRead/RW permission.

File operation: File operation includes file creationaddFile(fn, f, u), file read read(fn, u) (as described in Algorithm3), and file write write(fn, u) (as described in Algorithm 4). Auser u uses addFile(fn, f, u) to create a new file fn in the systemand uses read(fn, u) to read a file fn from the cloud provider.Also, a user u uses write(fn, u) to write to a file fn storedin the cloud provider. This algorithm invokes DELAYED DE-ONION(〈RK, u, r, c〉), which implements the delayed de-onionencryption strategy, to refresh the symmetric key list of fn.We noticed that in some cases, u does not need to execute thedelayed de-onion encryption strategy as no revocation happenssubject to fn.

D. Data integrity

Many works [16]–[19] have been done to ensure dataintegrity in untrusted cloud. Lighten by these works, we showhow to extend Crypt-DAC to ensure data integrity when a

Algorithm 3 read(fn, u)1: User u:2: Send (u, r, fn) to C.P.;3: C.P.:4: If there exists an RK tuple 〈RK, u, r, c〉 ∧5: a FK tuple 〈FK, r, (fn, op), c’〉 ∧6: a F tuple 〈F, fn, c”〉:7: Then8: Return the RK tuple, FK tuple, and F tuple to u;9: Else

10: Return ⊥ to u;11: User u:12: Compute dkr ← DecPub

dku(c);

13: Compute (k0, kt, rpkfn , t) ← DecPubdkr

(c’);14: For i = t & i > 1 & i−−:15: Compute ki−1 ← F-Drirpkfn

(ki);16: Compute k̂t = hash(kt, t);17: Compute c” ← DecSym

k̂t(c”);

18: For i = T & i ≥ 0 & i−−:19: Compute k̂i = hash(ki, i);20: Compute c” ← DecSym

k̂i(c”);

21: Output c”;

Algorithm 4 write(fn, u)1: User u:2: Send (fn, write request) to C.P.;3: C.P.:4: Include all the FK tuples containing fn into FK-set;5: Return 〈RK, u, r, c〉 to u;6: User u:7: DELAYED DE-ONION(〈RK, u, r, c〉);8:9: procedure DELAYED DE-ONION(〈RK, u, r, c〉)

10: User u:11: Compute k′0 ← GenSym();12: Compute c’ ← EncSym

k′0(f ’);

13: Compute δu ← Signsku (F, fn, c’);14: Send 〈F, fn, c’, δu〉 to C.P.;15: Send (k′0, fn) to Admin;16: Admin:17: For each role r’ with permission to fn:18: Compute c” ← EncPub

pkr(k′0, rpkfn , 0);

19: Insert c” into C-set;20: Send C-set to C.P.;21: C.P.:22: If there exists a U tuple 〈U, (u, vku), δSU 〉|valid← Vervku (F, fn, c’) ∧23: an RK tuple 〈RK, u, r, c〉 ∧ a FK tuple 〈FK, r, (fn, RW), c’〉:24: Then Write 〈F, fn, c’〉;25: For each 〈FK, r’, (fn, RW), c’〉 ∈ FK-set and a proper c” ∈ C-set:26: Update 〈FK, r’, (fn, RW), c’〉 to 〈FK, r’, (fn, RW), c”〉;27: Else28: Return ⊥ to u;

stronger threat model is needed. The two schemes in [12]can achieve data integrity by using signature scheme to signRK, FK, and F tuples. As these tuples are updated at theadministrator/user side, the administrator/user can generatenew signatures over the updated tuples before uploading to thecloud provider. On the other hand, Crypt-DAC and the schemein [23] cannot to do so by directly using signature scheme. Asthe administrator delegates the cloud provider to update RK,FK, and F tuples, the cloud provider cannot generate newsignatures over the updated tuples since it does not have thesigning key.

Instead, we propose to use sanitizable signature scheme[39] to ensure data integrity. Sanitizable signature scheme isa special signature scheme in which a signer can delegate aproxy to modify a certain portion of a signed message withoutinvalidating the attached signature. For RK and FK tuples, theadministrator uses sanitizable signature scheme to sign them

and delegates the cloud provider to modify the encryptionportion of them. In this way, the cloud provider can directlyupdate the RK and FK tuples without invalidating the attachedsignatures. Differently for F tuples, the administrator usesgeneral signature scheme to sign them. The reason is thatin a revocation, the administrator only delegates the cloudprovider to update the encryption portion of F tuples byadding a new encryption layer over it. This operation does notchange the encrypted file contents, and thus does not invalidatethe attached signatures. As a result, we do not need to usesanitizable signature scheme to sign F tuples.

With our extension, a malicious cloud provider cannotarbitrarily modify RK, FK, and F tuples or generate faketuples. Also, maliciously modifying the encryption portion ofRK and FK tuples can be easily detected by users.

V. SECURITY ANALYSIS

We analyze the security of Crypt-DAC using the access con-trol expressiveness framework known as application-sensitiveaccess control evaluation (ACE) [36]. ACE is a formalizedmathematical framework to evaluate how well a candidateaccess control scheme implement an idealized access controlscheme. We show that Crypt-DAC is correct and secureunder ACE. In specific, we prove that Crypt-DAC satisfiesthree properties defined in ACE: correctness, safety and AC-preservation.

At a high level, correctness and safety ensures that an exe-cution environment cannot determine whether it is interactingwith the idealized RBAC0 scheme or with Crypt-DAC throughinputs, outputs and intermediate states. The two propertiesensure that Crypt-DAC is correct. AC-preservation ensures thata permission in the idealized RBAC0 scheme is authorizedif and only if its mapping in Crypt-DAC is authorized. Thisproperty ensures that Crypt-DAC is secure. We summarize ourresult in theorem 1.

Theorem 1: Crypt-DAC implements RBAC0 with correct-ness, AC-preservation, and safety.

In our proof, we first formalize Crypt-DAC under theACE framework. We then provide a formal mapping fromCrypt-DAC to RBAC0. We show that this mapping achievescorrectness, AC-preservation, and safety. The full proof ofTheorem 1 can be found in Appendix.

As Crypt-DAC inherits the design of [12], our proof isalso similar with the proof of [12]. The difference is ourformalization of the query auth(u, p), which asks whethera user u has a permission p=(fn, op). We formalize auth(u,(fn, Read)) in a candidate access control system as whetheru can decrypt the F tuple 〈F, fn, c〉. This formalizationincludes the fact that in a revocation, if the involved F tuplesare not timely re-keyed and re-encrypted, the revoked userscan still access the files encrypted in the F tuples. With thisformalization, the second scheme in [12] has to use revokeUserand write to implement a revocation operation in RBAC0

to achieve correctness. This implementation, however, breakssafety. In specific, to execute a revocation operation in RBAC0,the scheme sequentially executes revokeUser and write. The

dom

ino

heal

thca

re

univ

ersi

ty

0

20

40

60

80

File

rek

eys

per

user

rev

ocat

ion

emea

firew

all1

firew

all2

0

50

100

150

200

250

Dataset

(a) File re-encryptions for a user re-vocation

dom

ino

emea

firew

all1

0.0

0.2

0.4

0.6

0.8

1.0

Encr

ypti

ons

for

each

file

firew

all2

heal

thca

re

univ

ersi

ty

0246810121416

Dataset

(b) The average number of re-encryptions for each file

Fig. 7. Summary of simulation results.

execution of revokeUser generates an intermediate state, inwhich a query auth(u, (fn, Read)) is TRUE for a revokeduser u and a file fn involved in the revocation. This query,however, is FALSE in the end state of RBAC0 generated bythe execution of revocation.

VI. SYSTEM EVALUATION

To simplify the presentation, we term the two revocationschemes proposed in [12] as immediate re-encryption (IMre)and deferred re-encryption (DEre), respectively. We also termthe revocation scheme proposed in [23] as homomorphic re-encryption (HOre). We implement IMre, DEre, HOre, andCrypt-DAC. In our implementation, we deploy the adminis-trator on a PC which is equipped with a 4-core Intel Xeon2.0 GHz processor and 16 GB RAM in our lab, and thecloud provider on AliCloud. We compare the performance ofthe four systems in access revocation and file reading/writing.We implement the cryptographic schemes based on Crypto++[37]. We select the AES scheme and the El Gamal scheme toinstantiate the symmetric and public key encryption schemesrespectively. Both the schemes are set with a security parame-ter of 80 bits. To evaluate the performance of the four systemsin a realistic access control scenario, we derive several criticalaccess control parameters through a simulation of data accesscontrol. We use the same simulation framework [38] over thesame real-world RBAC data sets as in [12] to generate traces ofaccess control actions, and extract the parameters from thesetraces.

A. Access trace simulation

The simulation framework proposed in [38] describes arange of realistic access control scenarios and allows us toinvestigate various access control actions and cryptographicoperations incurred by these actions. We initialize the sim-ulation from start states extracted from real-world data setsenforced by role based access controls. We then generate tracesof access control actions using actor-specific continuous-timeMarkov chains. From these traces, we can record the numberof instances of each cryptographic operation executed, includ-ing counts or averages. We simulate one-month periods inwhich the administrator of the system behaves.

We show our simulation results in Figure 7. In Fig 7(a),we show the number of files that need to be re-encrypted for

a single user revocation. In many scenarios, a user revocationtriggers the re-encryptions of tens or hundreds of files, such asin emea or firewall2. From this result, we extract the followingaccess control parameter: to revoke a user, the total numberof involved F tuples that need to be re-encrypted in averagefalls in [0, 200].

Fig 7(b) shows the upper bound a file needs to be re-encrypted within a month for the purpose of user revocation.In Crypt-DAC, this bounds the increased number of encryptionlayers of a file within a month. From this result, we extractthe following access control parameter: for file data, theencryption layers of each file in average increases less than3 within a month.

B. End to end experiments

Crypt-DAC only uses lightweight symmetric encryptions toencrypt file data and develops three new strategies to constrainthe size of key list and encryption layers for files.

For access revocation, Crypt-DAC uses delegation-awareencryption strategy to delegate the cloud provider to updateRK/FK tuples. As key lists are compactly stored in FK tuples,the administrator costs the same overhead to update RK/FKtuples as previous works. Crypt-DAC also uses adjustableonion encryption strategy to delegate the cloud to update Ftuples. As the administrator only sends symmetric keys forthe cloud provider to encrypt files, it costs far less overheadto update F tuples than previous works.

For file read/write, Crypt-DAC constrains encryption layersover files to improve the efficiency of file read/write op-erations. In specific, Crypt-DAC uses the adjustable onionencryption strategy to constrain the encryption layers in re-vocation operations and delayed re-onion encryption strategyto remove them periodically. The combination of the twostrategies ensure that the encryption layer of each file isunder an upper bound all the time. More interestingly, theadministrator can adjust this upper bound to suit specificapplication requirements by combining the two strategies ina flexible way.

We show such a way as follows. Suppose each file needsto be re-encrypted at most l times within every fixed-sizedperiod for the purpose of user revocation (3 times withinevery month in our trace simulation). By combining the twostrategies, the administrator can adjust an upper bound l×kof encryption layers over files. Given the delayed re-onionencryption strategy, the administrator sets a parameter α suchthat α fraction of files will be written at least once within everyk periods. For these files, the administrator uses the securitymode of the adjustable onion encryption strategy to updatethem in revocation operations. For the remainder 1-α files,the administrator uses the security mode to update them andturn to the efficiency mode once their encryption layers reach l× k in revocation operations. In this way, the encryption layerof each file is bounded by l×k all the time. As α and k hasa positive relationship, the administrator can adjust the upperbound l×k by adjusting the parameter α.

40 80 120 160 20010M 22.63 45.27 67.95 90.58 113.2450M 114.41 228.82 343.16 457.56 571.96100M 225.91 451.83 677.75 903.71 1129.54

22.63 45.27 67.95 90.58 113.24114.41228.82

343.16457.56

571.96

225.91

451.83

677.75

903.71

1129.54

0

200

400

600

800

1000

1200

40 80 120 160 200

minutes

10M 50M 100MNumber of F tuples

(a) Performance of IMre at administrator side

Crypt-DAC HOre40 11.241 11.58980 19.97 22.885120 28.949 33.886160 37.955 41.194200 50.382 54.782

11.241

19.97

28.949

37.955

50.382

11.589

22.885

33.886

41.194

54.782

0

10

20

30

40

50

60

40 80 120 160 200

seconds

Crypt-DAC HOreNumber of F tuples

(b) Performance of Crypt-DAC and HOre at admin-istrator side

Crypt-DAC DEre40 11.241 10.812580 19.97 20.2259120 28.949 33.1383160 37.955 40.2002200 50.382 51.0166

10.8125

20.2259

33.1383

40.2002

51.0166

0

10

20

30

40

50

60

40 80 120 160 200

seconds

DEreNumber of F tuples

(c) Performance of DEre at cloud side

Fig. 8. Performance in revocation.Crypt-DAC HOre10M 0.158157 83.600549

50M 0.803027 417.481759

100M 1.603901 834.407035

0100200300400500600700800900

10M 50M 100M

Crypt-DAC HOre

secondsseconds

Size of file

Fig. 9. Computation overhead of Crypt-DAC and HOre at cloud side inrevocation.

Revocation: We evaluate the performance of IMre, HOre,Crypt-DAC and DEre in revoking a user u from a role r. Thisexperiment is affected by two parameters: file size and numberof F tuples that need to be re-encrypted. We consider threesizes of a file: 10 M, 50 M and 100 M. We use the accesscontrol parameter that the number of F tuples that need to bere-encrypted falls in [0, 200] and show the experiment resultsin Figure 8.

In Figure 8(a-c), we observe that the time cost of IMreat the administrator side is prohibitive and increases fast asthe file size and the number of F tuples increases. Whenprocessing 200 F tuples with 100 M file size, IMre takes about1129 minutes. On the other hand, HOre and Crypt-DAC costsabout 50 seconds under the same parameters, achieving 1356times improvement. Also, we observe that the time cost ofHOre and Crypt-DAC is not affected by the file size. Thereason is that the administrator only needs to generate andsend cryptographic keys for F tuples regardless of their filesize. Finally, the performance of DEre is similar with HOreand Crypt-DAC and is not affected by the file size. The reasonis that DEre delayed the re-encryption of the F tuples to thenext users writing to them.

Additionally, in Figure 9, we observe that the time cost ofHOre at the cloud side is prohibitive and increases with the filesize. The reason is that the cloud needs to homomorphicallyre-encrypt each F tuple, while in Crypt-DAC, the cloud onlyneeds to AES-encrypt each F tuple. The time cost of HOre is520 times higher than Crypt-DAC for a cloud to process a file

0

20

40

60

80

100

120

140

160

180

10M 50M 100M 10M 50M 100M 10M 50M 100M

IMre/DEre Add cost of Crypt-DACseconds

k = 1 k = 3 k = 5

(a) Performance of IMre/DEre andCrypt-DAC at user side

10M 50M 100M1 0.486133 0.526553 0.5087832 1.901134 1.986156 1.9582143 3.352962 3.438913 3.4175954 4.734337 4.894237 4.8800295 6.141955 6.343719 6.3200956 7.558279 7.817389 7.7726697 8.979105 9.230058 9.302468 10.39846 10.69646 10.768459 11.82906 12.19558 12.24614

10 13.21864 13.5738 13.7203611 14.63024 15.01652 15.197812 16.06277 16.49044 16.63393

02468

1012141618

1 2 3 4 5 6 7 8 9 10 11 12

10M 50M 100Mpercentage

Encryption layer k

(b) Performance of Crypt-DAC andHOre at user side

Fig. 10. Performance in file reading

regardless of the file size.File reading/writing: We evaluate the performance of IMre,

DEre, HOre, and Crypt-DAC in file reading/writing. The totalexecution time (including both computation and communica-tion time) is affected by file size. We vary the file size from10 M, 50 M to 100 M. For Crypt-DAC, it is also affected bythe number of encryption layers of files. We set l = 3 and varyk (from 1 to 12) to evaluate the performance trend of Crypt-DAC in a long time (one year). We evaluate Crypt-DAC inthe worst case by encrypting files with the upper bound l×kof encryption layers.

Figure 10 compares the execution time of IMre/DEre andCrypt-DAC in reading operations. Figure 10(a) shows theadditional cost of Crypt-DAC comparing with IMre/DEre. Wecan see that the additional cost is moderate (7.2% when k =5). The reason is that Crypt-DAC uses AES scheme multipletimes to encrypt/decrypt files. Figure 10(b) shows the relationof the additional cost with the parameter k. We can see thatthe additional cost increases slowly as k increases regardlessof file size (1.4% each time k increases 1). The reason isthat AES is a lightweight cryptographic primitive. Moreover,the administrator can adjust the upper bound l×k to controlthis additional cost. Considering the performance advantageof Crypt-DAC in revocation, we believe that this extra cost isacceptable. Table II compares the execution time of HOre andCrypt-DAC in reading operations. We see that HOre takes 80computation times higher than Crypt-DAC (k = 5) and 6.7 total(computation and communication) times higher than Crypt-

TABLE IPERFORMANCE OF CRYPT-DAC/HORE IN FILE READING

File sizeCrypt-DAC HOre Cost of HOre

Comp/Comm Comp/Comm Comp/Total10 M 1.1/15.8 Sec 98.6/17.7 Sec 82.8/6.8 times

50 M 6.1/81.8 Sec 491.1/90.4 Sec 80.2/6.6 times

100 M 12.3/164.1 Sec 982.3/176.8 Sec 79.8/6.5 times

TABLE IIPERFORMANCE IN FILE WRITING

File sizeOthers HOre Cost of HOre

Comp/Comm Comp/Comm Comp/Total10 M 1.1/16.8 Sec 98.6/17 Sec 88.3/6.4 times

50 M 6.1/84.9 Sec 490.4/89.1 Sec 79.5/6.3 times

100 M 12.3/168 Sec 981.7/175.1 Sec 79.8/6.4 times

DAC (k = 5). The reason is that HOre uses homomorphicsymmetric encryption to encrypt files, and the overhead ofwhich is comparable with public key encryption schemes.Instead, Crypt-DAC uses symmetric key encryption schemeto do so.

Table III compares the execution time of writing operations.We see that IMre, DEre and Crypt-DAC takes same time.The reason is that all the three schemes use symmetric keyencryption scheme to encrypt files and the delayed de-onionencryption adopted in Crypt-DAC incurs no additional cost atuser side. Besides, HOre takes 82 computation times higherthan Crypt-DAC and 6.3 total (computation and communica-tion) times higher than Crypt-DAC in average. The reason isthat HOre uses homomorphic symmetric encryption to encryptfiles, and the overhead of which is comparable with public keyencryption schemes. Instead, Crypt-DAC uses symmetric keyencryption scheme to do so.

VII. RELATED WORK

Current cryptographically enforced access control schemescan be classified as follows.

Hierarchy access control: Gudes et al. [27] explore cryp-tography to enforce hierarchy access control without con-sidering dynamic policy scenarios. Akl et al. [28] proposea key assignment scheme to simplify key management inhierarchical access control policy. Also, this work does notconsider policy update issues. Later, Atallah et al. [29] proposea method that allows policy updates, but in the case ofrevocation, all descendants of the affected node in the accesshierarchy must be updated, which involves high computationand communication overhead.

Role based access control: Ibraimi et al. [30] crypto-graphically support role based access control structure usingmediated public encryption. However, their revocation oper-ation relies on additional trusted infrastructure and an activeentity to re-encrypt all affected files under the new policy.Similarly, Nali et al. [31] enforce role based access control

structure using public-key cryptography, but requires a seriesof active security mediators. Ferrara et al. [32] define a securemodel to formally prove the security of a cryptographically-enforced RBAC system. They further show that an ABE-basedconstruction is secure under such model. However, their workfocuses on theoretical analysis.

Attribute based access control: Pirretti et al. [33] proposean optimized ABE-based access control for distributed filesystems and social networks, but their construction does notexplicitly address the dynamic revocation. Sieve [23] is aattribute based access control system that allows users toselectively expose their private data to third web services.Sieve uses ABE to enforce attribute based access policiesand homomorphic symmetric encryption [24] to encrypt data.With homomorphic symmetric encryption, a data owner candelegate revocation tasks to the cloud assured that the privacyof the data is preserved. This work however incurs prohibitivecomputation overhead since it adopts the homomorphic sym-metric encryption to encrypt files.

Access matrix: GORAM [25] allows a data owner toenforce an access matrix for a list of authorized users andprovides strong data privacy in two folds. First, user accesspatterns are hidden from the cloud by using ORAM techniques[26]. Second, policy attributes are hidden from the cloud by us-ing attribute-hiding predicate encryption [21], [22]. The cryp-tographic algorithms, however, incur additional performanceoverhead in data communication, encryption and decryption.Also, GORAM does not support dynamic policy update. Over-encryption [34], [35] is a cryptographical method to enforce anaccess matrix on outsourced data. Over-encryption uses doubleencryption to enforce the whole access matrix. As a result,the administrator has to rely on the cloud to run complexalgorithms over the matrix to update access policy, assuminga high level of trust on the cloud.

VIII. CONCLUSION

We presented Crypt-DAC, a system that provides practicalcryptographic enforcement of dynamic access control in thepotentially untrusted cloud provider. Crypt-DAC meets itsgoals using three techniques. In particular, we propose to dele-gate the cloud to update the policy data in a privacy-preservingmanner using a delegation-aware encryption strategy. Wepropose to avoid the expensive re-encryptions of file data at theadministrator side using a adjustable onion encryption strategy.In addition, we propose a delayed de-onion encryption strategyto avoid the file reading overhead. The theoretical analysisand the performance evaluation show that Crypt-DAC achievesorders of magnitude higher efficiency in access revocationswhile ensuring the same security properties under the honest-but-curious threat model compared with previous schemes.

IX. ACKNOWLEDGEMENT

We acknowledge the support from National Natural Sci-ence Foundation of China (No 61602363, No. 61702437,No 61572382), China Postdoctoral Science Foundation(No 2016M590927), Hong Kong ECS under Grant PolyU

252053/15E, Key Project of Natural Science Basic ResearchPlan in Shaanxi Province of China (No. 2016JZ021), The StateKey Laboratory of Cryptology, PO Box 5159, Beijing 100878,China, Doctoral Fund of Ministry of Education of China (No.20130203110004), China 111 Project (No. B16037), and theFundamental Research Funds for the Central Universities (NoXJS16001, No JB161509).

REFERENCES

[1] J. Bethencourt, A. Sahai, and B. Waters, Ciphertext-policy attributebased encryption, in IEEE S&P, 2007.

[2] X. Wang, Y. Qi, and Z. Wang, Design and Implementation of SecPod:A Framework for Virtualization-based Security Systems, IEEE Transac-tions on Dependable and Secure Computing, vol. 16, no. 1, 2019.

[3] J. Ren, Y. Qi, Y. Dai, X. Wang, and Y. Shi, AppSec: A Safe ExecutionEnvironment for Security Sensitive Applications, in ACM VEE, 2015.

[4] V. Goyal, A. Jain, O. Pandey, and A. Sahai, Bounded ciphertext policyattribute based encryption, in ICALP, 2008.

[5] V. Goyal, O. Pandey, A. Sahai, and B. Waters, Attribute-based encryptionfor fine-grained access control of encrypted data, in ACM CCS, 2006.

[6] J. Katz, A. Sahai, and B. Waters, Predicate encryption supporting dis-junctions, polynomial equations, and inner products, in EUROCRYPT,2008.

[7] S. Muller and S. Katzenbeisser, Hiding the policy in cryptographicaccess control, in STM, 2011.

[8] R. Ostrovsky, A. Sahai, and B. Waters, Attribute-based encryption withnon-monotonic access structures, in ACM CCS, 2007.

[9] A. Sahai, and B. Waters, Fuzzy identity-based encryption, in EURO-CRYPT, 2005.

[10] T. Ring, Cloud computing hit by celebgate, http://www.scmagazineuk.com/cloud-computing-hit-by-celebgate/article/370815/, 2015.

[11] X. Jin, R. Krishnan, and R. S. Sandhu, A unified attribute-based accesscontrol model covering DAC, MAC and RBAC, in DDBSec, 2012.

[12] W. C. Garrison III, A. Shull, S. Myers, and, A. J. Lee, On the Practicalityof Cryptographically Enforcing Dynamic Access Control Policies in theCloud, in IEEE S&P, 2016.

[13] R. S. Sandhu, Rationale for the RBAC96 family of access control models,in proceedings of ACM Workshop on RBAC, 1995.

[14] T. Jiang, X. Chen, Q. Wu, J. Ma, W. Susilo, and W. Lou, Secureand Efficient Cloud Data Deduplication With Randomized Tag, IEEETrasactions on Information Forensics and Security, vol. 12, no. 3, 2017.

[15] M. Kallahalla, E. Riedel, R. Swaminathan, Q. Wang, K. Fu, Plutus:Scalable Secure File Sharing on Untrusted Storage, in proceedings ofUSENIX FAST, 2003.

[16] J. Wang, X. Chen, X. Huang, I. You, and Y. Xiang, Verifiable Auditingfor Outsourced Database in Cloud Computing, IEEE Transactions onComputers, vol. 64, no. 11, 2015.

[17] J. Wang, X. Chen, J. Li, J. Zhao, and J. Shen, Towards achieving flexibleand verifiable search for outsourced database in cloud computing,Future Generation Computer Systems, vol. 67, 2017.

[18] X. Chen, J. Li, X. Huang, J. Ma, and W. Lou, New Publicly VerifiableDatabases with Efficient Updates, IEEE Transactions on Dependableand Secure Computing, vol. 12, no. 5, 2015.

[19] T. Jiang, X. Chen, and J. Ma, Public Integrity Auditing for SharedDynamic Cloud Data with Group User Revocation, IEEE Transactionson Computers, vol. 65, no. 8, 2016.

[20] D. Boneh and M. Franklin, Identity-based encryption from the Weilpairing, SIAM Journal on Computing, vol. 32, no. 3, 2003.

[21] J. Katz, A. Sahai, and B. Waters, Predicate encryption supporting dis-junctions, polynomial equations, and inner products, in EUROCRYPT,2008.

[22] E. Shen, E. Shi, and B. Waters, Predicate privacy in encryption systems,in TCC, 2009.

[23] F. Wang, J. Mickens, N. Zeldovich, and V. Vaikuntanathan, Sieve:Cryptographically Enforced Access Control for User Data in UntrustedClouds, in NSDI, 2016.

[24] D. Boneh, K. Lewi, H. Montgomery, and A. Raghu Raghunathan, Keyhomomorphic PRFs and their applications, in CRYPTO, 2013.

[25] M. Maffei, G. Malavolta, M. Reinert, and D. Schroder, Privacy andaccess control for outsourced personal records, in IEEE S&P, 2015.

[26] J. R. Lorch, B. Parno, J. W. Mickens, M. Raykova, and J. Schiffman,Shroud: ensuring private access to large-scale data in the data center,in FAST, 2013.

[27] E. Gudes, The Design of a Cryptography Based Secure File System,IEEE Transactions on Software Engineering, vol. 6, no. 5, 1980.

[28] S. G. Akl and P. D. Taylor, Cryptographic solution to a problem ofaccess control in a hierarchy, IEEE TOCS, vol. 1, no. 3, 1983.

[29] M. J. Atallah, M. Blanton, N. Fazio, and K. B. Frikken, Dynamic andefficient key management for access hierarchies, ACM TISSEC, vol. 12,no. 3, 2009.

[30] L. Ibraimi, Cryptographically enforced distributed data access control,Ph.D. dissertation, University of Twente, 2011.

[31] D. Nali, C. M. Adams, and A. Miri, Using mediated identity-basedcryptography to support role-based access control, in ISC 2004, 2004.

[32] A. L. Ferrara, G. Fuchsbauer, and B. Warinschi, Cryptographicallyenforced RBAC, in CSF, 2013.

[33] M. Pirretti, P. Traynor, P. McDaniel, and B. Waters, Secure attribute-based systems, in ACM CCS, 2006.

[34] S. De Capitani di Vimercati, S. Foresti, S. Jajodia, S. Paraboschi, andP. Samarati, Over-encryption: Management of access control evolutionon outsourced data, in VLDB, 2007.

[35] S. De Capitani di Vimercati, S. Foresti, S. Jajodia, S. Paraboschi, and P.Samarati, Encryption policies for regulating access to outsourced data,TODS, vol. 35, no. 2, 2010.

[36] T. L. Hinrichs, D. Martinoia, W. C. Garrison III, A. J. Lee, A.Panebianco, and L. Zuck, Application-sensitive access control evaluationusing parameterized expressiveness, in CSF, 2013.

[37] https://www.cryptopp.com/[38] W. C. Garrison III, A. J. Lee, and T. L. Hinrichs, An actor-based,

application-aware access control evaluation framework, in SACMAT,2014.

[39] G. Ateniese, D. H. Chou, B. Medeiros, and G. Tsudik, SanitizableSignatures, in proceedings of ESORICS, 2005.

APPENDIX AFORMALIZATION OF CRYPT-DAC

To prove theorem 1, we need to represent Crypt-DAC as aformal access control system. We use m as the symmetric-key size. For signatures, we assume that hash-and-sign isused, where the message is hashed with a collision-resistanthash function and then digitally signed. We give the formaldefinitions of the three security properties as follows.

Definition 1 Correctness: Consider a workload W, a candi-date access control system Y, and an implementation (α, σ,π). Correctness states that the implementation is correct if (1)σ preserves π: for every workload state x we have Th(x) =π(Th(σ(x))) and (2) α congruence-preserves σ, which meansthe following: For all n ∈ N, states x0, and labels l1, ..., ln,let y0 = σ(x0), xi = Next(xi-1, li) for i = 1, ..., n, and yi =terminal(yi-1, α(yi-1, li)) for i = 1, ..., n. Then α congruence-preserves σ means that yi

∼= σ(xi) for all i = 1, ..., n.Definition 2 AC-preservation: An implementation with

query-mapping π is called AC-preserving if for all workloadstates s and authorization requests r we have s ` auth(r) iffπauth(r)(Th(σ(s))) = true.

Definition 3 Safety: An implementation is safe if the fol-lowing holds for all i whenever the execution of a workloadlabel yields the access control state sequence (s0, ..., sn).

Auth(si) – Auth(s0) ⊆ Auth(sn) – Auth(s0) (Grant)Auth(s0) – Auth(si) ⊆ Auth(s0) – Auth(sn) (Revoke)Definition 1 access control system: As defined in [40], a

formal access control system includes following components:1) S: a set of states2) R: a set of access control requests

3) Q: a set of queries including auth(r) for every r ∈ R4) `: a subset of S × Q (the entailment relation)5) L: a set of labels6) Next: States(M ) × L → States(M ) (the transition func-

tion)We represent Crypt-DAC as a formal access control system

as follows.1) S: (USERS, ROLES, FILES, FS)

• USERS: a list of (u, enku, siku) records containinguser names and their encryption and signing key pairs

• ROLES: a list of (r, vr, enkr, vr , sikr, vr ) recordscontaining role names, version numbers, and theirencryption and signing key pairs

• FILES: a list of (fn, vfn ) records containing filenames and version numbers

• FS: the set of RK, FK, and F tuples stored on thecloud provider

2) R: (u, p)• (u, p) for whether user u has permission p

3) Q: (RK, FK, Role, auth)• RK(u, r) returns whether a user is a member of a

role:∃(c, sign) (〈RK, u, (r, vr), c, sign〉 ∈ FS ∧ Accept =

VerifyvkSU((〈RK, u, (r, vr), c〉), sign)

• FK(r, (fn, op)) returns whether a role has a permis-sion for the latest version of a file.∃(c, sign) (〈FK, (r, vr) (fn, vfn , op), c, SU, sign〉 ∈F ∧ sign = SignskSU

(〈FK, (r, vr), (fn, vfn , op), c,SU〉)

• Role(r) returns whether a role exists in the system:∃(v, k1, k2) (r, v, k1, k2) ∈ ROLES

• auth(u, p) returns whether a user has a permission:∃r (RK(u, r) ∧ FK(r, p))

4) `: the entailment relation is implicitly defined in thedesign of Crypt-DAC

5) L: all of the operations (revokeUser, revokeRole, addUser,addRole, assignU, assignP, addFile, read, write) in Crypt-DAC

6) Next: the transition function is implicitly defined in thedesign of Crypt-DAC

Definition 2 Correctness: Consider a workload W, a candi-date access control system Y, and an implementation (α, σ,π). Correctness states that the implementation is correct if (1)σ preserves π: for every workload state x we have Th(x) =π(Th(σ(x))) and (2) α congruence-preserves σ, which meansthe following: For all n ∈ N, states x0, and labels l1, ..., ln,let y0 = σ(x0), xi = Next(xi-1, li) for i = 1, ..., n, and yi =terminal(yi-1, α(yi-1, li)) for i = 1, ..., n. Then α congruence-preserves σ means that yi

∼= σ(xi) for all i = 1, ..., n.Definition 3 AC-preservation: An implementation with

query-mapping π is called AC-preserving if for all workloadstates s and authorization requests r we have s ` auth(r) iffπauth(r)(Th(σ(s))) = true.

Definition 4 Safety: An implementation is safe if the fol-lowing holds for all i whenever the execution of a workloadlabel yields the access control state sequence (s0, ..., sn).

Auth(si) – Auth(s0) ⊆ Auth(sn) – Auth(s0) (Grant)Auth(s0) – Auth(si) ⊆ Auth(s0) – Auth(sn) (Revoke)

APPENDIX BIMPLEMENTATION OF RBAC0 BY CRYPT-DAC

We show that Crypt-DAC implements RBAC0 with cor-rectness, AC-preserving, and safety achieved.

Definition 5 implementation: For RBAC0 and a candidateaccess control system Y, an implementation has fields (α, σ,π):• State-mapping σ: States(RBAC0) → States(Y)• Label mapping α: States(Y) × Labels(RBAC0) → Label-

s(RBAC0)∗

• Query mapping π: for each q ∈ Queries(RBAC0), afunction πq that maps each theory for Y to either trueor false

We first show a implementation of RBAC0 by Crypt-DAC:1) State mapping α:

For each u ∈ U ∪ {SU}• Generate enku ← GenPub and siku ← GenSign.• Add (u, eku, vku) to USERS

Let FS = {}Let ROLES and FILES be blank. For each R(r) ∈ M:• Generate enkr,1 ← GenPub and sikr,1 ← GenSign.• Add (r, 1, ekr,1, vkr,1) to ROLES.• Update FS = FS ∪ {〈RK, SU, (r, 1), EncPubekSU

(dkr,1,skr,1), signSU 〉}.

For each P(fn, u) ∈ M:• Add (fn, 1) to FILES• Generate k ← GenSym

• Update FS = FS ∪ {〈F, fn, EncSymk (f ), signu〉}• Update FS = FS ∪ {〈FK, (SU, 1), (fn, 1, RW),EncPubekSU

(k), signu 〉}For each UR(u, r) ∈ M:• Find 〈FK, (SU, 1), (r, 1, RW), c, sign〉 ∈ FS• Update FS = FS ∪ {〈RK, u, (r, 1), EncPubeku

(dkr,1,skr,1), signSU 〉}.

For each PA(r, (fn, op)) ∈ M:• Find 〈FK, (SU, 1), (fn, 1, RW), EncPubekSU

(k), signSU 〉∈ FS

• Update FS = FS ∪ {〈FK, (r, 1), (fn, 1, RW),EncPubekr,1

(k), signSU 〉}Output (FS, ROLES, FILES)

2) Label mapping σ: The label mapping α simply maps anyRBAC0 label, regardless of the state, to the Crypt-DAClabel.

3) Query mapping π:

πUR(u,r)(T) = true if RK(u, r) ∈ TπPA(r,p)(T) = true if FK(r, p) ∈ TπR(r)(T) = true if Role(r) ∈ T

πauth(u,p)(T) = true if auth(u, p) ∈ Tfor each theory T of Crypt-DAC.

In crypt-DAC, the encryptions, signatures and version num-bers in RK/FK/F tuples are different after a revocation. As aresult, assigning and then revoking a user will not result inthe same state as if the user was never assigned. However,all the authorization requests will not be changed. Thesedifferences, however, make crypt-DAC unable to achieve theoriginal definition of correctness. For example, l1 assigns auser to a role and then l2 revokes that user from the role, x2will be equal to x0. Accordingly, σ(x2) should be equal toσ(x0). However, y2 will have different encryptions, signaturesand version numbers from y0.

We follow the way of [11] and prove a variant of correctnessnamed congruence correctness. We consider states, which areequal except for differences in encryptions, signatures andversion numbers, to be congruent, and represent this withthe ∼= relation. We define that state mappings σ’ and σ arecongruent if σ’(x) ∼= σ(x) for all states x. Thus we will showthat yi ∼= σ(xi) for all i = 1,..., n, which we define as αcongruence preserves σ.

We first prove that Crypt-DAC implements RBAC0 withcongruence-correctness achieved:

1) σ preserves π: To prove this, we show that for eachRBAC0 state x and query q, x ` q if and only ifπq(Th(σ(x))) = TRUE. As the proof is similar with thatof [11], we just omit the details here.

2) α congruence-preserves σ: To prove this, we show thatfor each RBAC0 state x and label l, and state mappingsσ’ congruent to σ, we have:

σ′(next(x, l)) ∼= terminal(σ′(x), α(σ′(x), l))

We consider each RBAC0 label l separately. As the proofis similar with that of [11] except revokeU and revokeR,we just show the two labels here.• revokeU: If l is an instance of revokeU(u, r), then

x’ = x\UR(u, r). Let (ekr,vr+1, dkr,vr+1) ← GenPub

and (skr,vr+1, vkr,vr+1) ← GenSig. Let T0 = {(u’,sig) | ∃〈RK, u’, (r, vr), cu’, sig〉 ∈ FS} and T1 = {fn| ∃〈FK, (r, vr), (fn, vfn , op), vfn , cr, sig〉 ∈ FS}.For each fn ∈ T1, let Tfn = {(r, sig) | 〈FK, (r, vr),(fn, vfn , op’), cr, sig〉 ∈ FS} and T ′fn = {(r’, sig) |〈FK, (r’, vr′ ), (fn, vfn , op), cr′ , sig〉 ∈ FS}. Then:

σ′(x’) = σ′(x \ UR(u, r))= σ′(next(x, revokeU(u, r))∼= σ′(x)\{FS(〈RK, u’, (r, vr), cu′ ,sig〉) | (u’, sig)∈T0}∪{FS(〈RK, u’,(r, vr + 1), c’u′ , sig〉) | (u’, sig) ∈ T0 ∧ u’6=u}\{FS(〈FK, (r, vr), (fn, vfn , op’), cr,sig〉) | fn ∈ T1 ∧ (r, sig)∈Tfn}∪{FS(〈FK, (r, vr + 1), (fn, vfn+1, op’), c′r, sig〉) |fn ∈ T0 ∧ (r, sig) ∈ Tfn}\{FS(〈FK, (r’, vr′ ), fn, vfn , op’), cr′

, sig〉) | fn ∈ T1 ∧ (r’, sig) ∈ T’fn}∪{FS(〈FK, (r’, vr′ ), (fn, vfn+1, op’), c′r′ , sig〉) | fn∈ T1 ∧ (r’, sig) ∈ T’fn}\ {FS(〈F, fn, cfn , sig〉) | (fn) ∈ T1}∪{FS(〈F, fn, c′fn , sig〉) | (fn) ∈ T1}∪{FILES(fn, vfn+1) | fn ∈ F}\ {FILES(fn, vfn ) | fn ∈ F}∪ ROLES(r, vr+1, ek(r,vr+1), vk(r,vr+1))\ ROLES(r, vr, ek(r,vr), vk(r,vr))=terminal(σ′(x), α′(σ′(x), l))

• revokeP: If l is an instance of revokeP(r, p) with p =〈fn, op〉, then x’ = x\PA(r, p). We consider two cases:

– If op = RW, then let T = {(r, c, sig) | ∃〈FK, (r,vr), (fn, vfn , RW), c, sig〉}. Thenσ′(x’) = σ′(x \ PA(r, p))=σ′(next(x’, revokeP(r, p)))=σ′(x) \ {FS(〈 FK, (r, vr), (fn, vfn , RW ),c, sig〉) | (r, c, sig) ∈ T }∪{FS(〈FK, (r, vr),(fn, vfn , Read),c, sig〉) | (r, c, sig) ∈ T}=terminal(σ′(x), α(σ′(x), l)).

– If op = Read, then let T = {(r, sig) | 〈FK,(r, vr),(fn, vfn , op’), c, sig〉 ∈ FS}, T1 = {(r’, op’) | r’ 6= r∧ ∃〈FK, r’, (fn, vfn , op’), cr’, sig〉 ∈ FS)}, and T2= {(fn) | 〈F, fn , cfn , SU, sig〉 ∈ FS)}. Thenσ′(x’) = σ′(x \ PA(r, p))=σ′(next(x, revokeP(r, p))∼=σ′(x) \ {FS(〈FK, (r, vr), (fn, vfn , op’),c, sig〉) | (r, sig) ∈ T}\ {FS(〈FK, r’, (fn, vfn , op’),cr′ , sig〉) | (r’, op’) ∈ T1}∪{FS(〈FK, r’, (fn, vfn , op’), vfn+1,c′r′ , sig〉) | (r’, op’) ∈ T1}\ {FS(〈F, fn, cfn , sig〉) | (fn) ∈ T2}∪{FS(〈F, fn, c′fn , sig〉) | (fn) ∈ T2}∪ FILES(fn, vfn+1) \ FILES(fn, vfn )=terminal(σ′(x), α(σ′(x), l)).

We then prove that Crypt-DAC implements RBAC0 withAC-preserving achieved. The query mapping π is AC-preserving because it maps auth(u, p) to TRUE for theoryT if and only if T contains auth(u, p).

We finally prove that Crypt-DAC implements RBAC0 withsafety achieved. The label mapping α is safe by inspection–forany RBAC0 state x and label l, the Crypt-DAC label α(σ(x),l) never revokes or grants authorizations except the images ofthose that are revoked or granted by l.