Privacy preserving and delegated access control for cloud applications

TSINGHUA SCIENCE AND TECHNOLOGYISSNl l1007-0214 l l04 /10 l lpp40-54Volume 21, Number 1, February 2016

Privacy Preserving and Delegated Access Control for CloudApplications

Xinfeng Ye�

Abstract: In cloud computing applications, users’ data and applications are hosted by cloud providers. This paper

proposed an access control scheme that uses a combination of discretionary access control and cryptographic

techniques to secure users’ data and applications hosted by cloud providers. Many cloud applications require users

to share their data and applications hosted by cloud providers. To facilitate resource sharing, the proposed scheme

allows cloud users to delegate their access permissions to other users easily. Using the access control policies

that guard the access to resources and the credentials submitted by users, a third party can infer information about

the cloud users. The proposed scheme uses cryptographic techniques to obscure the access control policies and

users’ credentials to ensure the privacy of the cloud users. Data encryption is used to guarantee the confidentiality

of data. Compared with existing schemes, the proposed scheme is more flexible and easy to use. Experiments

showed that the proposed scheme is also efficient.

Key words: cloud computing; access control; security

1 Introduction

In cloud computing, cloud providers host the data andapplications for cloud users. Data encryption has beenused[1, 2] to ensure the confidentiality of the data storedon cloud providers. However, a cloud provider not onlystores users’ data, it also hosts the applications thatits users execute. Thus, using mechanisms to controlthe access to these applications and data is anotherapproach of securing users’ assets hosted by cloudproviders. In this paper, data and applications are calleddigital assets or assets in short.

Fine-grained access control has been used in cloudcomputing[3, 4]. In fine-grained access control schemes,an access control policy is created for each data item.When a data item is accessed, the cloud providers carryout policy enforcement according to the access controlpolicy of the data item. A user can only access a

�Xinfeng Ye is with the Department of Computer Science, TheUniversity of Auckland, Auckland 1142, New Zealand. E-mail: [email protected].�To whom correspondence should be addressed.

Manuscript received: 2015-09-01; accepted: 2015-10-13

data item if the user’s credentials satisfy the data item’saccess policy.

Many cloud applications, e.g., cloudmanufacturing[5], require close collaboration ofthe users. This means that a user’s assets hosted bya cloud provider need to be accessed by other users.For this type of applications, the access control schemeshould allow the delegation of access permission.Access permission delegation means a user, say Alice,delegates her access permission on a data item or anapplication to another user, say Bob. This allows Bob tocarry out operations on the data item or the applicationon behalf of Alice.

Xu et al.[6] and Liu and Zic[7] proposed schemesthat allow access permission delegation. However, bothschemes do not consider delegating access permissionson the data items that are jointly owned by multipleusers. In practice, joint ownership frequently occurs.For example, when two companies jointly develop aproduct, the data concerning the product is jointlyowned. This means that a contractor working on theproduct must be vetted by both companies. Therefore,it is important to develop an access control scheme

www.redpel.com +917620593389


Xinfeng Ye: Privacy Preserving and Delegated Access Control for Cloud Applications 41

that allows the delegation of access permissions inthe presence of joint ownership on data items orapplications.

An issue with many existing access control schemes,e.g., Refs. [8, 9], etc., is that they do not hide the policiesor the credentials that are used in access control. Ye andKhoussainov[10] showed that the access control policiesand users’ credentials can reveal some secrets of thedata’s owners and the holders of the credentials. Usingmeaningless names for the attributes in policies andcredentials does not always solve the problem. This isbecause, with sufficient amount of access control rulesand credentials, it is possible to infer the meaning of theattributes[11].

Much research has been carried out to ensurethe confidentiality of data and the privacy of theiraccess control policies[2, 12–14]. However, none of theseschemes allow access permission delegation; and mostof these schemes are not practical due to usabilitylimitations[15].

This paper proposed an access control scheme forcloud applications. The scheme uses a fine-grainedattribute-based access control approach and allows thedelegation of access permissions to be carried out easilyin the presence of joint ownership of digital assets.The scheme guarantees both the confidentiality of dataand the privacy of the access control policies and thecredentials used for access control. Compared withexisting schemes, the proposed scheme is more flexibleand practical to use.

This paper is organized as below. Section 2 describessome concepts of cryptography. Section 3 shows thedetails of the proposed scheme. Section 4 measuresthe execution time of the scheme. Comparisons withexisting works and conclusions are given in Sections 5and 6, respectively.

2 The Basics of Cryptography

This paper uses the cryptosystem developed in ourearlier work[10] for hiding the contents of the accesscontrol rules and the credentials. The study in Ref. [10]is based on the RSA algorithm[16] and the scheme byRay et al.[17] This section introduces some concepts ofcryptography. The proof of Theorem 1 can be found inRef. [10].

Definition 1 Two integers, a and b, are relativelyprime if their greatest common divisor is 1. That is,gcd.a; b/ D 1.

Definition 2 Euler’s totient function '.N / isdefined as:8̂̂̂̂ˆ̂̂<̂ˆ̂̂̂̂̂:

if N is prime,

'.N / D N � 1I

if N D N1N2 � � �Nk and

8i; j W Œ1::k�:Ni and Nj are relatively prime,

'.N / D '.N1/'.N2/ � � �'.Nk/:

Definition 3 A key K is a pair he;N i, where N isa product of distinct primes and e is relatively prime to'.N /; e is the exponent and N is the base of key K.

Definition 4 The encryption of a message m withkey K D he;N i, denoted as Œm;K�, is defined as�

m; he;N i�D me mod N:

Definition 5 The matching key of key K D he;N i,denoted as K�1, is a pair hd;N i, satisfying ed �

1 mod '.N / where “�” is the congruence modulorelation. K can decrypt the message encrypted usingK�1, and vice versa. That is,h

Œm;K�;K�1iD

hŒm;K�1�; K

iD m:

In the RSA cryptosystem, a pair of matching keys iscalled a public/private key pair.

Definition 6 Two keys K1 D he1; N1i and K2 D

he2; N2i are compatible if e1 D e2 and N1 and N2 arerelatively prime.

Definition 7 If two keys K1 D he;N1i and K2 D

he;N2i are compatible, then the product key, K1 �K2,is defined as he;N1N2i.

Theorem 1 Let Ki D he;Ni i where 1 6 i 6 n becompatible keys. For any messagem such thatm 6 Ni ,h

Œm;K1 �K2 � � � � �Kn�; OK�1iD m;

where OK�1 is the matching key of key OK andOK D Kx1

�Kx2� � � � �Kxp

such that1 6 xi 6 n, 1 6 i 6 p, and xi ¤ xj if i ¤ j .

In Theorem 1, OK is a key that is formed by a subsetof the keys in set K1; K2; � � � ; Kn. Theorem 1 statesthat, if a message is encrypted using a product key thatis formed with all the keys in K1; K2; � � � ; Kn, then thematching key of OK, i.e., OK�1, can be used to decryptthe encrypted message. For example, assume that K1,K2, and K3 are compatible keys, a message encryptedwith product keyK1 �K2 �K3 can be decrypted usingany one of the keys in set:(

K�11 ; K�1

2 ; K�13 ; .K1 �K2/

�1; .K1 �K3/�1;

.K2 �K3/�1; .K1 �K2 �K3/

�1

):



42 Tsinghua Science and Technology, February 2016, 21(1): 40-54

3 The Scheme

3.1 An overview of the scheme

The proposed scheme uses a fine-grained attribute-based access control approach. In fine-grainedattribute-based access control, a set of access controlrules specifies the conditions under which access to adigital asset is granted. The rules are defined in termsof the attributes that a user might possess, e.g., radardesigner, etc.

Cloud providers store their users’ digital assets. Eachasset has an access control list containing rules thatallow users to access the asset based on the attributespossessed by the users. An access control list specifiesthree access modes: read, write, and execute. Eachmode has a set of access control rules. A user mayaccess an asset in a given mode if the user satisfies theaccess control rule for that access mode.

The owner of an asset delegates the access permissionof the asset to other users by setting the access controlrule for each of the access modes of the asset. A userthat satisfies the access control rule of an asset is calleda delegate. For each access mode, the owner alsospecifies whether a delegate can further delegate heraccess permission to other users. If further delegationis allowed, the delegates can delegate their permissionsto other users by specifying their own access controlrules. Thus, a chain of delegation can be formed foreach access mode of the asset. The users high up inthe chain can revoke the delegations to the users lowerdown in the chain. For example, Alice specified accesscontrol rules for read and write operations on her assetrespectively. Alice also indicated that the read operationcan be further delegated while the write operationcannot. Assume that Bob satisfies both Alice’s accesscontrol rules. Bob can delegate his read permission onAlice’s asset by specifying his own access control rulewhile he cannot delegate his write permission on Alice’sasset.

The users that have access permission on an assetare called the authorized users. Each authorized userdefines her own set of attributes, and assigns theattributes to the users that she wants to delegateaccess permission. An authorized user issues credentialcertificate to her delegates. A credential certificatestates the attributes that an authorized user assignedto her delegate. A user can acquire attributes frommultiple authorized users. As a result, the user will beissued multiple credential certificates. An authorized

user stores her delegates’ credential certificates on cloudproviders.

It is assumed that the cloud providers are honestbut curious. They honestly execute the access controlscheme. When a user, say Bob, wants to operate onan asset hosted by a cloud provider, say cp, cp decideswhether the operation can be carried out by checkingBob’s credentials (i.e., attributes) against the accesscontrol rules of the asset for the given operation.

To prevent a third party from inferring informationfrom the access control rules and credentials, accesscontrol rules and credentials should not be stored inclear text. In order to obscure the access control rulesand credentials, the cryptographic system developed inRef. [10] is used. A pair of matching keys is usedto encrypt and decrypt information for the purpose ofaccess control. The access control rules of an asset areconverted to a set of decryption keys called rule keys.The credentials of a user are converted to an encryptionkey called credential key. If and only if the credentialssatisfy the access control rules, the credential key andone of the rule keys form a matching key pair. Thatis, the information encrypted by the credential key canbe decrypted by the rule key. Thus, when a cloudprovider, say cp, checks whether the credentials of auser, say Bob, satisfies the access control rule of adigital asset, say DA, cp uses Bob’s credential key toencrypt a random string. If the encrypted string can bedecrypted correctly using DA’s rule key, it means thatthe credential key (i.e., Bob’s credentials) and the rulekey (i.e., the access control rule of DA) form a matchingkey pair. That is, Bob’s credentials satisfy DA’s accesscontrol rule. Otherwise, it means the two keys do notform a matching key pair. That is, Bob’s credentialsdo not satisfy DA’s access rule. Since the keys aresequences of bytes, even if the cloud provider knowsthe keys, the provider does not understand the contentsof the rule or the credentials. Thus, the privacy of theaccess control rule and the credentials is ensured.

The conversions of the rules and credentials to keysare carried out by authorized users when they createtheir access control rules and assign attributes to theirdelegates. Thus, only the authorized users know (a) themapping between the access control rules of the digitalassets and the rule keys, and (b) the mapping betweenthe users’ credentials and their credential keys.

To ensure the confidentiality of digital assets, dataencryption and program obfuscation can be used.Obfuscation can make applications hard to understand




by human[18]. This paper only investigates usingencryption to secure the data stored on the cloudprovider.

Each user has a pair of public/private keys. Thepublic keys are kept by the cloud provider and theusers hold their private keys. A data owner encrypts adata item using a symmetric-key encryption algorithmbefore the data is stored on the cloud provider. Thesecret key used to encrypt/decrypt the data item isencrypted using the public keys of the users that havepermissions to access the data. The encrypted secretkeys are stored on the cloud providers. If a user satisfiesan access control rule of a data item, the user will begiven the encrypted data item and the encrypted secretkey. The user decrypts the encrypted secret key usingher private key, and obtains the data item by decryptingit using the secret key. Since the data and the secret keysare encrypted, the cloud providers cannot read the dataor the secret keys in clear text. Thus, the confidentialityof the data is ensured.

A user needs to authenticate with the cloud providerbefore accessing an asset. It is assumed that a publickey authentication scheme[19] is used to establish theidentity of each user.

3.2 Access control rules

The access control rule given by an authorized user isrepresented as a logic expression in disjunctive normalform. For example, if a rule states that an asset canonly be read by users who have attributes A and B orattributesA andC , the logic expression representing therule is “.A^B/_ .A^C/”. If the attributes possessedby a user satisfy one of the disjuncts in the expression,the user satisfies the rule.

The attributes used in the access control rules ofan authorized user are defined by the authorized user.There is no need for the authorized users to agree onthe meaning of the attributes defined by them. This isbecause the authorized users do not need to understandeach other’s access control rules. In practice, peoplefrom different industries or disciplines might worktogether on a project. For example, a manufactureand a marketing company might set up a joint ventureto produce and sell a product. The manufacturerand the marketing company are likely to use differentterminologies. For the authorized users, the freedomof using their self-defined attributes in specifying theaccess control rules makes the scheme flexible and easyfor the authorized users to use as they do not need to

adopt attributes that they are not familiar with.

3.3 Joint ownership

An asset might be jointly owned by multiple usersui .1 6 i 6 n/. For example, two companies areworking together to make a product. The informationand the data for the product are owned by bothcompanies.

The co-owners of an asset set their access controlrules for the asset independently. The co-owners mustagree on the number of co-owners’ access control rulesthat a user must satisfy in order to be granted accesspermission of the asset. For example, if Alice, Bob,and Carol jointly own an asset, they might specify thata user must satisfy the rules of at least two co-owners inorder to be granted access permission of the asset. Anm-out-of-n access control rule can be represented as:_�

S2P.[16i6nfri g/�^.jS jDm/

.^

ri2S

ri / (1)

In the formula above, ri is the access control rulegiven by co-owner ui . [16i6nfrig represents the set ofthe rules given by all the co-owners. P.[16i6nfrig/ isthe power set of[16i6nfrig. jS j denotes the cardinalityof set S .

The m-out-of-n access control rule has two specialcases. They are (a) the access control rules of all co-owners must be satisfied (i.e., m D n), and (b) onlyone co-owner’s access control rule needs to be satisfied(i.e., m D 1). For the two special cases, the degenerateforms of the formula are ^n

1ri (i.e., m D n) and _n1ri

(i.e., m D 1), respectively.

3.4 Delegation

The owner of an asset specifies the original accesscontrol rule for various access modes of the asset. Theusers that satisfy the access control rules can carryout the corresponding operations on the asset. Theseusers are the delegates of the owner as well as theauthorized users as they satisfy the owner’s accesscontrol rules. If the owner of the asset allows theaccess permission to be delegated, the authorized userscan delegate their permissions by specifying their ownaccess control rules for the asset. An authorized usercan also specify whether her delegates can delegatetheir access permission.

For example, assume that (a) Alice created a file andspecified that users with attribute A can read the fileand delegate their read permission, (b) A is an attributeissued by Alice, and (c) Bob and Carol both have been




given attribute A by Alice. Thus, Bob and Carol canread the file. Bob might delegate his read permissionby specifying a rule allowing users with attribute B(issued by Bob) to read the file. Similarly, Carol mightdelegate her permission by stating a rule allowing theusers with attribute C (issued by Carol) to read thefile. Apart from specifying their access control rules,Bob and Carol also indicate whether their delegates canfurther delegate their read permission. Assume that Boballows his delegates to delegate their read permissionwhile Carol does not. If Jimmy is given attribute Bby Bob and Susan is assigned attribute C by Carol,Jimmy and Susan will be able to read the file. Jimmycan also delegate his read permission to other users byspecifying his own access control rules. Susan is notable to delegate her read permission to others as Caroldoes not allow her delegates to do so.

In the presence of permission delegation, the accesscontrol rules for each access mode of an asset areorganized as a delegation tree with the asset owner’srule stored at the root of the tree. The children of anode are the rules of the delegates of the node. Therules of the users in the above example are stored inthe tree shown in Fig. 1. The root of the tree storesthe rules given by Alice (i.e., the owner of the file).Bob’s and Carol’s rules are stored as the children ofthe root of the tree since Bob and Carol need to satisfythe rules given by Alice. Bob and Carol delegate theirpermissions to Jimmy and Susan, respectively. Jimmyonly needs to satisfy Bob’s rule. Hence, Jimmy’s rule isstored below Bob’s rule. For the same reason, Susan’srule is stored below Carol’s rule. Jimmy can have childnodes representing Jimmy’s delegates. Susan must be aleaf node as Carol does not allow Susan to delegate herread permission.

For jointly owned assets, the root of the delegationtree stores the combined access control rule of the co-owners, i.e.,

W�S2P.[16i6nfri g/

�^.jS jDm/

.V

ri2S ri /,

where ri is the rule set by co-owner ui as explained inSection 3.3. For example, Fig. 2 shows the delegationtree of an access mode of a file that was jointly created

Alice

Carol

SusanJimmy

Bob

Fig. 1 Delegation tree.

Alice and Ted

CarolBob

Fig. 2 Delegation tree for jointly owned asset.

by Alice and Ted. It is assumed that (a) Alice andTed require a user must satisfy both Alice’s and Ted’spolicy to gain read permission on the file, (b) Alice andTed allow the read permission to be further delegatedby their delegates, and (c) Bob and Carol both satisfyAlice’s and Ted’s policy. In Fig. 2, the root of thetree stores the logical conjunction of the rules given byAlice and Ted since both Alice’s and Ted’s rule must besatisfied.

The cloud provider is responsible for maintainingthe delegation trees. It constructs the logic expressionrepresenting the m-out-of-n access control ruleaccording to the requirements given by the co-ownersof an asset. It only allows a user to create her ownaccess control rules if the parent of the user in thedelegation tree indicates that the user can delegate heraccess permission.

3.5 Distributing public keys

Each user has a pair of public/private keys. The keysare used for authentication, access control, and ensuringthe confidentiality of data items. Since not every user iswilling to obtain a X.509 certificate from a certificateauthority, the proposed scheme relies on a chain of trustto distribute users’ public keys.

When the owner of an asset, say Alice, signs acontract with a cloud provider for hosting her assets,Alice generates a pair of public/private keys. Alicegives her public key to the cloud provider. The cloudprovider uses a public key authentication scheme toestablish the identity of each user. Thus, Alice’s publickey will be used by the cloud provider to authenticateAlice.

When Alice assigns an attribute to another user,say Bob, Bob generates a pair of public/private keysand gives his public key to Alice. Alice passes Bob’spublic key to the cloud provider. As the cloud providerhas Alice’s public key, Alice can be authenticated bythe cloud provider using a public key authenticationmechanism. Thus, the cloud provider is sure that theinformation received from Alice is sent by Alice.Hence, the cloud provider can be certain that the keygiven by Alice does belong to a person that Alice




regards as Bob. Since the cloud provider carries outaccess control on behalf of Alice, as long as Aliceis satisfied that the public key belongs to Bob, itis sufficient for the cloud provider to use the publickey to identify Bob in the public key authenticationmechanism.

If Bob delegates his access permission to anotheruser, say Carol, Carol gives her public key to Bob. Bobpasses Carol’s public key to the cloud server. As thecloud provider has Bob’s public key, it can authenticateBob. Thus, the provider can trust that the key given byBob does belong to a person that Bob regards as Carol.Similarly, Carol can give her delegates’ public keys tothe cloud provider. There is no limit on the depth of theaccess permission delegation. It can be seen that a chainof trust, i.e., “cloud provider!Alice! Bob! Carol”in the above example, is formed while the delegation ofpermission is carried out. Using this chain, the cloudprovider can collect the public keys of all the users.

3.6 Obscuring credentials

When an authorized user, say Alice, delegates heraccess permission to other users, Alice needs to specifyan access control rule in terms of the attributes thatshe defines. Alice assigns the attributes to the users towhom she wants to delegate her permission. Authorizedusers define their own attributes. They do not need tocoordinate with each other in defining their attributes.This makes it easier for the users to use the system.

An authorized user might give multiple attributes toa delegate. The delegates credential should include allthese attributes. An authorized user issues credentialcertificates to her delegates and gives all the credentialcertificates to the cloud provider. Since the certificatesare sent by the delegator to the cloud provider directly,they cannot be tampered by the delegates. Thus, thecloud provider can be assured of their authenticity.

In order to obscure the credentials, for each attributedefined by an authorized user, the authorized usercreates an attribute key that conforms to Definition 3in Section 2. An attribute key is used to represent theattribute possessed by a user. For an authorized user,all the attribute keys generated by the authorized userhave the same exponent, different bases, and the basesare relatively prime to each other. Thus, according toDefinition 6 in Section 2, the attribute keys generatedby one authorized user are compatible with each other.

Algorithm 1 is used by an authorized user to generatean attribute key. In Algorithm 1, since p1 and p2 are

Algorithm 1 Generating attribute keysGenerateKey(e, uprimes)Input: e is the exponent of all the keys;

uprimes is a set containing all theprimes that have already beenused to construct attributekeys by the authorized user

Output: a key that is compatible to all theexisting attribute keys

// find two un-used distinctive primes that// conform to Definition 3

1. find two primes, p1 and p2 such that.p1 ¤ p2/ ^ .p1 … uprimes/^.p2 … uprimes/ ^ .gcd.e; '.p1 � p2// D 1/

// record p1 and p2 as used primes2. uprimes uprimes [ fp1; p2g

// the new key is he; p1 � p2i

3. return he; p1 � p2i

different from all the primes in uprimes, p1 � p2 mustbe relatively prime to the product of any two primes inuprimes. Thus, according to Definition 6, the new keymust be compatible with all the existing keys.

If a user, say Bob, is given a single attributeby an authorized user, say Alice, the attribute keythat corresponds to Bob’s attribute is used as Bob’scredential. If Alice assigns several attributes to Bob,Bob’s credential is represented by the product keythat is formed by the keys corresponding to eachof Bob’s attributes. For example, if (a) Alice hasassigned attributes A1; A2; � � � , and An to Bob, and(b) K1; K2; � � � , and Kn are the corresponding attributekeys of A1; A2; � � � , and An, respectively, Bob’scredential is represented as K1 � K2 � � � � � Kn. Theproduct key is a pair he;N i where N D N1N2 � � �Nn

and Ki D he;Ni i .1 6 i 6 n/.Only Alice knows how to map an attribute defined by

her to its corresponding attribute key. Hence, the keyrepresenting the credential of a user cannot be easilylinked back to any attribute by Bob or any third party,e.g., the cloud provider. That is, only Alice understandsthe meaning of the credentials that she assigns to otherusers. Hence, the meanings of the user’s credentials arekept secret.

3.7 Obscuring access control rules

As described in Section 3.2, the access control rulegiven by a user is represented in a disjunctive normalform, e.g., “.A ^ B/ _ .A ^ C/”. The rule is given tothe cloud provider for enforcing access control on the




user’s asset. In order to make the access control ruleincomprehensible to the cloud provider, each disjunctin a rule is mapped to a key, i.e., a sequence of bytes.

As described in Section 3.6, each attribute is mappedto an attribute key. Using the attribute keys, a productkey corresponding to each disjunct in an access controlrule can be obtained. The product key is generatedusing the keys of the attributes in the disjunct. Forexample, for “.A ^ B/”, A’s and B’s attribute keys(i.e., KA and KB ) are used to generate the productkey KA � KB . Once the product key is obtained,.KA � KB/’s matching key, i.e., .KA � KB/

�1, iscalculated. .KA � KB/

�1 is called a rule key. A rulekey is used to represent the corresponding disjunct in anaccess control rule. Thus, a rule will be converted intoseveral rule keys. For example, rule “.A^B/_.A^C/”is converted into keys .KA�KB/

�1 and .KA�KC /�1.

Algorithm 2 describes how to convert a rule to a setof rule keys. AttributeToKey is a function that mapsan attribute to its corresponding attribute key. Eachauthorized user uses Algorithm 2 to convert her accesscontrol rule to a set of rule keys. The keys are given tothe cloud provider for rule enforcement.

3.8 Rule enforcement

Originally, an access control rule is a logic expressionin disjunctive normal form. According to Section 3.7,each rule is converted to a set of rule keys. Each keycorresponds to the conditions specified in a disjunct ofthe logic expression. Thus, as long as one of the keyscan be used to determine that a user’s credential makesthe corresponding disjunct evaluate to true, the accesscontrol rule is satisfied by the user. If an asset is jointlyowned by several authorized users, the user must satisfythe access control rules of at least m authorized users asdiscussed in Section 3.3.

As explained in Sections 3.5 and 3.6, users’ publickeys and credential certificates are stored on the cloudprovider. A user that wants to carry out operationson an asset hosted by a cloud provider needs to usea public key authentication mechanism to prove hisidentity to the cloud provider. The cloud providercan verify a user’s identity using the public key of theuser. After a user is authenticated, the cloud providercarries out some encryption and decryption operationsusing the user’s credentials (i.e., the credential keyscontained in the user’s certificates) and the rule keys ofthe asset that the user wants to access. The outcomesof these operations determine whether the user satisfies

Algorithm 2 Generating rule keysObscureRule(Rule)Input: Rule is the access control rule for an

access mode of an assetOutput: a set of rule keys// Keys is a set holding the converted rule keys

1. Keys ∅;// an access control rule is in disjunctive// normal form

2. let Rule D t1 _ t2 _ � � � _ tn// find the rule key for each disjunct in the rule

3. for each ti where 1 6 i 6 n in Rule do f// each disjunct is a conjunction of one or// more attributes// AttrKeys is a set that includes the// attribute keys of all the attributes in ti

4. let ti D r1 ^ r2 ^ � � � ^ rm andAttrKeys=fAttributeToKey.rj /j1 6 j 6 mg

// K is a product key that corresponds to ti5. K K1 �K2 � � � � �Km

where Ki 2 AttrKeysand Ki ¤ Kj for i ¤ j

6. let K D he;N i// compute K’s matching key, i.e., the rule// key that corresponds to disjunct ti

7. compute K�1 such thatK�1 D hd;N i

where e � d � 1 mod '.N /8. Keys Keys [ fK�1g

9. g // end of for each10. return Keys

the access control rules of the asset.A rule enforcement example is given below. Assume

that (a) a user, say Bob, has been given attributes A1

and A2 by Alice and attributes T1 and T2 by Ted, (b)Alice and Ted jointly own an asset, (c) “.A1 ^ A3/ _

A2 _ .A3 ^ A4/” and “.T1 ^ T3/ _ .T1 ^ T2/” are theaccess control rules set by Alice and Ted, respectively,(d) Alice and Ted require users to satisfy both theiraccess control rules in order to access the asset, and(e) the key assigned to attributesA1; A2; A3; A4; T1; T2,and T3 are KA1

; KA2; KA3

; KA4; KT1

; KT2, and KT3

,respectively. To access the asset, Bob needs to satisfyboth Alice’s and Ted’s rules. It can be seen that, inorder to satisfy a disjunct in a rule, the attributes thatappear in the disjunct must be a subset of the attributespossessed by Bob. According to the assumption, theset of attributes that Bob has been given by Alice andTed is fA1; A2; T1; T2g. The attributes appearing in




disjunct “.A1^A3/” of Alice’s access control rule formset fA1; A3g which is not a subset of fA1; A2; T1; T2g.As Bob does not have attribute A3, Bob cannot satisfydisjunct “.A1 ^ A3/” in Alice’s rule. According toSection 3.6, the credential given to Bob by Alice is theproduct key KA1

� KA2. From Section 3.7, .KA1

�

KA3/�1; K�1

A2, and .KA3

� KA4/�1 are the rule keys

corresponding to disjunct “.A1 ^ A3/”, “A2”, and“.A3 ^ A4/”, respectively. To check whether Bob’scredential satisfies Alice’s access control rule, the cloudprovider checks whether one of the disjuncts in Alice’saccess control rule can be satisfied by Bob’s credential.First, the cloud provider generates a random stringT and encrypts T using key KA1

� KA2(i.e., Bob’s

credential key given by Alice) to obtain ciphered textCT (i.e., CT D ŒT;KA1

�KA2�). To test whether Bob’s

credential satisfies “.A1 ^ A3/”, the cloud provideruses key .KA1

�KA3/�1 (i.e., the rule key representing

disjunct “.A1 ^ A3/”) to decrypt CT. Since “KA1�

KA2¤ KA1

� KA3”, .KA1

� KA3/�1 is not the

matching key of KA1� KA2

. As a result, .KA1�

KA3/�1 cannot decrypt CT. Since the decryption fails,

it is regarded as Bob does not satisfy the disjunct“.A1 ^ A3/” that is represented by .KA1

� KA3/�1.

Similarly, when examining whether Bob’s credentialsatisfies “A2”, the scheme uses rule key K�1

A2(i.e., the

rule key representing disjunct “A2” in Alice’s accesscontrol rule) to decrypt CT. Let OK D KA2

in Theorem 1in Section 2. Thus, “ OK�1 D K�1

A2” holds. According to

Theorem 1 in Section 2, “hŒT;KA1

�KA2�; K�1

A2

iD T ”

holds. As the decryption is successful, it is regardedthat the credential provided by Bob satisfies the disjunct(i.e., “A2”) that is represented by rule key K�1

A2. In

a disjunctive normal form, if one of the disjuncts issatisfied, the whole logic expression evaluates to true.Thus, if Bob satisfiesA2, Bob satisfies Alice’s rule. Theother disjunct (i.e., “.A3 ^ A4/”) does not need to bechecked. To access the asset, Bob also needs to satisfyTed’s policy. The same method is used when checkingwhether Bob’s credential satisfies Ted’s access controlrule.

Algorithm 3 checks whether a credential key satisfiesthe rule given by an authorized user. checknextdisjunctindicates whether there is a need to check the nextdisjunct in the access control rule expression (line 5). Ifone disjunct in the rule expression is true (i.e., the rulekey can decrypt CT), the rule is satisfied. Thus, thereis no need to check the rest of the disjuncts in the rule

Algorithm 3 Checking credential keyCredSatisfiesRule(key, Rule)

1. Input: Rule is the set of rule keyskey is the credential key of a user

2. Output: whether key satisfies Rule (i.e., trueor false)

3. generate a random string T// encrypt string T with the user’s credential// key key

4. CT ŒT; key�5. checknextdisjunct True

// each rule key in set Rule is used to// decrypt CT

6. for each Okey in Rule do f7. if .T D ŒCT; Okey�/ then8. checknextdisjunct false9. break10. end-if11. end-for-each12. if .checknextdisjunct/ then13. return false14. end-if15. return true

expression (lines 7 to 10).Algorithm 4 defines the rule enforcement process

that a cloud provider follows when it checks whethera user can be granted access permission to an asset.An asset might be jointly owned by several authorizedusers. Argument m specifies the minimum number ofauthorized users’ rules that a user needs to satisfy inorder to be granted access permission. Rules is a set ofrule keys set representing all the rules given by variousauthorized users of an asset. Each element in Rules isthe set of rule keys representing the access control ruleof one authorized user.

numOfSatisfiedRule records the number of accesscontrol rules that are satisfied by the user’s credentialso far (line 1). The cloud provider checks a user’scredential against the access control rule of eachauthorized user (line 2). A user might have severalcredential certificates issued by various authorizedusers. cert.issuer is the ID of the issuer of acertificate. An access control rule given by anauthorized user should be evaluated against thecredential issued by the same authorized user. Forexample, if Bob wants to access an asset whoseaccess control rule is set by Alice, Alice’s rule shouldbe checked against the credential issued to Bob byAlice. Thus, the correct credential certificate needs




Algorithm 4 Enforcing ruleRuleEnforcement(m;Rules;Certificates)Input: m is the minimum number of access

control rules that the user needs tosatisfy

Rules is a set of rule keys setrepresenting the access controlrules of authorized users

Certificates is a set of credentialcertificates of the user whosecredential is being checked

Output: grant or deny// initialise numOfSatisfiedRule

1. numOfSatisfiedRule 0

2. for each rule in Rules do f3. let rule be the access control rule set by

user au4. let cert be a certificate in Certificates

such that cert.issuer D au5. if (cert does not exist) then continue end-if6. extract credential key key from cert7. if CredSatisfiesRule(key; rule) then8. numOfSatisfiedRule

numOfSatisfiedRuleC 19. if numOfSatisfiedRulehm then10. continue11. else12. return grant13. end-if14. end-if15. end-for-each16. return deny

to be identified when an access rule is checked (line4). If the user has not been issued any credentialby the authorized user that created the access controlrule, the user cannot satisfy the rule. As the useris granted access permission as long as the user cansatisfy m of all the access control rules, failing onerule does not mean that the user should be deniedaccess permission. Thus, the next access controlrule is checked (line 5). Otherwise, the credential keyis retrieved from the certificate to check whether itsatisfies the rule (lines 6 and 7). numOfSatisfiedRule isincremented when an access control rule is satisfied(line 8). Once the user has satisfied sufficient numberof access control rules (i.e., numOfSatisfied > m),the user is granted access permission (lines 11 and12). Otherwise, the access control rule of anotherauthorized user is examined (lines 9 and 10). If thenumber of access control rules that are satisfied by the

user cannot reach the required number (i.e.,m) when allthe access control rules have been checked, the accessrequest is declined (line 16).

3.9 Ensuring data confidentiality

Encryption is used to ensure data confidentiality. Theproposed scheme uses an encryption mechanism that issimilar to the approach by Gonzalez-Manzano et al.[20]

The owner of a data item encrypts her data item usinga symmetric-key encryption algorithm, e.g., AES. Eachdata item is encrypted with its own unique secret key.The secret key needs to be given to all the users thathave permission to access the data. For each data item,the authorized user asks the cloud provider to find outall her delegates that satisfy her access control rule forthe data item. For each delegate that satisfies the accesscontrol rule of a data item, the authorized user uses thepublic key of the delegate to encrypt the secret key thatis used to encrypt the data item. The encrypted secretkeys are stored with their corresponding data items onthe cloud provider. When a user accesses a data item, ifthe user satisfies the access control rule of the data item,the cloud provider gives the encrypted data item as wellas its encrypted secret key to the user. The user decryptsthe encrypted secret key using her private key to obtainthe secret key. Then, the secret key is used to obtain theplain text of the data item.

Jointly owned data only need to be encrypted by oneof the co-owners since the purpose of encrypting a dataitem is to keep the cloud provider from knowing theclear text of the data. Thus, encrypting the data oncewould prevent the cloud provider from understandingthe content of the data. The co-owners need to reachan agreement on the secret key being used to encryptthe data item. Thus, all the co-owners can decrypt theencrypted data when they need it.

Storing the encrypted secret keys on the cloudproviders relieves the authorized users from distributingthe encrypted keys to their delegates. As the secret keysare encrypted, the cloud provider cannot find out theclear text of the keys. Hence, it is not able to use thekey to decrypt the encrypted data.

Cloud providers use Algorithm 5 to find the delegatesthat satisfy a user’s access control rule. Algorithm 5is invoked when the access control rule for an asset iscreated or changed. It is also applied to each data itemof an authorized user when the authorized user assignsa new attribute to her delegate. This is because thesechanges might result in some users satisfying the access




Algorithm 5 Finding conforming delegatesFindConformingDelegate(au, data)Input: au is the ID of an authorized user

data denotes a data itemOutput: a set of users that satisfy au’s access

control rule for data1. let Rule be the set of rule keys that corresponds

to au’s access control rule for data2. let Certificates be a set of credential

certificates issued by au// initialize conformDelegate

3. conformDelegate ∅4. for each cert in Certificates do f5. extract key from cert6. if CredSatisfiesRule(key;Rule) then7. conformDelegate

conformDelegate[ fcert’s holder g8. else9. remove the encrypted secret key

for cert’s holder10. end-if11. end-for-each12. return conformDelegate

rule of the authorized user.As explained in Sections 3.6 and 3.7, an authorized

user stores her access control rules and the credentials’certificates that have been issued to other users on thecloud providers. A cloud provider can find out theaccess control rule set by authorized user au (line 1)and all the credential certificates issued by au (line2). Set conformDelegate contains the IDs of all theusers that satisfy au’s access control rule (line 3). Eachcredential given by au is checked against au’s accesscontrol rule for data (lines 4 and 5). Users satisfyingau’s access control rule are added to conformDelegate(lines 6 and 7). If a user no longer satisfies au’s rule,the user cannot access data. Thus, the encrypted secretkey that au generated for the user (if any) should bedeleted (lines 8 and 9). After each of the credentialssupplied by au is checked, the set of IDs of the usersthat satisfy au’s access control rule is returned to userau (line 12).

3.10 Speeding up the access control process

The access control rules and the credentials of theusers are stored on the cloud providers. Thus, a user’spermission for accessing an asset can be determined bythe cloud providers before the user actually requests toaccess the asset. This means that, instead of carryingout the rule enforcement operation on the fly, the cloud

providers can pre-compute a list of eligible users foreach access mode of an asset. When a user wants tocarry out an operation on an asset, the cloud providerfirst verifies the user’s identity using a public keyauthentication mechanism. If the identity of the usercan be established, the cloud provider just needs to lookup the list of eligible users to determine whether theuser’s access request can be granted. Thus, at run time,the access control process becomes a simple look upoperation without involving the expensive encryptionand decryption operations.

3.11 Changing access control rules and credentials

An authorized user, say Alice, might change her accesscontrol rule on an asset. After Alice’s rule is changed,it is necessary to check whether Alice’s delegates cansatisfy Alice’s new rule. For the delegates that can nolonger meet the conditions in Alice’s new rule, theirencrypted secret keys for decrypting the data should bedeleted by the cloud provider. For Alice’s delegatesthat have created their own rules on the asset, if adelegate cannot satisfy Alice’s new rule, all the rulesthat are in the sub-tree rooted at the delegate’s node inthe delegation tree should be deleted. For example, inFig. 1, after Alice changes her rule, it is necessary tocheck whether Bob and Carol can satisfy Alice’s newrule. If a user, say Bob, no longer satisfies Alice’s newrule, Bob cannot delegate any permission to Jimmy. Asa result, Bob’s and Jimmy’s rules are deleted from thedelegation tree. The same reasoning applies to Carol.

Algorithm 6 is executed by the cloud provider whena user, say au, changes her access control rule. In thealgorithm, c:creator is the ID of the user that createdthe rule stored in node c of the delegation tree.

An authorized user, say Alice, might change thecredentials of her delegates (i.e., assign new attributesor revoke all or some attributes issued to delegates).If Alice revokes all the attributes of a delegate, sayBob, Alice would tell the cloud provider to delete Bob’scredential certificate issued by Alice. Otherwise, Alicewould issue a new credential certificate to Bob, andgives the new certificate to the cloud provider.

After being notified by Alice, the cloud providerscans through all the assets for which Alice has setaccess control rules to find out whether Bob has usedhis old credential to set his own access control rules onthese assets. If Bob’s new credential (if any) cannotsatisfy Alice’s rule, Bob’s rule and all the rules belowBob’s node in the delegation tree are deleted. This is




Algorithm 6 Updating delegation treePolicyCleanse(asset; au)input: asset is the asset whose access control

rule is changedau is the authorized user that sets an

access control rule on asset1. let R be the node holding user au’s access

control rule in asset’s delegation tree, andChildren be the set of R’s child nodes// check whether each of au’s delegates// satisfies au’s new rule

2. for each c in Children do// cert is the credential certificate that au// issued to delegate c:creator

3. let cert be the credential certificate of userc:creator such that cert.issuer D au

// key is the credential key of// delegate c:creator

4. extract key from cert// c:creator cannot satisfy au’s new rule

5. if :CredSatisfiesRule(key, au’s rule) then// the sub-tree rooted at node c is deleted// by recursive call to Algorithm 6

6. delete c:creator’s access control rulefrom node c

7. PolicyCleanse(asset; c:creator)8. delete the encrypted secret key

for c:creator9. delete node c10. end-if11. end-for-each

because Bob can neither access the asset nor delegateany access permission to other users.

Algorithm 7 is used by the cloud provider after auser’s credential is changed. If a user, say del, has notcreated any access control rule (i.e., if “rdel exists” inline 6 of Algorithm 7 is false), the delegation tree is notaffected by the change of del’s credential. If del has notbeen given a new certificate (i.e., “cert does not exist”in line 6 is true), it means all the user’s attributes havebeen revoked. cert.key in line 6 is del’s new credentialkey.

When access control rules and user credentials arechanged, the authorized users only need to generate thenew rule keys and credential keys. The cloud provideris responsible for checking whether the changes wouldinvalidate some access control rules. The secret keys forencrypting data items are not affected by the changesto rules and credentials. This is because the usersaffected by the changes still need to go through the rule

Algorithm 7 Revalidating delegateCheckDelegate(au; del)input: au is an authorized user that has changed

some attributes assigned to au’s delegatedel

1. let DA be the set of assets that au has setaccess rules

2. let cert be del’s new credential certificategiven by au

3. for each asset da in DA do4. let rau be the node storing au’s rule in da’s

delegation tree5. let rdel be a child node of rau and rdel

stores del’s access control rule// actions to be taken when del’s new// credential cannot satisfy au’s access// control rule

6. if .rdel exists/ ^ ..cert does not exist/_:CredSatisfiesRule.cert.key; rau:rule//then// delete the sub-tree rooted at rdel by// calling Algorithm 6

7. delete del’s access control rule from rdel

8. PolicyCleanse(da; del)// If del cannot access the asset, its// encrypted secret key need to be// removed.

9. delete the encrypted secret key for del10. delete node rdel

11. end-if12. end-for-each

enforcement process of the cloud provider to obtain thedata and the secret keys for decrypting the data. If theycan no longer meet the conditions specified in the accesscontrol rules of the data, they will be denied the accessto the data and the secret key by the cloud provider.

4 Performance Evaluation

A prototype of the proposed scheme has beenimplemented using Java to evaluate the execution costof the scheme. The evaluation was carried out on a DellLatitude E6540 with a 2.7 GHz Intel Core i5-4310Mprocessor, 8 GB memory, and 64-bit Windows 7. Inall experiments, (a) the exponent of each key (i.e., e)is 65 537, and (b) the rule key has a single disjunct (i.e.,“Attr1 ^ Attr2 ^ � � � ^ Attrn” where 1 6 n 6 10).

The first experiment measures the time for generatingattribute keys using Algorithm 1 in Section 3.6. 10 000keys were generated. The average time for generatingone key of various length is shown in Fig. 3. It can be




30

25

20

15

10

5

0256 512

Size of a key (bit)1024

Tim

e to

gen

erat

e a

key

(ms)

Fig. 3 Time for generating an attribute key.

seen that the time is comparable with generating a keyof the same size in the RSA algorithm. Thus, attributekeys can be generated efficiently.

The second experiment evaluates (a) how the numberof attributes possessed by a user affects the cost ofcreating a credential key, and (b) how the number ofattributes appearing in a disjunct of an access ruleinfluences the time for generating a rule key. Two setsof experiments were carried out. In one experiment,the size of each attribute key is set to 256 bits. Thelength of each attribute key is set to 512 bits in the otherexperiment. As shown in Fig. 4, the cost of generatinga rule key is much higher than generating a credentialkey. This is because creating a rule key also requiresapplying the extended Euclidean algorithm to calculatethe matching key. However, the longest time observedin the experiment (i.e., there are 10 attributes in a rule

50

40

30

20

10

0

4000

3000

2000

1000

0

Tim

e fo

r cr

eden

tial

key

(m

s)

Tim

e fo

r ru

le k

ey (m

s)

Number of attributes in a key

(a)

(b)

Number of attributes in a key

512-bit key

512-bit key

256-bit key

256-bit key

1

1

2

2

3

3

4

4

5

5

6

6

7

7

8

8

9

9

10

10

Fig. 4 Time for generating a rule/credential key.

key and each attribute key is 512 bits) is only about3500�s. Hence, the credential keys and rule keys canbe generated efficiently.

The last experiment measures the costs of ruleenforcement. The enforcement involves encrypting a10-byte string using the credential key and decryptingthe encrypted string using a rule key. The speeds of theencryption and decryption are affected by the sizes ofthe keys. The size of a key depends on the numberof attributes in a credential or a rule. According toDefinition 7 in Section 2, the size of a product key ismnwherem is the size of each attribute key and n is thenumber of attribute keys used to form the product key.In this experiment, the credential key is set to contain10 attributes while the number of attributes in the rulekey varies between 1 and 10.

In the experiments, the size of an attribute key is setto 256 and 512 bits respectively. According to Fig. 5,when the size of an attribute key is 256 bits, the longesttime for the enforcement operation is 35 ms. Thisappears to be reasonable for any on-line application.In the worst case (i.e., there are 10 attributes in thecredential key and rule key respectively, and the size ofeach attribute key is 512 bits), the enforcement time isabout 249 ms. As discussed in Section 3.10, the cloudproviders can carry out the rule enforcement operationsin advance. That is, the cloud provider pre-computes alist of users that are eligible to access an asset. Hence,the rule enforcement operation can be carried out off-line. For an off-line operation, 249 ms seems to bereasonably efficient.

5 Related Work

Nabeel and Bertino[21] proposed a scheme for dividingthe access control operations between the data ownerand the cloud provider. The scheme divides the accesscontrol rules into two sets. One set is only visibleto the data owner while the other set is given to thecloud provider. Thus, the access control policies are

300

250

200

150

100

50

0Enf

orce

men

t ti

me

(ms)

Number of attributes in a rule key1 2 3 4 5 6 7 8 9 10

512-bit key256-bit key

Fig. 5 Time for carrying out rule enforcement.




partially hidden from the cloud provider. Differentfrom Ref. [21], the scheme here hides the accesscontrol policies from the cloud providers completelyby representing the policies in a form that cannot beunderstood by the cloud providers. Unlike the schemein Ref. [21], this paper also addressed the issue ofdelegating access permissions which is important formany cloud applications.

Many approaches that use cryptographicmechanisms to enforce access control rules havebeen proposed[1, 13, 14]. They usually group data itemsbased on access control rules and encrypt each groupwith a different symmetric key. Then, users can derivethe keys only for the data items they are allowed toaccess. Like the scheme in Ref. [21], none of theseschemes address delegating access permissions whichwas studied in this paper.

Ye and Khoussainov[10] presented an access controlscheme that allows the access control rules andcredentials to be stored in an obscured form. Differentfrom the scheme in this paper, Ref. [10] did not allowaccess permission delegation. Hence, Ref. [10] is not asflexible as the scheme in this paper.

Ray et al.[17] proposed a scheme for controllingthe access of files in a hierarchical organisation. Thescheme requires the credential keys of the entities atthe lower levels of the hierarchy contain the keys of theentities at higher levels of the hierarchy. Thus, a singleentity is needed for generating the keys for all the usersin the system. However, it might not be practical tofind an entity that is trusted by everyone in the system.Hence, the scheme is not well suited for many cloudapplications. Unlike Ref. [17], the scheme in this paperallows the users to manage their own keys’ generation.Thus, it is more flexible to use.

Carrying out access control with hidden credentialshas been studied by many people[11, 22]. These schemesare based on the identity-based encryption scheme[23].In these schemes, the access control policies are usedas keys to encrypt the data. Only the people whomeet the conditions specified in the policies are able togenerate the decryption keys. Frikken et al.[12] improvedthe performance of hidden credential schemes. Li andLi[24] proposed a scheme for hiding the attributes ofthe identity during a trust negotiation. They used atopologically uniform circuit and a committed-integerbased oblivious transfer protocol. All these schemeshave very high running cost. For example, Frikken’sscheme needs O.�mn/ encryption operations and

O.�2mn/ communications where m is the number ofcredentials, n is the number of attributes in a policy, and� is the number of bits used to represent the attributes.The cost of running the scheme in this paper is lowas it only needs one encryption and one decryptionoperation, and, it does not require the server and theuser to engage in multiple rounds of communications.Unlike the identity-based encryption schemes[12, 24], thescheme in this paper uses a different approach ingenerating the credential and rule keys. As a result,the keys used by the proposed scheme can be generatedmore efficiently.

Baden et al.[25] used attribute-based encryption toensure the confidentiality of data. They assumed thatall the users share the same set of attributes. Inpractice, this requirement might be difficult to be met.For example, in cloud manufacturing, partners fromdifferent industries might need to collaborate on aproject. These partners are likely to use differentterminologies. Unlike Ref. [25], the scheme proposedin this paper allows users to use their own attributeswhen defining access control rule. Thus, the schemein this paper is easier and more flexible for people touse.

She et al.[8, 26] proposed several schemes forcontrolling the flow of information through a compositeservice. The schemes do not hide the contents of accesscontrol policies. Confidential policies remain on thepolicy’s creator and access control needs to be carriedout by the creator. Different to She’s schemes, thescheme in this paper hides the contents of the policyand allows the policy to be checked by cloud providers.Thus, the proposed scheme incurs less communicationsbetween the users and the cloud providers. Hence, theproposed scheme is more efficient.

Trust negotiation has been studied in Refs. [9,27], etc. To minimize the amount of informationdisclosed to partners, Winsborough’s scheme requiresthe partners exchange their credentials in severalrounds. Squicciarini’s scheme uses substitution andgeneralization to minimize and blur the informationexchanged between partners. These schemes did notintend to hide the policies or credentials. Differentto these schemes, the scheme in this paper completelyhides the contents of the policies and credentials. Thus,it provides a higher level of privacy.

The access delegation schemes by Liu and Zic[7]

and Xu et al.[6] allow users to delegate their accesspermission without changing the system configuration.




Both schemes did not consider how to delegatepermissions on jointly owned data items. Unlike Refs.[6, 7], the scheme in this paper used an attribute-basedaccess control approach. By setting access controlrules, permission delegation for jointly owned assetscan be easily handled in this paper.

Gonzalez-Manzano et al.[28] proposed a model forhandling access control policies of co-owners of jointlyowned object. Their focus is on decomposing objectsand mediating the access control rules of the co-ownersto ensure that the requirements of all the co-ownerscan be satisfied. Unlike the scheme proposed in thispaper, the scheme in Ref. [28] does not consider theconfidentiality of data nor the privacy of the accesscontrol policies.

6 Conclusions

The access control scheme in this paper allows accesspermission delegation to be carried out easily in a cloudenvironment. In the proposed scheme, cryptography isused to ensure the confidentiality of data, the privacy ofthe access control rules, and the credentials required foraccess control. The scheme is flexible and easy to useas it allows users to delegate their access permissionsby (a) assigning user self-defined attributes to theirdelegates and (b) specifying access control rules interms of the attributes. Access control enforcement andmost of the tasks caused by changing access controlrules and credentials are carried out by cloud providers.Users’ tasks are limited to generating credential key andpolicy keys. Compared with the existing schemes, theproposed scheme is simple and efficient to use. Theexperiments showed that (a) the time for generating anattribute key is comparable to generating an RSA key,and (b) when the size of each attribute key is 256 bits,with no more than ten attributes in the credential orthe access control rule, the policy enforcement can becarried out in less than 35 ms. The scheme allows theefficiency of the access control process to be furtherimproved by pre-computing a list of eligible users foreach asset.

References

[1] M. Nabeel, N. Shang, and E. Bertino, Privacy preservingpolicy based content sharing in public clouds, IEEETransactions on Knowledge and Data Engineering, vol.25, no. 11, pp. 2602–2614, 2013.

[2] K. P. N. Puttaswamy, C. Kruegel, and B. Y. Zhao,Silverline: Toward data confidentiality in storage-intensive

cloud applications, in Proceedings of the 2nd ACMSymposium on Cloud Computing, New York, NY, USA,2011.

[3] D. Song, E. Shi, I. Fischer, and U. Shankar, Cloud dataprotection for the masses, Computer, vol. 45, no. 1, pp.39–45, 2012.

[4] S. Yu, C. Wang, K. Ren, and W. Lou, Achieving secure,scalable, and fine-grained data access control in cloudcomputing, in Proceedings of the 29th Conference onInformation Communications, Piscataway, NJ, USA, 2010,pp. 534–542.

[5] X. Xu, From cloud computing to cloud manufacturing,Robotics and Computer-Integrated Manufacturing, vol.28, no. 1, pp. 75–86, 2012.

[6] Y. Xu, A. M. Dunn, O. S. Hofmann, M. Z. Lee, S. A.Mehdi, and E. Witchel, Application-defined decentralizedaccess control, in Proceedings of the 2014 USENIXConference, Berkeley, CA, USA, 2014, pp. 395–408.

[7] D. Liu and J. Zic, User-controlled identity provisioningfor secure account sharing, in Proceedings of the 2014IEEE International Conference on Cloud Computing,Washington, DC, USA, 2014, pp. 644–651.

[8] W. She, I. Yen, B. Thuraisingham, and E. Bertino,The SCIFC model for information flow control in webservice composition, in Proceedings of the 2009 IEEEInternational Conference on Web Services, Washington,DC, USA, 2009, pp. 1–8.

[9] A. C. Squicciarini, E. Bertino, E. Ferrari, and I. Ray,Achieving privacy in trust negotiations with an ontology-based approach, IEEE Trans. Dependable Secur. Comput.,vol. 3, no. 1, pp. 13–30, 2006.

[10] X. Ye and B. Khoussainov, Fine-grained access control forcloud computing, Int. J. Grid Util. Comput., vol. 4, no. 2/3,pp. 160–168, 2013.

[11] R. W. Bradshaw, J. E. Holt, and K. E. Seamons,Concealing complex policies with hidden credentials, inProceedings of the 11th ACM Conference on Computerand Communications Security, New York, NY, USA, 2004,pp. 146–157.

[12] K. Frikken, M. Atallah, and J. Li, Attribute-based accesscontrol with hidden policies and hidden credentials, IEEETrans. Comput., vol. 55, no. 10, pp. 1259–1270, 2006.

[13] M. Harbach, Towards privacy-preserving access controlwith hidden policies, hidden credentials and hiddendecisions, in Proc. of the 10th Annual InternationalConference on Privacy, Security and Trust, Paris, France,2012, pp. 17–24.

[14] R. Zhang, L. Liu, and X. Rui, Role-based and time-bound access and management of EHR data, Security andCommunication Networks, vol. 7, no. 6, pp. 994–1015,2014.

[15] H. Takabi, Privacy aware access control for data sharing incloud computing environments, in Proceedings of the 2ndInternational Workshop on Security in Cloud Computing,New York, NY, USA, 2014, pp. 27–34.

[16] R. L. Rivest, A. Shamir, and L. Adleman, A method forobtaining digital signatures and public-key cryptosystems,Commun. ACM, vol. 21, no. 2, pp. 120–126, 1978.




[17] I. Ray, I. Ray, and N. Narasimhamurthi, A cryptographicsolution to implement access control in a hierarchy andmore, in Proceedings of the Seventh ACM Symposiumon Access Control Models and Technologies, ACM, NewYork, NY, USA, 2002, pp. 65–73.

[18] I. You and K. Yim, Malware obfuscation techniques: Abrief survey, in Proceedings of the 2010 InternationalConference on Broadband, Wireless Computing,Communication and Applications, IEEE ComputerSociety, Washington DC, USA, 2010, pp. 297–300.

[19] Wikibooks, https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Authentication Keys, 2015.

[20] L. Gonzalez-Manzano, A. I. Gonzalez-Tablas, J. M. deFuentes, and A. Ribagorda, Extended U+F social networkprotocol: Interoperability, reusability, data protection andindirect relationships in web based social networks, TheJournal of Systems and Software, vol. 94, pp. 50–71, 2014.

[21] M. Nabeel and E. Bertino, Privacy preserving delegatedaccess control in public clouds, IEEE Trans. Knowl. DataEng., vol. 26, no. 9, pp. 2268–2280, 2014.

[22] J. E. Holt, R. W. Bradshaw, K. E. Seamons, and H. Orman,Hidden credentials, in Proceedings of the 2003 ACMWorkshop on Privacy in the Electronic Society, ACM, NewYork, NY, USA, 2003, pp. 1–8.

[23] D. Boneh and M. K. Franklin, Identity-based encryptionfrom the weil pairing, in Proceedings of the 21st Annual

International Cryptology Conference on Advances inCryptology, Springer-Verlag, London, UK, 2001, pp. 213–229.

[24] J. Li and N. Li, Policy-hiding access control in openenvironment, in Proceedings of the Twenty-Fourth AnnualACM Symposium on Principles of Distributed Computing,ACM, New York, NY, USA, 2005, pp. 29–38.

[25] R. Baden, A. Bender, N. Spring, B. Bhattacharjee, andD. Starin, Persona: An online social network with user-defined privacy, in Proceedings of the ACM SIGCOMM2009 Conference on Data Communication, ACM, NewYork, NY, USA, 2009, pp. 135–146.

[26] W. She, I. Yen, B. Thuraisingham, and E. Bertino,Effective and efficient implementation of an informationflow control protocol for service composition, in IEEEInternational Conference on Service-Oriented Computingand Applications, 2009, pp. 1–8.

[27] W. H. Winsborough, K. E. Seamons, and V. E. Jones,Negotiating disclosure of sensitive credentials, in Proc.of Second Conference on Security in CommunicationNetworks, 1999, pp. 1–8.

[28] L. Gonzalez-Manzano, A. I. Gonzalez-Tablas, J. M. deFuentes, and A. Ribagorda, CooPeD: Co-owned personaldata management, Computers & Security, vol. 47, pp. 41–65, 2014.

Xinfeng Ye gained his BSc degreein computer science from HuaqiaoUniversity, China, in 1987, and MScand PhD degrees in computer sciencefrom The University of Manchester,England, in 1988 and 1991, respectively.He is currently a senior lecturer in theDepartment of Computer Science at The

University of Auckland, New Zealand. His current researchinterests include cloud computing and system security.



Education

Privacy preserving and delegated access control for cloud applications