Attribute-Based Data Sharing with Flexible and Direct Revocation in Cloud Computing

Abstract

Attribute-based encryption (ABE) is a promising cryptographic primitive for implementing fine-grained data sharing in cloud computing. However, before ABE can be widely deployed in practical cloud storage systems, a challenging issue with regard to attributes and user revocation has to be addressed. To our knowledge, most of the existing ABE schemes fail to support flexible and direct revocation owing to the burdensome update of attribute secret keys and all the ciphertexts. Aiming at tackling the challenge above, we formalize the notion of ciphertext-policy ABE supporting flexible and direct revocation (FDR-CP-ABE), and present a concrete construction. The proposed scheme supports direct attribute and user revocation. To achieve this goal, we introduce an auxiliary function to determine the ciphertexts involved in revocation events, and then only update these involved ciphertexts by adopting the technique of broadcast encryption. Furthermore, our construction is proven secure in the standard model. Theoretical analysis and experimental results indicate that FDR-CP-ABE outperforms the previous revocation-related methods.

1. Introduction

With the advent of cloud computing technology, sharing data through a third-party service provider has never been more economical and convenient than now. However, due to data outsourcing and untrusted storage servers, data access control becomes a challenging issue in cloud storage, where differentiated data access is frequently required in the sense that users with different attributes should be granted different levels of access privileges. Traditional methods based on access control lists are no longer suitable for cloud computing, because they require a fully trusted cloud server.

Aiming at providing fine-grained access control over cloud storage, a novel public key primitive namely attribute-based encryption (ABE) [1] was introduced in the cryptographic community, which enables public one-to-many encryption. ABE comes in two flavors called key-policy ABE (KP-ABE) and ciphertext-policy ABE (CP-ABE) [2]. Compared with KP-ABE, CP-ABE is extremely suitable for cloud-based data sharing, because it enables data owners to make and enforce access policies themselves. In CP-ABE, every ciphertext is associated with an access policy, and every secret key is associated with a set of attributes. A particular attribute secret key can decrypt a ciphertext if and only if the attributes associated with the secret key match the underlying access policy in the ciphertext.

Though CP-ABE is a promising primitive for designing fine-grained access control systems in cloud computing, there are several challenges that remain in applications of CP-ABE.

To the authors’ knowledge, however, there are no CP-ABE schemes, which have constant-size ciphertexts and provide direct attribute revocation mechanisms.

1.1 Our Contribution

Research contributions of this paper can be summarized as follows:

1.2 Organization

The remaining of this work is organized as follows. In Section 2, we review the state-of-the-art attribute-based encryption schemes. Some preliminaries are given in Section 3. We formalize the notion and security model of FDR-CP-ABE in Section 4. Our FDR-CP-ABE construction is detailed in Section 5. Security results together with performance comparisons are presented in Section 6. In Section 7, the application of our technique to KP-ABE counterparts is discussed. Finally, we conclude this paper in Section 8.

 

2. Related Work

Since the introduction of ABE [1] in implementing fine-grained data access control systems, plenty of researches have been done on ABE. In KP-ABE, access policies are enforced in secret keys and ciphertexts are labeled with a set of attributes. In CP-ABE, the roles of the attribute set and the access policy are swapped from what we described for KP-ABE. The first KP-ABE construction [2] realized monotonic access structures for key policies. To enable more flexible access policies, Ostrovsky et al. [13] presented the first KP-ABE system that supports the expression of non-monotone formulas in key policies. On the other hand, Bethencourt et al. [3] proposed the first CP-ABE scheme, but the security proof is given in the generic group model. To overcome this weakness, Cheung and Newport [11] presented another construction that is proven selectively secure in the standard model. To achieve full security, Lewko et al. [12] proposed a fully secure CP-ABE scheme in composite order bilinear groups, and proved its security from three static assumptions. There are also many works proposed to make further improvements on ABE, such as accountable ABE [14][15], anonymous ABE [16][17][18], ABE with constant-size ciphertexts [19][20][21], etc. Despite various attractive features, the above CP-ABE schemes cannot realize a revocation mechanism, which is indispensable for attribute-based systems in that users’ secret keys might get compromised at some point in the future.

In order to deal with the challenging revocation issue in attribute-based systems, several attribute-revocable ABE schemes have been proposed [3][4]. These schemes realize attribute revocation by setting an expiration time on each attribute, and hence the method is called a timed rekeying mechanism. However, these attribute-revocable ABE schemes suffer a security drawback in terms of the backward and forward secrecy, and the method based on validation time fails to realize attribute change in a timely fashion, i.e., the immediate attribute revocation. For the sake of practical ABE systems [5][6][7][8], Yu et al. [5] proposed a CP-ABE scheme supporting immediate attribute revocation mechanisms with the help of a semi-trusted proxy server. Hur et al. [6] proposed an immediate attribute revocation mechanism in CP-ABE by allowing a proxy server to re-encrypt ciphertexts with a set of attribute group keys. Yang et al. [7] proposed an attribute revocation method to cope with the dynamic changes of users’ access privileges. Li et al. [8] used ABE to realize secure sharing of personal health records and their solution supports attribute revocation. Researches on the security of e-healthcare have also been done in [22][23]. However, all the above schemes only support indirect revocation, that is, the attribute center indirectly realizes revocation by only allowing non-revoked users to update secret keys. The indirect revocation method has a disadvantage that the key update phase can be a performance bottleneck for both the attribute center and all the non-revoked users.

To tackle the above issue, Attrapadung et al. [9] proposed directly user-revocable CP-ABE schemes by combining the techniques of ABE and broadcast encryption (BE). Direct revocation has a desirable property that revocation can be realized without affecting any non-involved users, that is, it does not require users to update attribute secret keys periodically. Since Fiat et al. [24] first introduced the notion of BE, Boneh et al. [25] proposed a collusion-resistant BE scheme with short ciphertexts and private keys. The methods in [9] require that data owners should take full charge of maintaining the membership lists for each attribute group. Accordingly, these schemes are not suitable for data sharing in cloud computing, where the data owners upload their data into clouds and they will no longer be in direct control of the data. Sahai et al. [10] presented a generic method to show that a CP-ABE scheme with ciphertext delegation and piecewise key generation implies a revocable storage CP-ABE scheme. Furthermore, they proposed a variant of the CP-ABE scheme [12] that supports ciphertext delegation and piecewise key generation. However, the proposed scheme fails to support direct attribute revocation and the ciphertext length is not constant. Other researches on direct revocation mechanisms can be seen in [26][27]. The above directly revocable ABE schemes cannot efficiently realize attribute and user revocation, and the ciphertext size linearly increases with the number of revoked users or the complexity of access policies. In the extended abstract [28] of this paper, we formalized the notion of FDR-CP-ABE and presented a concrete scheme. We revise the paper a lot and add more technical details as compared to [28]. Firstly, in order to realize data sharing based on ABE in cloud computing, we add Section 4.2 to describe the system architecture, and add Section 4.3 to analyze security and efficiency goals of attribute-based data sharing systems. Secondly, for the FDR-CP-ABE construction, we provide detailed security proofs in the standard model in Section 6.1. Thirdly, we do intensive experiments and present more extensive performance comparisons in Section 6.2. Lastly, we add Section 7 to demonstrate that our technique is applicable to the KP-ABE counterpart.

 

3. Preliminaries

3.1 Bilinear Pairings

Let and be two cyclic multiplicative groups of prime order p, g be a generator of , and 1 be the identity of . We call map : × → a bilinear pairing if it satisfies the following properties. 1) Computability: there exists an efficient algorithm for computing map . 2) Bilinearity: (ga,gb) = (g,g)ab for all a,b ∈ . 3) Non-degeneracy: (g,g) ≠ 1.

3.2 Complexity Assumptions

Bilinear Diffie-Hellman Exponent (BDHE) assumption: Let be a bilinear group of prime order p, and g,h be two independent generators of . Let g,a,l = (g1,g2,…,gl,gl+2,…,g2l) ∈ , where gi = g(αi) for some unknown α ∈ . An algorithm B that outputs μ ∈ {0, 1} has advantage ϵ in solving the decision ℓ-BDHE problem if

We say the decision (t, ϵ, ℓ)-BDHE assumption holds in if no t-time algorithm has advantage at least ϵ in solving the decision ℓ-BDHE problem in .

 

4. Definition and Models

4.1 Notations

For simplicity, we explain some notations in Table 1, which are frequently used in this paper. Note that the attribute center in a data sharing system will publish an attribute revocation list on a public bulletin board when an attribute revocation event occurs. In Table 1, the attribute revocation information R and the public parameter PP are published on the public bulletin board by the attribute center.

Table 1.Notations frequently used in this paper

4.2 System Architecture

As shown in Fig. 1, the architecture of an attribute-based data sharing system in cloud computing consists of four types of parties: an attribute center, a cloud service provider, data owners, and users. Data owners and users are administrated by the attribute center. The cloud service provider is honest-but-curious and it manages a cloud to provide data storage service. Note that the cloud is assumed to have sufficient storage capacity and computation power. Data owners encrypt their contents and store ciphertext data in the cloud for sharing. To access the shared contents in the cloud, users download encrypted contents of interest from the cloud and then decrypt them based on their secret keys. In particular, the cloud service provider can update ciphertexts involved in some revocation events based on the delegation key from the attribute center.

Fig. 1.Architecture of an attribute-based data sharing system

4.3 Design Goals

We aim to propose a CP-ABE scheme supporting flexible and direct revocation mechanisms. On the one hand, it achieves the following security goals.

On the other hand, the proposed scheme enjoys the following efficiency benefits.

4.4 Definition of FDR-CP-ABE

A FDR-CP-ABE scheme consists of six algorithms: Setup, KeyGen, Encrypt, UKeyGen, CTUpdate, and Decrypt, where Encrypt and CTUpdate play an important role in realizing revocation mechanisms. Particularly, there are four types of ciphertexts in FDR-CP-ABE: Type-1 ciphertexts, Type-2 ciphertexts, Type-3 ciphertexts, and Type-4 ciphertexts, which are defined in the following algorithms Encrypt and CTUpdate. It is worth noting that Type-1 and Type-2 ciphertexts are generated by encryptors in the algorithm Encrypt, while Type-3 and Type-4 ciphertexts are generated by cloud service providers in the algorithm CTUpdate.

Remark 1. We say CTW is a ciphertext if W is not involved in R. Otherwise, CTW is said to be a Type-2 ciphertext if W is involved in R. Simply speaking, Type-1 ciphertexts are not involved in revocation events while Type-2 ciphertexts are relevant to revocation events. In the concrete scheme in Section 5.3, if a user is involved in any one of revocation events in R, he fails to recover M from CTW=Encrypt(PK, M, W, R) even if his attribute set satisfies W. Hence, plays a role of attribute revocation.

Remark 2. We say is a Type-3 (resp. Type-4) ciphertext if CTW is a Type-1 (resp. Type-2) ciphertext. Furthermore, if CTW is a Type-3 (resp.Type-4) ciphertext, the updated ciphertext is still a Type-3 (resp. Type-4) ciphertext. Simply speaking, Type-3 ciphertexts are geneated by updating Type-1 or Type-3 ciphertexts, and Type-4 ciphertexts are geneated by updating Type-2 or Type-4 ciphertexts. In the concrete scheme in Section 5.3, if a user is involved in R(k), he fails to decrypt =CTUpdate(PK, CTW, UK(k), R(k)) even if he can decrypt CTW. Hence, CTUpdate plays a role of attribute revocation.

4.5 Security Model

In order to achieve the security goals considered in Section 4.3, we model the capability of adversaries. We formalize two types of adversaries: Type-I adversary AI and Type-II adversary AII. AI aims to break the confidentiality of Type-1 ciphertexts in which no attribute revocation events are involved, and hence AI is not allowed to make a secret key query on the attribute set satisfying the challenge access structure. However, AII intends to break the confidentiality of Type-2, Type-3, and Type-4 ciphertexts, which are involved in revocation events, and hence AII is allowed to make a secret key query on any attribute sets. It is worth observing that the design goals of Data Confidentiality, Collusion-Resistance and Backward and Forward Secrecy are integrated in the indistinguishability against selective ciphertext-policy and chosen plaintext attacks (IND-sCP-CPA) model, which is based on the following IND-sCP-CPA game involving an adversary Ai(i = I, II) and a simulator B. In fact, in the initialization phase of the proposed security model, AI only needs to submit a challenge access structure W* to the simulator, and AII has to additionally submit attribute revocation information R* and an attribute revocation list R*(k). In order to integrate collusion-resistance, different users are allowed to collude to guess the random bit chosen by the challenger in the security model. To demonstrate that backward and forward secrecy is reflected in the security model, different kinds of challenge ciphertexts are generated based on R* and R*(k) in the challenge phase. Hence, if the proposed scheme is proven secure in the proposed security model, it enjoys data confidentiality, collusion-resistance and backward and forward secrecy. The IND-sCP-CPA game is described as follows:

► Init: Ai(i = I, II) chooses a challenge access structure W* and submits it to B. It should be noted that attribute revocation information is published on a public bulletin board by B. In addition, AII submits attribute revocation information and R* = {R*(1), R*(2),…, R*(j)} an attribute revocation list R*(k) with k ≥ j + 1.

► Setup: B chooses a security parameter λ, and runs the Setup algorithm to get a master key SK and the corresponding system public key PK. It retains SK and gives PK to Ai.

► Phase 1: Ai issues a polynomially (in λ) bounded number of queries as follows:

► Challenge: Once Ai decides that Phase 1 is over, it outputs two equal length messages M0, M1 on which it wishes to be challenged with respect to W*. B chooses a bit b ∈R {0,1}, and generates challenge ciphertexts for Ai as follows:

► Phase 2: The same as Phase 1. Furthermore, Ai can make ciphertext update queries on challenge ciphertexts.

► Guess: Ai outputs a guess bit b' ∈ {0, 1} and wins the game if b' = b. The advantage of Ai in the above IND-sCP-CPA game is defined as .

Definition 1. A probabilistic algorithm A is said to (t, ϵ, qK)-break a FDR-CP-ABE scheme if A achieves an advantage , when running in at most steps, and making at most qK queries to the key generation oracle OKeyGen. A FDR-CP-ABE scheme is said to be (t, ϵ, qK)-secure if no forger can (t, ϵ, qK)-break it.

 

5. Construction of FDR-CP-ABE

5.1 Attribute and Access Structure

Suppose there are n attributes in universe denoted by = {w1, w2,…, wn} for a certain natural number n. And, each attribute wi would have three occurrences: positive , negative and “don't care” *, where represents a user has the attribute wi, and denotes a user does not have wi or wi is not a proper attribute of the user. We consider the access structure W that consists of AND gates on positive and negative attributes, that is, , where W ⊆ {1, 2,…,n} is the index set of attributes specified in W and i is or . If an attribute does not appear in the AND gate, its occurrence is “don't care”. This kind of policies are also adopted in [5][11]. It is noted that S W if and only if for i ∈ W, wi ∈ S when i = and wi ∉ S when i = .

5.2 Auxiliary Function

We introduce an auxiliary function Revolndex to check whether an access structure W is involved in an attribute revocation list R(k) or not. In other words, we can decide based on Revolndex if a ciphertext with the underlying access structure W should be updated when the k-th attribute revocation event occurs.

RevoIndex(PK, W, R(k)) → : On input PK, W and R(k), RevoIndex outputs the index set associated with W of users involved in the k-th attribute revocation event. Note that , where and . (k) is the set of attributes the attribute center has revoked. Let , then RevoIndex outputs , where if i = and if i = . Suppose = RevoIndex(PK, W, R(k)). If = ⵁ, the ciphertexts under W have not to be updated even if the k-th attribute revocation event occurs. Otherwise, , ≠ ⵁ, the ciphertexts under W have to be updated by the attribute center such that users specified by cannot access these ciphertexts again.

For a better understanding, we illustrate RevoIndex by an example. As shown in Table 2, we consider n = 10, m = 20, and , it easily follows that W = {1,2,4}, (k) = {w1,w2,w3} and Hence, we have and . From Table 2, where RSN deontes the revocation serial number, we know that = {1,2,5,8}. That is, when the k-th attribute revocation event occurs, the ciphertexts under have to be updated such that users specified by = {1,2,5,8} cannot access them again.

Table 2.Data structure of the attribute revocation list R(k)

5.3 Construction

► Setup(1λ): Let , be cyclic multiplicative groups of prime order p, and : × → be a bilinear map. Define a hash function H : {1, 2,… ,2n} → . The attribute center chooses a generator g ∈R , x1, x2,… ,x2n ∈R and y1, y2,…, y2n ∈R . For i = 1, 2,… ,2n, the attribute center sets ui = g-xi, Yi = (g,g)yiH(i). It also picks and α, β ∈R and sets v = gβ. Suppose the total number of users in the system is bounded above by some natural number m. For notational simplicity, we let m = {1, 2,… , m}in the following. For i = 1, 2,… , m, m + 2, m + 3,… , 2m, the attribute center computes gi = g(αi). The system public key is published as PK = . The master key is MK = <{xk,yk}1≤k≤2n, β>.

► KeyGen(PK, MK, S): Let S be an attribute set of the user who wants to obtain the corresponding attribute secret key. The attribute center chooses h ∈R for the user. Then for i ∈ {1, 2,… , n}, it computes i as follows:

Also, the attribute center computes d = , where sn ∈ {1, 2,… , m} is a serial number. Note that sn is used by the attribute center to indicate that the current user is the sn-th one to join the system. Finally, the attribute secret key is SKS = .

► Encrypt(PK, M, W, R):2 Suppose the attribute center has published a total of Nnow attribute revocation lists denoted by R. We have R = {R(i)}1≤i≤Nnow, where R(i) represents the i-th attribute revocation list. In order to encrypt a message M ∈ under a ciphertext policy , an encryptor computes , where is defined as follows:

In addition, for 1 ≤ i ≤ Nnow, the encryptor uses W and R(i) to call RevoIndex to generate = RevoIndex(PK, W, R(i)). Then, it sets , where RW represents the attribute revocation information corresponding to W in R. The encryptor chooses s ∈R and computes the ciphertext CTW of M with respect to W as follows:

► UkeyGen(PK, MK, R(k)): The attribute center chooses uk(k) ∈R , sets UK(k) = uk(k)β and computes PP(k) = vuk(k) = gUK(k). Then, it publishes PP(k) on a public bulletin board, and sends UK(k) to the cloud service provider through a secure channel.

► CTUpdate(PK, CTW, UK(k), R(k)): In order to update the ciphertext CTW according to the k-th attribute revocation list R(k), in the following, four circumstances are taken into consideration in terms of the type of CTW.

Subsequently, it sets , where . Then, if , there is no need to update. Otherwise, , the cloud service provider computes K = (g1, gm)UK(k). Then it sets = C0 · K, and computes = CR(k), where

Finally, = , which is said to be a Type-3 ciphertext.

Finally, = , which is still a Type-3 ciphertext.

► Decrypt(PK,PP,CTW,SKS): The ciphertext CTW can be decrypted by a user with secret key SKS = as follows. If S W, the algorithm returns ⊥. Otherwise, S W, there are four cases in terms of the type of CTW to be considered.

Finally, the message can be recovered as

Finally, the message can be recovered as

Finally, the message can be recovered as

 

6. Analysis of the Proposed FDR-CP-ABE Scheme

6.1 Security Analysis

Theorem 1. Suppose the decision (t, ϵ, m)-BDHE assumption holds in , then the proposed FDR-CP-ABE scheme is (t, ϵ, m)-secure, where m is an upper bound of the total number of users in the system.

Proof. Suppose there exists a t-time adversary A (AI, AII) such that . We build a simulator B that has advantage ϵ in solving the decision m-BDHE problem in . B takes as input a random decision m-BDHE challenge (g, , , Z)), where = (g1, g2, … , gm, gm+2, … , g2m) and Z is either (gm+1, ) or a random element in . The simulator B plays a role of the challenger in the IND-sCP-CPA game, and interacts with the adversary A (AI, AII) as follows.

► Init. The simulator B receives a challenge access structure specified by the adversary A (AI, AII), where with w ≤ n represents the attribute index set specified in the challenge access structure W*. In addition, AII submits attribute revocation information R* = {R*(1), R*(2), …, R*(j)} and an attribute revocation list R*(k) with k ≥ j + 1.

► Setup. B chooses j* ∈R {1,2,…,w}, xij ∈R for ij ∈ W*, and , yk ∈R for 1 ≤ k ≤ 2n. In the following, to generate components there are three cases to be considered.

Furthermore, B chooses β ∈ , and sets v = gβ(∏j∈U* gm+1-j)-1, if RW* ≠ ⵁ, where U* ⊆ RW* denotes the target set of involved users to be challenged by the adversary AII when revocation events occur, else v = gβ if RW* ≠ ⵁ. Then the system public key is PK = and B sends PK to A.

► Phase 1. The adversary A (AI, AII) makes the following queries.

Subsequently, if RW* ≠ ⵁ, B computes . It is noted that

If RW* = ⵁ, B computes d = = v(αsn). The key point is that sn ≤ m, and that since sn ∈ m - RW* we know sn ≠ j and the product defining d does not include the term gm+1. It follows that B has all the necessary values to compute the secret component d. On the other hand, if A = AII and S W*, B chooses ij ∈RW* and generates a secret key in the method above. In any case, B returns SKS = .

► Challenge. B runs the IND-sCP-CPA game under the aggregated public encryption key. We denote . Then the aggregated public encryption key is , where

B can challenge A as follows. A summits two messages M0 and M1 of equal length. B chooses b ∈R {0,1}, and computes , , and . Then B generates challenge ciphertexts for A as follows:

The challenge ciphertext is a valid encryption of Mb whenever Z = (gm+1, ). On the other hand, when Z is a random element, is independent of b in the adversary's view.

► Phase 2: The same as Phase 1. Furthermore, the adversary A can make ciphertext update queries on challenge ciphertexts.

► Guess: A outputs a guess bit b' of b. If b' = b, B outputs 1 in the m-BDHE game to guess that Z = ê(gm+1, ). Otherwise, it outputs 0 to indicate that T is a random element in . Note that if Z = (gm+1, ), then is a valid ciphertext and we have

If Z is a random element in , the message Mb is completely hidden from A, and we have

Therefore, it follows that B has advantage at least ϵ in solving decision m-BDHE in within time t. This concludes the proof of Theorem 1.

Remark 3. (A Possible Privacy Leakage) In the proposed security model, the adversaries who are able to learn of some correlations between the previous ciphertext and the updated ciphertext are not taken into consideration. It follows from the proposed scheme that many elements from are the same as CTW, which means some users may learn of the correlation between CTW and . In particular, if revoked users can find this correlation and collude with users who previously decrypt the ciphertexts, they would be able to obtain the plaintexts. So, the proposed scheme seems cannot tackle this kind of privacy leakage. In the proposed construction, it is assumed that the previous ciphertexts are deleted from storage servers by the cloud service provider. The ciphertexts which are involved in revocation events are updated based on the ciphertext update algorithm. Otherwise, revoked users only need to decrypt the previous ciphertexts to obtain corresponding plaintexts in that they have the decryption ability before revocation. On the other hand, in the proposed security model, two kinds of adversaries AI and AII are taken into account. In particular, AII is allowed to make secret key queries on any attribute sets. In the initialization phase, AII has to submit attribute revocation information R* = {R*(1), R*(2), … , R*(j)} and R*(k) with k ≥ j + 1. In the challenge phase, three types of updated ciphertexts are returned to AII as challenge ciphertexts, which are generated based on the above revocation information. However, AII fails to guess the random bit chosen by the challenger and hence finds no information about plaintexts from the challenge ciphertexts. In a word, the proposed scheme is proven secure in the proposed security model, and it has some limitations with respect to security considering the above possible privacy leakage.

6.2 Performance Comparison

In this section, we compare the security and efficiency of the proposed FDR-CP-ABE scheme with some existing revocable CP-ABE schemes [3][5][6][9][10]. The notations used in the comparison are described in Table 3. In Table 4, these schemes are compared with respect to the parameter size, the decryption cost, the type of revocation mechanisms, and the application in the setting of data sharing. It is noted that direct revocation can eliminate the performance bottleneck due to attribute secret key updates. As shown in Table 4, only the schemes in [9][10] and ours achieve direct user revocation on the system level, of which only the proposed scheme realizes direct attribute revocation. In particular, the proposed FDR-CP-ABE scheme is a directly revocable CP-ABE scheme applicable to the setting of data sharing.

Table 3.Notations used in comparisons

Table 4.Security and efficiency comparisons of revocable CP-ABE schemes

On the other hand, ciphertext size implies the communication cost in the system. We note that only the proposed FDR-CP-ABE scheme has constant-size ciphertexts. Furthermore, whenever a revocation event occurs, all the ciphertexts in schemes [3][5][6][9] have to be updated to realize secure access control, while our scheme only needs to update partial ciphertexts which are involved in revocation. Compared with the directly revocable schemes in [9], our FDR-CP-ABE is more efficient in terms of the system public key size and decryption cost. The scheme [10] has two attractive properties: (1) The generality of the proposed method; (2) The support of updating ciphretexts to others with more restrictive access policies. However, the proposed method suffers an efficient drawback in that all the ciphertexts have to be updated whenever a revocation event occurs. In addition, the proposed concrete scheme in [10] fails to support direct attribute revocation and the ciphertext length is not constant. Compared with the scheme [10], our construction is more desirable because it enjoys direct attribute revocation, partial ciphertext update, and constant-size ciphertexts. Our scheme has a disadvantage that it only achieves selective security. In future research, we will focus on directly attribute-revocable CP-ABE schemes with full security. In general, the proposed FDR-CP-ABE scheme is the first CP-ABE scheme supporting flexible and direct attribute revocation, and it has constant-size ciphertexts.

Considering the desirable properties of direct revocation, we compare schemes [9] denoted as BCP-ABE1 and BCP-ABE2, scheme [10] denoted as SSW-CP-ABE, and ours in terms of the ciphertext length and the decryption cost in Fig. 2 and Fig. 3, respectively. For the ciphertext length comparison, we set L0 = L1 = 160 bits and the number of revocation events as r = 5. Notice that the ciphertext length in the scheme BCP-ABE2 linearly increases with r. In the decryption cost comparison, we set r = 5 and the maximum number of users in the system is m = 500. In order to precisely evaluate the performance of BCP-ABE1, BCP-ABE2, SSW-CP-ABE, and FDR-CP-ABE, our simulation experiments are based on the Stanford Pairing-Based Crypto library (version 0.5.12) [29] and a Linux machine with 3.30 GHz × 8 Intel Xeon(R) E3-1230 V2 CPU and 7.5 GB of RAM. In our experiments, we consider the worst case of the access policy, which ensures that all the ciphertext components are involved in decryption. Specifically, we generate 100 distinct access policies in the form of with t(=n) increasing from 1 to 100. For each access policy, we repeat the experiment 10 times and take the average values as the final results. Given the number of revocation events, both the decryption cost of the schemes BCP-ABE1, BCP-ABE2, and SSW-CP-ABE is linearly proportional to the number of attributes or columns in access structures, and the decryption cost of ours is constant. Therefore, we argue that the proposed FDR-CP-ABE scheme is more suitable for data sharing in cloud computing.

Fig. 2.Comparison of ciphertext length

Fig. 3.Comparison of cost for decryption

 

7. FDR-KP-ABE: KP-ABE with Flexible and Direct Revocation

In this section, we show that the idea of constructing FDR-CP-ABE can be used to realize KP-ABE with flexible and direct revocation (FDR-KP-ABE). In KP-ABE, the roles of the attribute set and access policy are swapped from what we described for CP-ABE. That is, each ciphertext is labeled by the data owner with a set of descriptive attributes, while each secret key is associated with an access policy on attributes that specifies which type of ciphertexts the secret key can decrypt. A particular user can decrypt a particular ciphertext only if the ciphertext attributes satisfy the access policy of the key. An exciting application of KP-ABE is pay-TV systems, in which user access privileges are defined over content attributes and could be determined by the price they paid. In these scenarios, the issue of key revocation also exists. In order to realize flexible and direct revocation, we can introduce an auxiliary function to determine which ciphertext components are involved in some revocation events, and then use the BE technique to update these involved ciphertexts by setting the broadcast set as the index set of non-involved users. In the following, we illustrate the above method by an example.

Suppose a ciphertext corresponds to an attribute set

while a key policy W is associated to TV program package keys that a particular user receives when subscribing programs, where

Now, the user is allowed to access any programs of types "SPORT", "MOVIE", or "NEWS" provided by channel 1. Later, the system administrator wants to disable the user’s access right on programs with type "SPORT" for some reasons such as unpaid expenses. For this purpose, it is necessary to revoke the corresponding components of the user’s secret key. In fact, the storage server just needs to specify the broadcast set as the index set of all users excluding the revoked one, and then based on the technique of BE to update the ciphertext components associated with the attribute "TYPE: SPORT".

 

8. Conclusion

We formalize the notion of FDR-CP-ABE and present a concrete scheme, which is based on AND-gates policy supporting positive and negative attributes with wildcards. The proposed scheme is proven secure and enjoys desirable properties such as no secret key update, partial ciphertext update, and constant-size ciphertexts. The FDR-CP-ABE construction can be used to realize fine-grained attribute-based access control over encrypted data in cloud computing. In addition, we show that our technique is applicable to the KP-ABE counterpart.