1.1 Our contributions

In this paper, we show that it is possible to design an RIBE scheme with the SD method in a generic way. As described above, the generic RIBE scheme with the CS method uses IBE and two-level HIBE schemes as basic building blocks [18]. On the contrary, our generic RIBE scheme with the SD method uses IBE, identity-based revocation (IBR), and two-level HIBE schemes as basic building blocks. The IBR scheme is a special type of identity-based broadcast encryption (IBBE) scheme in which a set R of revoked users is specified in an IBR ciphertext whereas a set S of receivers is specified in an IBBE ciphertext. The newly derived RIBE scheme with the SD method consists of O(r) number of IBE and IBR private keys in an update key and O(log² N) number of IBE and IBR ciphertexts in a ciphertext. Compared with the previous generic RIBE scheme with the CS method, the size of an update key is reduced but the size of a ciphertext is increased. The detailed comparison of RIBE schemes is given in Table 1.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Table 1. Comparison of revocable identity-based encryption schemes.

https://doi.org/10.1371/journal.pone.0239053.t001

To analyze the security of our generic RIBE scheme with the SD method, we show that if the underlying IBE, IBR, and HIBE schemes are adaptively (or selectively) secure under chosen plaintext attacks, then the proposed generic RIBE scheme is also adaptively (or selectively) secure under chosen plaintext attacks. The key idea of our proof is to first divide the types of an attacker according to the queries of the attacker, and to isolate the attacker of a specific type to break the security of the underlying IBE, IBR, or HIBE scheme. However, this idea is not simple to apply since the SD method has a complicated subset cover structure unlike the CS method. To handle this complicated structure in a ciphertext, we introduce additional hybrid games in the security proof and handle each ciphertext element of the challenge ciphertext one by one.

In addition, we show that it is possible to reduce the size of a ciphertext by extending our generic RIBE scheme to use the more efficient LSD method instead of using the SD method, but this modified scheme increases the size of an update key slightly. We also show that our generic RIBE scheme which provides only chosen-plaintext attack (CPA) security can be extended to provide the security against the more powerful chosen-ciphertext attacker (CCA). To provide the CCA security of RIBE, the underlying IBE, IBR, and HIBE schemes should provide the CCA security and a one-time signature scheme with strong unforgeability should be used.

1.2 Related work

2.1 Identity-based encryption

Identity-based encryption (IBE) is a kind of public key encryption (PKE) that can use a receiver’s identity as a public key [2]. In IBE, a sender generates a ciphertext by encryption a message for the receiver’s identity ID. A receiver retrieves a private key corresponding to his identity ID from a trusted center and then decrypts the ciphertext if the identity of the ciphertext is equal to the identity of the private key. The detailed syntax of IBE is given as follows.

Definition 2.1 (Identity-Based Encryption, IBE). Let be an identity space and be a message space. An IBE scheme consists of four algorithms Setup, GenKey, Encrypt, and Decrypt, which are defined as follows:

1. Setup(1^λ): The setup algorithm takes as input a security parameter 1^λ. It outputs a master key MK and public parameters PP.
2. GenKey(ID, MK, PP): The private key generation algorithm takes as input an identity , the master key MK, and public parameters PP. It outputs a private key SK_ID.
3. Encrypt(ID, M, PP): The encryption algorithm takes as input an identity , a message , and public parameters PP. It outputs a ciphertext CT_ID.
4. Decrypt(CT_ID, SK_ID′, PP): The decryption algorithm takes as input a ciphertext CT_ID, a private key SK_ID′, and public parameters PP. It outputs a message M.

The correctness of IBE is defined as follows: For all MK and PP generated by Setup(1^λ), SK_ID generated by GenKey(ID, MK, PP) for any ID, and any ID and M, it is required that

• Decrypt(Encrypt(ID, M, PP), SK_ID, PP) = M.

The security model of IBE is defined by extending the IND-CPA security model of PKE to allow additional private key queries [2]. In this model, an attacker can request a private key of an identity ID. In the challenge stage, the attacker submits a challenge identity ID* and challenge messages , , and then receives a challenge ciphertext CT*. The attacker further queries private keys and finally guesses the message hidden in CT*. The detailed description of the security model of IBE is given as follows.

Definition 2.2 (IND-CPA Security). The IND-CPA security of IBE is defined in terms of the following game between a challenger and a PPT adversary :

1. Setup: generates a master key MK and public parameters PP by running Setup(1^λ). It keeps MK to itself and gives PP to .
2. Phase 1: may adaptively request private keys for identities . In response, gives the corresponding private keys to by running GenKey(ID_i, MK, PP).
3. Challenge: submits a challenge identity ID* and two messages with the equal length subject to the restriction: for all ID_i of private key queries, ID_i ≠ ID*. flips a random coin μ ∈ {0, 1} and gives the challenge ciphertext CT* to by running Encrypt .
4. Phase 2: may continue to request private keys for ID_q1+1, …, ID_q.
5. Guess: outputs a guess μ′ ∈ {0, 1} of μ, and wins the game if μ = μ′.

The advantage of is defined as where the probability is taken over all the randomness of the game. An IBE scheme is IND-CPA secure if for all PPT adversary , the advantage of is negligible in the security parameter λ.

2.2 Identity-based revocation

Identity-based revocation (IBR) is a kind of public-key broadcast encryption (PKBE) [26], in which a large number of users with identities can participate to the system and a sender can specify the set R of revoked users in a ciphertext instead of the set S of receivers. In IBR, a sender generates a ciphertext CT by using a revoked set R and a message M, and then broadcasts the ciphertext. A receiver retrieves a private key for his or her identity from a trusted central and decrypt the ciphertext if his or her identity is not included in the set R. The detailed syntax of IBR is given as follows.

Definition 2.3 (Identity-Based Revocation, IBR). An IBR scheme consists of four algorithms Setup, GenKey, Encrypt, and Decrypt, which are defined as follows:

1. Setup(1^λ): The setup algorithm takes as input a security parameter 1^λ. It outputs a master key MK and public parameters PP.
2. GenKey(ID, MK, PP): The private key generation algorithm takes as input an identity , the master key MK, and public parameters PP. It outputs a private key SK_ID.
3. Encrypt(R, M, PP): The encryption algorithm takes as input revoked identities , a message , and public parameters PP. It outputs a ciphertext CT_R.
4. Decrypt(CT_R, SK_ID, PP): The decryption algorithm takes as input a ciphertext CT_R, a private key SK_ID, and public parameters PP. It outputs a message M.

The correctness of IBR is defined as follows: For all MK and PP generated by Setup(1^λ), SK_ID generated by GenKey(ID, MK, PP) for any ID, and any R such that ID ∉ R and any M, it is required that

• Decrypt(Encrypt(R, M, PP), SK_ID, PP) = M.

The security model of IBR is defined by extending the IND-CPA security model of PKBE to account for the revoked set R [26]. In this model, an attacker requests private key queries on identities. In the challenge step, the attacker submits a challenge revoked set R* and the challenge message and receives a challenge ciphertext CT*. The attacker additionally requests private key queries and finally guesses the hidden message in CT*. In this game, all identities of private keys must belong to the revoked set R*. The detailed description of the security model is given as follows.

Definition 2.4 (IND-CPA Security). The IND-CPA security of IBR is defined in terms of the following game between a challenger and a PPT adversary :

1. Setup: generates a master key MK and public parameters PP by running Setup(1^λ). It keeps MK to itself and gives PP to .
2. Phase 1: may adaptively request private keys for identities . In response, gives the corresponding private keys to by running GenKey(ID_i, MK, PP).
3. Challenge: submits a challenge revoked set R* of users and two messages with the equal length subject to the restriction: for all ID_i of private key queries, ID_i ∈ R*. flips a random coin μ ∈ {0, 1} and gives the challenge ciphertext CT* to by running Encrypt .
4. Phase 2: may continue to request private keys for ID_q1+1, …, ID_q.
5. Guess: outputs a guess μ′ ∈ {0, 1} of μ, and wins the game if μ = μ′.

The advantage of is defined as where the probability is taken over all the randomness of the game. An IBR scheme is IND-CPA secure if for all PPT adversary , the advantage of is negligible in the security parameter λ.

2.3 Hierarchical identity-based encryption

Hierarchical identity-based encryption (HIBE) is an extension of IBE in which a hierarchical identity is used to represent a user’s identity and the delegation of private keys is provided [3, 35]. In HIBE, a user receives a private key for his hierarchical identity from a trusted center, or receives a delegated private key from another user. If a sender creates a ciphertext for a receiver’s hierarchical identity and transmits it to a receiver, then the receiver can decrypt the ciphertext by using his private key if the hierarchical identity of his private key is a prefix of the hierarchical identity of the ciphertext.

Let HID = (ID₁, …, ID_k) be an identity vector of size k. We let HID|_j be a vector (ID₁, …, ID_j) of size j derived from HID. We define a function Prefix(HID|_k) that returns a set of prefix vectors {HID|_j}_1≤j≤k where HID|_k = (ID₁, …, ID_k). The detailed syntax of HIBE is given as follows.

Definition 2.5 (Hierarchical Identity-Based Encryption, HIBE). An HIBE scheme consists of five algorithms Setup, GenKey, Delegate, Encrypt, and Decrypt, which are defined as follows:

1. Setup(1^λ, L_max). The setup algorithm takes as input a security parameter 1^λ and maximum hierarchical depth L_max. It outputs a master key MK and public parameters PP.
2. GenKey(HID|_k, MK, PP). The key generation algorithm takes as input a hierarchical identity where k ≤ L_max, the master key MK, and the public parameters PP. It outputs a private key .
3. Delegate(). The delegation algorithm takes as input a hierarchical identity HID|_k, a private key for HID|_k−1, and the public parameters PP. It outputs a delegated private key .
4. Encrypt(HID|_ℓ, M, PP). The encryption algorithm takes as input a hierarchical identity where ℓ ≤ L_max, a message M, and public parameters PP. It outputs a ciphertext .
5. Decrypt(). The decryption algorithm takes as input a ciphertext , a private key , and public parameters PP. It outputs a message M.

The correctness of HIBE is defined as follows: For all MK, PP generated by Setup(1^λ, L_max), all HID|_ℓ, HID|_k, any generated by GenKey(HID|_k, MK, PP) such that HID|_k ∈ Prefix(HID|_ℓ), it is required that

• .

The security model of HIBE is defined by extending the security model of IBE to include additional private key delegations [3, 35]. That is, an attacker can request delegated private key queries together with general private key queries. In this case, if the distribution of general private keys and the distribution of delegate private keys are the same, then we can only consider general private key queries to simplify the security model. The detailed security model of HIBE is given as follows.

Definition 2.6 (IND-CPA Security). The IND-CPA security of HIBE is defined in terms of the following game between a challenger and a PPT adversary :

1. Setup: generates a master key MK and public parameters PP by running Setup(1^λ, L_max). It keeps MK to itself and gives PP to .
2. Phase 1: may adaptively request a polynomial number of private key queries. In response, gives a corresponding private key to by running GenKey(HID|_k, MK, PP) for each query.
3. Challenge: submits a challenge hierarchical identity HID*|_ℓ and two messages with the equal length subject to the restriction: for each HID|_k of private key queries, HID|_k ∉ Prefix(HID*|_ℓ). flips a random coin μ ∈ {0, 1} and gives a challenge ciphertext CT* to by running Encrypt .
4. Phase 2: may continue to request private key queries.
5. Guess: outputs a guess μ′ ∈ {0, 1} of μ, and wins the game if μ = μ′.

The advantage of is defined as where the probability is taken over all the randomness of the game. An HIBE scheme is IND-CPA secure if for all PPT adversary , the advantage of is negligible in the security parameter λ.

2.4 Revocable identity-based encryption

Revocable identity-based encryption (RIBE) is an extension of existing identity-based encryption (IBE) to support private key revocation [6]. In RIBE, each user receives a private key for his or her identity ID from a trusted center. The trusted center then periodically generates an update key which is associated with time T and a non-revoked user set, and then it broadcasts the update key through the public channel. In this case, if the private key of a user is not revoked in the update key, the user can derive a decryption key for ID and T by combining the private key and the update key, and this decryption key can be used to decrypt a ciphertext which is related with ID and T. The syntax of RIBE is given as follows.

Definition 2.7 (Revocable IBE, RIBE). An RIBE scheme consists of seven algorithms Setup, GenKey, UpdateKey, DeriveKey, Encrypt, Decrypt, and Revoke, which are defined as follows:

1. Setup(1^λ): The setup algorithm takes as input a security parameter 1^λ. It outputs a master key MK, an (empty) revocation list RL, and public parameters PP.
2. GenKey(ID, MK, PP): The private key generation algorithm takes as input an identity , the master key MK, and public parameters PP. It outputs a private key SK_ID.
3. UpdateKey(T, RL, MK, PP): The update key generation algorithm takes as input update time , the revocation list RL, the master key MK, and public parameters PP. It outputs an update key UK_T.
4. DeriveKey(SK_ID, UK_T, PP): The decryption key derivation algorithm takes as input a private key SK_ID, an update key UK_T, and public parameters PP. It outputs a decryption key DK_ID,T.
5. Encrypt(ID, T, M, PP): The encryption algorithm takes as input an identity , time T, a message , and public parameters PP. It outputs a ciphertext CT_ID,T.
6. Decrypt(CT_ID,T, DK_{ID′, T′}, PP): The decryption algorithm takes as input a ciphertext CT_ID,T, a decryption key DK_{ID′, T′}, and public parameters PP. It outputs a message M.
7. Revoke(ID, T, RL): The revocation algorithm takes as input an identity ID to be revoked and revocation time T, and a revocation list RL. It outputs an updated revocation list RL.

The correctness of RIBE is defined as follows: For all MK, RL, and PP generated by Setup(1^λ), SK_ID generated by GenKey(ID, MK, PP) for any ID, UK_T generated by UpdateKey(T, RL, MK, PP) for any T and RL such that (ID, T_j)∉RL for all T_j ≤ T, CT_ID,T generated by Encrypt(ID, T, M, PP) for any ID, T, and M, it is required that

• Decrypt(CT_ID,T, DeriveKey(SK_ID, UK_T, PP), PP) = M.

The security model of RIBE was first defined by Boldyreva et al. [6], and then this security model was extended by Seo and Emura [9] to support decryption key exposure resistance. In the security model of RIBE, an attacker can request a private key query for an identity ID, an update key query for time T, a decryption key query for ID and T, and a revocation query. In the challenge step, the attacker submits a challenge identity ID*, challenge time T*, and challenge messages , and receives a challenge ciphertext CT*. Note that the private key query for ID* is not allowed in the IBE security model, but this private key query for ID* is allowed in the RIBE security model. At this time, if the private key for ID* is queried, then the private key for ID* must be revoked in the update key on the challenge time T*. The detailed definition of the RIBE security model is given as follows.

Definition 2.8 (IND-CPA Security). The IND-CPA security of RIBE is defined in terms of the following experiment between a challenger and a PPT adversary :

1. Setup: generates a master key MK, a revocation list RL, a state ST, and public parameters PP by running Setup(1^λ). It keeps MK, RL to itself and gives PP to .
2. Phase 1: adaptively request a polynomial number of queries. These queries are processed as follows:
   • If this is a private key query for an identity ID, then it gives the corresponding private key SK_ID to by running GenKey(ID, MK, PP).
   • If this is an update key query for time T, then it gives the corresponding update key UK_T,R to by running UpdateKey(T, RL, MK, PP).
   • If this is a decryption key query for an identity ID and time T, then it gives the corresponding decryption key DK_ID,T to by running DeriveKey(SK_ID, UK_T, PP).
   • If this is a revocation query for an identity ID and revocation time T, then it updates the revocation list RL by running Revoke(ID, T, RL, ST) with the restriction: The revocation query for time T cannot be queried if the update key query for the time T was already requested.
   
   Note that we assume that the update key queries and the revocation queries are requested in non-decreasing order of time.
3. Challenge: submits a challenge identity ID*, challenge time T*, and two challenge messages with equal length with the following restrictions:
   • If a private key query for an identity ID such that ID = ID* was requested, then the identity ID* should be revoked at some time T such that T ≤ T*.
   • The decryption key query for ID* and T* was not requested.
   
   flips random μ ∈ {0, 1} and obtains a ciphertext CT* by running Encrypt . It gives CT* to .
4. Phase 2: may continue to request a polynomial number of additional queries subject to the same restrictions as before.
5. Guess: Finally, outputs a guess μ′ ∈ {0, 1}, and wins the game if μ = μ′.

The advantage of is defined as where the probability is taken over all the randomness of the experiment. An RIBE scheme is IND-CPA secure if for all PPT adversary , the advantage of is negligible in the security parameter λ.

3.1 Binary tree

A perfect binary tree is a tree data structure in which all internal nodes have two child nodes and all leaf nodes have the same depth. Let N = 2ⁿ be the number of leaf nodes in . The number of all nodes in is 2N − 1 and we denote v_i as a node in for any 1 ≤ i ≤ 2N − 1. The depth d_i of a node v_i is the length of the path from a root node to the node. The root node of a tree has depth zero. The depth of is the length of the path from the root node to a leaf node. A level of is a set of all nodes at given depth.

Each node has an identifier L_i ∈ {0, 1}* which is a fixed and unique string. An identifier of each node is assigned as follows: Each edge in the tree is assigned with 0 or 1 depending on whether it is connected to the left or right child node. The identifier L_i of a node v_i is obtained by reading all labels of edges in a path from the root node to the node v_i. The root node has an empty identifier ϵ. For a node v_i, we define Label(v_i) be the identifier of v_i and Depth(v_i) be the depth d_i of v_i.

A subtree in is defined as a tree that is rooted at a node . A subset S_i is defined as a set of all leaf nodes in . For any two nodes where v_j is a descendant of v_i, is defined as a subtree , that is, all nodes that are descendants of v_i but not v_j. A subset S_i,j is defined as the set of leaf nodes in , that is, S_i,j = S_i\S_j.

For a perfect binary tree and a subset R of leaf nodes, is defined as the Steiner Tree induced by the set R and the root node, that is, the minimal subtree of that connects all the leaf nodes in R and the root node.

3.2 Subset difference method

The subset difference (SD) method is one instance of the subset cover (SC) framework proposed by Naor et al. [19] which was used for efficient symmetric key broadcast encryption. The SD method is more efficient than the complete subtree (CS) method because the size of the cover set representing the non-revoked users is smaller than that of the CS method. We follow the SD definition of Lee et al. [36]. The SD method uses a perfect binary tree and each user is located at a leaf node in the binary tree. The Assign algorithm computes a path set PV, which is consists of subsets associated with the path from the root node to a user’s leaf node. The Cover algorithm derives a cover set CV that can effectively cover non-revoked leaf nodes. The Match algorithm can derive two related subsets if a user’s leaf node is not revoked in the cover set. A simple example of the SD method is given in Figs 1 and 2. A detailed description of the SD method is given as follows.

1. SD.Setup(N): Let N = 2ⁿ be the number of leaf nodes. It sets a perfect binary tree of depth n and outputs . Note that a user is assigned to a leaf node in and the collection of SD is the set of all subsets {S_i,j} where and v_j is a descendant of v_i.
2. SD.Assign(): Let v be the leaf node of that is assigned to a user ID. Let be a path from the root node to the leaf node . It initializes a path set PV as an empty one. For all i, j ∈ {k₀, …, k_n} such that v_j is a descendant of v_i, it adds a subset S_i,j defined by two nodes v_i and v_j in the path into PV. It outputs the path set PV = {S_i,j}.
3. SD.Cover(): Let R be a revoked set of leaf nodes (or users). It first sets a subtree as , and then it builds a cover set CV iteratively by removing nodes from until consists of just a single node as follows:
   1. It finds two leaf nodes v_i and v_j in such that the least-common-ancestor v of v_i and v_j does not contain any other leaf nodes of in its subtree. Let v_l and v_k be the two child nodes of v such that v_i is a descendant of v_l and v_j is a descendant of v_k. If there is only one leaf node left, it makes v_i = v_j to the leaf node, v to be the root of and v_l = v_k = v.
   2. If v_l ≠ v_i, then it adds the subset S_l,i to CV; likewise, if v_k ≠ v_j, it adds the subset S_k,j to CV_R.
   3. It removes from all the descendants of v and makes v a leaf node.
   
   It outputs the cover set CV = {S_i,j}.
4. SD.Match(CV, PV): Let CV = {S_i,j} and PV = {S_i,j}. It finds two subsets S_i,j ∈ CV and S_{i′, j′} ∈ PV such that (v_i = v_i′)∧(d_j = d_j′)∧(v_j ≠ v_j′) where d_j is the depth of v_j. If two subsets exist, then it outputs (S_i,j, S_{i′, j′}). Otherwise, it outputs ⊥.

The correctness of the SD scheme requires that if v ∉ R, then SD.Match(CV, PV) = (S_i,j, S_{i′, j′}) such that (v_i = v_i′)∧(d_j = d_j′)∧(v_j ≠ v_j′) where S_i,j is defined by two nodes v_i and v_j.

Lemma 3.1 ([19]). Let N = 2ⁿ be the number of leaf nodes in a perfect binary tree and r be the size of a revoked set. In the SD method, the size of a path set is O(log² N) where the hidden constant is 1/2 and the size of a cover set is at most 2r − 1.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 1. A path set for ID = 010 in the SD method.

https://doi.org/10.1371/journal.pone.0239053.g001

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 2. A cover set for R = {v₁₂, v₁₃} in the SD method.

https://doi.org/10.1371/journal.pone.0239053.g002

3.3 Design principle

In order to design a generic RIBE scheme with the SD method, we first analyze the generic RIBE scheme with the CS method proposed by Ma and Lin [18]. The key design principle of their RIBE scheme with the CS method is that the identity ID of a receiver can be fixed to the path of a binary tree and a ciphertext is associated with the path set of the receiver’s identity ID where as the private key of a user is associated with the path set of a binary tree in directly constructed many RIBE schemes. Therefore, if the receiver’s identity ID is not revoked in the CS method, there is a common node in the path set of the binary tree and a node in the cover set of an update key. Thus, the equality function of IBE can be used to handle this common node since the path can be related to IBE ciphertexts and the cover set can be related to IBE private keys.

However, this design method is difficult to apply to the SD method. The reason is that in the SD method, unlike the CS method, there are no common nodes in the path set and the cover set. To solve this problem, we use the new interpretation of the SD method which was used for an efficient public-key revocation (PKR) scheme and RIBE scheme by using the SD method [15, 36]. To design an efficient PKR scheme, Lee et al. [36] observed that the subset S_i,j of the SD method can be interpreted as a set of single member revocation instead of the existing interpretation that the subset S_i,j is a set of leaf nodes where each leaf node belongs to the subtree but does not belong to the subtree . That is, if we consider a group set GL which consists of all nodes of the subtree that has the same depth as the node v_j, the subset S_i,j can be interpreted as the same as GL except that the node v_j is excluded from GL. Thus, S_i,j can be interpreted as single member revocation because it revokes one node v_j in GL.

This interesting observation was also used to directly construct an RIBE scheme with the SD method by Lee et al. [15]. They used a degree-one polynomial in the exponent to implement single member revocation, but they only achieved an RIBE scheme in a non-generic way. In this work, we found that IBE and IBR schemes can be combined in a generic way to achieve single member revocation if an RIBE ciphertext is associated with a path set PV for a receiver’s identity ID and an RIBE update key is associated with a cover set CV for a revoked set R. That is, given the subset S_i,j, if we set a group label GL = L_i‖d_j and a member label ML = L_j where L_i, L_j are identifiers of nodes v_i, v_j and d_j is the depth of v_j, then all members of the group GL can be represented by a label pair (GL, ML). In this case, a label pair (GL, ML) in a ciphertext and another label pair (GL′, ML′) in an update key can be matching pairs if the group labels are equal but the member labels are different such that GL = GL′∧ML ≠ ML′. Thus, we can support the equality GL = GL′ by using an IBE scheme, and we can support the inequality ML ≠ ML′ by using an IBR scheme. In addition, to provide security against collusion attacks in the black-box construction, we divided the message M of a ciphertext into several secret shares by using a simple secret sharing scheme, and then encrypt these shares by using IBE and IBR schemes. Additionally, we use an HIBE scheme to provide the decryption key exposure resistance.

3.4 Generic construction

Let IBE = (Setup, GenKey, Encrypt, Decrypt) be an IBE scheme, IBR = (Setup, GenKey, Encrypt, Decrypt) be an IBR scheme that supports a single revoked identity, and HIBE = (Setup, GenKey, Delegate, Encrypt, Decrypt) be a two-level HIBE scheme. We define GMLabels(S_i,j) = (GL = Label(v_i)‖Depth(v_j), ML = Label(v_j)) where GL is a group label and ML is a member label. A simple example of a group of nodes derived from a subset S_i,j is given in Fig 3. A generic RIBE scheme using the SD method is described as follows.

1. RIBE.Setup(1^λ): Let be the identity space.
   1. It first obtains MK_IBE, PP_IBE by running IBE.Setup(1^λ). It obtains MK_IBR, PP_IBR by running IBR.Setup(1^λ). It also obtains MK_HIBE, PP_HIBE by running HIBE.Setup(1^λ, 2).
   2. It defines a binary tree by running SD.Setup(2ⁿ) where . Note that it will deterministically assign an identity ID to a leaf node such that Label(v) = ID.
   3. It outputs a master key MK = (MK_IBE, MK_IBR, MK_HIBE), a revocation list RL = ∅, and public parameters .
2. RIBE.GenKey(ID, MK, PP): To generate a private key for ID, it proceeds as follows:
   1. It obtains SK_HIBE by running HIBE.GenKey((ID), MK_HIBE, PP_HIBE).
   2. Finally, it outputs a private key SK_ID = SK_HIBE.
3. RIBE.UpdateKey(T, RL, MK, PP): To generate an update key for T, it proceeds as follows:
   1. It initializes RV = ∅. For each (ID_j, T_j)∈RL, it adds a leaf node which is associated with ID_j into RV if T_j ≤ T. It obtains CV_T by running SD.Cover .
   2. For each S_i,j ∈ CV_T, it sets labels (GL, ML) = GMLabels(S_i,j) and performs: It obtains by running IBE.GenKey(GL‖T, MK_IBE, PP_IBE) and by running IBR.GenKey (ML ∥ T, MK_IBR, PP_IBR).
   3. Finally, it outputs an update key .
4. RIBE.DeriveKey(SK_ID, UK_T, PP): Let SK_ID = SK_HIBE. To derive a decryption key for ID and T, it proceeds as follows:
   1. It obtains DK_HIBE by running HIBE.Delegate((ID, T), SK_HIBE, PP_HIBE).
   2. Finally, it outputs a decryption key DK_ID,T = (UK_T, DK_HIBE).
5. RIBE.Encrypt(ID, T, M, PP): To generate a ciphertext for ID and T, it proceeds as follows:
   1. It selects random R₁ and sets R₂ = M⊕R₁. It obtains CT_HIBE by running HIBE.Encrypt ((ID, T), R₂, PP_HIBE).
   2. Let v_ID be a leaf node associated with ID such that ID = Label(v_ID). Recall that the leaf node v_ID is fixed by the Label function. It obtains PV_ID by running SD.Assign .
   3. For each S_i,j ∈ PV_ID, it sets labels (GL, ML) = GMLabels(S_i,j) and performs:
      1. It selects random and sets .
      2. It obtains by running IBE.Encrypt and obtains by running IBR.Encrypt .
      
      It creates .
   4. Finally, it outputs a ciphertext CT_ID,T = (CT_PV, CT_HIBE).
6. RIBE.Decrypt(CT_ID,T, DK_{ID′, T′}, PP): Let CT_ID,T = (CT_PV, CT_HIBE) and DK_{ID′, T′} = (UK_T, DK_HIBE). It proceeds as follows:
   1. It first obtains R₂ by running HIBE.Decrypt(CT_HIBE, DK_HIBE, PP_HIBE).
   2. It finds (S_i,j, S_{i′, j′}) = SD.Match(PV_ID, CV_T). It retrieves from CT_PV and from UK_T. Next, it obtains R₃ by running IBE.Decrypt and obtains R₄ by running IBR.Decrypt .
   3. Finally, it outputs a message M = R₃⊕R₄⊕R₂.
7. RIBE.Revoke(ID, T, RL): If (ID, *) already exists in RL, it outputs RL. Otherwise, it adds (ID, T) to RL and outputs the updated RL.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 3. A single member revoked group from the subset S_1,6 = (v₁, v₆).

https://doi.org/10.1371/journal.pone.0239053.g003

3.5 Correctness

The correctness of the above RIBE scheme can be easily seen by using the correctness of the underlying IBE, IBR, HIBE and SD schemes. Let CT_ID,T = (CT_PV, CT_HIBE) be a ciphertext associated with ID and T, and DK_{ID′, T′} = (UK_T, DK_HIBE) be a decryption key is associated with ID′ and T′. In this case, if the condition ID = ID′∧T = T′ is satisfied, then the random R₂ is correctly decrypted by running HIBE.Decrypt(CT_HIBE, SK_HIBE, PP_HIBE) because of the correctness of HIBE.

Now we show that random R₁ can be correctly decrypted from CT_PV and UK_T if the identity ID of the ciphertext is not revoked in the update key UK_T. Recall that the ciphertext CT_PV is associated with PV_ID and the update key UK_T is associated with CV_T. By the correctness of the SD scheme, the SD.Match algorithm outputs two subsets of S_i,j, S_{i′, j′} such that (v_i = v_i′)∧(d_j = d_j′)∧(v_j ≠ v_j′) if the leaf node v_ID is not included in the revoked set RV. Let and be corresponding tuples of S_i,j and S_{i′, j′} respectively. From the definition of GMLabels, labels (GL, ML) = GMLabels(S_i,j) and (GL′, ML′) = GMLabels(S_{i′, j′}) are obtained and they satisfy GL = GL′∧ML ≠ ML′. Therefore, if the time T of the ciphertext is the same as the time T′ of the update key, then random R₃ can be decrypted by running IBE.Decrypt because of GL‖T = GL′‖T′ and random R₄ can be decrypted by running IBR.Decrypt because of ML‖T ≠ ML′‖T′. Therefore, random R₁ is obtained from R₃⊕R₄.

3.6 Discussions

4.1 Type-I adversary

The Type-I attacker does not request a private key query on the challenge ID*, but can request decryption key queries such that ID = ID* and T ≠ T*. To deal with this attacker, we build a reduction algorithm that attacks the HIBE scheme and selects the other IBE and IBR schemes by itself. In this case, this algorithm will be able to handle all queries of the Type-I attacker by using the queries for the HIBE scheme. The detailed proof is as follows.

Lemma 4.2. For the Type-I adversary, the generic RIBE scheme is IND-CPA secure if the HIBE scheme is IND-CPA secure.

Proof. Suppose there exists an adversary that attacks the RIBE scheme with a non-negligible advantage. An algorithm that attacks the HIBE scheme is initially given public parameters PP_HIBE by a challenger . Then that interacts with is described as follows:

Setup: generates MK_IBE, PP_IBE by running the IBE.Setup algorithm, generates MK_IBR, PP_IBR by running the IBR.Setup algorithm. It initializes RL = ∅ and gives PP = (PP_IBE, PP_IBR, PP_HIBE) to .

Phase 1: adaptively requests a polynomial number of private key, update key, decryption key, and revocation queries.

• For a private key query with an identity ID, proceeds as follows: It receives SK_HIBE from by querying a private key for ID since ID ≠ ID* by the restriction of the Type-I adversary. It gives SK_ID = SK_HIBE to .
• For an update key query with time T, proceeds as follows: It simply generates UK_T by running the RIBE.UpdateKey algorithm since it knows MK_IBE and MK_IBR. It gives UK_T to .
• For a decryption key query with an identity ID and time T, proceeds as follows:
  1. It generates UK_T by running the RIBE.UpdateKey algorithm since it knows MK_IBE and MK_IBR.
  2. It receives DK_HIBE from by querying a private key for ID and T since ID ≠ ID* or ID = ID*∧T ≠ T* by the restriction of the Type-I adversary.
  3. It gives DK_ID,T = (UK_T, DK_HIBE) to .
• For a revocation query with an identity ID and time T, proceeds as follows: It adds (ID, T) to RL if ID was not revoked before.

Challenge: submits a challenge identity ID*, challenge time T*, and two challenge messages . proceeds as follows:

1. It first select random R₁ and sets .
2. Next, it receives from by submitting ID*, T*, and two challenge messages R_2,0, R_2,1.
3. To creates for ID* and T*, it simply follows the procedures in the RIBE.Encrypt algorithm with the random R₁ input.
4. It gives a challenge ciphertext to .

Phase 2: Same as Phase 1.

Guess: Finally, outputs a guess μ′ ∈ {0, 1}. also outputs μ′.

4.2 Type-II adversary

Since the Type-II attacker requests a private key query on the challenge ID*, we can not handle the private key queries of the RIBE scheme by using the private key queries of the HIBE scheme in the proof. Therefore, we prove the security by relating the security of the IBE and IBR schemes with the security of the RIBE scheme against the Type-II attacker.

The main idea of the proof is to take advantage of the restriction of the RIBE security model such that if the attacker queries the private key for the challenge identity ID*, then the corresponding private key for ID* must be revoked from the update key on the challenge time T*. Thus, the ciphertext in the challenge ciphertext consists of the IBE and IBR ciphertexts associated with the subset S_i,j belonging to the path set PV_ID*, but the IBE and IBR private keys that can decrypt the corresponding ciphertext elements in are not included in the update key for T* because of the restriction. Using this fact, we can prove the security of the RIBE scheme against the Type-II attacker by using the security of the IBE or IBR scheme.

We prove the security by using hybrid games consisting of multiple sub-games because the ciphertext is composed of many IBE and IBR ciphertexts. That is, in the hybrid games, a ciphertext which encrypts a random value related to is changed to another ciphertext which encrypts a random value related to . In this hybrid steps, since the number of IBE and IBR ciphertext pairs in is maximum O(n²), the proof can be completed by performing O(n²) hybrid games. The detailed proof is described as follows.

Lemma 4.3. For the Type-II adversary, the generic RIBE scheme is IND-CPA secure if the IBE and IBR schemes are IND-CPA secure.

Proof. Let ID* be the challenge identity and PV_ID* be the path set of ID* where the number of subsets in PV_ID* is ℓ = n(n − 1)/2. The challenge ciphertext is formed as where . For the security proof, we define hybrid games G₀, G₁, G₂, G₃ as follows:

1. Game G₀. This game is the original security game defined in the security model except that the challenge bit μ is fixed to 0.
2. Game G₁. This game is the same as the game G₀ except that the settings of random R₁ and R₂ in the challenge ciphertext are changed. That is, R₂ are randomly chosen and R₁ is set as .
3. Game G₂. In this game, the generation of in the challenge ciphertext CT* is changed. That is, a random is encrypted instead of to generate .
   For the analysis of security, we define additional sub-games H₀, …, H_ρ, …, H_ℓ where H₀ = G₁ and H_ℓ = G₂. The game H_ρ is similar to the game H_ρ−1 except that the tuple is an encryption on the random . Specifically, each tuple for k ≤ ρ is an encryption on the random and each tuple for k > ρ is an encryption on the random .
   In the game H_ρ, we let of where is related with PV_ID*. We divide the adversary as the following sub-types:
   - An adversary is Type-II-A if it requests an update key for time T* such that GL ≠ GL* for all labels (GL, ML) = GMLabels(S_i,j) of S_i,j ∈ CV_R where UK_T* is related with CV_R.
   - An adversary is Type-II-B if it requests an update key for time T* such that GL = GL* for some labels (GL, ML) = GMLabels(S_i,j) of S_i,j ∈ CV_R where UK_T* is related with CV_R. In this case, we have that ML ≠ ML* since the identity ID* should be revoked in UK_T* by the restriction of the security model.
4. Game G₃. This game is the same as the game G₂ except that the settings of random and R₂ in the challenge ciphertext are changed. That is, is randomly chosen and R₂ is set as . This game is the original security game in the security model except that the challenge bit μ is fixed to 1.

Let be the event that outputs 0 in a game G_i. From Lemmas 4.4 and 4.5, we obtain the following result

This completes our proof.

Lemma 4.4. If the IBE scheme is IND-CPA secure, then no polynomial-time Type-II-A adversary can distinguish between H_ρ−1 and H_ρ with a non-negligible advantage.

Proof. Suppose there exists an adversary that attacks the RIBE scheme with a non-negligible advantage. An algorithm that attacks the IBE scheme is initially given public parameters PP_IBE by a challenger . Then that interacts with is described as follows:

Setup: generates MK_IBR, PP_IBR by running the IBR.Setup algorithm and generates MK_HIBE, PP_HIBE by running the HIBE.Setup algorithm. It initializes RL = ∅ and gives PP = (PP_IBE, PP_IBR, PP_HIBE) to .

Phase 1: adaptively requests a polynomial number of private key, update key, decryption key, and revocation queries.

• For a private key query with an identity ID, proceeds as follows: It generates SK_ID by running the RIBE.GenKey algorithm since it knows MK_HIBE. It gives SK_ID to .
• For an update key query with time T, proceeds as follows:
  1. It initializes RV = ∅. For each (ID_j, T_j)∈RL, it adds a leaf node into RV if T_j ≤ T. It obtains CV_T by running SD.Cover .
  2. For each S_i,j ∈ CV_T, it sets (GL_k, ML_k) = GMLabels(S_i,j) and performs: It receives from by submitting an identity GL_k‖T. It generates by running IBR.GenKey (ML_k∥T, MK_IBR, PP_IBR).
  3. It creates and gives UK_T to .
• For a decryption key query with an identity ID and time T, proceeds as follows:
  1. It retrieves SK_ID = SK_HIBE by querying a private key to its own oracle. It also retrieves UK_T by querying an update key to its own oracle.
  2. Next, it generates a delegated key DK_HIBE of SK_HIBE by running HIBE.DelegateKey for ID and T.
  3. It gives DK_ID,T = (UK_T, DK_HIBE) to .
• For a revocation query with an identity ID and time T, proceeds as follows: It adds (ID, T) to RL if ID was not revoked before.

Challenge: submits a challenge identity ID*, challenge time T*, and two challenge messages . proceeds as follows:

1. It first selects random R₂ and sets .
2. Next, it generates by running HIBE.Encrypt((ID*, T*), R₂, PP_HIBE).
3. It obtains PV_ID* by running SD.Assign where a leaf node v_ID* is associated with ID*. For each S_i,j ∈ PV_ID*, it obtains (GL_k, ML_k) = GMLabels(S_i,j) and proceeds as follows:
   • If k < ρ, then it selects random R_3,k and sets , and then generates by running IBE.Encrypt(GL_k‖T*, R_3,k, PP_IBE) and by running IBR.Encrypt (ML_k∥T*, R_4,k, PP_IBR).
   • If k = ρ, then it performs the follows:
     1. (a) It selects random R_4,k and sets , .
     2. (b) It receives from by submitting a challenge identity GL_k‖T* and challenge messages .
     3. (c) It generates by running IBR.Encrypt(ML_k‖T*, R_4,k, PP_IBR).
   • If k > ρ, then it selects random R_3,k and sets , and then generates by running IBE.Encrypt(GL_k‖T*, R_3,k, PP_IBE) and by running IBR.Encrypt (ML_k∥T*, R_4,k, PP_IBR).
   
   It creates .
4. It gives a challenge ciphertext to .

Phase 2: Same as Phase 1.

Guess: Finally, outputs a guess μ′ ∈ {0, 1}. also outputs μ′.

Lemma 4.5. If the IBR scheme is IND-CPA secure, then no polynomial-time Type-II-B adversary can distinguish between H_ρ−1 and H_ρ with a non-negligible advantage.

Proof. Suppose there exists an adversary that attacks the RIBE scheme with a non-negligible advantage. An algorithm that attacks the IBR scheme is initially given public parameters PP_IBR by a challenger . Then that interacts with is described as follows:

Setup: generates MK_IBE, PP_IBE by running the IBE.Setup algorithm and generates MK_HIBE, PP_HIBE by running the HIBE.Setup algorithm. It initializes RL = ∅ and gives PP = (PP_IBE, PP_IBR, PP_HIBE) to .

Phase 1: adaptively requests a polynomial number of private key, update key, decryption key, and revocation queries.

• For a private key query with an identity ID, proceeds as follows: It generates SK_ID by running RIBE.GenKey algorithm since it knows MK_HIBE. It gives SK_ID to .
• For an update key query with time T, proceeds as follows:
  1. It initializes RV = ∅. For each (ID_j, T_j)∈RL, it adds a leaf node into RV if T_j ≤ T. It obtains CV_T by running SD.Cover .
  2. For each S_i,j ∈ CV_T, it sets (GL_k, ML_k) = GMLabels(S_i,j) and performs: It generates by running IBE.GenKey(GL_k‖T, MK_IBE, PP_IBE). It receives from by submitting an identity ML_k‖T.
  3. It creates and gives UK_T to .
• For a decryption key query with an identity ID and time T, proceeds as follows:
  1. It retrieves SK_ID = SK_HIBE by querying a private key to its own oracle. It also retrieves UK_T by querying an update key to its own oracle.
  2. Next, it generates a delegated key DK_HIBE of SK_HIBE by running HIBE.DelegateKey for ID and T.
  3. It gives DK_ID,T = (UK_T, DK_HIBE) to .
• For a revocation query with an identity ID and time T, proceeds as follows: It adds (ID, T) to RL if ID was not revoked before.

Challenge: submits a challenge identity ID*, challenge time T*, and two challenge messages . proceeds as follows:

1. It first select random R₂ and sets .
2. Next, it generates by running HIBE.Encrypt((ID*, T*), R₂, PP_HIBE).
3. It obtains PV_ID* by running SD.Assign where a leaf node v_ID* is associated with ID*. For each S_i,j ∈ PV_ID*, it obtains (GL_k, ML_k) = GMLabels(S_i,j) and proceeds as follows:
   • If k < ρ, then it selects random R_3,k and sets , and then generates by running IBE.Encrypt(GL_k‖T*, R_3,k, PP_IBE) and by running IBR.Encrypt (ML_k∥T*, R_4,k, PP_IBR).
   • If k = ρ, then it performs the follows:
     1. (a) It selects random R_3,k and sets , .
     2. (b) It generates by running IBE.Encrypt(GL_k‖T*, R_3,k, PP_IBE).
     3. (c) It receives from by submitting a challenge identity ML_k‖T* and challenge messages .
   • If k > ρ, then it selects random R_3,k and sets , and then generates by running IBE.Encrypt(GL_k‖T*, R_3,k, PP_IBE) and by running IBR.Encrypt (ML_k∥T*, R_4,k, PP_IBR).
   
   It creates .
4. It gives a challenge ciphertext to .

Phase 2: Same as Phase 1.

Guess: Finally, outputs a guess μ′ ∈ {0, 1}. also outputs μ′.

5.1 RIBE from bilinear maps

Previously, many RIBE schemes using the CS method were directly constructed on bilinear maps [6, 7, 9]. In addition, an RIBE scheme using the SD method was also directly constructed on bilinear maps [15]. Recently, a generic construction for RIBE using the CS method was proposed by Ma and Lin [18]. Nonetheless, different generic construction for RIBE using the SD/LSD method is still an interesting method because it allows different RIBE instantiations by changing the underlying cryptographic schemes and allows RIBE schemes with shorter update keys. Here, we will look at different instantiations of RIBE using the SD/LSD method that provide selective security or adaptive security.

First, we instantiate an efficient RIBE scheme that provides selective security by following the generic construction. To do this, we choose the BB-IBE scheme of Boneh and Boyen [38] as the underlying IBE scheme, which provides selective security in the DBDH assumption. For underlying IBR scheme, we choose the efficient LSW-IBR scheme of Lewko et al. [26]. However, the IBR scheme for our generic construction only requires that the revoked set R of ciphertexts just consists of a single revoked identity ID. Thus, we can derive a simplified LSW-IBR scheme which supports a single revoked identity, and this simplified IBR scheme provides selective security in the DBDH assumption [27]. Finally, we choose the two-level BB-HIBE scheme of Boneh and Boyen [38] that provides selective security in the DBDH assumption. The resulting RIBE scheme that uses the SD/LSD method provides selective security under the DBDH assumption.

We analyze the private key, update key, and ciphertext size of our generic RIBE scheme with the LSD method in an asymmetric bilinear group. In the MNT159 bilinear group, the size of the group is 159 bits, and the size of the group and the group is 954 bits. In the BB-IBE scheme, the private key size is and the ciphertext size is where denotes the size of a group element. In the LSW-IBR scheme, the private key size is and the ciphertext size is . In the BB-HIBE scheme, the private key size is and the ciphertext size is . In our RIBE scheme, the private key size is since it consists of the private key of HIBE, and the update key size is since it is composed of the IBE and IBR private keys associated with a cover set, and the ciphertext size is approximately since it consists of the IBE and IBR ciphertexts associated with a path set. Thus, if we set N = 2³² and r = 1000, the private key size is 238 bytes, the update key size is 2385 kilobytes, and the ciphertext size is 30 kilobytes.

Next, we instantiate an RIBE scheme that provides adaptive security. To this security, we use the IBE scheme of Waters [30] which provides adaptive security under the DBDH and DLIN assumptions, the IBR scheme of Okamoto and Takashima [39] which is derived from an NIPE scheme that provides adaptive security, and the two-level HIBE scheme of Waters [30] that provides adaptive security under the DBDH and DLIN assumptions. The resulting RIBE scheme provides adaptive security under these standard assumptions in prime-order bilinear groups. The previous adaptively secure RIBE scheme of Lee et al. [15] is built in composite-order bilinear groups, but this generic RIBE scheme is built in prime-order bilinear groups. However, this generic RIBE scheme has a small size of private keys and a large size of ciphertexts, whereas the RIBE scheme of Lee et al. has a small size of ciphertexts and a large size of private keys.

5.2 RIBE from lattices

A number of RIBE schemes in lattices have been previously proposed [8, 11, 14, 17]. Although the first lattice based RIBE scheme using the CS method did not provide decryption key exposure resistance (DKER), the new RIBE scheme using the CS method that allows DKER was recently proposed by using the delegation property of HIBE [8, 17]. In addition, a lattice based RIBE scheme using the SD method also has been proposed, but this scheme has a serious limitation such that the identity space is restricted to be small universe because the Lagrange interpolation technique is directly applied to lattices [11].

We use the previously proposed efficient lattice based IBE, IBR, and two-level HIBE schemes to instantiate a lattice based RIBE scheme using the SD method. For the underlying IBE and HIBE schemes, we choose efficient IBE and HIBE schemes of Agrawal et al. [40] that provide selective security in the LWE assumption. For the underlying simple IBR scheme, we choose the NIPE scheme of Katsumata and Yamada [41] which is derived from a linear functional encryption scheme. Note that an NIPE scheme is easily transformed into a simplified IBR scheme with a single revoked identity and this resulting IBR scheme provides selective security in the LWE assumption.

We compare our RIBE scheme with the SD method and the RIBE scheme directly designed by Cheng and Zhang [11]. Cheng and Zhang derived their RIBE scheme in lattices by applying the design principle of the RIBE scheme of Lee et al. [15] in bilinear maps. To use the technique of Lee et al., it is necessary to use the Lagrange interpolation to recover a polynomial value in decryption. In lattices, if Lagrange coefficients and noise values in ciphertexts are multiplied, then a large noise value is obtained in the decryption process, which should be removed to obtain a message. Since the resulting noise value is exponentially increased as the size of the identity space increases, their RIBE scheme has a serious problem that only a small universe of identity can be accepted. Therefore, our RIBE scheme with the SD method is the first lattice based RIBE scheme using the SD method that supports a large universe of identity and provides the DKER property.