1 Introduction

Attribute-Based Encryption (ABE) is a generalization of Identity-Based Encryption (IBE) [5, 6, 11,12,13, 48]. It provides flexibility of data sharing for system users in the sense that a data encryptor is allowed to specify some descriptive values x for an encryption and thus, the encryption can be decrypted successfully by a secret key associated with some descriptive values y matching x. ABE has many network applications, such as cloud computing [23, 35], cloud storage systems [20, 21, 34, 50] and medical e-healthcare systems [7, 17, 22, 38] etc. ABE can be classified into two different types: one is Key-Policy ABE (KP-ABE), and the other is Ciphertext-Policy ABE (CP-ABE). In a KP-ABE system, ciphertexts are associated with attribute sets and secret keys are associated with access policies. On the opposite side, in a CP-ABE scheme ciphertexts are related to access policies, and attribute sets are tagged with secret keys.

Before deploying ABE into any practical scenarios, one has to solve for the user revocation problem. No organization will be happy to see that any of its revoked users can still be able to decrypt the document designated for its users.

When we talk about revocability in ABE, there are different levels of revocation:

  1. 1.

    Attribute Revocation. In this case, the user has changed his/her attributes. For example, the original attributes for Alice are \(\{\texttt {Physics},\) \(\texttt {Student},\) \(\texttt {University A}\}\). Now she has changed to \(\{\texttt {Chemistry, Student},\) \( \texttt {University A}\}\). Therefore, the original Physics attribute should be revoked (but not Student or University A).

  2. 2.

    User Revocation. In this case, the user has left the organization. That is, all attributes have to be revoked. In the previous example of Attribute Revocation, Alice has left University A and therefore the user Alice should be revoked.

  3. 3.

    Key Revocation. In this case, the secret key of the user is revoked. This is the most generalized level of revocation. This can be happened in different scenarios. For example, the user has left the organization (case (2)). Or if the user has lost his secret key (and got a replacement key), the old one has to be revoked. It can also cover case (1): If Alice changes her attribute from Physics to Chemistry, her old key is revoked while she has been issued with a new key associated with her new attribute.

          Usually in this case the key is also associated with an identity or a serial number, which is used in the revocation process by the authority. The encryptor does not need to know this identity or number. In the rest of this paper, we refer to revocation as this case (key revocation).

1.1 Different Approaches for Revocable ABE

There are several approaches to tackle the problem of revocability in ABE:

  1. 1.

    Key Update for Non-revoked Users. This is also called the Indirect Approach. In this approach, every user has a secret key with a state. The authority will execute a key update algorithm for every non-revoked users. The keys for revoked users will not be updated. Upon the update, a new state will be issued to the secret key. Ciphertext is generated according to the current state. Therefore those revoked users who only have the secret keys of previous state(s) cannot decrypt the ciphertext which is associated with the new state.

          If the ciphertext is stored on cloud, those revoked users however are still able to decrypt the old ciphertext (generated with previous states). In order to hinder this vulnerability, a ciphertext update algorithm can be executed so that all old ciphertexts will be modified to associate with the current state. In this way, revoked users (whose secret keys are associated with an old state) can no longer decrypt any old ciphertext from the cloud as it has been updated to the current state which is only decryptable by a secret key with the new state.       Nevertheless we only regard the ciphertext update as an optional feature, as we have no way to prevent a revoked user from downloading the ciphertext (and thus decrypting the ciphertext) before he has been revoked.

          The main issue of the key update approach is the inability of instant user revocation. Suppose Alice is revoked now and the next key update algorithm is scheduled at the 1st of coming month. Alice is still able to decrypt any newly generated ciphertext from now to the end of this month. (Even if the cloud is equipped with ciphertext update, Alice cannot decrypt only those old ciphertext but still can decrypt those newly generated one.) One may try to argue that the authority may execute the key update algorithm once there is any revoked user. In the point of view of security, this action can block the loophole of inability instant user revocation. Nevertheless, it is definitely not practical especially if there are a large number of non-revoked users. In a large organization, there may be a new revoked user in every hour or even every minute. It is impossible to ask every non-revoked user to update their key every minute! If we schedule a longer key update period, the instant user revocation problem will be worse then.

  2. 2.

    Embedding Revocation List into Ciphertext. This is also called the Direct Approach. In this approach, there is a public revocation list. The encryptor embeds the latest revocation list into the ciphertext so that only those users not in the revocation list and satisfying the predicate (attributes-policy matching) can decrypt the ciphertext. This approach can provide instant user revocation (and thus solve the problem from the indirect approach). No key update is required in this approach.

          However, there is another practical problem with this approach. The revocation list will grow longer as time goes by. If the organization is large, the revocation list will become an efficiency bottleneck for the encryption and decryption as it will continue to grow all the time. There is no way to reduce or delete the revocation list, unless the revoked user re-joins the organization in the future. This is not likely to happen in most of the scenarios though.

  3. 3.

    Cloud-Assisted. Another approach is to make use of the cloud assistance. In this approach, the decryption ability is split into two halves. The first half is owned by the user while another half is owned by the cloud. The cloud needs to partially decrypt the ciphertext into an intermediate data first, which is then sent to the user for the second level decryption. If the user is revoked, the cloud refuses to execute the first level decryption. Then the revoked user cannot decrypt the ciphertext without the assistance from the cloud.

          This is the simplest way to achieve user revocation for ABE. In spite of that, the cloud will be very busy if the number of users is large, as the decryption of every user requires the assistance from the cloud.

More examples on each approach will be given in Sect. 2.

1.2 A Naïve Approach

One may immediately think of a naïve approach by combining the indirect and direct approaches together in order to possess the merits from both sides. Intuitively the simple combination is to use a key update ABE (the indirect revocable ABE) to encrypt the plaintext first into the first-level ciphertext. Then the resulting ciphertext is further encrypted using another ABE with revocation list embedded into the ciphertext (the direct revocable ABE) as the second-level. If a user is revoked before the next key update period, since his identity has been put into the revocation list embedded into the second-level ciphertext (generated by the direct revocable ABE), he cannot decrypt it. On the other side, if the revoked user’s key has been expired (that is, not being updated as it has been revoked), his identity is not needed to be put into the revocation list by the direct revocable ABE as the revoked key cannot be used to decrypt the first-level ciphertext (generated by the indirect revocable ABE) even though it can still decrypt the second level ciphertext. In this way, the revocation list can be kept short while instant revocation can be achieved and thus no frequent key update is required.

This naïve approach seems working fine, if we do not consider collusion attack. Simply speaking, collusion attack in ABE refers to two different users who both cannot decrypt the ciphertext individually but they can succeed to do so if they are colluding with each other. Suppose Alice is revoked just right now (before the next key update period) and therefore her identity Alice is in the revocation list embedded into the second-level ciphertext. Bob is another revoked user who was revoked in the previous time period. Thus his key has not been updated in the current time period and his identity Bob is not in the revocation list embedded into the second-level ciphertext. It is obviously that both Alice and Bob cannot decrypt the combined ciphertext individually. However, if they are working together, they can successfully decrypt it: Bob can use his secret key to decrypt the second-level ciphertext (as his identity is not in the revocation list) and he can pass the resulting intermediate data (which has become the first-level ciphertext) to Alice. Alice can use her secret key to decrypt this first-level ciphertext as her key is the most updated one. As a result, Alice and Bob can get the final plaintext if they are working together.

We definitely have to avoid this kind of collusion attack in any circumstance.

1.3 Our Contribution

In this paper, we propose an efficient and practical revocable CP-ABE scheme. Our scheme is motivated from the (non-revocable) CP-ABE given in [36] and incorporates the merit from all existing approaches for revocation, yet we do not have the emerged trade-off and we are immune to the collusion attack mentioned above in the naive approach. Namely,

  • We have a revocation list, which is used by the encryptor to be embedded into the ciphertext. On the other side, we also have a key update process for non-revoked users at a reasonable interval (e.g. once every two years). The revocation list only contains those revoked users whose keys are not expired yet. If their keys are expired (they are not allowed to update their keys as they are revoked), they should not be able to decrypt any ciphertext generated after their expiry date even though they are not included in the revocation list. In other words, they can be removed from the revocation list after the expiry date of their keys and thus the revocation list can be kept short.

  • Although we still require a key update process for all non-revoked users, we do not need to execute it frequently in order to provide instant key revocation. We argue that most organizations will require their users to renew their contracts at a reasonable time interval (e.g. once every two years). It is practical to renew their secret keys at the time they are renewing their contracts. This time does not need to be synchronized. Every user may have his own time for expiry and renewal.

  • We do not need the cloud in our basic system (a cloud-free system). Extension can be made to provide ciphertext update in the cloud (e.g. using the ciphertext update technique in [31, 47]) so that revoked users are no longer able to decrypt any ciphertext generated in the past.

  • We are immune to the collusion attack mentioned in the naïve approach. Suppose there is a set of users. Anyone in this set cannot decrypt the ciphertext individually. They cannot succeed to do so even if they are working together, or by someone who has the secret keys for all users in this set.

  • We use Hierarchical Identity-based Encryption (HIBE) technique to further shorten the size of user secret key. Our time period is hierarchical. That is, we have year, month and day. A user with secret key valid for the whole year can derive the key with validity for the underlying months of that year. A user with secret key valid for the whole month can derive the key with validity for the underlying days of that month. With this technique, we can further support discontinuity of user validity, which is believed as a common scenario in the practical world (e.g. no-paid leave).

We provide a concrete construction for our proposed scheme. The size of the ciphertext only depends on the embedded policy (access structure) but NOT the revocation list, though the size of the secret key is linear with the maximum length of the revocation list and the number of attributes of the user. In the decryption, the number of pairing operations only depends on the access structure but NOT the number of users in the revocation list or the total number of users in the system. The performance of our construction enjoys a significant improvement over other similar schemes.

Table 1 gives a functional comparison between other approaches and our proposed approach.

Table 1. Features comparison
Full size table

2 Related Works

There are several schemes in the literature addressing the problem of revocation in ABE. We briefly describe them using the classification in Sect. 1.Footnote 1

  1. 1.

    Key Update for Non-revoked Users (Indirect) Approach. The first revocable ABE was proposed by Boldyreva et al. [9]. It is a KP-ABE. Revocation list is stored in the authority which executes key update algorithm with each non-revoked users (those users not in the revocation list) during a regular time interval. Revoked users (without having their keys updated) cannot decrypt any newly generated ciphertext. Yu et al. [47] proposed another revocable ABE in the context of CP-ABE using key update approach. In addition, they provide a mechanism to update ciphertext so that revoked users cannot decrypt the updated ciphertext in the cloud. Nevertheless, they support policies with logical AND only. A more promising construction was given by Sahai et al. [31]. They provided constructions for both KP-ABE and CP-ABE. There are key update and ciphertext update algorithms. Ciphertext is decryptable only if the encryption time \(t < t'\) where \(t'\) is the key expiry time. If the user is revoked, ciphertext will be updated so that the newly revoked users cannot decrypt those old ciphertext (those ciphertext generated before the user is revoked). All other users will then run the key update algorithm except the revoked user.

          Later on, Xie et al. [39] (the full version of [40]), proposed a revocable CP-ABE. In their construction, each user has two keys. There is an individual key and also a group key. A group is defined as a set of users with the same attributes. Decryption requires to have the group key and the individual user secret key. Revocation is done by updating the keys of non-revoked users. Ciphertext update is also allowed as in [47]. Naruse et al. [26] proposed another CP-ABE with attribute update by the cloud server. The cloud re-encrypts the ciphertext and re-generates new secret key for users, who have updated their attributes. Similar approach has also been suggested in [27, 29].

  2. 2.

    Embedding Revocation List into Ciphertext (Direct) Approach. Another approach is called direct approach, which requires the encryptor to incorporate the revocation list in the ciphertext. In this way, users in the revocation list cannot decrypt the ciphertext even though their attributes/policy satisfy the policy/attributes associated with the ciphertext. No key update is required using this approach. Attrapadung and Imai [2] proposed a revocable ABE by incorporating the revocation information into the ciphertext. Their approach is to use broadcast encryption. That is, the encryptor needs to know the identities of those unrevoked users. They provide a KP-ABE constructions. Later, Attrapadung et al. [4] proposed another revocable KP-ABE. Different from the previous one, this construction only requires the encryptor to know the identities of revoked users (instead of unrevoked users). Wang et al. [33] proposed another revocable KP-ABE using broadcast encryption which requires the encryptor to know the list of unrevoked users. Nieto et al. [28] generalize the revocability technique to Predicate Encryption. They require the encryptor to embed the revocation list into the ciphertext. They use dual pairing vector space as the primitive and thus the number of pairing operations in the decryption is very large (linear with the number of users in the system). Balu and Kuppusamy [8] proposed a revocable CP-ABE by incorporating the revocation list. Encryptor only needs to know the identities of revoked users. However, their model is very weak. They only allow the adversary to query secret key that does not satisfy the challenge access structure AND not in the revocation list. In other words, it does not allow adversary to query a secret key that satisfies the access structure but in the revocation list. (This models the case for revoked users.) Zhang [49] proposed another revocable CP-ABE scheme using similar approach. In addition, the scheme also supports leakage resilient. But the construction only supports attribute-level revocation (the basic level of revocation). Datta et al. [15] proposed a KP-ABE construction using similar approach using multilinear maps. Liu and Wong [25] proposed a CP-ABE construction. Again they deploy similar approach but using matrix representation for users. Thus the size of ciphertext is of size \(O(\sqrt{N})\), where N is the total number of users in the system. Recently, Datta et al. [16] proposed another KP-ABE that supports revocability with this approach. This time they use subset difference technique to achieve the purpose.

          There is also a construction using either direct and indirect approach. Attrapadung and Imai [1] proposed a KP-ABE which allows the encryptor to use whether direct or indirect mode (but not both).

  3. 3.

    Cloud-Assisted Approach. With the assistance of cloud, revocation becomes easier without letting the encryptor to get the revocation list, or executing any key update for non-revoked users. Earlier stage cloud-assisted scheme [30] only provides ciphertext-update so that revoked users cannot decryp the ciphertext in the cloud. Later on, other cloud-assisted schemes require all decryption must go through the cloud as a partial process. The cloud has the control to refuse the assistance of decryption for revoked users. Without the help from the cloud, no one can decrypt the ciphertext. Hur and Noh [19] proposed a revocable CP-ABE scheme. The data owner first outsourced the data into the cloud. The cloud then re-encrypts (using a double-encryption technique) according the set of authenticated (valid) membership. The revocation is easy. The cloud just deletes the revoked user from the membership (which is a binary tree). Decryption requires the cloud to process first. It then sends the partially decrypt data to the user. Yang et al. [43] and Shi et al. [32] proposed another cloud-assisted scheme independently. In their schemes, the decryption is split into two halves. The cloud stores the first half and the user stores another half. A complete decryption requires both parts. Yang et al. [44] use similar approach. They further reduce the trust on cloud by increasing the risk of collusion with users. Recently, Cui et al. [14] reduced the trust to the cloud server by letting the cloud server to use a kind of proxy re-encryption key only.

3 Definition

3.1 Time Period

A time period can be a day, a month or a year.Footnote 2 For example, we use “2016-Jun-15” to represent a day; “2016-Dec” to represent a month etc. Our scheme can also support some special case for non-continuity. For example, if the user is going to take no-paid leave from 01 August 2016 to 29 November 2016, then we can just assign the valid period from 15 June 2016 to 31 July 2016 and from 30 November 2016 to 31 December 2016. (Assume today is 15 June 2016 and the user expiries at the end of 2016.)

A decryptable time period is a time period set by the encryptor such that only users with validity completely covered the period can decrypt. (A specific setting is to let the encrypting time to be the decryptable time period.) For example, suppose the decryptable time period is December 2016 and the validity of user secret key is only limited to 31 December 2016. This is not a complete cover and thus this secret key is not able to decrypt. On the opposite, if the decryptable time period is 01 December 2016 and the validity of user secret key is December 2016, then it is able to decrypt as it has a complete cover for the decryptable time period (provided that other conditions are also satisfied).

3.2 Definition of Revocable Ciphertext-Policy Attribute-Based Encryption

A revocable ciphertext-policy attribute based encryption scheme consists of four algorithms: Setup, KeyGen, Encrypt, Decrypt.

  • Setup(\(1^\kappa ,U,R, \mathtt{T}\)). Take as input the security parameter \(\kappa \), the number of attributes in the system U, the maximum number of revoked users in the revocation list R and the depth of the time tree \(\mathtt {T}\). It outputs the public parameters PK and a master key MK. We omit the description of \(\kappa \) in the rest of this paper.

  • KeyGen(\(MK,ID,S, \mathsf{T}\)). Take as input the master key MK, a user’s identity IDFootnote 3, a set of attributes S and a range of validity time periods T. It outputs a private key \(SK_{(ID,S,\mathsf{T})}\).

  • Encrypt(\(PK,m, \mathsf{T}_c, \mathcal {R},\mathbb {A}\)). Take as input the public parameters PK, a message m, a decryptable time period \(\mathsf{T}_c\), a revoked set \(\mathcal {R}\) and an access structure \(\mathbb {A}\) over the universe of attributes. It outputs a ciphertext CT.

  • Decrypt(\(PK,CT,\mathcal {R}, \mathbb {A},\mathsf{T}_{c},SK_{(ID,S, \mathsf{T})}\)). Take as input the public parameters PK, a ciphertext CT, along with a description of a revoked set \(\mathcal {R}\), an access policy \(\mathbb {A}\) and a decryptable time period \(\mathsf{T}_c\), and a private key \(SK_{(ID,S, \mathsf{T})}\), which is a private key for the user’s identity ID, attributes set S and the range of validity time periods T. If the user’s identity ID is not in the revoked set \(\mathcal {R}\), the set S of attributes satisfies the access structure \(\mathbb {A}\) and the range of validity time periods T completely covers the decryptable time period \(\mathsf{T}_c\), then the algorithm will decrypt the ciphertext and return a message m. Otherwise it outputs \(\perp \).

Note that we do not explicitlly define the key update algorithm as its function can be implicitly covered by the KeyGen algorithm with the new validity time period.

3.3 Security Model

We now describe a selective security model for the revocable ciphertext-policy ABE scheme. The security model is described by the following game between a challenger \(\mathcal {C}\) and an adversary \(\mathcal {A}\). In the game, \(\mathcal {A}\) needs to submit an access structure \(\mathbb {A}^*\), a revocation list \(\mathcal {R}^*\) and a decryptable time period \(\mathsf{T}^*_c\) to \(\mathcal {C}\) before seeing the public parameter PK. At any time \(\mathcal {A}\) can query for any private keys that cannot be used to decrypt the challenge ciphertext.

  • Init. \(\mathcal {A}\) needs to submit the challenge access structure \(\mathbb {A}^*\), the challenge revocation list \(\mathcal {R}^*\) and the challenge decryptable time period \(\mathsf{T}^*_c\) to the Challenger \(\mathcal {C}\).

  • Setup. \(\mathcal {C}\) runs the Setup algorithm and gives the public parameters PK to the adversary.

  • Phase 1. Adversary \(\mathcal {A}\) makes repeated private key queries corresponding to the identity ID, the attribute set S and the range of validity time periods T such that for any single returned secret key \(SK_{(ID,S,\mathsf{T})}\), at least one of the following conditions must be fulfilled:

    • S does not satisfy the access structure \(\mathbb {A}^*\).

    • \(ID \in \mathcal {R}^*\).

    • \(\mathsf{T}^*_c\) is not completely covered in T.

  • Challenge. Adversary \(\mathcal {A}\) submits two equal length messages \(m_0\) and \(m_1\). Challenger \(\mathcal {C}\) flips a random coin \(\beta \in \{0,1\}\) and encrypts \(m_{\beta }\) under the access structure \(\mathbb {A}^*\), the revoked set \(\mathcal {R}^*\) and the time \(\mathsf{T}^*_c\). The ciphertext \(CT^*\) is given to adversary \(\mathcal {A}\).

  • Phase 2. It is the same as in Phase 1.

  • Guess. The adversary outputs a guess \(\beta '\) for \(\beta \).

The advantage of adversary \(\mathcal {A}\) in the above game is defined as \(Adv_{\mathcal {A}}=Pr[\beta '=\beta ]-1/2\).

Definition 3.1

A revocable ciphertext-policy attribute-based encryption scheme is secure if all polynomial time adversaries have at most a negligible advantage in the above game.

Other mathematical background is provided in the full version [24].

4 Our Scheme

4.1 Overview

Our scheme is motivated by the (non-revocable) CP-ABE scheme in [36]. We first add a revocation list in the ciphertext so that users in the revocation list cannot decrypt. We then add time validity to user secret key and a decryptable time period in the ciphertext. Users without having a complete cover of validity for the decryptable time period cannot decrypt. (Readers may refer to Sect. 3.1 for more details.)

Observe that the valid time always have the “AND” relation with the user attributes. Therefore, we have to attach the time validity tightly to the secret key in order to avoid the collusion attack. A naïve approach is to treat each time period as an attribute. In the policy, we just need to add the “AND” relation with all valid time periods (that is, time-attributes) together with the original policy. It works fine, if the number of valid time periods in the system is small. Otherwise, the size of public parameters and user secret key will be very large as they grow linear with the number of attributes (that is, number of time periods in this naïve approach). For example, if the system supports up to 10 years and the smallest unit of time period is day, then there will be more than 3000 time-attributes in the system!

If the user is revoked before the normal expiry time, the user ID will be put into the revocation list until his expiry time has passed. Anyone whose ID is in the revocation list will not be able to decrypt any ciphertext, regardless of his attributes. The idea of the revocation approach is motived from [3, 4].

Also note that we have the same restriction as the scheme in [36] using the decisional BDHE assumption (the first scheme). That is, an attribute can only be used in at most one row in the ciphertext access matrix M (the function \(\rho (\cdot )\) is injective). This can be thought of as an attribute appearing in at most one node in a formula. However, this limitation can be easily mitigated by assigning a different string for each time an attribute is associated with a row in an access structure.

4.2 Technical Construction

We borrow the idea from the Boneh-Boyen-Goh Hierarchical Identity-based Encryption (HIBE) scheme [10] to apply in our time validity control. We take advantage of the fact that the validity period of a user’s key or ciphertext is usually represented as some time interval (e.g. from January to December), instead of some discrete time segments (e.g. January and March and July and December). Therefore, we use a tree-based approach to further improve the efficiency for continuous time interval. The advantage is two-fold. Firstly, the size of the user secret key is reduced. Secondly, if the encryptor wants to encrypt the message for some time interval, then only the user with keys valid in the complete time interval can decrypt. At the same time, the size of the ciphertext is still independent of the length of the time interval.

We use the set-cover approach to select the minimum number of nodes that can represent all the valid time periods. A node (except the root node) in the tree represents a time period. By using HIBE, the user obtains the keys corresponding to these nodes only. Consider the following example:

figure a

The first level represents the year. The second level represents the month. The third level represents the day.

Suppose an employee joins the company on 29 November 2015 and his contract ends on 31 December 2016. He should obtain keys for the nodes of “2015-Nov-29”, “2015-Nov-30”, “2015-Dec” and “2016”. For the encryptor, he can choose to encrypt a message for a specific day, for a whole month or whole year. The employee who is authorized for the whole month can decrypt the ciphertext for the whole month. On the other hand, if the ciphertext is specified for a single day only, the employee can derive the decryption key from the corresponding month or year key using the HIBE approach.

In order to simplify the description, suppose the time tree has depth T and each node have z children. A time period (e.g. a day, a month, a year) can be represented by a z-ary element \((\tau _1, \tau _2, \ldots , \tau _k)\) for some \(k < \mathtt{T}\). Our construction is as follows.

  1. 1.

    Setup\((U,R,\mathtt{T})\): U is the number of attributes in the system. Time is represented as a z-ary string \(\{1,z\}^{\mathtt{T}-1}\). The maximum number of revoked users is \(R-1\). Choose a bilinear group \(\mathbb {G}\) of prime order p with a random generator g and U random elements \(h_1,\ldots ,h_{U},\in \mathbb {G}\). Randomly choose \(\alpha ,\alpha _0\in \mathbb {Z}_p\) and \(\varvec{\alpha }=(\alpha _1, \ldots , \alpha _{R})^{\top } \in _R \mathbb {Z}_p^R\), \(V_0, V_1, \ldots , V_\mathtt{T} \in _R \mathbb {G}\), set

    $$\begin{aligned} \varvec{\mathbf {F}} = g^{\varvec{\mathbf {\alpha }}}=(g^{\alpha _1},\cdots ,g^{\alpha _R})^{\top } = (f_1,\ldots ,f_R)^{\top }. \end{aligned}$$

    Output \(PK= \Big \{g, g^{\alpha _0},e(g,g)^\alpha ,h_1,\ldots , h_{U}, V_0, V_1, \ldots , V_\mathtt{T}, \varvec{\mathbf {F}} \Big \}\) and \(MK= \alpha \).

  2. 2.

    KeyGen\((MK,{ID}, S, \mathsf{T})\): S is the set of attributes of a user with identity ID. \(\mathsf{T}\) is the range of validity time periods for the user ID. Denote \(\mathbb {T}\) as the set-cover representing T which consists of some time elements \(\tau = (\tau _1, \tau _2, \ldots , \tau _{k_\tau }) \in \{1,z\}^{k_\tau }\) where \(k_\tau < \mathtt{T}\) for any \(\tau \in \mathbb {T}\).Footnote 4 Randomly choose \(u, t, v_\tau \in _R \mathbb {Z}_p\) for all \(\tau \in \mathbb {T}\) and compute

    $$\begin{aligned} D_0= & {} g^t , \qquad D'_0 = g^u , \qquad \Big \{D_{0,\tau }^{''} = g^{v_\tau } \Big \}_{\tau \in \mathbb {T}} , \\ \Big \{D_{1,\tau }= & {} g^{\alpha } g^{\alpha _0 t} g^{\alpha _1 u} (V_0 \prod _{j=1}^{k_\tau } V_j^{\tau _j})^{v_\tau } \Big \}_{\tau \in \mathbb {T}}, \qquad \{L_{j,\tau } = V_j^{v_\tau } \}_{j = k_\tau +1 ,\ldots , \mathtt{T}, \tau \in \mathbb {T}},\\ \{K_x= & {} h_x^t\}_{x\in S}, \qquad \Big \{F_i = (f_1^{-ID^{i-1}}\cdot f_i)^u \Big \}_{i=2,\cdots ,R}. \end{aligned}$$

    Output

    $$ SK_{(ID, S, \mathsf{T})} = \Big \{ D_0,D'_0, \{D_{0,\tau }^{''}, D_{1,\tau }, L_{k_\tau +1, \tau }, \ldots , L_{\mathtt{T}, \tau }\}_{\tau \in \mathbb {T}}, \{K_x\}_{x\in S}, \{F_i\}_{i=2,\cdots ,R} \Big \} $$

    as the user secret key for the user with identity ID, attribute set S and time validity period T.

  3. 3.

    Encrypt\((PK, m, \mathsf{T}_c, \mathcal {R}, \mathbb {A}=(M,\rho ))\): \(\mathcal {R}=({ID}_1,\ldots , {ID}_r )\) is the revocation list with r revoked users and \(r<R\). \(m \in \mathbb {G}_T\) is the plaintext message and \(\mathsf{T}_c\) is the decryptable time period of this ciphertext. Let \(\tau _c = (\tau _1, \ldots , \tau _k) \in \{1,z\}^k\) be the z-ary representation of \(\mathsf{T}_c\), where \(k < \mathtt{T}\).Footnote 5 Take as input an LSSS access structure \(\mathbb {A}=(M,\rho )\). The function \(\rho \) associates rows of M to attributes. Let M be an \(\ell \times n\) matrix. The algorithm first chooses a random vector \(\varvec{\mathbf {v}}=(s, y_2, \ldots , y_n) \in \mathbb {Z}_p^n\). These values will be used to share the encryption exponent s. For \(i = 1\) to \(\ell \), it calculates \(\lambda _i = \langle \varvec{\mathbf {v}}, M_i \rangle \), where \(M_i\) is the vector corresponding to the ith row of M. Also let

    $$\begin{aligned} \mathcal {F}_{\mathcal {R}}(Z) = (Z-{ID}_1)\cdots (Z-{ID}_r)=y_1+y_2 Z+\cdots +y_{r}Z^{r-1}+y_{r+1} Z^r. \end{aligned}$$
    (1)

    If \(r+1<R\), the coefficients \(y_{r+2},\cdots ,y_R\) are set to 0. Compute

    $$\begin{aligned} C_0= & {} m \cdot e(g,g)^{\alpha s}, \ \ C_0^{'} = g^s , \ \ C_0^{''} = (f_1^{y_1}\cdots f_R^{y_R})^s , \ \ C_0^{'''} = (V_0 \prod _{j=1}^k V_j^{\tau _j})^s,\\ C_1= & {} g^{\alpha _0 \lambda _1 } h_{\rho (1)}^{-s}, \ \ \ldots , \ \ C_\ell = g^{\alpha _0 \lambda _\ell } h_{\rho (\ell )}^{-s}. \end{aligned}$$

    Output a ciphertext CT = \(\{C_0\), \(C_0^{'}\), \(C_0^{''}\), \(C_0^{'''}\), \(C_1\), \(\ldots \), \(C_\ell \}\) along with a description of \(\mathsf{T}_c, (M,\rho )\) and the revoked set \(\mathcal {R}\).

  4. 4.

    Decrypt\((CT,\mathcal {R},SK_{(ID,S,\mathsf{T})})\): First define \(\varvec{\mathbf {X}}\) = (1, ID, \(\cdots \), \(ID^{R-1})\) from the identity ID and \(\varvec{\mathbf {Y}}=(y_1,\cdots ,y_{R}) \) from the revoked set \(\mathcal {R}\) (where \(y_i\), \(i=1,\ldots , R\) are defined as in equation (1)). Note that

    $$ \langle \varvec{\mathbf {X}},\varvec{\mathbf {Y}}\rangle = y_1 + y_2 ID + \ldots + y_r ID^{r-1} + y_{r+1} ID^r = \mathcal {F}_{\mathcal {R}}(ID), $$

    and if \(r+1<R\), the coefficients \(y_{r+2},\cdots ,y_R\) are 0. If any one of the following conditions occurs, output \(\perp \):

    • S does not satisfy the access structure \((M, \rho )\).

    • \(ID \in \mathcal {R}\). That is, \(\langle \varvec{\mathbf {X}},\varvec{\mathbf {Y}}\rangle = \mathcal {F}_{\mathcal {R}}(ID) = 0\).

    • \(\mathsf{T}_c\) is not completely covered in T. That is, \(\tau _c\) and all its prefixes are not in \(\mathbb {T}\), where \(\tau _c\) is the z-ary representation for \(\mathsf{T}_c\) and \(\mathbb {T}\) is the set-cover for T.

    Otherwise, now we have \(ID \notin \mathcal {R}\) (that is, \(\langle \varvec{\mathbf {X}},\varvec{\mathbf {Y}}\rangle \ne 0\)). First compute

    $$ F=\prod _{i=2}^RF_i^{y_i} = \Big (f_1^{-\langle \varvec{\mathbf {X}},\varvec{\mathbf {Y}}\rangle }\cdot \prod _{i=1}^Rf_i^{y_i} \Big )^u \text { and } \varsigma _1=\Big (\frac{e(F,C_0')}{e(D'_0,C_0^{''})}\Big )^{\frac{-1}{\langle \varvec{\mathbf {X}},\varvec{\mathbf {Y}}\rangle }} = e(g,g)^{\alpha _1su} . $$

    Further let \(I \subset \{1, 2, \ldots , \ell \}\) be defined as \(I = \{ i: \rho (i) \in S \}\). Then, let \(\{\omega _i \in \mathbb {Z}_p \}_{i \in I}\) be a set of constants such that if \(\{ \lambda _i \}\) are valid shares of any secret s according to M, then \(\sum _{i \in I} \omega _i \lambda _i = s\). Compute

    $$\begin{aligned} \varsigma _2=\prod _{i\in I} (e(C_i,D_0)\cdot e(C_0^{'},K_{\rho (i)}))^{\omega _i} = e(g,g)^{\alpha _0st} . \end{aligned}$$

    If \(\tau _c = (\tau _1, \ldots , \tau _k) \in \mathbb {T}\), \(D_{1,\tau _c}\) should be one of the components in the secret key. Otherwise, let its prefix \(\tau '_c = (\tau _1, \ldots , \tau _{k'})\), where \(k' < k\), such that \(\tau '_c \in \mathbb {T}\). Then derive the key from the secret key with respect to \(\tau '_c\) as follows: \( D_{1,\tau _c} = D_{1,\tau '_c} \prod _{j=k'+1}^k L_{j, \tau '_c}^{\tau _j}, \) and set \(\tau _c = \tau '_c\). Finally, compute \( m=\frac{C_0 \cdot \varsigma _1\cdot \varsigma _2 \cdot e(D_{0,\tau _c}^{''}, C_0^{'''})}{e(D_{1,\tau _c},C_0') } . \)

We provide the correctness and security analysis in the full version [24].

4.3 Future Enhancements

There are some future enhancements that we can further improve upon the current construction:

  • To lift the restriction for repeated attributes while keeping simple or standard assumption. We note that [37] provided a construction for non-revocable CP-ABE that has removed this restriction. Yet they use a non-standard assumption (decisional parallel BDHE assumption). Theoretically speaking, we can build up a system based on this scheme. However, the resulting system will also rely on the decisional parallel BDHE assumption.

  • To add ciphertext update for revoked users (so that they cannot decrypt those ciphertext generated in the past). We can use the technique of proxy re-encryption to achieve this. But we believe this is not the most essential feature of a revocable ABE since revoked users can anyway decrypt the past ciphertext before they are revoked. If they have done so, it has no use to re-encrypt the ciphertext unless the system is fully cloud-based (e.g. cloud-assisted approach).

5 Performance Analysis

We first compare the efficiency of our scheme with other revocable ABE schemes. We present our comparison in Table 2. We use the following symbols in our comparison table:

Table 2. Efficiency comparison
Full size table

  • R: max number of revoked users; U: max number of attributes in the system

  • T: number of time period level (depth of time tree)

  • N: max number of users in the system; S: number of attributes of the user

  • r: number of revoked users in the revocation list

  • \(\ell \): number of rows of the access structure matrix

  • I: number of attributes used in the decryption

  • L: max number of length of input wires (exclusive for [15] only)

  • Q: max number of gates (exclusive for [15] only)

  • \(\mathbb {G}_T\): number \(\mathbb {G}_T\) elements; \(\mathbb {G}\): number \(\mathbb {G}\) elements

Note that we exclude the following for the comparison as they are of different features or security level with our scheme:

  • Using indirect approach and cloud-assisted approach (such as those listed in Sect. 2), as they cannot support instant revocation or require a cloud server to assist decryption.

  • Using broadcast encryption technique (such as [2, 33]) as they require the encryptor to know the identity of all possible decryptors, which is not exactly an ABE but more or less similar to a broadcast encryption in nature.

  • Weak security model [8]. Their model is very week. They only allow the adversary to query secret key that does not satisfy the challenge access structure AND not in the revocation list. Under this model, the collusion attack we mentioned in Sect. 1.2 is NOT considered as a valid attack. That means their model cannot capture such a low-level attack.

  • Attribute-level revocation only [49]. They only support attribute-level revocation, instead of the more generalized user-level or key-level revocation.

From the comparison, we can see that our scheme is the most efficient CP-ABE using direct approach for revocation. In practice, T can be very small. For example, if we only consider year, month and day, T = 3. Our space and computation complexity do not depend on N, the total number of users in the system, which is supposed to be a very large number.

6 Conclusion

In this paper, we proposed a revocable CP-ABE scheme based on the direct revoke approach. That is, the revocation list is embedded into the ciphertext so that instant revocation can be achieved. In order to shorten the revocation list, we further propose a time validity technique so that expired users cannot decrypt ciphertext associated with a decryptable time period not completely covered under their validity period. We deploy a tree-based structure and HIBE technique to construct the time validity part. The efficiency analysis also shows that our scheme is practical enough to be deployed.