CP-ABE Access Control Scheme for Sensitive Data Set Constraint with Hidden Access Policy and Constraint Policy

,


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][3][4][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][7][8][9][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)  company A and  company B to the cloud, to which the Chinese Wall security policy [11] should be applied, as company A and company B 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][15][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.

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.
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.

Structure
(a) Chinese Wall Structure.For the two disjoint data sets { 1 ,  2 , . . .,   } and {  1 ,   2 , . . .,    }, 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].
The Chinese Wall structure is equivalent to the (, ) structure if we set (, ) = (2, 2) and use the concept of equivalence classes.For example, two disjoint data sets { 1 } and { 2 ,  3 } have a Chinese Wall structure.If 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  , , 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, ({{  }, {  }, {  1 ,   2 }, {  }}, #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 that

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.

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.

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.
We call the sets in A the authorized sets of attributes, and the sets not in A 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.G 0 and G 1 are two multiplicative cyclic groups of prime order . is a generator of G 0 , and  is a bilinear map,  : G 0 ×G 0 → G 1 . has the following properties: (ii) Nondegeneracy: (, ) ̸ = 1.
(iii) Computability: computing the bilinear map  : Bilinear Diffie-Hellman (BDH) Assumption.Based on the aforementioned notations, given a generator  of G 0 and elements   ,   ,   for , ,  ∈ Z *  , 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 ⟨, G 0 , G 1 , ⟩ is hard with respect to unconditional anonymity, session key secrecy, and impersonation.(v) H Attr(  , SDS ()  ): 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.

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].

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.

CP-ABE Access Control Scheme Construction for the SDS
Constraint.Let G 0 be a bilinear group of prime order , and let  be the generator of G 0 .In addition, let  : G 0 × G 0 → G 1 denote the bilinear map.A security parameter, , will determine the size of the groups.We use two hash functions,  : {0, 1} * → G 0 and  1 : G 1 → {0, 1} log  , which we will model as a random oracle.For the Lagrange coefficients Δ , for any  ∈ Z *  and a set, , of elements in Z *  , we define Δ , () = ∏ ∈, ̸ = (( − )/( − )).
The proxy server chooses a random exponent  ∈  Z *  ; then, the public and private keys for the proxy server are PK  =   and MK  = (ID  )  , respectively.
The SDS monitor chooses a random exponent  ∈  Z *  ; then, the public and private keys for the SDS monitor are PK SDS =   and MK SDS = (ID SDS )  , respectively.Key Generation.The KGC produces private keys for users by running the KeyGen(MK KGC , ) algorithm.The algorithm takes as input MK KGC and  and outputs a private key for a user that holds all attributes in .The KGC selects two random exponents   ∈  Z *  and   ∈  Z *  , 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: Before releasing the data object,   encrypts the data object under an access tree T defined by him/her by running the Encrypt(PK KGC , PK  , PK SDS , , T) algorithm.The algorithm first chooses a polynomial   for each node , including the leaves, in the tree T. For additional details, see the definition of access trees in [3].
Let  be the set of leaf nodes in T. The data owner computes   = ((  )  , (  )) for all  ∈  in the leaf node of the access tree and then computes  1 (  ).
To encrypt the data object  under T, the data owner computes a session key between the data owner and the proxy server   = ((  )  , (ID  )) as well as the session key between the data owner and the SDS monitor  SDS = ((  )  , (ID SDS )).Then, the algorithm constructs a ciphertext as The data owner   sends (ID  ,   , CT) 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 TK   ,  by running the GenToken(SK   ,   ) algorithm.For all   ∈   , the algorithm computes   = (  ,    ) = (  , (  )  ).Then, the algorithm selects a random  ∈  Z *  and constructs the token for   as TK   ,  = (∀  ∈   :   =  1 (  ) , (  ) , (   )  ) .(4) 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 CT.If the token matches the access control policy of the data object, then it partially decrypts the ciphertext by running the PartDecrypt(CT, TK   ,  ) algorithm for user   .
The PartDecrypt(CT, TK   ,  ) algorithm operates in a recursive manner.We first define a recursive algorithm DecryptNote(CT, TK, ) that takes as input a ciphertext CT, a token TK, which is associated with a set of attributes   , and a node  from the tree T. The algorithm outputs a group element of G 1 or ⊥.
Suppose that the proxy server runs the algorithm with a token TK   ,  provided by a user   .Suppose that an attribute assigned to a leaf node  is blinded as  1 (  ).Then, make the following definition: If  1 (  ) ∈ I, where I is a set of all attribute indices   associated with the token, then If  1 (  ) ∉ I, define DecryptNote(CT, TK, ) = ⊥.Now, consider the recursive case in which  is a nonleaf node.The DecryptNote(CT, TK   ,  , ) algorithm is executed as follows: For all nodes  that are children of , the algorithm calls DecryptNote(CT, TK   ,  , ) and stores the output as   .Let   be an arbitrary   -sized set of child nodes  such that   ̸ = ⊥; then, the algorithm computes =  (, ) and returns the result.The algorithm begins by calling the function on the root node  of the access tree T. If the access tree is satisfied by the token associated with the set of attributes   , then the proxy server extracts DecryptNote(CT, TK   ,  , ) = (, )    .
Next, the SDS monitor updates the historical SDS constraint specific attribute set as H Attr(  , SDS ()   ) = H Attr(  , SDS ()   ) ∪ { , } and sends CT  = ( C ,  = ℎ  , ) to the user.Data Decryption.When user   receives the ciphertext CT  from the SDS monitor, he/she uses the Decrypt(CT  , SK   ,  ) algorithm to decrypt the ciphertext by computing C ( (, ) / ()  [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 tree.Moreover, he/she cannot cast off the session keys   and  SDS embedded in the ciphertext component C =  ⋅   ⋅  SDS ⋅ (, )  because   is only shared by the data owner and the proxy server, and  SDS 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  SDS embedded in the ciphertext component C =  ⋅   ⋅  SDS ⋅ (, )  because  SDS is only shared by the data owner and the SDS monitor.
The KGC cannot decrypt the ciphertext because the session keys   and  SDS are embedded in the ciphertext component C =  ⋅   ⋅  SDS ⋅ (, )  .In addition,   is shared only by the data owner and the proxy server, and  SDS is shared only by the data owner and the SDS monitor.The KGC cannot determine   and  SDS because of the session key secrecy property of the key agreement [20].Assuming that the KGC can access the partially decrypted ciphertext CT  = ( C ,  = ℎ  , ,  1 (  , )), where C = C/  =  ⋅  SDS ⋅ (, )  from the proxy server, it still cannot cast off  SDS because  SDS 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 C =  ⋅   ⋅  SDS ⋅ (, )  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  SDS is embedded in the ciphertext component C =  ⋅   ⋅  SDS ⋅ (, )  .Neither the proxy server, the KGC, nor the user can cast off  SDS because  SDS 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  1 (  , ) in the ciphertext to the precomputed values Θ , =  1 (  , ),  = 1, 2, . . .,   ,  = 1, 2, . . ., , where   , = (  , ( , )  ),  = 1, 2, . . .,   ,  = 1, 2, . . ., , for SDS INFO ()  = { ()  ,1 ,  () ,2 , . . .,  () ,  ,   } 1≤≤ , and it checks if |H Attr(  , SDS (  )  ) ∪ { , }| =   .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 Security and Communication Networks 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.

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 { ,1 ,  ,2 , . ..,  ,  ,   } 1≤≤ 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 { ,1 ,  ,2 , . . .,  ,  ,   } 1≤≤ 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  1 (  , ).If they observe that several ciphertexts that belong to a data owner have the same  1 (  , ), 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.

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  = {  | ∃SDS, ,   ∈ SDS ∧   ∉ []}.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.

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.

Related Work
There are quite a few research works on the formal specification of access control constraints [13,16,17,[21][22][23][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][26][27][28][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][26][27][28] did not consider access control constraints.Compared to [25][26][27][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][7][8][9][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.

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.

Figure 1 :Figure 2 :
Figure 1: Dummy attributes corresponding to the data objects in an SDS constraint.

𝐿 0 :
Bit-length of element in G 0  1 : Bit-length of element in G 1 : 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 exp: Exponentiation in group operation ê: Bilinearpairing.
Let us consider anexample.There is a database table of an organization; the table has columns , ,  1 ,  2 , , and .The data of column  for each row is sensitive or confidential; however, it can be inferred from any three corresponding columns out of , ,  1 ,  or , ,  2 , .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 , ,  1 ,  or , , 2 1,2 , . . .,  1, 1 } , { 2,1 ,  2,2 , . . .,  2, 2 } , . . ., { ,1 ,  ,2 , . . .,  ,  }} , (attribute access structure).Let { 1 ,  2 , . . .,   } be a set of attributes.A collection A ⊆ 2 { 1 , 2 ,...,  } is monotone if ∀, : if  ∈ A and  ⊆ , then  ∈ A. An attribute access structure (resp., monotone attribute access structure) is a collection (resp., monotone collection) A of nonempty subsets of { 1 ,  2 Token Generation.GenToken(SK  ,   ) → TK   , .The user  takes SK  and the set of attributes   ⊆  as input and outputs a token TK   , .TK   , ) → CT  .The proxy server determines if   matches the access control policy.If so, then the server partially decrypts CT and outputs CT  for further partial decryption by the SDS monitor; otherwise, it returns ⊥.SDSPartDecrypt(CT  ) → CT  .The SDS monitor determines if the current data access violates any SDS constraint; if so, then CT  is destroyed, and ⊥ is returned; otherwise, the monitor takes CT  as input and outputs CT  for the user.Security and Communication Networks Data Decryption.Decrypt(CT  , SK  ) → .The user takes CT  and SK  as input and outputs data object  if the decryption is successful.
PK  , MK  ), (PK SDS , MK SDS ).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 (PK KGC , MK KGC ), (PK  , MK  ), and (PK SDS , MK SDS ), respectively.Key Generation.KeyGen(MK KGC , ) → SK  .The KGC takes MK KGC and a set of attributes  ∈ 2 O ATTR \ {0} as input, and it outputs the private key SK  for the user .Data Encryption.Encrypt(PK KGC , PK  , PK SDS , , T) → CT.The data owner takes PK KGC , PK  , and PK SDS and the tree access structure T as parameters to encrypt the data object .The data owner outputs a ciphertext CT.

Table 1 :
Comparison of different schemes.
= .(8)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  1 ,  2 , and  3 and defined th SDS constraint