Abstract
CP-ABE (Ciphertext-Policy Attribute-Based Encryption) with hidden access control policy enables data owners to share their encrypted data using cloud storage with authorized users while keeping the access control policies blinded. However, a mechanism to prevent users from achieving successive access to a data owner’s certain number of data objects, which present a conflict of interest or whose combination thereof is sensitive, has yet to be studied. In this paper, we analyze the underlying relations among these particular data objects, introduce the concept of the sensitive data set constraint, and propose a CP-ABE access control scheme with hidden attributes for the sensitive data set constraint. This scheme incorporates extensible, partially hidden constraint policy. In our scheme, due to the separation of duty principle, the duties of enforcing the access control policy and the constraint policy are divided into two independent entities to enhance security. The hidden constraint policy provides flexibility in that the data owner can partially change the sensitive data set constraint structure after the system has been set up.
1. Introduction
With the advancement of cloud computing [1], an increasing number of organizations and individual users are willing to store their private data in cloud storage to share with others. Unlike traditional access control, the data owner reserves the right to define the access control policy for his/her data for release on the cloud. Moreover, the data owner encrypts his/her data according to his/her access control policy before putting the data on the cloud because the cloud might be compromised or untrusted. Attribute-Based Encryption [2–5] provides desirable solutions to meet the data owner’s needs. Compared to KP-ABE (Key-Policy Attribute-Based Encryption) [4] and fuzzy identity-based encryption [2], CP-ABE (Ciphertext-Policy Attribute-Based Encryption) [3, 5] is more appropriate, as it enables the data owner to more freely define the access control policy. Moreover, because the access control policy itself may leak critical information, efforts have been made [6–10] to hide the access control policy by blinding the attributes within it.
However, the data owner may unavoidably release some data onto the cloud storage whereby either there may exist a conflict of interest or one can derive sensitive or confidential data from the released data. For example, the data owner may release two data objects (a data object refers to an encryption data unit in CP-ABE scenario, e.g., a file, a message) and to the cloud, to which the Chinese Wall security policy [11] should be applied, as and are competitors. Any authorized user of the two data objects can freely access either data object, but once he/she has accessed one of them, he/she can no longer access the other. In the CP-ABE scenario, it is inappropriate to split all users into two mutually disjoint sets beforehand by choosing an access structure for the two data objects. This is because an authorized user is initially supposed to be able to access either of the two data objects freely. The relations among the data released to the cloud storage are substantially more complicated. Other types of data sets exist as well. In [12, 13], we emphasized the situation in which a user’s consecutive access to any data out of may yield a conflict of interest or disclosure of some sensitive data. This type of data set has been studied in primary access control constraints such as SOD (Separation of Duty) of RBAC (Role-Based Access Control) [14–16] and the Chinese Wall security policy [11]; we call this kind of data set a sensitive data set in this paper. The handling of the sensitive data set problem for cloud storage should be considered. Some work has been conducted on such data sets [17, 18]. However, for cloud storage, where the access control is realized via CP-ABE, there remains no such mechanism for effectively controlling a user’s successive access to data objects from a data owner’s sensitive data set to prevent commercial fraud, mistakes, or the leakage of critical information.
To handle the constraint for a sensitive data set stored in cloud storage that utilizes CP-ABE, we propose a CP-ABE access control scheme for sensitive data sets with a flexible, partially hidden constraint policy; in addition, the scheme retains the features of the hidden access control policy. In this work, first, we analyze the general characteristics and structures of the sensitive data set constraint and present a formal definition of it. Second, we utilize the concept of dummy attributes [19] for the data objects in the sensitive data set, and we also introduce a semitrusted constraint monitor that is responsible for keeping track of the user’s access to data objects from the sensitive data set using these dummy attributes. In our scheme, the constraint policies defined by the data owner are fully hidden from entities, except for the constraint monitor; the policies are partially hidden from the constraint monitor, and the access control policies are hidden from all entities.
The user’s previous successful access to data objects in a sensitive data set constraint may affect the user’s future access to other data objects in the same set. To handle the sensitive data set constraint, an entity in the system needs to know whether the user has the ability to decrypt the data objects in the sensitive data set without knowing any information about the access control policy of the data object. In addition, we choose the tree access structure with “AND,” “OR,” and “ OF ” gates. For the above reasons, we construct our scheme based on Hur’s promising scheme [8], but our emphasis is on the constraint.
The remainder of this paper is organized as follows. Section 2 explores the essential features of a sensitive data set constraint along with its structure. The assignment of dummy attributes for the sensitive data set constraint is introduced in Section 3. Section 4 provides the system architecture, assumptions, and requirements for our scheme. The formal specification of the CP-ABE access control scheme for the constraint is presented in Section 5. A detailed scheme construction is provided in Section 6. In Section 7, we discuss extra costs due to the enforcement of the constraint, in comparison with [8]. In Section 8, security, consistency, and accessibility analyses are given. In Section 9, we survey related works. Section 10 summarizes our work.
2. Sensitive Data Set Constraint
Some data objects released to the cloud storage may be characterized by certain correlations. The combination of such data objects may induce a conflict of interest; a user may easily derive highly sensitive or confidential data that are not supposed to be disclosed to any user from other legitimately accessed but otherwise insignificant data objects. Although the data owner is aware of the hazard posed by releasing such data objects to the cloud, he/she might accept the tradeoff of information protection for sharing his/her data. We first analyze the underlying relations among the data objects released by the data owner and present the formal definition of the sensitive data set constraint.
2.1. Implicit Data
, if all data objects from a data set are accessed by one user; then, these combined access instances are equivalent to accessing data by this user. is the minimal set that satisfies the above condition. We call implicit data [12].
If the implicit data are sensitive or confidential and are not supposed to be available to any user, then we should add constraints to a user’s successive access to these data objects to prevent the user’s derivation of the implicit data.
2.2. Structure
(a)Chinese Wall Structure. For the two disjoint data sets and , once a user accesses a data object from one data set, he/she should no longer be authorized to access any data object from another data set [11].(b) Structure. Denoted as , this structure requires that no user can access or more data objects from the data set . This implies that the combination of any or more data objects from is sensitive or induces a conflict of interest [13].
The Chinese Wall structure is equivalent to the structure if we set and use the concept of equivalence classes. For example, two disjoint data sets and have a Chinese Wall structure. If and , then we have or .
Based on the aforementioned analysis, we introduce a general and formal definition of the sensitive data set constraint.
Definition 1 (SDS constraint). Define ( , ),, as a sensitive data set (SDS) constraint if any user is forbidden from accessing data objects from or more different equivalence classes out of classes, and .
For an SDS constraint, we say that data objects from different equivalence classes are incompatible; on the contrary, we say that data objects from the same equivalence class are compatible. For example, for , if , , then and are incompatible; if , then and are compatible.
A data object can be under multiple SDS constraints. Assume that and are two SDS constraints; then, is allowed.
We also have an extra rule about SDS constraints.
Rule 1. Any two compatible data objects in an SDS constraint cannot be incompatible in any other SDS constraint and vice versa.
Let us consider an example. There is a database table of an organization; the table has columns , , , , , and . The data of column for each row is sensitive or confidential; however, it can be inferred from any three corresponding columns out of , , , or , , , . The organization releases this table to the cloud storage without column . If any user is authorized to access data of any three columns out of , , , or , , , , then he/she can infer the data of column despite the fact that he/she is not authorized to access the data of column [12]. So, the organization should specify an SDS constraint for this case, that is, .
3. SDS Constraint Specific Attributes
In CP-ABE, attributes play a key role in the enforcement of access control. Therefore, to handle the SDS constraint, additional SDS constraint specific attributes can be used. Because the additional attributes are only used to handle the SDS constraint and have no special meaning, we adopt dummy attributes [19] in our scheme.
If a data object is organized into an SDS constraint, then we need to upgrade the original access requirement for the data object. Because the data object is no longer independent, a user’s access to the data object may affect later access to other data objects under the same SDS constraint. We upgrade the original access requirements with dummy attributes. Below, we first discuss the assignment of dummy attributes for the SDS constraints.
Suppose thatis one of the SDS constraints for data owner . As shown in Figure 1, we use dummy artificial attributes , which are unique to . are used to distinguish between different equivalence classes. Therefore, corresponds to the data set in in this example. We assume that these attributes do not overlap with the same data owner’s other dummy attributes or with the normal attributes used in the whole system.
Consider a case in which a data object is organized into two different SDS constraints. If and , with , assume that the corresponding SDS constraint specific attributes for the two SDS constraints are and , respectively. If in and in , then and are both used to upgrade the access requirement for .
4. CP-ABE Access Control System Architecture for SDS Constraint
4.1. System Architecture and Assumptions
The system architecture is as shown in Figure 2. The entities in the system are described as follows.
Cloud Storage Server. The cloud storage server provides the data sharing service.
Data Owner. The data owner owns the data objects and releases them to the cloud storage server after encryption under his/her access control policies. Furthermore, he/she defines the SDS constraints based on Definition 1 and Rule 1.
User (Consumer). The user accesses encrypted data objects on the cloud storage server.
Key Generation Center (KGC). The KGC generates public and private keys for the system. It is assumed to be semitrusted. The KGC performs legitimate tasks assigned to it by other entities, but it may peek at the data owner’s data objects, access control policies, and constraint policies.
Proxy Server. The proxy server enforces access control for the data objects and performs partial decryption. It is assumed to be semitrusted. The proxy server performs legitimate tasks assigned to it by other entities, but it may peek at the data owner’s data objects, access control policies, and constraint policies. Another additional assumption about the proxy server is that it does not tamper with any component of the ciphertext of the data object.
SDS Monitor. The SDS monitor enforces the SDS constraint for the data objects. It is assumed to be semitrusted. The SDS monitor performs legitimate tasks assigned to it by other entities, but it may peek at the data owner’s data objects. Another critical assumption about the SDS monitor is that it will destroy the partially decrypted ciphertext if the user’s accessing of the corresponding data object is about to violate any SDS constraint.
4.2. Security, Privacy, Consistency, and Accessibility Requirements
Security. Data confidentiality and collusion resistance [3, 8] should be guaranteed. Moreover, as per our contribution, the SDS constraint in Definition 1 should also be guaranteed; accessing data objects should not cause a violation of any SDS constraint.
Policy Privacy. No entities have any information about the attributes of the access control policy. No entities, except for the SDS monitor, have any valuable information about the SDS constraint policy or its structure. The SDS monitor has limited information about the SDS constraint policy and its structure.
Consistency. Any two compatible data objects in an SDS constraint cannot be incompatible in any other SDS constraint and vice versa (Rule 1). The reason for the consistency requirement is simple: a user’s access to data objects in an SDS constraint may affect his/her subsequent access to other data objects that are incompatible with the initial data objects being accessed but will not affect his/her subsequent access to other data objects that are compatible with the initial data objects being accessed. Thus, we have the consistency requirement to support the SDS constraint policy.
Accessibility. A user whose valid attributes match the tree access structure of a data object can access the data object even if it is organized into an SDS constraint unless the access violates any SDS constraint. In contrast, a user whose valid attributes do not match the tree access structure of the data object still cannot access the data object after it is organized into an SDS constraint.
5. CP-ABE Access Control Scheme for SDS Constraint
5.1. Cryptographic Background
In this section, we specify the formal definition of the CP-ABE access control scheme for the SDS constraint. Our proposal is based on [8]. We briefly review the cryptographic background on the reason for the integrity of the content.
5.1.1. Attribute Access Structure
Definition 2 (attribute access structure). Let be a set of attributes. A collection is monotone if : if and , then . An attribute access structure (resp., monotone attribute access structure) is a collection (resp., monotone collection) of nonempty subsets of , that is, . We call the sets in the authorized sets of attributes, and the sets not in are the unauthorized sets of attributes.
The attribute access structure is a monotone access structure for all data objects regardless of whether they are in the SDS constraint.
Bilinear Pairings. and are two multiplicative cyclic groups of prime order . is a generator of , and is a bilinear map, . has the following properties:(i)Bilinearity: and , .(ii)Nondegeneracy: .(iii)Computability: computing the bilinear map is efficient.
Bilinear Diffie-Hellman (BDH) Assumption. Based on the aforementioned notations, given a generator of and elements , , for , the BDH problem is to find .
One-Way Anonymous Key Agreement. Kate et al. [20] proposed a one-way anonymous key agreement scheme and proved that it is secure in the random oracle model under the assumption that the BDH problem in is hard with respect to unconditional anonymity, session key secrecy, and impersonation.
5.2. CP-ABE Access Control Components for the SDS Constraint
The CP-ABE access control components for the SDS constraint are as follows:(i): the user set.(ii): original attributes.(iii): SDS constraint specific attributes for a user ; has different SDS constraints; can be different for different users.(iv): SDS constraint information for user ’s th SDS constraint.(v): historical SDS constraint specific attribute set; it is initially an empty set; when user successfully accesses data owner ’s data object under ’s th SDS constraint, then the SDS constraint specific attribute that corresponds to the equivalence class the accessed data object belongs to will be put into the set.(vi): all SDS constraint specific attributes in the system.(vii), all attributes in the system, .
5.3. CP-ABE Access Control Scheme for SDS Constraint
The access control scheme for the SDS constraint with the hidden access control policy and the constraint policy includes the algorithms below. In our scheme, we omit the access control process for data objects that are not under the SDS constraints, as it is the same as the process in Hur’s scheme [8].
Setup. , , . The KGC generates public parameters for the whole system. Then, the KGC, the proxy server, and the SDS monitor output their public key and master private key pairs , , and , respectively.
Key Generation. . The KGC takes and a set of attributes as input, and it outputs the private key for the user .
Data Encryption. . The data owner takes , , and and the tree access structure as parameters to encrypt the data object . The data owner outputs a ciphertext .
Token Generation. . The user takes and the set of attributes as input and outputs a token .
Partial Decryption(a)Proxy-Server-Side Partial Decryption. . The proxy server determines if matches the access control policy. If so, then the server partially decrypts and outputs for further partial decryption by the SDS monitor; otherwise, it returns .(b)SDS-Monitor-Side Partial Decryption. . The SDS monitor determines if the current data access violates any SDS constraint; if so, then is destroyed, and is returned; otherwise, the monitor takes as input and outputs for the user.
Data Decryption. . The user takes and as input and outputs data object if the decryption is successful.
6. Construction of CP-ABE Access Control Scheme for SDS Constraint
The construction of the scheme is partly based on Hur’s scheme [8]. However, we add the partially hidden, flexible SDS constraint policy to his scheme. To enforce the SDS constraint, the system must have the ability to determine if the user can successfully decrypt the data object before sending it to the user. This is because the user’s current and previous successful access to data objects under an SDS constraint may affect the user’s future access to other data objects under the same SDS constraint. In [8], the storage server happened to have the desired ability without having any knowledge about the attributes in the access structure. Therefore, Hur’s work comes in handy here. The access tree specification and satisfying the access tree are the same as in [3]; we thus omit them here.
6.1. CP-ABE Access Control Scheme Construction for the SDS Constraint
Let be a bilinear group of prime order , and let be the generator of . In addition, let denote the bilinear map. A security parameter, , will determine the size of the groups. We use two hash functions, and , which we will model as a random oracle. For the Lagrange coefficients for any and a set, , of elements in , we define .
Setup. The KGC, proxy server, and SDS monitor produce their public and master private key pairs.
The KGC chooses of prime order , where is its generator. The KGC chooses , and the following public parameters: .
The KGC chooses two random exponents , ; then, the public and private keys for the KGC are and , respectively.
The proxy server chooses a random exponent ; then, the public and private keys for the proxy server are and , respectively.
The SDS monitor chooses a random exponent ; then, the public and private keys for the SDS monitor are and , respectively.
Key Generation. The KGC produces private keys for users by running the algorithm. The algorithm takes as input and and outputs a private key for a user that holds all attributes in . The KGC selects two random exponents and , where is a unique secret to user and is a unique secret to attribute . Then, the KGC generates the following private key for the user:
Data Encryption. Suppose that a data owner has different SDS constraints, , where the corresponding dummy attributes are . For an SDS, the data owner selects a random and then computes . These computations can be completed beforehand. The data owner only releases the SDS constraint information , to the cloud storage server.
Suppose that the data owner wants to release his/her data object to the cloud storage server, , where . Before releasing the data object, encrypts the data object under an access tree defined by him/her by running the algorithm. The algorithm first chooses a polynomial for each node , including the leaves, in the tree . For additional details, see the definition of access trees in [3].
Let be the set of leaf nodes in . The data owner computes for all in the leaf node of the access tree and then computes .
To encrypt the data object under , the data owner computes a session key between the data owner and the proxy server as well as the session key between the data owner and the SDS monitor . Then, the algorithm constructs a ciphertext as
The data owner sends to the proxy server.
Token Generation. When a user sends an access request for a data object, where the data object’s owner is , to the proxy server using a set of attributes , where is the set of all valid attributes held, user obtains from the proxy server first. Then, he/she generates a token by running the algorithm.
For all , the algorithm computes . Then, the algorithm selects a random and constructs the token for as
If , then the algorithm outputs .
Next, user sends the token to the proxy server and a request for the partial decryption of the ciphertext with this token. Tokens can also be precomputed.
Partial Decryption
(a) Proxy-Server-Side Partial Decryption. After receiving the token from the user, the proxy server determines whether the set of attribute indices in the token matches the blinded access control policy embedded in . If the token matches the access control policy of the data object, then it partially decrypts the ciphertext by running the algorithm for user .
The algorithm operates in a recursive manner. We first define a recursive algorithm that takes as input a ciphertext , a token , which is associated with a set of attributes , and a node from the tree . The algorithm outputs a group element of or .
Suppose that the proxy server runs the algorithm with a token provided by a user . Suppose that an attribute assigned to a leaf node is blinded as . Then, make the following definition: If , where is a set of all attribute indices associated with the token, then
If , define .
Now, consider the recursive case in which is a nonleaf node. The algorithm is executed as follows: For all nodes that are children of , the algorithm calls and stores the output as . Let be an arbitrary -sized set of child nodes such that ; then, the algorithm computesand returns the result.
The algorithm begins by calling the function on the root node of the access tree . If the access tree is satisfied by the token associated with the set of attributes , then the proxy server extracts .
The proxy server computes and in ; then, it sends to the SDS monitor, where
(b) SDS-Monitor-Side Partial Decryption. After receiving from the proxy server, the SDS monitor determines if the current data access violates any SDS constraint defined by the data owner. If so, the SDS monitor destroys and returns , and the user’s access request will be denied. Otherwise, the SDS monitor takes as input and outputs for the user by running the algorithm.
Now, we give the determination process in detail. The SDS monitor precomputes all , after computing , for ; and it compares in to these precomputed dummy attribute indices . By comparison, it finds out that and determines the SDS constraint information , and the threshold should be applied to the current data. According to the threshold value , the SDS monitor checks if , and then it determines whether the current data access violates SDS constraint and destroys the data immediately; otherwise, the SDS monitor performs its partial decryption. The SDS monitor first computes and then computes .
Next, the SDS monitor updates the historical SDS constraint specific attribute set as and sends to the user.
Data Decryption. When user receives the ciphertext from the SDS monitor, he/she uses the algorithm to decrypt the ciphertext by computing
6.2. A Case Study
We illustrate through an example how the SDS monitor checks whether the current data access violates any SDS constraint. Suppose a data owner Alice released three data objects , , and and defined th SDS constraint over them; that is, . The corresponding SDS constraint information is released to the cloud storage server. and are the two dummy attributes corresponding to and , respectively. Suppose a user Bob’s attributes match the access structures of data objects and . When Bob sends an access request for , the proxy server uses Bob’s token to partially decrypt the following ciphertext: where is the tree access structure of and is the set of leaf nodes in .
Since Bob’s attributes match , then the partial decryption by the proxy server will be successful. The proxy server knows that is under an SDS constraint because there is in the ciphertext, and then it transfers the ciphertext to the SDS monitor. When the SDS monitor receives the partially decrypted ciphertext from the proxy server, it compares in the ciphertext to the precomputed values , where , for , and then it gets . Therefore, the SDS monitor determines that is the SDS constraint information applied to the data . The SDS monitor checks if . Since , we have Therefore, the SDS monitor knows that the current access to does not violate . After that, it updates as and then sends to Bob. Bob successfully accesses .
When Bob sends another access request for , the proxy server uses Bob’s token to partially decrypt the following ciphertext: where is the tree access structure of and is the set of leaf nodes in .
Since Bob’s attributes match , then the partial decryption by the proxy server will be successful. The proxy server knows that the ciphertext is under an SDS constraint because there is , and then it transfers the ciphertext to the SDS monitor. When the SDS monitor receives the partially decrypted ciphertext from the proxy server, it compares in the ciphertext to the precomputed values , where , for , and then it gets . Therefore, the SDS monitor determines that is also the SDS constraint information applied to the data . The SDS monitor checks if . Now, we have so the SDS monitor knows that the current access to violates . It destroys the corresponding ciphertext immediately. Bob cannot access .
7. Extra Costs due to the SDS Constraint and Comparison
We discuss the additional costs due to the enforcement of the SDS constraint, in comparison with [8]. We also compare our scheme with [9, 10]. We use notations in the Notations Section.
In Table 1, we compare the user’s private key size, ciphertext size, public key size, and computational cost used in the whole system with those in [8–10]. Compared to [8], the user’s private key size is the same, the ciphertext size is increased by the bit size of an element in because is embedded into it, and the public key size is increased by the bit size of an element in because is used as one of the public keys in the system.
In addition, we have the additional dummy attributes for a data owner who has different SDS constraints. However, the obfuscation of these dummy attributes by the data owner and the computation of the attribute indices of these dummy attributes by the SDS monitor can be performed beforehand.
Compared to [8–10], our scheme has an extra network communication cost per data object if the data object is under an SDS constraint. The proxy server sends the partially decrypted ciphertext to the SDS monitor, and the SDS monitor sends the further partially decrypted ciphertext to the user.
8. Security, Consistency, and Accessibility Analysis
The security, policy privacy, consistency, and accessibility analyses are presented in this section with respect to the requirements enumerated in Section 4.2.
8.1. Security
Data Confidentiality. For data objects that are not under any SDS constraint, confidentiality is guaranteed because we follow [8] for these data objects. The SDS monitor can just be regarded as an external user who does not have sufficient attributes.
Considering data objects that are under the SDS constraints, we introduced the following concepts: the SDS monitor, the SDS constraint specific dummy attributes, and additional partial decryption by the SDS monitor. Therefore, we mainly analyze the effect of the corresponding changes regarding the data confidentiality.
An external user whose attributes do not match the tree access structure in the ciphertext cannot produce a valid token for partial decryption. This results in the fact that the proxy server cannot extract the expected value with the invalid token without knowing and , which are unique secrets to the user.
Assuming that the unauthorized user directly fetches the ciphertext from the cloud storage server without using the token, he/she cannot compute because his/her attributes do not match the access tree. Moreover, he/she cannot cast off the session keys and embedded in the ciphertext component because is only shared by the data owner and the proxy server, and is only shared by the data owner and the SDS monitor.
The proxy server, similar to other external unauthorized users, not only does not have sufficient attributes to decrypt the ciphertext but also cannot cast off embedded in the ciphertext component because is only shared by the data owner and the SDS monitor.
The KGC cannot decrypt the ciphertext because the session keys and are embedded in the ciphertext component . In addition, is shared only by the data owner and the proxy server, and is shared only by the data owner and the SDS monitor. The KGC cannot determine and because of the session key secrecy property of the key agreement [20]. Assuming that the KGC can access the partially decrypted ciphertext , where from the proxy server, it still cannot cast off because is only shared by the data owner and the SDS monitor. Moreover, the KGC cannot cast off from to obtain the expected value because is a unique secret to the user.
The SDS monitor cannot decrypt the ciphertext for two reasons. First, it cannot cast off from to obtain the expected value because is a unique secret to the user. Second, the SDS monitor does not know , , or to obtain the expected value because and are private keys of the KGC and because is a unique secret to the user.
In addition, the SDS constraint specific dummy attributes themselves do not disclose any information about the content of the data object because they are completely independent of the content of the data object.
Collusion Resistance. For both ordinary data objects and the data objects that are under the SDS constraints, collusion resistance is guaranteed. The ciphertext component is different from that in Hur’s scheme for the data that are under an SDS constraint, but this does not affect collusion resistance. The random value , which is unique to each user in the users’ private keys, prevents several users from combining their private keys to produce a token to decrypt the ciphertext unless one of the users has sufficient valid attributes to produce a token to achieve .
SDS Constraint. The data object that is under an SDS constraint must pass through the SDS constraint checkpoint, the SDS monitor, because the session key is embedded in the ciphertext component . Neither the proxy server, the KGC, nor the user can cast off because is only shared by the data owner and the SDS monitor. When the SDS monitor receives the partially decrypted ciphertext from the proxy server, the SDS monitor checks if the user’s current data access violates an SDS constraint by comparing in the ciphertext to the precomputed values , where , for , and it checks if . If the SDS monitor determines that the current data access violates an SDS constraint, the SDS monitor destroys the data immediately. We consider that the duty of access control policy enforcement and the duty of SDS constraint policy enforcement should be separated into two different entities. Therefore, we add an SDS monitor to the system architecture instead of only using the proxy server to perform both duties. Performing this separation follows the access control principle of separation of duty.
8.2. Policy Privacy
Access Control Policy Privacy. For both ordinary data object and the data objects that are under the SDS constraint, access control policy privacy is guaranteed because we follow Hur’s scheme [8]. We omit the description here.
Constraint Policy Privacy. First, when the data owner only releases the SDS constraint information to the cloud storage server, he/she does not disclose any information about which dummy attributes are used for which data object. Initially, other entities only have knowledge that are used for SDS constraint and nothing else.
If the user receives the partially decrypted ciphertext from the SDS monitor, and not from the proxy server, then he/she only knows that the current data object is under an SDS constraint. The user does not know to which SDS constraint the data object belongs; the relations among this data object and other data objects received from the SDS monitor previously are also unknown to him/her.
The KGC and the proxy server know that the ciphertext is under an SDS constraint if there is a ciphertext component . If they observe that several ciphertexts that belong to a data owner have the same , then they only know that the corresponding data objects belong to the same equivalence class in an SDS; this does not pose a security threat. However, they still do not know other structure information of an SDS constraint, including the threshold , and other data objects that are in a different equivalence class of the same SDS constraint.
The SDS monitor can observe the relations among the ciphertexts but does not know the entire SDS structure exactly. For example, it does not know how many data objects are contained in the same equivalence class. The total number of equivalence classes can vary over time as the number of corresponding dummy attributes varies. However, the SDS monitor is responsible for enforcing the SDS constraint; therefore, the SDS monitor is the entity that possesses the most knowledge about the SDS constraint structure; this situation is indispensable.
8.3. Consistency
Any two compatible data objects under an SDS constraint cannot be incompatible under any other SDS constraint and vice versa. The data owner is required to define consistent SDS constraints. This can be achieved as follows. For each data object , we maintain its global current incompatible set . If the data owner needs to add a new SDS constraint or add new data objects into an existing SDS constraint that includes the data object , then he/she should ensure that data objects from are not put into . The details on how to maintain SDS constraint consistency are beyond the scope of this paper. However, if we cannot guarantee this consistency, this may result in a violation of both security and accessibility requirements.
8.4. Accessibility
A user whose valid attributes match the tree access structure of a data object can access the data object even if it is organized into an SDS constraint, unless the data access violates an SDS constraint. Access control policy enforcement is implemented by the proxy server using the user’s token, which is associated with the user’s valid attributes; thus, the proxy server can partially decrypt the ciphertext if the user has the valid attributes. The partially decrypted ciphertext must pass through the SDS monitor to enforce the SDS constraint. If the current data access does not violate the SDS constraint, then the SDS monitor also partially decrypts the ciphertext to send it to the user for full decryption; otherwise, the SDS monitor destroys it, and the user cannot receive the partially decrypted ciphertext. Therefore, this requirement is guaranteed to be met.
In contrast, a user whose valid attributes do not match the tree access structure of a data object still cannot access the data object after it is organized into an SDS constraint. Access control policy enforcement is performed first by the proxy server using the user’s token, which is associated with the user’s valid attributes. Therefore, the proxy server cannot partially decrypt the ciphertext if the user does not possess valid attributes. In that case, the proxy server does not pass the ciphertext to either the SDS monitor or the user; the user thus cannot access the data object. Therefore, this requirement is guaranteed to be met.
9. Related Work
There are quite a few research works on the formal specification of access control constraints [13, 16, 17, 21–24]. Crampton [16] analyzed and classified RBAC constraints in detail. In our previous works [13, 24], we proposed general access control constraints against similar users’ successive access to permissions from a sensitive combination of permissions. Joshi et al. [21] presented the formal specification of RBAC constraints, therein considering time and location in access control decision-making. Sharifi and Tripunitara [17] proposed an approach for enforcing the Chinese Wall security policy in a least-restrictive manner compared to Brewer and Nash’s specification [11]. Bijon et al. [23] first introduced ABCL (Attribute-Based Constraint Specification Language) to specify constraints in ABAC (Attribute-Based Access Control), which supports the SOD of RBAC. In contrast to these works, we intended to generalize access control constraints for data released to a cloud storage server, on which the promising CP-ABE access control mechanism is utilized; we handled the constraint in a less-restrictive manner based on accessibility requirements. Our proposal coincides as much as possible with the CP-ABE access control paradigm. The SDS constraint proposed in this paper is a compact and generalized constraint that mostly covers the SOD constraint and Chinese Wall security policy. However, we did not consider write actions on the data by the user (consumer); the main action described in this paper is the read action.
In data outsourcing environments, access control is supported by cryptographic methods [25–29]. Di Vimercati et al. [25, 26] introduced a novel approach that combines cryptography with access control. Data are placed with an honest but curious third party; therefore, their approach adopted a two-layer encryption method; the first layer of encryption is performed by the data owner, as the server is not fully trusted, and the server performs the second layer of encryption to reflect dynamic changes over the access control policy. Asghar et al. used RBAC policies for outsourced environments [28]. In their work, the actual RBAC policy is hidden via encryption from the service provider, as the service provider is honest but curious. The PDP (Policy Decision Point) can perform the policy evaluation without disclosing the contents of the requests or policies to the service provider. However, [25–28] did not consider access control constraints. Compared to [25–28], our emphasis is placed on the generalization and enforcement of access control constraints, which covers most of static SOD and Chinese Wall security policies, on outsourced data released to the cloud with the objective of achieving better synergy with the CP-ABE access control mechanism.
The privacy of the access control policy defined for the outsourced data, where CP-ABE realizes the access control, is also a nontrivial issue. Researchers have been focusing on hiding access control policies from outsiders [6–10]. Yu et al. [6] and Nishide et al. [7] proposed CP-ABE schemes with a hidden access control policy. Their schemes only used “AND” gates, which restrains the expressiveness of the policy; the key size of each user is proportional to the number of attributes. In Nishide et al.’s second scheme [7], new possible values for attributes can be added after system setup. Hur’s work [8] is also a variant of CP-ABE with a hidden access control policy. In his work, the computation-intensive work, the partial decryption of the ciphertext, is completed by the storage center; the access control policy has the same expressiveness as in Bethencourt et al.’s work [3]. The main reason why we extend Hur’s scheme is because the handling of the SDS constraint in our approach needs an entity, aside from the data owner, to determine if the user’s attributes satisfy the access control policy of the data object before sending the data object to the user without knowing the policy; in Hur’s scheme, the storage center possesses the desired ability. Lai et al. [9, 10] proposed CP-ABE with a partially hidden access policy. In their work, the attributes have two parts: the attribute name and the attribute value. The data owner hides the attribute value, and thus the access policy is partially hidden. Their schemes are fully secure in the standard model. Compared to these works, we followed CP-ABE with the hidden access control policy; however, our emphasis focused on how to handle the SDS constraint, where the SDS constraint policy structure is hidden from all entities except for the SDS monitor. The constraint policy structure is partially hidden from the SDS monitor.
Asghar et al. [29] proposed a cryptographic approach for enforcing the dynamic SOD and Chinese Wall security policy. Their proposal hides users’ access histories with respect to dynamic SOD via encryption because a user’s access history might reveal critical information to the service provider, who is not fully trusted. They utilized Bethencourt et al.’s [3] access structure to describe the access control constraint. Their work is on hiding conventional constraints. Compared to their work, our work is suitable for outsourced data access control realized by CP-ABE with a hidden access control policy. In our work, the constraint policy related attributes are blinded and embedded in the ciphertext; most of the computations related to the constraint policy can be precomputed, and the SDS constraint policy can be partially changed after system setup. We can easily extend our scheme by adding a time duration to transform the SDS constraint into a time-aware dynamic constraint.
10. Conclusion
In this paper, we proposed an access control approach for generalized SDS constraints for cloud storage; the constraint originated from the SOD of RBAC and the Chinese Wall security policy. Our approach is based on CP-ABE with a hidden access control policy. We handled the SDS constraint using additional artificial attributes through the participation of an additional entity: the SDS monitor. To enforce the SDS constraint, a session key, established between the data owner and the SDS monitor, is embedded in the ciphertext component to force the proxy server to pass the initial partially decrypted ciphertext to the SDS monitor to perform the second partial decryption. The SDS constraint policy structure is hidden from the KGC, the proxy server, and the user. To prevent commercial fraud or mistakes, the duties of enforcing both the access control policy and the constraint policy are divided between the proxy server and the SDS monitor. The security, policy privacy, consistency, and accessibility analyses indicated that the approach is secure and effective. The SDS constraint policy is also extensible in that the data owner puts more data objects into the equivalence classes of an SDS constraint after system setup; the data owner can increase the total number of equivalence classes and the threshold in an SDS constraint at a lower cost following system setup. To our knowledge, the generalized concept of SDS constraints and their structure as well as the use of dummy attributes to enforce a partially hidden constraint policy represents the novelty of our work.
As our future work, we will consider how to fully hide the constraint policy structure from all entities, especially from the SDS monitor, without affecting the enforcement of the SDS constraint. To improve the expressiveness of the SDS constraint, we will also consider using “AND,” “OR,” and “ OF ” in the SDS constraint.
Notations
| : | Bit-length of element in |
| : | Bit-length of element in |
| : | The number of attributes associated with the ciphertext |
| : | The number of attributes associated with the private key of a user |
| : | The size of original attribute universe |
| : | The total number of possible values of all attributes |
| : | The number of user’s attributes satisfying an access structure |
| : | The number of rows in LSSS matrix |
| : | Exponentiation in group operation |
| : | Bilinear pairing. |
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
The authors would like to thank Professor David Du at the Department of Computer Science and Engineering, University of Minnesota, for providing the necessary support to conduct the research and also for providing valuable suggestions. This research work was supported by the National Natural Science Foundation of China (Grants nos. 61562085, 11261057, and 11461069).