Fine-grained Access Control for Cloud Computing

Transcription

1 Fine-grained Access Control for Cloud Computing Xinfeng Ye Department of Computer Science, Auckland University, Auckland, New Zealand Bakh Khoussainov Department of Computer Science, Auckland University, Auckland, New Zealand Abstract: Fine-grained access control schemes are commonly used in cloud computing. In this type of schemes, each data item is given its own access control policy. The entity that wants to access the data item needs to provide its credentials to a policy enforcer. In a cloud environment, normally, the policy enforcer is not the owner of the data. The access control policies and the credentials might reveal some information that the policy enforcer is not entitled to know. This paper proposed a finegrained access control scheme. It prevents the policy enforcers from comprehending the access control policies and the entities credentials by using cryptographic techniques. Compared with the existing schemes, the proposed scheme provides higher level privacy. Keywords: access control, cloud computing Biographical notes: Xinfeng Ye gained his PhD in Computer Science from The University of Manchester, England, in He is currently a senior lecturer in the Department of Computer Science at The University of Auckland, New Zealand. His current research interests include web services and cloud computing. Bakh Khoussainov received his PhD in Algebra and Logic from Novosibirsk University, Russia, in He is currently a professor in the Department of Computer Science at The University of Auckland, New Zealand. His current research interests include automatic and computable structures, and games on finite graphs and complexity. 1 Introduction As cloud computing has helped many businesses increase their competitiveness (Narasimhan, 2011), many manufacturers are adopting the concept of cloud computing into their manufacturing process (Saito et al., 2011). Cloud manufacturing is being regarded as the future manufacturing model (Xu, 2012). In cloud manufacturing, manufacturers pool their resources together to form a cloud platform. A manufacturing process can be formed by integrating the services provided by the manufacturers in the cloud platform. To ensure data security, it is important to provide finegrained access control to the data in the cloud (Bethencourt et al., 2007; Song et al., 2012; Yu et al., 2010; Barhamgi et al., 2012). For example, when a company stores data in the cloud, the company would only allow its contractors to view the data that are relevant to the projects that the contractors are working on. Many fine-grained access control schemes have been developed, e.g. (Ye and Zhong, 2011). In these schemes, the access control policy for a data item is attached to the data item. The data s policy is transmitted with the data at the same time. Data are only sent to an entity if the entity s credentials satisfy the data s access control policy. Cryptography has also been used to achieve fine-grained access control in cloud computing (Yu et al. 2010; Bethencourt et al., 2007; Zhou et al., 2011; Tian, 2012; Fan, 2012). In these approaches, attribute-based encryptions are used to encrypt data. The encrypted data can only be decrypted by the clients who possess the desired attributes. Encryption-based access control is designed for storing data on storage service providers. It assumes that the hosts of the data should not know the contents of the data. However, this assumption does not suit cloud manufacturing. For example, assume a company has two contractors working on a project. The company stores project-related data on the two contractors sites. The two contractors are also expected to exchange project-related data between them. It can be seen that the data stored on the contractors sites cannot be encrypted as the contractors need to access the contents of the data. The problem with the existing fine-grained access control schemes is that the access control policies are not entirely hidden from the policy enforcers. Goyal et al. stated that it is important to hide the access control policies for some applica-

2 tions (Goyal et al., 2006). This is because the access control policies and the credentials used to access the data might compromise the secrecy of some information concerning the data s owner and the holders of the credentials as shown in the example below. A car company GreenCar is working on a new model, say LessFeul, and has outsourced (a) the engine design to company LowEmission, and (b) the ignition system design to company Sparky. GreenCar gives (a) credentials engine designer and LessFeul s contractor to LowEmission, and (b) credentials ignition designer and LessFeul s contractor to Sparky. Assume that GreenCar sends LessFeul s engine design data to LowEmission to allow LowEmission to work on the engine design. As LowEmission and Sparky both need to access LessFeul s engine design data, when GreenCar stores LessFeul s engine design data on LowEmission, GreenCar sets the access control policy of the data as (engine designer OR ignition designer) AND LessFeul s contractor. The policy indicates the credentials that an entity needs to possess in order to retrieve the data. When Sparky retrieves LessFeul s engine design data from LowEmission, Sparky needs to provide its credentials to LowEmission for policy enforcement purpose. However, handing credentials over to a third party might reveal more information than required by the policy enforcement process. For example, a rogue employee in LowEmission might be interested in buying Sparky s share. When Sparky retrieves LessFeul s data from LowEmission, the rogue employee can read the credentials submitted by Sparky to find out whether Sparky also has other credentials given by GreenCar apart from the credentials for model LessFuel. Having more credentials means Sparky is also working on other GreenCar s models. This would give more assurance that Sparky s share price would go up when these new models go into production. On the other hand, the access control policy might also reveal some commercial secrets. For example, once the design of LessFuel is approved, GreenCar would move to the planning stage for the production of Less- Fuel. At this stage, the access control policies for LessFuel s data would become to ((engine designer OR ignition designer) AND LessFeul s contractor) OR production planner. The planning for the production of a car is regarded as a commercial secret. However, by observing the change in access control policies, people can infer the planned production of Less- Fuel. To avoid the problems mentioned above, the contents of the credentials and the policies should be made incomprehensible to the policy enforcers. Researches have been carried out in trust negotiation and access control with hidden policies and credentials (Frikken et al., 2006; Li and Li, 2005). However, these schemes are computationally intensive and very inefficient. Thus, it is not practical to use them in real applications. This paper proposed an access control scheme for cloud manufacturing. The scheme uses cryptographic techniques to obscure the access control policies and the credentials required for accessing data. Compared with the existing schemes, the proposed scheme provides a higher level of security, and it is more efficient and flexible than the existing schemes that hide policies and credentials. In this paper, 2 describes the theoretical background of the scheme. 3 shows the details of the scheme. Comparisons with existing works and conclusions are given in 4 and 5 respectively. 2 The Theoretical Foundations of the Scheme Ray et al. developed a scheme for carrying out access control in a hierarchical organization (Ray et al., 2002). Ray s scheme is based on the RSA algorithm (Rivest et al., 1978). This paper extends Ray s scheme to build a cryptosystem for obscuring access control policies and entities credentials. The proposed scheme does not require the entities in the system to be organised into a hierarchical structure. This section introduces the theoretical foundations of the proposed scheme. The proof of Theorem 1 and 2 were given in (Ray et al., 2002). Definition 1: Two integers, a and b, are relatively prime if their greatest common divisor is 1. That is, gcd(a,b) = 1. Definition 2: Euler s totient function is defined as: 1 if is prime if and, : 1... and are relatively prime Definition 3: A key K is a pair < e, N >, where N is a product of distinct primes and e is relatively prime to ; e is the exponent and N is the base of key K. Definition 4: The encryption of a message m with the key K = < e, N >, denoted as [m, K], is defined as [m, < e, N >] = m e mod N Definition 5: The matching key of key K =< e, N >, denoted as K -1, is a pair < d, N >, satisfying ed 1 mod where is the congruence modulo relation. K can decrypt the message encrypted using K -1, and vice versa. That is,,,,, Definition 6: Two keys K 1 =< e 1, N 1 > and K 2 =< e 2, N 2 > are compatible if e 1 = e 2 and N 1 and N 2 are relatively prime. Definition 7: If two keys K 1 =< e, N 1 > and K 2 =< e, N 2 > are compatible, then the product key,, is defined as <e, N 1 N 2 >. Theorem 1: Let K 1 = < e, N 1 > and K 2 = < e, N 2 >. For any two messages m and,,, if and only if m =,, if and only if m = Theorem 2: If 0 < m < N and N = N 1 N 2 N k and N 1, N 2,, N k are primes, where x is an integer. Lemma: Let K 1 =< e, N 1 > and K 2 =< e, N 2 > be two compatible keys. holds.

3 Proof: According to Definition 7,, and, hold. Since holds, it can be seen that the lemma holds. In Theorem 3, is a product key that is formed by a subset of the keys in set,,,. Theorem 3 states that, if a message is encrypted using a product key that is formed with all the keys in,,,, then the matching key of, i.e., can be used to decrypt the encrypted message. For example, assume,, and are compatible keys. A message encrypted with product key can be decrypted using any one of the keys in set {,,,,,,. Theorem 3: Let, where 1 be compatible keys. For any message m such that, the following holds:,, where is the matching key of key and such that 1, 1 and if Proof: Since and,, according to Definition 7,, where. Since, the following property holds: (Prop 1) From Definition 5, it can be seen that, where ed 1 mod. Hence, the following property holds: 1 where x is an integer (Prop 2) The proof uses the following property of the mod operation: (Prop 3) Let where 1, 1, if,,,,,,, {,,,,,,,,,, Since (a) and are formed by all the keys in {,,,, and (b) they do not have any key in common, according to Lemma, holds. Hence,,,,,, (Def. 4 with key ), (sub., for a in Prop 3), (Theorem 1) (Def. 4 with key ) (idempotency of mod) (sub. for a in Prop 3) (Prop 2) (Theorem 2) (from Prop 1, ) Thus, Theorem 3 holds. 3 Access Control with Obscured Policies and Credentials 3.1 An Overview A cloud manufacturing platform consists of several manufacturers that provide their services to other people. These manufacturers are called the service providers. A client of the platform might build its manufacturing process by integrating the services of several service providers. During the manufacturing process, a client s data might need to be stored on its service providers. Since the service providers need to cooperate with each other to carry out the client s task, the client s data might need to be passed amongst the service providers. A client is the owner of its data. For example, GreenCar owns the data relating to LessFeul s design. Each data item has an access control policy attached. The policy is set by the owner of the data item. An attribute-based access control scheme is used for controlling the access to data. In attribute-based access control, the access control policy of a data item is specified in terms of the attributes that an entity needs to possess in order to obtain the data item. For example, if the access control policy for LessFuel s data is (engine designer AND LessFeul s contractor), it means the data can only be accessed by entities that are both engine designer and LessFeul s contractor. Each data owner defines a set of attributes. The access control policies are specified in terms of these attributes. It is assumed that each data owner is responsible for defining and assigning attributes to the entities that want to access their data. Data are passed among the service providers. As a result, data might reside on a service provider that is not the owner of the data. For the example in 1, although GreenCar owns LessFeul s engine design data, Sparky retrieves LessFeul s engine data from LowEmission. To access a data item, an entity must possess appropriate attributes which are obtained from the owner of the data. The owner of the data issues credential certificate to an entity. The credential certificate states the attributes that the owner assigns to the entity. The certificates are digitally signed by the issuers. It is assumed that a certificate authority exists for distributing the public keys of the issuers of the credential certificates. Thus, the validity of the credential certificates can be easily verified. Data can be passed among the service providers through service invocation. When a service provider, say Sparky, invokes an operation on another service provider, say LowEmission, Sparky passes its credentials to LowEmission. LowEmission decides whether the operation can be carried out by checking Sparky s credentials against the access control policies of the data accessed by the operation. This paper focuses on access control. Thus, it is assumed that an authentication scheme exists for verifying the identity of the entity. In order to hide the access control policies and credentials, a cryptographic system is developed. The system is similar to

4 the RSA cryptosystem. That is, a matching public and private key pair is used to encrypt and decrypt information. The access control policy of a data item is converted to a set of decryption keys called rule keys, and, the credentials of an entity are converted to an encryption key called credential key. If and only if the credentials satisfy the access control policy, the information encrypted by the credential key can be decrypted by at least one of the rule keys. Thus, when a service provider, say LowEmission, checks whether the credentials of a service provider, say Sparky, satisfy the access control policy of a data item, say D, LowEmission generates a random string T first. LowEmission uses Sparky s credential key to encrypt the random string to obtain a ciphered string CT. If CT can be decrypted successfully using one of D s rule keys, it means that Sparky s credentials satisfy D s access control policy. If none of D s rule keys can decrypt CT correctly, it means that Sparky s credentials do not satisfy D s access control policy. The conversions of policies and credentials to keys are carried out by the owners of data when they create the policies and assign attributes to the entities that want to access their data. Thus, only the owner of a data item knows (a) the mapping between the access control policy and the rule keys, and (b) the mapping between the entities attributes and their credential keys. Hence, even if the policy enforcer knows the keys, the enforcer does not know the contents of the policy or the meaning of the entity s credentials. Therefore, the privacy of the policy and the credentials are ensured. Figure 1 shows the interactions between the participants of the system. GreenCar converts the access control policy of the data to rule keys, and sends the data and the rule keys to LowEmission. (labelled 1). Sparky wants to access the data owned by GreenCar. Thus, Sparky obtains credentials from GreenCar (labelled 2). GreenCar assigns attributes to Sparky, and converts the attributes to a credential key. The key is placed in a credential certificate and sent to Sparky (labelled 3). When Sparky retrieves the data from LowEmission, it sends its credential certificate to LowEmission (labelled 4). LowEmission checks whether a rule key of the data can decrypt the information encrypted by Sparky s credential key to decide whether to grant/decline Sparky s request (labelled 5). Fig. 1. The Interactions between the Participants of the System 3.2 Security Model It is assumed that the policy enforcers honestly carry out the access control scheme. The enforcers are interested in finding out the contents of the access control policies of the data and the credentials of the entities that want to retrieve the data. The entities might collude with each other to gain access to the data that they are not entitled to access. For example, GreenCar might have stored some data that can only be accessed by an entity that has both attributes engine designer and ignition designer. LowEmission has attribute engine designer, and Sparky has attribute ignition designer. LowEmission and Sparky might collude to combine their credentials together to gain access to GreenCar s data. 3.3 Assigning Credentials and Setting Policies As data are passed among service providers during the manufacturing process, an entity might need to retrieve data from a service provider that is not the owner of the data. For example, Sparky needs to retrieve GreenCar s data from LowEmission. In order to access the data, Sparky should provide credentials that are issued by GreenCar. It is assumed that each service provider has obtained relevant credentials from the owners of the data that it needs to access. This assumption is reasonable as, during service negotiation, GreenCar would issue the relevant credentials to Sparky to allow Sparky to access the data that are needed by Sparky s contract. The access control policy of a data item is a rule representing the conditions that an entity needs to satisfy in order to obtain the data. A rule is represented as a logic expression in disjunctive normal form. For example, if a policy states that a data item can only be read by users who have attributes A and B or attributes A and C, the logic expression representing the rule is. 3.4 Obscuring Credentials For each attribute defined by a data owner, the owner creates an attribute key that conforms to Definition 3. For a data owner, all the attribute keys have the same exponent, different bases, and, the bases are relatively prime to each other. Thus, according to Definition 6, the attribute keys generated by one data owner are compatible with each other. The algorithm below is used by a data owner to generate an attribute key. GenerateAttributeKey(e, uprimes) input: e is the exponent of all the keys; uprimes is a set containing all the primes that have been used to construct attribute keys on a data owner //find two un-used distinctive primes that conform to Definition 3 find two distinctive primes, and such that gcd, 1, // record p 1 and p 2 as used primes return, // the new key is, In GenerateAttributeKey, the product of any two primes in uprimes are relatively prime to. This is because and are new prime numbers that do not exist in uprimes. Thus, according to Definition 6, the new key, is compatible with all the existing keys. A data owner might give one or several attributes to an entity. For example, LowEmission has attributes engine designer and LessFeul s contractor. The credential issued to an entity should include all the attributes that the entity has been given by the data owner. Assume a data owner assigns attributes A 1, A 2,, A n to an entity c. The owner creates a

5 product key using all the attribute keys given to c. The product key is used to represent c s credential. For example, if the attribute keys of A 1, A 2,, and A n are K 1, K 2,, and, K n respectively, c s credential is represented as. The product key is a pair <e, N> where and, 1. As only the data owner knows how to map an attribute defined by it to the corresponding attribute key, the product key cannot be linked back to any attribute by any service provider. Thus, the meanings of the entities credentials are kept secret. 3.5 Obscuring Policies As described in 3.3, each rule in an access control policy is represented in disjunctive normal form, e.g.. If an entity can satisfy any of the conjunctive clauses, the entity satisfies the rule. To satisfy a conjunctive clause, an entity must possess all the attributes that appear in the clause. For example, if a clause is, an entity must have both attribute A and B in order to satisfy the clause. In order to hide the policy, the scheme in this paper first calculates a product key for each of the conjunctive clauses in a rule. The product key is generated using the keys of the attributes that appear in the clause. For example, for, A s and B s attribute keys (i.e. and ) are used to generate the product key. Once the product key is obtained, the scheme calculates s matching key, i.e.. is called a rule key. It is used to replace in the rule. Thus, a rule will be converted into several rule keys. Each key corresponds to a conjunctive clause in the rule expression. For example, rule is converted to keys and. The algorithm below describes how to convert a rule to a set of rule keys. is a function that maps an attribute to its corresponding key. ConvertRuleToKey(Rule) Input: Rule is a rule in the access control policy for a data item ; // records the set of rule keys being generated let Rule = // find the product key for each conjunctive clause in a rule for each t i where 1 in Rule do { // AttributeKeys is a set including the keys of all the attributes in t i let and 1 // K is the product key where and for let, // compute s matching key compute such that, where 1 // is a rule key } // end of for each t i return 3.6 Policy Enforcement In order to retrieve a data item, an entity must satisfy the access control rule of the data item. Originally, a rule is written as a logic expression in disjunctive normal form. As described in 3.5, each rule is converted to a set of rule keys. Each key corresponds to a conjunctive clause in the logic expression. Thus, if one of the keys in a rule can be used to determine that the entity s credentials make the rule to evaluate to true, the entity satisfies the rule. An entity gives its credential certificate to a service provider when the entity retrieves a data item from the service provider. The service provider uses the credential key in the certificate and the rule keys representing the access control policy to carry out some encryption and decryption operations. The outcomes of these operations determine whether the entity satisfies the access control policy of the data item. Here is an example showing the policy enforcement process. Assume that (a) an entity has attributes A, B and D, (b) a rule in a data item s access control policy specifies, and, (c) the key assigned to attributes A, B, C and D are,,, and respectively. It can be seen that, if a conjunctive clause in the rule can be satisfied by the entity s credential, the attributes that appear in the conjunctive clause must be a subset of the attributes possessed by the entity. In this example, the set of attributes that the entity has is {A, B, D}. The attributes appearing in conjunctive clause form set {A, C} which is not a subset of {A, B, D}. As the entity does not have attribute C, the entity cannot satisfy conjunctive clause. According to 3.4 and 3.5, (a) the credentials given to the entity is the product key, and (b) key, and are created to replace, and respectively in the access control policy. First, a randomly generated string T is encrypted using the entity s credential key to obtain ciphered text CT. To check whether the entity s credential satisfies, the scheme uses (i.e. the key representing ) to decrypt CT. Since, is not the matching key of. Thus, cannot decrypt CT successfully. Since the decryption fails, it is regarded that the entity does not satisfy the conjunctive clause which is represented by. Similarly, when checking whether the entity s credential satisfies, the scheme uses the key (i.e. the key representing ) to decrypt CT. According to Theorem 3,,, holds. As the decryption is successful, it is regarded that the credential provided by the entity satisfies. In a disjunctive normal form, if one of the conjunctive clauses is satisfied, the whole logic expression evaluates to true. Thus, other conjunctive clauses (i.e. in this example) do not need to be checked. The algorithm below shows the policy enforcement process. PolicyEnforcement(Policy, D) 1 Input: D is the data item that an entity wants to access Policy is the access control rule guarding the data 2 Output: the access is granted or denied 3 let cert be a certificate such that cert.signer = Policy.creator 4 if ((cert does not exist) (cert is invalid)) return deny 5 extract Key from cert and generate a random string T 6, 7 for each in Policy do { 8 if (, ) return grant

6 9 } // end of for each 10 return deny An entity might have acquired several credential certificates from different data owners. When it requests for data, it gives all its credential certificates to the server for evaluation. cert.signer denotes the ID of the issuer of a certificate. rule.creator is the ID of the creator of a rule. As the entity s credentials need to be given by the same data owner that specified the access control policy, when checking a rule, the right certificate needs to be used (line 3). If (a) the entity has not been issued any credential by the data owner that created the rule, or (b) the signature on the certificate is invalid, the access request is denied (line 4). Otherwise, the credential key is retrieved from the certificate to encrypt a random string (lines 5 and 6). Each rule consists of a set of keys; and, each key corresponds to a conjunctive clause in the original rule expression. If one conjunctive clause in the rule is true (i.e. the key can decrypt CT), the rule is satisfied. Thus, there is no need to check the rest of the conjunctive clauses in the rule; and, the access request is granted (line 8). If none of the keys can decrypt CT correctly (i.e. the end of the for loop is reached in line 9), it means none of the conjunctive clauses in the rule can be satisfied. That is, the entity s credential cannot satisfy the access control policy. Thus, the entity is denied access to the data (line 10). 3.7 Coping with a Range of Values A rule in an access control policy might specify a range of values, e.g. age > 5. To allow this kind of rules to be checked during policy enforcement, the rules need to be specified as a logic expression in terms of the bits that make up the value. For example, assume that each number is represented as a 4-bit unsigned binary number B 3 B 2 B 1 B 0. age > 0101 (i.e. age > 5 if the value is given in decimal) can be specified as This means that, for an entity s age attribute, if bit B 3 of the attribute is 1or bits B 2 and B 1 are both 1s, the entity satisfies rule age > Similarly, rule age < 0101 can be specified as If a data owner creates a rule that specifies a range of values for an attribute, say attr, and the values are represented as n-bit numbers, the data owner generates two attribute keys for each bit representing the attribute value. The keys for bit i of attr are denoted as, and,. They indicate the value of bit i is 0 and 1 respectively. An entity s credential contains either key, or, depending on whether bit i of the entity s attr is 0 or 1. For example, assume the age of an entity is 0110 (i.e. B 3 B 2 B 1 B 0 =0110). Since bits B 2 and B 1 in the entity s age attribute are 1, keys, and, are contained in the entity s credential. As bits B 3 and B 0 are 0, keys, and, are included in the entity s credential. The,, data owner gives product key,, to the entity as the entity s credential. To convert a rule specifying a range of values to a set of rule keys, the key or the product key that corresponds to the condition specified by each of the conjunctive clauses in a rule is obtained first. The matching keys of these keys are the rule keys. For rule 1 1 1, key, corresponds to clause 1. This is because 1 means bit 3 of the value should be 1. Product key,, corresponds to clause 1 1 since 1 1 indicates both bit 2 and bit 1 of the attribute are 1. Thus, the rule keys for the rule are, and,,. Algorithm ConvertValue- ToKey converts a rule representing a range of values to a set of rule keys. ConvertValueToKey(Rule) Input: Rule is a rule specifying a range of values for attribute attr ; // records the set of rule keys being generated Let (a) Rule = (b) the value of attr be an n-bit number B n-1 B 1 B 0 (c), and, be the attribute keys for bit x of attr // find the product key for each conjunctive clause in Rule for each t i where 1 in Rule do { let 0, " 0" where 1, " 1" and 1 compute s matching key that conforms to Definition 5 // is a rule key } // end of for each t i return During policy enforcement, the rule keys are used to decrypt the information encrypted using the entity s credential as discussed in 3.6. For example, assume the credential is,,,, (i.e. the entity s age is 0110) and the rule keys are, and,, (i.e. the rule is age > 0101 ). According to Theorem 3, rule key,, can decrypt the infor- mation encrypted with key,,,,. That is, the credential (i.e. age = 0110 ) satisfies the rule (i.e. age > 0101 ). 3.8 Handling Policy Change and Certificates Revocation The owner of a data item might change the access control policy for the data item after the data is sent to some service providers. To update the policies for data items, a tracking mechanism is needed to track how data are passed among the service providers. Using the mechanism, new policies can be propagated to relevant data items. To implement the tracking mechanism, a tracking table is set up on each service provider. Each entry in the table is a pair <ID, DestSet>. ID is the name of a data item, and DestSet is a set containing the IDs of the service providers to which the corresponding data item has been sent. For example, an entry of the table might look like <sensor specification, {sp 1, sp 2 }> which means sensor s specification data has been passed to service provider sp 1 and sp 2. A service provider updates its tracking table when it sends a data item to another service provider.

7 When the owner of a data item changes the access control policy of the data item, the owner propagates the new policy to the servers in the DestSet of the data item. The receivers of the new policy look up the data item in their tracking tables to propagate the new policy to the servers in the DestSet of the data item. In this way, the new policy can be propagated to all the servers that have a copy of the data item. Fig. 2. Revoking Certificate A data owner might revoke the credential certificates that it has issued to some entities. The tracking mechanism is also used to inform the service providers of the revoked credential certificates. Since the entities need to use their credential certificates when they access data items, as long as the service providers that are holding the data items which might be accessed using the revoked certificates are informed, the revoked certificates become useless. Fig.2 shows how the certificate revocation notices are propagated to the service providers. In Fig.2, GreenCar has sent engine design data and chassis design data to SecureData. In turn, these data are retrieved by LowEmission and ToughFrame respectively. Assume that (a) the access control policy for the engine design data is engine designer OR ignition designer, (b) the access control policy for the chassis design data is chassis designer, and (c) GreenCar assigned attribute ignition designer to Sparky and revoked the credential certificate to Sparky later. As ignition designer appears in engine design data s access control policy, Sparky would be able to use its credential certificate to access the engine design data. To prevent Sparky from using the revoked certificate to access the engine design data, the system needs to inform all the service providers that have a copy of the engine design data about Sparky s revoked certificate (i.e. LowEmission in this example). Since the chassis design data s policy does not contain attribute ignition designer, the revoking of Sparky s certificate does not concern the service providers that are only holding the chassis design data (i.e. ToughFrame in this example). Therefore, ToughFrame does not need to know the revoking of the certificate. Thus, whenever a data owner revokes a credential certificate, the data owner (a) finds out the data whose access control policies refer to the attributes in the revoked certificate, (b) uses the tracking table to identify the servers which have received the data, and (c) informs these servers about the revoked certificate. Propagating the information about revoked certificates is carried out in the same way as propagating new access control policies. 3.9 Analysis of the Scheme Each data owner defines its own attributes relating to access control policy and entity credentials. As only the data owners know the mapping between the attributes and the attributes keys, the holders of the credential keys and the rule keys are not able to link the keys to the keys corresponding attributes. Therefore, the access control policies and the credentials of the entities are kept secret. If two entities collude with each other to access the information that they are not entitled to access, their effort will be detected. For example, if LowEmission only has attribute engine designer, Sparky only has attribute ignition designer, and they want to access a file which can only be accessed by entities with both attributes engine designer and ignition designer. LowEmission and Sparky can combine their credential keys to form a new credential key. However, as they do not know GreenCar s private key, they will not be able to correctly signed the forged credential certificate. As a result, the policy enforcer will detect that the certificate is invalid (line 5 of algorithm PolicyEnforcement in 3.6). Hence, the access request will be declined. 4 Related Works Ray et al. proposed a scheme for controlling the access of files in a hierarchical organisation (Ray et al., 2002). Unlike the scheme in this paper, Ray s scheme applies to a single organization. It does not involve exchanging policies between different organizations. Bethencourt et al. (Bethencourt et al., 2007), Yu et al. (Yu et al., 2010) and Li et al. (Li et al., 2010) used attribute-based encryption technique to encrypt data. Then, the policies or the attributes of the entities are used to decrypt the data. In order to encrypt or decrypt the information, the attributes that are used to encrypt the data must be attached to the encrypted data. This means that anyone would be able to know the attributes contained in the access control policy. Compared to these schemes, the scheme in this paper provides better privacy since it only allows the data owner know the attributes in access control policies. She et al. proposed a scheme for controlling the flow of information through a composite service (She et al., 2009). She s scheme does not attempt to hide the contents of access control policies. If a policy contains confidential information, the policy will remain on the policy s creator s site, and the creator is responsible for carrying out policy checking. Different to She s scheme, the scheme in this paper obscures the policy and allows the policy to be checked by any service providers. Thus, the proposed scheme incurs less communications for policy checking. Hence, it is more efficient.

8 Trust negotiation were studied in (Squicciarini et al., 2006; Winsborough et al., 1999) etc. Instead of hiding policies or credentials, they try to minimize and blur the information exchanged between partners. Different to these schemes, the scheme in this paper completely hides the contents of the policies and credentials. Thus, it provides better privacy. Carrying out access control with hidden credentials has been studied by many people (Bradshaw et al., 2004; Holt et al., 2003; Li and Li, 2005). These schemes are based on the identity-based encryption (Boneh and Franklin, 2001). Frikken et al. (Frikken et al., 2006) improves the performance these schemes. All these schemes have very high running cost due to the complexity of the schemes. For example, Frikken s scheme needs O(ρmn) encryption operations and communications where m is the number of credentials, 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 low as it only needs one encryption and decryption operations. 5 Conclusions This paper proposed a scheme that prevents policy enforcers from comprehending the meaning of the access control policies of data and the credentials required for accessing the data. The scheme increased the level of privacy and security for both data owners and the entities that want to access the data. The scheme is flexible as it allows access control policies to include rules that specify a range of values. The data tracking mechanism allows the access control policies to be modified after data items left their original owners. The tracking mechanism also makes it easier to prevent people from using the revoked certificates to access data. Compared with the existing schemes, the proposed scheme is simple and efficient to use. Acknowledgments This work is supported by a Faculty Research Development Fund ( ) of The University of Auckland. References Barhamgi M., Benslimane D., Ghedira C., Benharkat A., and Gancarski A. (2012) PPPDM - a privacy-preserving platform for data mashup. Int. J. of Grid and Utility Computing. Vol. 3, No. 2/3, pp Bethencourt J., Sahai A., and Waters B. (2007) Ciphertext-Policy Attribute-Based Encryption. Proceedings of the 2007 IEEE Symposium on Security and Privacy, IEEE Computer Society, pp Boneh D. and Franklin M. K. (2001) Identity-Based Encryption from the Weil Pairing. Proceedings of the 21st Annual International Cryptology Conference on Advances in Cryptology, Springer-Verlag, pp Bradshaw R. W., Holt J. E., and Seamons K. E. (2004) Concealing complex policies with hidden credentials. Proceedings of the 11th ACM conference on Computer and communications security, ACM, pp Fan K., Wang Y., and Li H. (2012) A new proxy blind signature scheme Int. J. of Grid and Utility Computing. Vol. 3, No. 1, pp Frikken K., Atallah M., and Li J. (2006) Attribute-Based Access Control with Hidden Policies and Hidden Credentials. IEEE Trans. Comput.55, 10 (October 2006), pp Goyal V., Pandey O., Sahai A., and Waters B. (2006) Attributebased encryption for fine-grained access control of encrypted data. Proceedings of the 13th ACM conference on Computer and communications security (CCS '06). ACM, pp Holt J. E., Bradshaw R. W., Seamons K. E., and Orman H. (2003) Hidden Credentials. Proceedings of the 2003 ACM workshop on Privacy in the electronic society, ACM, pp.1-8. Li J. and Li N. (2005) Policy-hiding access control in open environment. Proceedings of the twenty-fourth annual ACM symposium on Principles of distributed computing, ACM, pp Li M., Yu S., Ren K. and Lou W. (2010) Securing Personal Health Records in Cloud Computing: Patient-centric and Fine-grained Data Access Control in Multi-owner Settings. Proceedings of the 6 th International Conference on Security and Privacy in Communication Networks, Springer-Verlag, pp Narasimhan B. and Nichols R. (2011) State of Cloud Applications and Platforms: The Cloud Adopters' View. Computer Vol. 44, No. 3, IEEE Computer Society, pp Ray I., Ray I., and Narasimhamurthi N. (2002) A cryptographic solution to implement access control in a hierarchy and more. Proceedings of the seventh ACM symposium on Access control models and technologies. ACM, pp Rivest R. L., Shamir A., and Adleman L. (1978) A method for obtaining digital signatures and public-key cryptosystems. Commun. ACM 21, 2, pp Saito S., Ito A., Matsumoto H. and Ohta E. (2011) Engineering Cloud: Flexible and Integrated Development Environment, FUJITSU Scientific & Technical Journal, VOL.47, No.4, pp She W., Yen I., Thuraisingham B., and Bertino E. (2009) The SCIFC Model for Information Flow Control in Web Service Composition. Proceedings of the 2009 IEEE International Conference on Web Services. IEEE Computer Society, pp.1-8. Song D., Shi E., Fischer I., and Shankar U. (2012) Cloud Data Protection for the Masses. Computer, Vol. 45, No. 1, pp Squicciarini A. C., Bertino E., Ferrari E., and Ray I. (2006) Achieving Privacy in Trust Negotiations with an Ontology-Based Approach. IEEE Trans. Dependable Secur. Comput. Vol. 3, No. 1, pp Tian H. (2012) A new strong multiple designated verifiers signature. Int. J. of Grid and Utility Computing. Vol. 3, No. 1, pp Winsborough W. H. and Seamons K. E. and Jones V. E. (1999) Negotiating Disclosure of Sensitive Credentials. Second Conference on Security in Communication Networks. Amalfi, Italy. Xu X. (2012) From cloud computing to cloud manufacturing. Robotics and Computer-Integrated Manufacturing. 28(1). Elsevier, pp Ye X. and Zhong L. (2011) Improving Web Service Security and Privacy, Proceedings of the 2011 IEEE World Congress on Services. IEEE Computer Society, pp Yu S., Wang C., Ren K., and Lou W. (2010) Achieving secure, scalable, and fine-grained data access control in cloud computing. Proceedings of the 29th conference on Information communications. IEEE Press, pp Zhou L., Varadharajan V., and Hitchens M. (2011) Enforcing Role- Based Access Control for Secure Data Storage in the Cloud. Comput. J. Vol. 54, No. 10, pp