Revocable Hierarchical IdentityBased Encryption
from Multilinear Maps
Abstract
In identitybased encryption (IBE) systems, an efficient key delegation method to manage a large number of users and an efficient key revocation method to handle the dynamic credentials of users are needed. Revocable hierarchical IBE (RHIBE) can provide these two methods by organizing the identities of users as a hierarchy and broadcasting an update key for nonrevoked users per each time period. To provide the key revocation functionality, previous RHIBE schemes use a treebased revocation scheme. However, this approach has an inherent limitation such that the number of update key elements depends on the number of revoked users. In this paper, we propose two new RHIBE schemes in multilinear maps that use the publickey broadcast encryption scheme instead of using the treebased revocation scheme to overcome the mentioned limitation. In our first RHIBE scheme, the number of private key elements and update key elements is reduced to and respectively where is the depth of a hierarchical identity. In our second RHIBE scheme, we can further reduce the number of private key elements from to .
Keywords: Hierarchical identitybased encryption, Key revocation, Key delegation, Multilinear maps.
1 Introduction
Identitybased encryption (IBE) is a specific type of publickey encryption (PKE) that uses an identity string of a user (e.g., email address, phone number) as a public key to simplify the management of public keys [28, 5]. IBE can be extended to hierarchical IBE (HIBE) that supports the delegation of private keys by allowing a parent user to generate private keys of child users [15, 14]. For the deployment of IBE (or HIBE) in real environments, an efficient revocation mechanism is needed to handle dynamically changing credentials (private keys) of users. Revocable HIBE (RHIBE) is an extension of HIBE that provides both the delegation of private keys and the revocation of private keys. Although there already exists a revocable IBE (RIBE) scheme [2], it is not easy to directly apply the technique of RIBE to RHIBE since the key delegation of HIBE makes it hard to handle the revocation.
The first RHIBE scheme was proposed by Seo and Emura [25] that uses a treebased revocation scheme of Naor, Naor, and Lotspiech [21] for the revocation functionality. To create an update key in this RHIBE scheme, a user who has a private key should retrieve all update keys of all ancestors. This method is called as historypreserving updates. After that, Seo and Emura proposed another RHIBE scheme via historyfree updates [27]. In this RHIBE scheme via historyfree updates, a user can simply create an update key after retrieving the update key of his parent only. By using this new approach, they also reduced the size of a private key from to where is the depth of the identity and is the maximum number of users in each level. Recently, Lee and Park proposed new RHIBE schemes with shorter private keys and update keys by removing the undesirable multiplicative factor from the size of private keys and update keys [18].
Although the progress of RHIBE is impressive, the size of a private key and an update key in previous RHIBE schemes still depends on the size of a private key and a ciphertext in the treebased revocation scheme. Recently, Park, Lee, and Lee [22] proposed a new RIBE scheme with short keys from multilinear maps by using the publickey broadcast encryption (PKBE) scheme of Boneh, Gentry, and Waters [6] for the key revocation. Their new technique enables for RIBE to have a constant number of private key elements and update key elements. Therefore, we ask the following question in this paper: “Can we also reduce the size of keys further in RHIBE by using the PKBE scheme for the key revocation?”
1.1 Our Results
In this paper, we propose two RHIBE schemes from multilinear maps^{4}^{4}4Note that many candidate multilinear maps are currently broken [10, 9], but the multilinear map from indistinguishability obfuscation is still alive [1]. with shorter private key elements and shorter update key elements. The followings are our results:
RHIBE via HistoryPreserving Updates. We first construct an RHIBE scheme via historypreserving updates from threeleveled multilinear maps by combining the HIBE scheme of Boneh and Boyen (BBHIBE) [3] and the PKBE scheme of Boneh, Gentry and Waters (BGWPKBE) [6]. We also prove its security in the selective revocation model under the multilinear DiffieHellman exponent (MDHE) assumption. In this RHIBE scheme, the number of group elements in a private key, an update key, and a ciphertext is , , and respectively where is the maximum number of hierarchy identity. Note that the number of private key elements and update key elements in our RHIBE scheme only depends on the depth of a hierarchy identity.
RHIBE via HistoryFree Updates. Next, we present another RHIBE scheme via historyfree updates from threeleveled multilinear maps with a constant number of private key elements. This RHIBE scheme is also secure in the selective revocation list model under the MDHE assumption. In this RHIBE scheme, the number of group elements in a private key, an update key, and a ciphertext is , , and respectively. Compared with our first RHIBE scheme that has group elements in a private key, our second RHIBE scheme just has group elements in a private key. The detailed comparison of RHIBE schemes is given in Table 1.
Scheme  PP Size  SK Size  UK Size  Model  Maps  Assumption 
SE [25]  SEIND  BLM  DBDH  
SE (CS) [27]  SEIND  BLM  Type  
SE (SD) [27]  SRLIND  BLM  Type  
LP (CS) [18]  SEIND  BLM  Type  
LP (SD) [18]  SRLIND  BLM  Type  
Ours  SRLIND  MLM  MDHE  
Ours  SRLIND  MLM  MDHE  
Let be a security parameter, be the maximum hierarchical level, be the maximum number of users, and be the number of revoked users. Sizes for public parameters (PP), private keys (SK), and update keys (UK) count group elements. BLM stands for bilinear maps and MLM stands for multilinear maps. 
1.2 Our Techniques
To construct RHIBE schemes with shorter keys from multilinear maps, we basically follow the design technique of Park, Lee, and Lee [22] that uses the BGWPKBE scheme [6] instead of the treebased revocation system of Naor et al. [21]. However, the naive employment of this technique does not work since the delegation of private keys should be considered. To solve this problem, we devise new techniques for RHIBE in multilinear maps. We briefly review the RIBE scheme of Park, Lee, and Lee [22] and then overview our twolevel RHIBE scheme for a simple exposition.
If we simply follow the design strategy of Park et al. [22], a trusted center which has a master key creates a private key for a level identity as and broadcasts a level update key for time and a revoked set as where is an index assigned to and is the set of receiver indexes. Note that is tied to the private key of PKBE and is tied to the ciphertext header of PKBE. After that, the level user of the identity can delegate his private key to a level user with an identity by creating a 2level private key as . Next, the level user broadcasts a level update key for time and a revoked set as . If and , then the level user of the identity can derive a decryption key by performing paring operations.
However, there are some problems in the above approach. The first problem is that the level user can extract the private key of the level user from his private key since is contained in . The second problem is that the master key part of the decryption key is wrongly structured since a random value that is hidden to a sender is used. To overcome these problems, we devise a new random blinding technique for RHIBE that safely blinds a private key in delegation and cancels unnecessary random values in decryption. In this technique, the private key component of is multiplied by a random element and a new element is included in the private key delegation process. This newly added element enables to cancel the random values and in the decryption key derivation process. Note that a level user who is not revoked in only can derive a correct decryption key which has a master key by cancelling the random values. Furthermore, if we encode the identity of a user carefully, we can reduce the size of private key elements from to where is the hierarchical depth of the identity. Therefore, we can build an RHIBE scheme via the historypreserving updates [25] in which a private key and an update key include all private keys and update keys of lower level users from 3leveled multilinear maps.
To achieve an RHIBE scheme with a constant number of private key elements, we apply the historyfree updates approach of Seo and Emura [27]. Let be the level private key for , be the level update key, and be the level decryption key as the same as our first RHIBE scheme. By following this approach, the level user with an identity simply creates a level private key for as . Next, he creates a level update key by using his decryption key instead of using the level update key . In this step, we use the random blinding technique to prevent a collusion attack. That is, the decryption key component is safely blinded by a random element . Then, the 1level update key is formed as . Note that this random blinding element is removed in the decryption key derivation process. Therefore, we have an RHIBE scheme with shorter private keys.
1.3 Related Work
The concept of IBE was introduced by Shamir to solve the certificate management problem in PKE [28]. After the first realization of an IBE scheme in bilinear maps by Boneh and Franklin [5], many IBE schemes in bilinear maps were proposed [3, 29, 12, 30]. As mentioned before, providing an efficient revocation mechanism for IBE is a very important issue. Boneh and Franklin introduced a simple revocation method for IBE by concatenating an identity with time [5]. However, this method is not scalable since a trusted center periodically generates a private key for each user on each time period. The first scalable RIBE scheme was proposed by Boldyreva, Goyal, and Kumar [2] by combining the Fuzzy IBE scheme of Sahai and Waters [24] and the complete subtree (CS) scheme of Naor et al. [21]. Many other RIBE schemes also followed this design technique [20, 26]. A different RIBE scheme that uses the subset difference (SD) scheme instead of using the CS scheme proposed by Lee et al. [16]. Recently, Park, Lee, and Lee proposed a new RIBE scheme from multilinear maps that has a constant number of private key elements and update key elements [22].
As mentioned before, the notion of IBE can be extended to HIBE where a trusted center can delegate the generation of private keys to other users. After the introduction of HIBE [15], many HIBE scheme with different properties were proposed [14, 3, 4, 8, 13, 30, 19, 17]. The first RHIBE scheme was presented by Seo and Emura [25] that combines the BBHIBE scheme and the CS scheme. To reduce the size of private keys in the first RHIBE scheme, Seo and Emura proposed another RHIBE scheme via historyfree update method that combines the BBGHIBE scheme and the CS (or SD) scheme [27]. In previous RHIBE schemes, the maximum hierarchy depth should be fixed in the setup phase. To overcome this limitation, Ryu et al. proposed an unbounded RHIBE scheme by using an unbounded HIBE scheme [23]. Recently, Lee and Park proposed an RHIBE scheme with shorter private keys and update keys [18]. To reduce the size of private keys and update keys, they first presented a new HIBE scheme that supports a short intermediate private key and build an RHIBE scheme in a modular way.
2 Preliminaries
In this section, we review multilinear maps and complexity assumptions in multilinear maps.
2.1 Notation
Let be a security parameter and be the set for . Let be the identity space. A hierarchical identity with a depth is defined as an identity vector . We let be a vector of size derived from . If , then we have . We define for simplicity. A function returns a set of prefix vectors where where for some . For two hierarchical identities and with , is an ancestor identity of and is a descendant identity of if .
2.2 Leveled Multilinear Maps
We define generic leveled multilinear maps that are the leveled version of the cryptographic multilinear maps introduced by Boneh and Silverberg [7]. We follow the definition of Garg, Gentry, and Halevi [11].
Definition 2.1 (Leveled Multilinear Maps).
We assume the existence of a group generator , which takes as input a security parameter and a positive integer . Let be a sequence of groups of large prime order . In addition, we let be a canonical generator of respectively. We assume the existence of a set of bilinear maps that have the following properties:

Bilinearity: The map satisfies the following relation:

Nondegeneracy: We have that for each valid .
We say that is a multilinear group if the group operations in as well as all bilinear maps are efficiently computable. We often omit the subscripts of and just write .
2.3 Complexity Assumptions
We introduce complexity assumptions in multilinear maps. This assumption is the multilinear version of the Bilinear DiffieHellman Exponent (BDHE) assumption of Boneh, Gentry, and Waters [6].
Assumption 1 (Multilinear DiffieHellman Exponent, Mdhe).
Let be the description of a leveled multilinear group of order . Let be a generator of . The decisional MDHE assumption is that if the challenge tuple
are given, no PPT algorithm can distinguish from a random element with more than a negligible advantage. The advantage of is defined as where the probability is taken over random choices of .
Assumption 2 (ThreeLeveled Multilinear DiffieHellman Exponent, Mdhe).
Let be the description of a threeleveled multilinear group of order . Let be a generator of . The decisional MDHE assumption is that if the challenge tuple
are given, no PPT algorithm can distinguish from a random element with more than a negligible advantage. The advantage of is defined as where the probability is taken over random choices of .
3 Revocable HIBE with HistoryPreserving Updates
In this section, we first define the syntax and the security of RHIBE. Next, we propose an RHIBE scheme with historypreserving updates from threeleveled multilinear maps and prove its selective security.
3.1 Definition
Revocable HIBE (RHIBE) is an extension of IBE that provides both the delegation of private keys and the revocation of private keys [25]. In RHIBE, a user who has a private key for a hierarchical identity can generate a (longterm) private key for a child user with the identity where . The user with also periodically broadcasts an update key for the set of revoked child users at a time period . If the child user with who has a private key is not included in the revoked set , then he can derive a (shortterm) decryption key from and . A sender creates a ciphertext that encrypts a message for a receiver identity and a time period , and then the receiver who has a decryption key can obtain the message by decrypting the ciphertext . The syntax of RHIBE is defined as follows:
Definition 3.1 (Revocable HIBE).
A revocable HIBE (RHIBE) scheme that is associated with the identity space , the time space , and the message space , consists of seven algorithms Setup, GenKey, UpdateKey, DeriveKey, Encrypt, Decrypt, and Revoke, which are defined as follows:

Setup(): The setup algorithm takes as input a security parameter , the maximum number of users in each depth, and the maximum depth of the identity. It outputs a master key , a revocation list , a state , and public parameters .

GenKey(): The private key generation algorithm takes as input a hierarchical identity , a private key , the state , and public parameters . It outputs a private key for and updates .

UpdateKey(): The update key generation algorithm takes as input update time , a revocation list , an update key , the state , and the public parameters . It outputs an update key for and where is the set of revoked identities at the time .

DeriveKey(): The decryption key derivation algorithm takes as input a private key , an update key , and the public parameters . It outputs a decryption key or .

Encrypt(): The encryption algorithm takes as input a hierarchical identity , time , a message , and the public parameters . It outputs a ciphertext for and .

Decrypt(): The decryption algorithm takes as input a ciphertext , a decryption key , and the public parameters . It outputs an encrypted message or .

Revoke(): The revocation algorithm takes as input a hierarchical identity and revocation time , a revocation list , and a state . It updates the revocation list .
The correctness property of RHIBE is defined as follows: For all generated by , generated by for any , generated by for any and , generated by for any , , and , it is required that

If , then .

If , then with all but negligible probability.

If , then .

If , then with all but negligible probability.
The security model of RHIBE with historypreserving updates was defined by Seo and Emura [25]. For the security proof our RHIBE scheme, we define a selective revocation list model where an adversary initially submits the set of revoked identities. This weaker model was introduced by Boldyreva, et al. [2] and used in other schemes [16, 22, 27]. In this paper, we follow the selective revocation list model refined by Seo and Emura [27]. In this security model of RHIBE, an adversary initially submits a challenge identity , challenge time , and a revoked identity set at the time . After receiving public parameters , the adversary can adaptively request private keys, update keys, decryption keys, and revocations with some restrictions. In the challenge step, the adversary submits challenge messages and the challenger creates a challenge ciphertext that encrypts one of the challenge messages. The adversary continually requests private keys, update keys, and decryption keys. Finally, if the adversary correctly guesses the encrypted message, then he wins the game. The details of the security model is described as follows:
Definition 3.2 (Selective Revocation List Security, SRLIND).
The SRLIND security of RHIBE is defined in terms of the following experiment between a challenger and a PPT adversary :

Init: initially submits a challenge identity , challenge time , and a revoked identity set at the time .

Setup: generates a master key , a revocation list , a state , and public parameters by running . It keeps to itself and gives to .

Phase 1: adaptively requests a polynomial number of queries. These queries are processed as follows:

Private key: If this is a private key query for a hierarchical identity , then it gives the private key to by running with the restriction: If is a prefix of where , then the revocation query for or one of its ancestors must be queried at some time where .

Update key: If this is an update key query for a hierarchical identity and time , then it gives the update key to by running with the restriction: If , then the revoked identity set of at the time should be equal to a revoked identity set derived from .

Decryption key: If this is a decryption key query for a hierarchical identity and time , then it gives the decryption key to by running with the restriction: The decryption key query for and cannot be queried.

Revocation: If this is a revocation query for a hierarchical identity and revocation time , then it updates the revocation list by running with the restriction: The revocation query for time cannot be queried if the update key query for the time was already requested.
Note that is allowed to request the update key query and the revocation query in nondecreasing order of time, and an update key implicitly includes a revoked identity set derived from .


Challenge: submits two challenge messages with equal length. flips a random coin and gives the challenge ciphertext to by running .

Phase 2: may continue to request a polynomial number of private keys, update keys, and decryption keys subject to the same restrictions as before.

Guess: Finally, outputs a guess , and wins the game if .
The advantage of is defined as where the probability is taken over all the randomness of the experiment. An RHIBE scheme is SRLIND secure if for all PPT adversary , the advantage of in the above experiment is negligible in the security parameter .
3.2 Building Blocks
Let be the identity space and be the time space where and for a security parameter . Let be an hierarchical identity. We define as a function that takes as input and outputs a concatenated identity where , denotes the concatenation of two strings, and is a collisionresistant hash function. This encoding function has an interesting property such that if then for all except with negligible probability [18].
We describe a modified HIBE scheme of Boneh and Boyen [3] that additionally takes a time period in multilinear groups. Note that we define the keyencapsulation mechanism (KEM) version of HIBE.
 HIBE.Setup():

Let be the description of a multilinear group and be the maximum depth of the hierarchical identity.

It first selects random elements . It also selects random . Let and for a multilinear level . Note that and can be obtained from and by performing pairing operations.

Next, it defines and where is a bit value at the position and is a bit value at the position .

It selects a random exponent and outputs a master key and public parameters

 HIBE.GenKey():

Let , , and . It obtains by calling . It selects random exponents and outputs a private key
 HIBE.RandKey():

Let and . It selects random exponents and outputs a randomized private key .
 HIBE.Delegate():

Let and . It obtains by calling . It selects random a exponent and creates a temporal private key . Next, it outputs a delegated private key by running .
 HIBE.Encrypt():

Let and is a random exponent in . It obtains by calling . It outputs a ciphertext header
and a session key .
 HIBE.Decrypt():

Let and . If , then it outputs the session key by computing . Otherwise, it outputs .
Let where is the (polynomial) number of users. We describe the PKBE scheme of Boneh, Gentry, and Waters [6].
 PKBE.Setup():

Let and be the maximum number of users. It selects random exponents and outputs a master key , an element , and public parameters
 PKBE.GenKey():

Let be an index and . It outputs a private key
 PKBE.Encrypt():

Let