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

Authors: Nurmamat Helil; Kaysar Rahman
Journal: Security and Communication Networks
 (2017)

---

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


---

## Body

## 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)Mcompany_A and Mcompany_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 k data out of n 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 “k OF n” 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. Section2 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

∃
M
′
∉
{
M
1
,
M
2
,
…
,
M
n
}, if all data objects from a data set {M1,M2,…,Mn} are accessed by one user; then, these combined access instances are equivalent to accessing data M′ by this user. {M1,M2,…,Mn} is the minimal set that satisfies the above condition. We call M′ 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 {M1,M2,…,Ms} and {M1′,M2′,…,Mt′}, 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)
(
n
,
k
)
Structure. Denoted as ({M1,M2,…,Mn},#k),2≤k≤n, this structure requires that no user can access k or more data objects from the data set {M1,M2,…,Mn}. This implies that the combination of any k or more data objects from {M1,M2,…,Mn} is sensitive or induces a conflict of interest [13].The Chinese Wall structure is equivalent to the(n,k) structure if we set (n,k)=(2,2) and use the concept of equivalence classes. For example, two disjoint data sets {M1} and {M2,M3} have a Chinese Wall structure. If [M1]={M1} and [M2]=[M3]={M2,M3}, then we have ({[M1],[M2]},#2) or ({[M1],[M3]},#2).Based on the aforementioned analysis, we introduce a general and formal definition of the sensitive data set constraint.Definition 1 (SDS constraint).
Define ({[M1],[M2],… , [Mn]},#k),2≤k≤n, as a sensitive data set (SDS) constraint if any user is forbidden from accessing data objects from k or more different equivalence classes out of n classes, and Mi∩Mj=∅,0≤i,j≤n,i≠j.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({[M1],[M2],…,[Mn]},#k),2≤k≤n,∀M1′,M2′, if M1′∈[Mi], M2′∈[Mj],i≠j, then M1′ and M2′ are incompatible; if M1′,M2′∈[Mi], then M1′ and M2′ are compatible.A data object can be under multiple SDS constraints. Assume that({[M1],[M2],…,[Ms]},#k1) and ({[M1′],[M2′],…,[Mt′]},#k2) are two SDS constraints; then, (⋃i=1s[Mi])∩(⋃j=1t[Mj′])≠∅ 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 columnsA, B, C1, C2, D, and E. The data of column E for each row is sensitive or confidential; however, it can be inferred from any three corresponding columns out of A, B, C1, D or A, B, C2, D. The organization releases this table to the cloud storage without column E. If any user is authorized to access data of any three columns out of A, B, C1, D or A, B, C2, D, then he/she can infer the data of column E despite the fact that he/she is not authorized to access the data of column E [12]. So, the organization should specify an SDS constraint for this case, that is, ({{MA},{MB},{MC1,MC2},{MD}},#3).


## 2.1. Implicit Data

∃
M
′
∉
{
M
1
,
M
2
,
…
,
M
n
}, if all data objects from a data set {M1,M2,…,Mn} are accessed by one user; then, these combined access instances are equivalent to accessing data M′ by this user. {M1,M2,…,Mn} is the minimal set that satisfies the above condition. We call M′ 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 {M1,M2,…,Ms} and {M1′,M2′,…,Mt′}, 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)
(
n
,
k
)
Structure. Denoted as ({M1,M2,…,Mn},#k),2≤k≤n, this structure requires that no user can access k or more data objects from the data set {M1,M2,…,Mn}. This implies that the combination of any k or more data objects from {M1,M2,…,Mn} is sensitive or induces a conflict of interest [13].The Chinese Wall structure is equivalent to the(n,k) structure if we set (n,k)=(2,2) and use the concept of equivalence classes. For example, two disjoint data sets {M1} and {M2,M3} have a Chinese Wall structure. If [M1]={M1} and [M2]=[M3]={M2,M3}, then we have ({[M1],[M2]},#2) or ({[M1],[M3]},#2).Based on the aforementioned analysis, we introduce a general and formal definition of the sensitive data set constraint.Definition 1 (SDS constraint).
Define ({[M1],[M2],… , [Mn]},#k),2≤k≤n, as a sensitive data set (SDS) constraint if any user is forbidden from accessing data objects from k or more different equivalence classes out of n classes, and Mi∩Mj=∅,0≤i,j≤n,i≠j.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({[M1],[M2],…,[Mn]},#k),2≤k≤n,∀M1′,M2′, if M1′∈[Mi], M2′∈[Mj],i≠j, then M1′ and M2′ are incompatible; if M1′,M2′∈[Mi], then M1′ and M2′ are compatible.A data object can be under multiple SDS constraints. Assume that({[M1],[M2],…,[Ms]},#k1) and ({[M1′],[M2′],…,[Mt′]},#k2) are two SDS constraints; then, (⋃i=1s[Mi])∩(⋃j=1t[Mj′])≠∅ 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 columnsA, B, C1, C2, D, and E. The data of column E for each row is sensitive or confidential; however, it can be inferred from any three corresponding columns out of A, B, C1, D or A, B, C2, D. The organization releases this table to the cloud storage without column E. If any user is authorized to access data of any three columns out of A, B, C1, D or A, B, C2, D, then he/she can infer the data of column E despite the fact that he/she is not authorized to access the data of column E [12]. So, the organization should specify an SDS constraint for this case, that is, ({{MA},{MB},{MC1,MC2},{MD}},#3).


## 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(1)SDSia=M1,1,M1,2,…,M1,n1,M2,1,M2,2,…,M2,n2,…,Ml,1,Ml,2,…,Ml,nl,#kis one of the SDS constraints for data owner ua. As shown in Figure 1, we use l dummy artificial attributes θi,1(a),θi,2(a),…,θi,l(a), which are unique to SDSi(a). θi,1(a),θi,2(a),…,θi,l(a) are used to distinguish between different equivalence classes. Therefore, θi,j(a) corresponds to the data set {Mj,1,Mj,2,…,Mj,nj} in SDSi(a) 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.Figure 1
Dummy attributes corresponding to the data objects in an SDS constraint.Consider a case in which a data object is organized into two different SDS constraints. IfSDSi1(a)=({[M1],[M2],…,[Ml1]},#k1) and SDSi2(a)=({[M1′],[M2′],…,[Ml2′]},#k2), with M∈(⋃t=1l1[Mt])∩(⋃t=1l2[Mt′]), assume that the corresponding SDS constraint specific attributes for the two SDS constraints are θi1,1(a),θi1,2(a),…,θi1,l1(a) and θi2,1(a),θi2,2(a),…,θi2,l2(a), respectively. If M∈[Mj1] in SDSi1(a) and M∈[Mj2] in SDSi2(a), then θi1,j1(a) and θi2,j2(a) are both used to upgrade the access requirement for M.


## 4. CP-ABE Access Control System Architecture for SDS Constraint

### 4.1. System Architecture and Assumptions

The system architecture is as shown in Figure2. The entities in the system are described as follows.Figure 2
CP-ABE access control system architecture for SDS constraints.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.


## 4.1. System Architecture and Assumptions

The system architecture is as shown in Figure2. The entities in the system are described as follows.Figure 2
CP-ABE access control system architecture for SDS constraints.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{λ1,λ2,…,λn} be a set of attributes. A collection A⊆2{λ1,λ2,…,λn} is monotone if ∀B,C: if B∈A and B⊆C, then C∈A. An attribute access structure (resp., monotone attribute access structure) is a collection (resp., monotone collection) A of nonempty subsets of {λ1,λ2,…,λn}, that is, A⊆2{λ1,λ2,…,λn}∖{∅}. 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. G0 and G1 are two multiplicative cyclic groups of prime order p. g is a generator of G0, and e is a bilinear map, e:G0×G0→G1. e has the following properties:(i)
Bilinearity:∀u,v∈Go and ∀x,y∈Zp∗, e(ux,vy)=e(u,v)xy.(ii)
Nondegeneracy:e(g,g)≠1.(iii)
Computability: computing the bilinear mape:G0×G0→G1 is efficient.Bilinear Diffie-Hellman (BDH) Assumption. Based on the aforementioned notations, given a generator g of G0 and elements gx, gy, gz for x,y,z∈Zp∗, the BDH problem is to find e(g,g)xyz.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 p,G0,G1,e 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)
USERS={u1,u2,…,ul}: the user set.(ii)
O_ATTR={λ1,λ2,…,λs}: original attributes.(iii)
SDS_ATTR(uj)={θi,1(j),θi,2(j),…,θi,ni(j)}1≤i≤m,j=1,2,…,l: SDS constraint specific attributes for a user uj; uj has m different SDS constraints; m can be different for different users.(iv)
SDS_INFOi(j)={θi,1(j),θi,2(j),…,θi,ni(j),ki},1≤i≤m,j=1,2,…,l: SDS constraint information for user uj’s ith SDS constraint.(v)
H_Attr(ut,SDSi(j)): historical SDS constraint specific attribute set; it is initially an empty set; when user ut successfully accesses data owner uj’s data object under uj’s ith 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)
SDS_ATTR=⋃j=1lSDS_ATTR(uj): all SDS constraint specific attributes in the system.(vii)
ATTR=O_ATTR∪SDS_ATTR, all attributes in the system, O_ATTR∩SDS_ATTR=∅.


### 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. Setup(1λ)→(PKKGC,MKKGC), (PKS,MKS), (PKSDS,MKSDS). 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 (PKKGC,MKKGC), (PKS,MKS), and (PKSDS,MKSDS), respectively.Key Generation. KeyGen(MKKGC,S)→SKu. The KGC takes MKKGC and a set of attributes S∈2O_ATTR∖{∅} as input, and it outputs the private key SKu for the user u.Data Encryption. Encrypt(PKKGC,PKS,PKSDS,M,T)→CT. The data owner takes PKKGC, PKS, and PKSDS and the tree access structure T as parameters to encrypt the data object M. The data owner outputs a ciphertext CT.Token Generation. GenToken(SKu,S′)→TKS′,u. The user u takes SKu and the set of attributes S′⊆S as input and outputs a token TKS′,u.Partial Decryption
(a)
Proxy-Server-Side Partial Decryption. SPartDecrypt(CT,TKS′,u)→CT′. The proxy server determines if S′ 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 ⊥.
(b)
SDS-Monitor-Side Partial Decryption. 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.Data Decryption. Decrypt(CT′′,SKu)→M. The user takes CT′′ and SKu as input and outputs data object M if the decryption is successful.


## 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{λ1,λ2,…,λn} be a set of attributes. A collection A⊆2{λ1,λ2,…,λn} is monotone if ∀B,C: if B∈A and B⊆C, then C∈A. An attribute access structure (resp., monotone attribute access structure) is a collection (resp., monotone collection) A of nonempty subsets of {λ1,λ2,…,λn}, that is, A⊆2{λ1,λ2,…,λn}∖{∅}. 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. G0 and G1 are two multiplicative cyclic groups of prime order p. g is a generator of G0, and e is a bilinear map, e:G0×G0→G1. e has the following properties:(i)
Bilinearity:∀u,v∈Go and ∀x,y∈Zp∗, e(ux,vy)=e(u,v)xy.(ii)
Nondegeneracy:e(g,g)≠1.(iii)
Computability: computing the bilinear mape:G0×G0→G1 is efficient.Bilinear Diffie-Hellman (BDH) Assumption. Based on the aforementioned notations, given a generator g of G0 and elements gx, gy, gz for x,y,z∈Zp∗, the BDH problem is to find e(g,g)xyz.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 p,G0,G1,e is hard with respect to unconditional anonymity, session key secrecy, and impersonation.


## 5.1.1. Attribute Access Structure

Definition 2 (attribute access structure).
Let{λ1,λ2,…,λn} be a set of attributes. A collection A⊆2{λ1,λ2,…,λn} is monotone if ∀B,C: if B∈A and B⊆C, then C∈A. An attribute access structure (resp., monotone attribute access structure) is a collection (resp., monotone collection) A of nonempty subsets of {λ1,λ2,…,λn}, that is, A⊆2{λ1,λ2,…,λn}∖{∅}. 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. G0 and G1 are two multiplicative cyclic groups of prime order p. g is a generator of G0, and e is a bilinear map, e:G0×G0→G1. e has the following properties:(i)
Bilinearity:∀u,v∈Go and ∀x,y∈Zp∗, e(ux,vy)=e(u,v)xy.(ii)
Nondegeneracy:e(g,g)≠1.(iii)
Computability: computing the bilinear mape:G0×G0→G1 is efficient.Bilinear Diffie-Hellman (BDH) Assumption. Based on the aforementioned notations, given a generator g of G0 and elements gx, gy, gz for x,y,z∈Zp∗, the BDH problem is to find e(g,g)xyz.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 p,G0,G1,e 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)
USERS={u1,u2,…,ul}: the user set.(ii)
O_ATTR={λ1,λ2,…,λs}: original attributes.(iii)
SDS_ATTR(uj)={θi,1(j),θi,2(j),…,θi,ni(j)}1≤i≤m,j=1,2,…,l: SDS constraint specific attributes for a user uj; uj has m different SDS constraints; m can be different for different users.(iv)
SDS_INFOi(j)={θi,1(j),θi,2(j),…,θi,ni(j),ki},1≤i≤m,j=1,2,…,l: SDS constraint information for user uj’s ith SDS constraint.(v)
H_Attr(ut,SDSi(j)): historical SDS constraint specific attribute set; it is initially an empty set; when user ut successfully accesses data owner uj’s data object under uj’s ith 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)
SDS_ATTR=⋃j=1lSDS_ATTR(uj): all SDS constraint specific attributes in the system.(vii)
ATTR=O_ATTR∪SDS_ATTR, all attributes in the system, O_ATTR∩SDS_ATTR=∅.


## 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. Setup(1λ)→(PKKGC,MKKGC), (PKS,MKS), (PKSDS,MKSDS). 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 (PKKGC,MKKGC), (PKS,MKS), and (PKSDS,MKSDS), respectively.Key Generation. KeyGen(MKKGC,S)→SKu. The KGC takes MKKGC and a set of attributes S∈2O_ATTR∖{∅} as input, and it outputs the private key SKu for the user u.Data Encryption. Encrypt(PKKGC,PKS,PKSDS,M,T)→CT. The data owner takes PKKGC, PKS, and PKSDS and the tree access structure T as parameters to encrypt the data object M. The data owner outputs a ciphertext CT.Token Generation. GenToken(SKu,S′)→TKS′,u. The user u takes SKu and the set of attributes S′⊆S as input and outputs a token TKS′,u.Partial Decryption
(a)
Proxy-Server-Side Partial Decryption. SPartDecrypt(CT,TKS′,u)→CT′. The proxy server determines if S′ 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 ⊥.
(b)
SDS-Monitor-Side Partial Decryption. 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.Data Decryption. Decrypt(CT′′,SKu)→M. The user takes CT′′ and SKu as input and outputs data object M 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

LetG0 be a bilinear group of prime order p, and let g be the generator of G0. In addition, let e:G0×G0→G1 denote the bilinear map. A security parameter, k, will determine the size of the groups. We use two hash functions, H:0,1∗→G0 and H1:G1→{0,1}log⁡p, which we will model as a random oracle. For the Lagrange coefficients Δi,S for any i∈Zp∗ and a set, S, of elements in Zp∗, we define Δi,S(x)=∏j∈S,j≠i((x-j)/(i-j))‍.Setup. The KGC, proxy server, and SDS monitor produce their public and master private key pairs.The KGC choosesG0 of prime order p, where g is its generator. The KGC chooses H:{0,1}∗→G0, H1:G1→{0,1}log⁡p and the following public parameters: (G0,g,H,H1).The KGC chooses two random exponentsα,β∈ZRp∗, h=gβ; then, the public and private keys for the KGC are PKKGC=(h,e(g,g)α) and MKKGC=(β,gα), respectively.The proxy server chooses a random exponentγ∈ZRp∗; then, the public and private keys for the proxy server are PKS=gγ and MKS=H(IDS)γ, respectively.The SDS monitor chooses a random exponentσ∈ZRp∗; then, the public and private keys for the SDS monitor are PKSDS=gσ and MKSDS=H(IDSDS)σ, respectively.Key Generation. The KGC produces private keys for users by running the KeyGen(MKKGC,S) algorithm. The algorithm takes as input MKKGC and S and outputs a private key for a user that holds all attributes in S. The KGC selects two random exponents rt∈ZRp∗ and rj∈ZRp∗, where rt is a unique secret to user ut and rj is a unique secret to attribute λj∈S. Then, the KGC generates the following private key for the user: (2)SKut=D=gα+rt/β,∀λj∈S:Dj=grt·Hλjrj,Dj′=grj,Dj′′=Hλjβ.Data Encryption. Suppose that a data owner ua has m different SDS constraints, SDSi(a)=({[M1],[M2],…,[Mni]},#ki),i=1,2,…,m, where the corresponding dummy attributes are {θi,1(a),θi,2(a),…,θi,ni(a)}1≤i≤m. For an SDS, the data owner selects a random a∈ZRp∗ and then computes Kθi,j=(e(gσ)a,H(θi,j)),j=1,2,…,ni,i=1,2,…,m. These computations can be completed beforehand. The data owner only releases the SDS constraint information SDS_INFOi(a)={θi,1,θi,2,…,θi,ni,ki},1≤i≤m, to the cloud storage server.Suppose that the data ownerua wants to release his/her data object M∈G1 to the cloud storage server, M∈[Mȷ], where Mȷ∈SDSıa=({[M1],[M2],…,[Mnı]},#kı). Before releasing the data object, ua encrypts the data object under an access tree T defined by him/her by running the Encrypt(PKKGC,PKS,PKSDS,M,T) algorithm. The algorithm first chooses a polynomial qx for each node x, including the leaves, in the tree T. For additional details, see the definition of access trees in [3].LetY be the set of leaf nodes in T. The data owner computes sy=(e(gβ)a,H(λy)) for all y∈Y in the leaf node of the access tree and then computes H1(sy).To encrypt the data objectM under T, the data owner computes a session key between the data owner and the proxy server KS=e((gγ)a,H(IDS)) as well as the session key between the data owner and the SDS monitor KSDS=e((gσ)a,H(IDSDS)). Then, the algorithm constructs a ciphertext as (3)CT=T,C~=M·KS·KSDS·eg,gαs,C=hs,∀y∈Y:Cy=gqy0,Cy′=Hλyqy0,H1Kθı,ȷ.The data ownerua sends (IDa,ga,CT) to the proxy server.Token Generation. When a user ut sends an access request for a data object, where the data object’s owner is ua, to the proxy server using a set of attributes S′⊆S, where S is the set of all valid attributes ut held, user ut obtains ga from the proxy server first. Then, he/she generates a token TKS′,ut by running the GenToken(SKut,S′) algorithm.For allλj∈S′, the algorithm computes sj=e(ga,Dj′′)=e(ga,H(λj)β). Then, the algorithm selects a random τ∈ZRp∗ and constructs the token for S′ as (4)TKS′,ut=∀λj∈S′:Ij=H1sj,Djτ,Dj′τ.IfS′⊈S, then the algorithm outputs ⊥.Next, userut 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 Ij 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 SPartDecrypt(CT,TKS′,ut) algorithm for user ut.TheSPartDecrypt(CT,TKS′,ut) algorithm operates in a recursive manner. We first define a recursive algorithm DecryptNote(CT,TK,x) that takes as input a ciphertext CT, a token TK, which is associated with a set of attributes S′, and a node x from the tree T. The algorithm outputs a group element of G1 or ⊥.Suppose that the proxy server runs the algorithm with a tokenTKS′,ut provided by a user ut. Suppose that an attribute assigned to a leaf node x is blinded as H1(sx). Then, make the following definition: If H1(sx)∈I, where I is a set of all attribute indices Ij associated with the token, then (5)DecryptNoteCT,TKS′,ut,x=eDxτ,CxeDx′τ,Cx′=egrt·Hλxrxτ,gqx0egrxτ,Hλxqx0=eg,grtτqx0.IfH1(sx)∉I, define DecryptNote(CT,TK,x)=⊥.Now, consider the recursive case in whichx is a nonleaf node. The DecryptNote(CT,TKS′,ut,x) algorithm is executed as follows: For all nodes z that are children of x, the algorithm calls DecryptNote(CT,TKS′,ut,z) and stores the output as Fz. Let Sx be an arbitrary kx-sized set of child nodes z such that Fz≠⊥; then, the algorithm computes(6)Fx=∏z∈SxFzΔi,Sx′0,wherei=indexz,Sx′=indexz:z∈Sx=∏z∈Sxeg,grt·τ·qz0Δi,Sx′0=∏z∈Sxeg,grt·τ·qparentzindexzΔi,Sx′0=∏z∈Sxeg,grt·τ·qxiΔi,Sx′0=eg,grt·τ·qx0and returns the result.The algorithm begins by calling the function on the root nodeR of the access tree T. If the access tree is satisfied by the token associated with the set of attributes S′, then the proxy server extracts DecryptNote(CT,TKS′,ut,R)=e(g,g)rtτs.The proxy server computesKS=e(ga,MKS)=e(ga,H(IDS)γ) and C~′=C~/KS=M·KSDS·e(g,g)αs in CT; then, it sends CT′=(C~′,C=hs,A,H1(Kθı,ȷ)) to the SDS monitor, where (7)A=DecryptNoteCT,TKS′,ut,R=eg,grtτs.(b) SDS-Monitor-Side Partial Decryption. After receiving CT′ 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 CT′ and returns ⊥, and the user’s access request will be denied. Otherwise, the SDS monitor takes CT′ as input and outputs CT′′ for the user by running the SDSPartDecrypt(CT′) algorithm.Now, we give the determination process in detail. The SDS monitor precomputes allΘi,j=H1(Kθi,j),j=1,2,…,ni,i=1,2,…,m, after computing Kθi,j=e(ga,H(θi,j)σ),j=1,2,…,ni,i=1,2,…,m, for {θi,1,θi,2,…,θi,ni}1≤i≤m; and it compares H1(Kθı,ȷ) in CT′ to these precomputed dummy attribute indices Θi,j,j=1,2,…,ni,i=1,2,…,m. By comparison, it finds out that Θı,ȷ=H1(Kθı,ȷ) and determines the SDS constraint information SDS_INFOı(a)={θı,1(a),θı,2(a),…,θı,nı(a),kı}, and the threshold kı should be applied to the current data. According to the threshold value kı, the SDS monitor checks if |H_Attr(ut,SDSı(a))∪{θı,ȷ}|=kı, and then it determines whether the current data access violates SDS constraint SDSı(a) and destroys the data immediately; otherwise, the SDS monitor performs its partial decryption. The SDS monitor first computes KSDS=e(ga,MKSDS)=e(ga,H(IDSDS)σ) and then computes C~′′=C~′/KSDS=M·e(g,g)αs.Next, the SDS monitor updates the historical SDS constraint specific attribute set asH_Attr(ut,SDSı(a))=H_Attr(ut,SDSı(a))∪{θı,ȷ} and sends CT′′=(C~′′,C=hs,A) to the user.Data Decryption. When user ut receives the ciphertext CT′′ from the SDS monitor, he/she uses the Decrypt(CT′′,SKS′,ut) algorithm to decrypt the ciphertext by computing (8)C~′′eC,D/A1/τ=C~′′ehs,gα+rt/β/eg,grtτs1/τ=C~′′egβs,gα+rt/β/eg,grts=Meg,gαseg,gαs=M.


### 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 ownerAlice released three data objects M1, M2, and M3 and defined ıth SDS constraint over them; that is, SDSı(Alice)={{M1},{M2,M3},#2}. The corresponding SDS constraint information SDS_INFOı(Alice)={θı,1,θı,2,2} is released to the cloud storage server. θı,1 and θı,2 are the two dummy attributes corresponding to {M1} and {M2,M3}, respectively. Suppose a user Bob’s attributes match the access structures of data objects M1 and M2. When Bob sends an access request for M1, the proxy server uses Bob’s token to partially decrypt the following ciphertext: (9)CT1=T1,C~1=M1·KS·KSDS·eg,gαs1,C1=hs1,∀y∈Y1:Cy=gqy0,Cy′=Hλyqy0,H1Kθı,1,where T1 is the tree access structure of M1 and Y1 is the set of leaf nodes in T1.Since Bob’s attributes matchT1, then the partial decryption by the proxy server will be successful. The proxy server knows that M1 is under an SDS constraint because there is H1(Kθı,1) in the ciphertext, and then it transfers the ciphertext CT1′=(C~1′,C1=hs1,A1,H1(Kθı,1)) to the SDS monitor. When the SDS monitor receives the partially decrypted ciphertext from the proxy server, it compares H1(Kθı,1) in the ciphertext to the precomputed values Θi,j=H1(Kθi,j), where Kθi,j=e(ga,H(θi,j)σ),j=1,2,…,ni,i=1,2,…,m, for {θi,1,θi,2,…,θi,ni}1≤i≤m, and then it gets Θı,1=H1(Kθı,1). Therefore, the SDS monitor determines that SDS_INFOı(Alice)={θı,1,θı,2,2} is the SDS constraint information applied to the data M1. The SDS monitor checks if |H_Attr(Bob,SDSı(Alice))∪{θı,1}|=2. Since H_Attr(Bob,SDSı(Alice))=∅, we have (10)H_AttrBob,SDSıAlice∪θı,1=1<2.Therefore, the SDS monitor knows that the current access to M1 does not violate SDSı(Alice). After that, it updates H_Attr(Bob,SDSı(Alice)) as (11)H_AttrBob,SDSıAlice=H_AttrBob,SDSıAlice∪θı,1and then sends CT1′′=(C~1′′,C1=hs1,A1) to Bob. Bob successfully accesses M1.When Bob sends another access request forM2, the proxy server uses Bob’s token to partially decrypt the following ciphertext: (12)CT2=T2,C~2=M2·KS·KSDS·eg,gαs2,C2=hs2,∀y∈Y2:Cy=gqy0,Cy′=Hλyqy0,H1Kθı,2,where T2 is the tree access structure of M2 and Y2 is the set of leaf nodes in T2.Since Bob’s attributes matchT2, 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 H1(Kθı,2), and then it transfers the ciphertext CT2′=(C~2′,C2=hs2,A2,H1(Kθı,2)) to the SDS monitor. When the SDS monitor receives the partially decrypted ciphertext from the proxy server, it compares H1(Kθı,2) in the ciphertext to the precomputed values Θi,j=H1(Kθi,j), where Kθi,j=e(ga,H(θi,j)σ),j=1,2,…,ni,i=1,2,…,m, for {θi,1,θi,2,…,θi,ni}1≤i≤m, and then it gets Θı,2=H1(Kθı,2). Therefore, the SDS monitor determines that SDS_INFOı(Alice)={θı,1,θı,2,2} is also the SDS constraint information applied to the data M2. The SDS monitor checks if |H_Attr(Bob,SDSı(Alice))∪{θı,2}|=2. Now, we have (13)H_AttrBob,SDSıAlice∪θı,2=2,so the SDS monitor knows that the current access to M2 violates SDSı(Alice). It destroys the corresponding ciphertext immediately. Bob cannot access M2.


## 6.1. CP-ABE Access Control Scheme Construction for the SDS Constraint

LetG0 be a bilinear group of prime order p, and let g be the generator of G0. In addition, let e:G0×G0→G1 denote the bilinear map. A security parameter, k, will determine the size of the groups. We use two hash functions, H:0,1∗→G0 and H1:G1→{0,1}log⁡p, which we will model as a random oracle. For the Lagrange coefficients Δi,S for any i∈Zp∗ and a set, S, of elements in Zp∗, we define Δi,S(x)=∏j∈S,j≠i((x-j)/(i-j))‍.Setup. The KGC, proxy server, and SDS monitor produce their public and master private key pairs.The KGC choosesG0 of prime order p, where g is its generator. The KGC chooses H:{0,1}∗→G0, H1:G1→{0,1}log⁡p and the following public parameters: (G0,g,H,H1).The KGC chooses two random exponentsα,β∈ZRp∗, h=gβ; then, the public and private keys for the KGC are PKKGC=(h,e(g,g)α) and MKKGC=(β,gα), respectively.The proxy server chooses a random exponentγ∈ZRp∗; then, the public and private keys for the proxy server are PKS=gγ and MKS=H(IDS)γ, respectively.The SDS monitor chooses a random exponentσ∈ZRp∗; then, the public and private keys for the SDS monitor are PKSDS=gσ and MKSDS=H(IDSDS)σ, respectively.Key Generation. The KGC produces private keys for users by running the KeyGen(MKKGC,S) algorithm. The algorithm takes as input MKKGC and S and outputs a private key for a user that holds all attributes in S. The KGC selects two random exponents rt∈ZRp∗ and rj∈ZRp∗, where rt is a unique secret to user ut and rj is a unique secret to attribute λj∈S. Then, the KGC generates the following private key for the user: (2)SKut=D=gα+rt/β,∀λj∈S:Dj=grt·Hλjrj,Dj′=grj,Dj′′=Hλjβ.Data Encryption. Suppose that a data owner ua has m different SDS constraints, SDSi(a)=({[M1],[M2],…,[Mni]},#ki),i=1,2,…,m, where the corresponding dummy attributes are {θi,1(a),θi,2(a),…,θi,ni(a)}1≤i≤m. For an SDS, the data owner selects a random a∈ZRp∗ and then computes Kθi,j=(e(gσ)a,H(θi,j)),j=1,2,…,ni,i=1,2,…,m. These computations can be completed beforehand. The data owner only releases the SDS constraint information SDS_INFOi(a)={θi,1,θi,2,…,θi,ni,ki},1≤i≤m, to the cloud storage server.Suppose that the data ownerua wants to release his/her data object M∈G1 to the cloud storage server, M∈[Mȷ], where Mȷ∈SDSıa=({[M1],[M2],…,[Mnı]},#kı). Before releasing the data object, ua encrypts the data object under an access tree T defined by him/her by running the Encrypt(PKKGC,PKS,PKSDS,M,T) algorithm. The algorithm first chooses a polynomial qx for each node x, including the leaves, in the tree T. For additional details, see the definition of access trees in [3].LetY be the set of leaf nodes in T. The data owner computes sy=(e(gβ)a,H(λy)) for all y∈Y in the leaf node of the access tree and then computes H1(sy).To encrypt the data objectM under T, the data owner computes a session key between the data owner and the proxy server KS=e((gγ)a,H(IDS)) as well as the session key between the data owner and the SDS monitor KSDS=e((gσ)a,H(IDSDS)). Then, the algorithm constructs a ciphertext as (3)CT=T,C~=M·KS·KSDS·eg,gαs,C=hs,∀y∈Y:Cy=gqy0,Cy′=Hλyqy0,H1Kθı,ȷ.The data ownerua sends (IDa,ga,CT) to the proxy server.Token Generation. When a user ut sends an access request for a data object, where the data object’s owner is ua, to the proxy server using a set of attributes S′⊆S, where S is the set of all valid attributes ut held, user ut obtains ga from the proxy server first. Then, he/she generates a token TKS′,ut by running the GenToken(SKut,S′) algorithm.For allλj∈S′, the algorithm computes sj=e(ga,Dj′′)=e(ga,H(λj)β). Then, the algorithm selects a random τ∈ZRp∗ and constructs the token for S′ as (4)TKS′,ut=∀λj∈S′:Ij=H1sj,Djτ,Dj′τ.IfS′⊈S, then the algorithm outputs ⊥.Next, userut 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 Ij 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 SPartDecrypt(CT,TKS′,ut) algorithm for user ut.TheSPartDecrypt(CT,TKS′,ut) algorithm operates in a recursive manner. We first define a recursive algorithm DecryptNote(CT,TK,x) that takes as input a ciphertext CT, a token TK, which is associated with a set of attributes S′, and a node x from the tree T. The algorithm outputs a group element of G1 or ⊥.Suppose that the proxy server runs the algorithm with a tokenTKS′,ut provided by a user ut. Suppose that an attribute assigned to a leaf node x is blinded as H1(sx). Then, make the following definition: If H1(sx)∈I, where I is a set of all attribute indices Ij associated with the token, then (5)DecryptNoteCT,TKS′,ut,x=eDxτ,CxeDx′τ,Cx′=egrt·Hλxrxτ,gqx0egrxτ,Hλxqx0=eg,grtτqx0.IfH1(sx)∉I, define DecryptNote(CT,TK,x)=⊥.Now, consider the recursive case in whichx is a nonleaf node. The DecryptNote(CT,TKS′,ut,x) algorithm is executed as follows: For all nodes z that are children of x, the algorithm calls DecryptNote(CT,TKS′,ut,z) and stores the output as Fz. Let Sx be an arbitrary kx-sized set of child nodes z such that Fz≠⊥; then, the algorithm computes(6)Fx=∏z∈SxFzΔi,Sx′0,wherei=indexz,Sx′=indexz:z∈Sx=∏z∈Sxeg,grt·τ·qz0Δi,Sx′0=∏z∈Sxeg,grt·τ·qparentzindexzΔi,Sx′0=∏z∈Sxeg,grt·τ·qxiΔi,Sx′0=eg,grt·τ·qx0and returns the result.The algorithm begins by calling the function on the root nodeR of the access tree T. If the access tree is satisfied by the token associated with the set of attributes S′, then the proxy server extracts DecryptNote(CT,TKS′,ut,R)=e(g,g)rtτs.The proxy server computesKS=e(ga,MKS)=e(ga,H(IDS)γ) and C~′=C~/KS=M·KSDS·e(g,g)αs in CT; then, it sends CT′=(C~′,C=hs,A,H1(Kθı,ȷ)) to the SDS monitor, where (7)A=DecryptNoteCT,TKS′,ut,R=eg,grtτs.(b) SDS-Monitor-Side Partial Decryption. After receiving CT′ 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 CT′ and returns ⊥, and the user’s access request will be denied. Otherwise, the SDS monitor takes CT′ as input and outputs CT′′ for the user by running the SDSPartDecrypt(CT′) algorithm.Now, we give the determination process in detail. The SDS monitor precomputes allΘi,j=H1(Kθi,j),j=1,2,…,ni,i=1,2,…,m, after computing Kθi,j=e(ga,H(θi,j)σ),j=1,2,…,ni,i=1,2,…,m, for {θi,1,θi,2,…,θi,ni}1≤i≤m; and it compares H1(Kθı,ȷ) in CT′ to these precomputed dummy attribute indices Θi,j,j=1,2,…,ni,i=1,2,…,m. By comparison, it finds out that Θı,ȷ=H1(Kθı,ȷ) and determines the SDS constraint information SDS_INFOı(a)={θı,1(a),θı,2(a),…,θı,nı(a),kı}, and the threshold kı should be applied to the current data. According to the threshold value kı, the SDS monitor checks if |H_Attr(ut,SDSı(a))∪{θı,ȷ}|=kı, and then it determines whether the current data access violates SDS constraint SDSı(a) and destroys the data immediately; otherwise, the SDS monitor performs its partial decryption. The SDS monitor first computes KSDS=e(ga,MKSDS)=e(ga,H(IDSDS)σ) and then computes C~′′=C~′/KSDS=M·e(g,g)αs.Next, the SDS monitor updates the historical SDS constraint specific attribute set asH_Attr(ut,SDSı(a))=H_Attr(ut,SDSı(a))∪{θı,ȷ} and sends CT′′=(C~′′,C=hs,A) to the user.Data Decryption. When user ut receives the ciphertext CT′′ from the SDS monitor, he/she uses the Decrypt(CT′′,SKS′,ut) algorithm to decrypt the ciphertext by computing (8)C~′′eC,D/A1/τ=C~′′ehs,gα+rt/β/eg,grtτs1/τ=C~′′egβs,gα+rt/β/eg,grts=Meg,gαseg,gαs=M.


## 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 ownerAlice released three data objects M1, M2, and M3 and defined ıth SDS constraint over them; that is, SDSı(Alice)={{M1},{M2,M3},#2}. The corresponding SDS constraint information SDS_INFOı(Alice)={θı,1,θı,2,2} is released to the cloud storage server. θı,1 and θı,2 are the two dummy attributes corresponding to {M1} and {M2,M3}, respectively. Suppose a user Bob’s attributes match the access structures of data objects M1 and M2. When Bob sends an access request for M1, the proxy server uses Bob’s token to partially decrypt the following ciphertext: (9)CT1=T1,C~1=M1·KS·KSDS·eg,gαs1,C1=hs1,∀y∈Y1:Cy=gqy0,Cy′=Hλyqy0,H1Kθı,1,where T1 is the tree access structure of M1 and Y1 is the set of leaf nodes in T1.Since Bob’s attributes matchT1, then the partial decryption by the proxy server will be successful. The proxy server knows that M1 is under an SDS constraint because there is H1(Kθı,1) in the ciphertext, and then it transfers the ciphertext CT1′=(C~1′,C1=hs1,A1,H1(Kθı,1)) to the SDS monitor. When the SDS monitor receives the partially decrypted ciphertext from the proxy server, it compares H1(Kθı,1) in the ciphertext to the precomputed values Θi,j=H1(Kθi,j), where Kθi,j=e(ga,H(θi,j)σ),j=1,2,…,ni,i=1,2,…,m, for {θi,1,θi,2,…,θi,ni}1≤i≤m, and then it gets Θı,1=H1(Kθı,1). Therefore, the SDS monitor determines that SDS_INFOı(Alice)={θı,1,θı,2,2} is the SDS constraint information applied to the data M1. The SDS monitor checks if |H_Attr(Bob,SDSı(Alice))∪{θı,1}|=2. Since H_Attr(Bob,SDSı(Alice))=∅, we have (10)H_AttrBob,SDSıAlice∪θı,1=1<2.Therefore, the SDS monitor knows that the current access to M1 does not violate SDSı(Alice). After that, it updates H_Attr(Bob,SDSı(Alice)) as (11)H_AttrBob,SDSıAlice=H_AttrBob,SDSıAlice∪θı,1and then sends CT1′′=(C~1′′,C1=hs1,A1) to Bob. Bob successfully accesses M1.When Bob sends another access request forM2, the proxy server uses Bob’s token to partially decrypt the following ciphertext: (12)CT2=T2,C~2=M2·KS·KSDS·eg,gαs2,C2=hs2,∀y∈Y2:Cy=gqy0,Cy′=Hλyqy0,H1Kθı,2,where T2 is the tree access structure of M2 and Y2 is the set of leaf nodes in T2.Since Bob’s attributes matchT2, 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 H1(Kθı,2), and then it transfers the ciphertext CT2′=(C~2′,C2=hs2,A2,H1(Kθı,2)) to the SDS monitor. When the SDS monitor receives the partially decrypted ciphertext from the proxy server, it compares H1(Kθı,2) in the ciphertext to the precomputed values Θi,j=H1(Kθi,j), where Kθi,j=e(ga,H(θi,j)σ),j=1,2,…,ni,i=1,2,…,m, for {θi,1,θi,2,…,θi,ni}1≤i≤m, and then it gets Θı,2=H1(Kθı,2). Therefore, the SDS monitor determines that SDS_INFOı(Alice)={θı,1,θı,2,2} is also the SDS constraint information applied to the data M2. The SDS monitor checks if |H_Attr(Bob,SDSı(Alice))∪{θı,2}|=2. Now, we have (13)H_AttrBob,SDSıAlice∪θı,2=2,so the SDS monitor knows that the current access to M2 violates SDSı(Alice). It destroys the corresponding ciphertext immediately. Bob cannot access M2.


## 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 Table1, 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 G1 because H1(Kθi,j) is embedded into it, and the public key size is increased by the bit size of an element in G0 because PKSDS=gσ is used as one of the public keys in the system.Table 1
Comparison of different schemes.
Hur’s [8]
Lai et al.’s [9]
Lai et al.’s [10]
The proposed scheme
Ciphertext size
(
2
t
+
1
)
L
0
+
L
1
(
N
+
1
)
L
0
+
L
1
(
4
l
+
2
)
L
0
+
2
L
1
(
2
t
+
1
)
L
0
+
2
L
1
Private key size
(
3
k
+
1
)
L
0
(
u
+
1
)
L
0
(
u
+
2
)
L
0
(
3
k
+
1
)
L
0
Public key size
2
L
0
+
L
1
(
N
+
2
)
L
0
+
L
1
(
u
+
5
)
L
0
+
L
1
3
L
0
+
L
1
Encryption cost
(
3
t
+
3
)
e
x
p
+
(
t
+
1
)
e
^
(
N
+
2
)
e
x
p
(
8
l
+
4
)
e
x
p
(
3
t
+
4
)
e
x
p
+
(
t
+
2
)
e
^
Partial decryption cost (storage server or proxy server)
(
2
|
R
|
+
1
)
e
^
+
e
x
p
/
/
(
2
|
R
|
+
1
)
e
^
+
e
x
p
Partial decryption cost (SDS monitor)
/
/
/
e
^
+
e
x
p
Decryption cost (user)
e
^
+
3
e
x
p
(
N
+
1
)
e
^
(
4
l
+
2
)
e
^
+
(
2
l
+
3
)
e
x
p
e
^
+
3
e
x
p
Token generation cost (user)
|
R
|
e
^
+
2
|
R
|
e
x
p
/
/
|
R
|
e
^
+
2
|
R
|
e
x
pIn addition, we have the additional dummy attributes{θi,1,θi,2,…,θi,ni}1≤i≤m for a data owner who has m 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 Section4.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 userut 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 e(g,g)rtτs with the invalid token without knowing rt and τ, which are unique secrets to the user.Assuming that the unauthorized userut directly fetches the ciphertext from the cloud storage server without using the token, he/she cannot compute e(g,g)rts because his/her attributes do not match the access tree. Moreover, he/she cannot cast off the session keys KS and KSDS embedded in the ciphertext component C~=M·KS·KSDS·e(g,g)αs because KS is only shared by the data owner and the proxy server, and KSDS 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 offKSDS embedded in the ciphertext component C~=M·KS·KSDS·e(g,g)αs because KSDS is only shared by the data owner and the SDS monitor.The KGC cannot decrypt the ciphertext because the session keysKS and KSDS are embedded in the ciphertext component C~=M·KS·KSDS·e(g,g)αs. In addition, KS is shared only by the data owner and the proxy server, and KSDS is shared only by the data owner and the SDS monitor. The KGC cannot determine KS and KSDS because of the session key secrecy property of the key agreement [20]. Assuming that the KGC can access the partially decrypted ciphertext CT′=(C~′,C=hs,A,H1(Kθi,j)), where C~′=C~/KS=M·KSDS·e(g,g)αs from the proxy server, it still cannot cast off KSDS because KSDS is only shared by the data owner and the SDS monitor. Moreover, the KGC cannot cast off τ from A=e(g,g)rtτs to obtain the expected value e(g,g)rts because τ is a unique secret to the user.The SDS monitor cannot decrypt the ciphertext for two reasons. First, it cannot cast offτ from A=e(g,g)rtτs to obtain the expected value e(g,g)rts because τ is a unique secret to the user. Second, the SDS monitor does not know β, rt, or gα to obtain the expected value g(α+rt)/β because β and gα are private keys of the KGC and because rt 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~=M·KS·KSDS·e(g,g)αs 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 rt, 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 e(g,g)αs.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 KSDS is embedded in the ciphertext component C~=M·KS·KSDS·e(g,g)αs. Neither the proxy server, the KGC, nor the user can cast off KSDS because KSDS 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 H1(Kθı,ȷ) in the ciphertext to the precomputed values Θi,j=H1(Kθi,j),j=1,2,…,ni,i=1,2,…,m, where Kθi,j=e(ga,H(θi,j)σ),j=1,2,…,ni,i=1,2,…,m, for SDS_INFOi(a)={θi,1(a),θi,2(a),…,θi,ni(a),ki}1≤i≤m, and it checks if |H_Attr(ut,SDSı(ua))∪{θı,ȷ}|=kı. 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 {θi,1,θi,2,…,θi,ni,ki}1≤i≤m 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 {θi,1,θi,2,…,θi,ni,ki}1≤i≤m 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 componentH1(Kθi,j). If they observe that several ciphertexts that belong to a data owner have the same H1(Kθi,j), 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 ki, 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 objectM, we maintain its global current incompatible set M¯={M′∣∃SDS,M,M′∈SDS∧M′∉[M]}. 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 M, then he/she should ensure that data objects from M¯ are not put into [M]. 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.


## 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 userut 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 e(g,g)rtτs with the invalid token without knowing rt and τ, which are unique secrets to the user.Assuming that the unauthorized userut directly fetches the ciphertext from the cloud storage server without using the token, he/she cannot compute e(g,g)rts because his/her attributes do not match the access tree. Moreover, he/she cannot cast off the session keys KS and KSDS embedded in the ciphertext component C~=M·KS·KSDS·e(g,g)αs because KS is only shared by the data owner and the proxy server, and KSDS 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 offKSDS embedded in the ciphertext component C~=M·KS·KSDS·e(g,g)αs because KSDS is only shared by the data owner and the SDS monitor.The KGC cannot decrypt the ciphertext because the session keysKS and KSDS are embedded in the ciphertext component C~=M·KS·KSDS·e(g,g)αs. In addition, KS is shared only by the data owner and the proxy server, and KSDS is shared only by the data owner and the SDS monitor. The KGC cannot determine KS and KSDS because of the session key secrecy property of the key agreement [20]. Assuming that the KGC can access the partially decrypted ciphertext CT′=(C~′,C=hs,A,H1(Kθi,j)), where C~′=C~/KS=M·KSDS·e(g,g)αs from the proxy server, it still cannot cast off KSDS because KSDS is only shared by the data owner and the SDS monitor. Moreover, the KGC cannot cast off τ from A=e(g,g)rtτs to obtain the expected value e(g,g)rts because τ is a unique secret to the user.The SDS monitor cannot decrypt the ciphertext for two reasons. First, it cannot cast offτ from A=e(g,g)rtτs to obtain the expected value e(g,g)rts because τ is a unique secret to the user. Second, the SDS monitor does not know β, rt, or gα to obtain the expected value g(α+rt)/β because β and gα are private keys of the KGC and because rt 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~=M·KS·KSDS·e(g,g)αs 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 rt, 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 e(g,g)αs.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 KSDS is embedded in the ciphertext component C~=M·KS·KSDS·e(g,g)αs. Neither the proxy server, the KGC, nor the user can cast off KSDS because KSDS 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 H1(Kθı,ȷ) in the ciphertext to the precomputed values Θi,j=H1(Kθi,j),j=1,2,…,ni,i=1,2,…,m, where Kθi,j=e(ga,H(θi,j)σ),j=1,2,…,ni,i=1,2,…,m, for SDS_INFOi(a)={θi,1(a),θi,2(a),…,θi,ni(a),ki}1≤i≤m, and it checks if |H_Attr(ut,SDSı(ua))∪{θı,ȷ}|=kı. 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 {θi,1,θi,2,…,θi,ni,ki}1≤i≤m 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 {θi,1,θi,2,…,θi,ni,ki}1≤i≤m 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 componentH1(Kθi,j). If they observe that several ciphertexts that belong to a data owner have the same H1(Kθi,j), 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 ki, 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 objectM, we maintain its global current incompatible set M¯={M′∣∃SDS,M,M′∈SDS∧M′∉[M]}. 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 M, then he/she should ensure that data objects from M¯ are not put into [M]. 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 considerwrite actions on the data by the user (consumer); the main action described in this paper is theread 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 “k OF n” in the SDS constraint.



---

*Source: 2713595-2017-09-28.xml*