Revocable Hierarchical Identity-Based Encryptionfrom Multilinear Maps

Revocable Hierarchical Identity-Based Encryption from Multilinear Maps

Abstract

In identity-based 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 non-revoked users per each time period. To provide the key revocation functionality, previous RHIBE schemes use a tree-based 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 public-key broadcast encryption scheme instead of using the tree-based 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 identity-based encryption, Key revocation, Key delegation, Multilinear maps.

1 Introduction

Identity-based encryption (IBE) is a specific type of public-key encryption (PKE) that uses an identity string of a user (e.g., e-mail 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 tree-based 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 history-preserving updates. After that, Seo and Emura proposed another RHIBE scheme via history-free updates [27]. In this RHIBE scheme via history-free 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 tree-based revocation scheme. Recently, Park, Lee, and Lee [22] proposed a new RIBE scheme with short keys from multilinear maps by using the public-key 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 maps4 with shorter private key elements and shorter update key elements. The followings are our results:

RHIBE via History-Preserving Updates. We first construct an RHIBE scheme via history-preserving updates from three-leveled multilinear maps by combining the HIBE scheme of Boneh and Boyen (BB-HIBE) [3] and the PKBE scheme of Boneh, Gentry and Waters (BGW-PKBE) [6]. We also prove its security in the selective revocation model under the multilinear Diffie-Hellman 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 History-Free Updates. Next, we present another RHIBE scheme via history-free updates from three-leveled 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] SE-IND BLM DBDH
SE (CS) [27] SE-IND BLM -Type
SE (SD) [27] SRL-IND BLM -Type
LP (CS) [18] SE-IND BLM -Type
LP (SD) [18] SRL-IND BLM -Type
Ours SRL-IND MLM MDHE
Ours SRL-IND 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.
Table 1: Comparison of revocable hierarchical identity-based encryption schemes

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 BGW-PKBE scheme [6] instead of the tree-based 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 two-level 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 2-level 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 history-preserving updates [25] in which a private key and an update key include all private keys and update keys of lower level users from 3-leveled multilinear maps.

To achieve an RHIBE scheme with a constant number of private key elements, we apply the history-free 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 1-level 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 BB-HIBE 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 history-free update method that combines the BBG-HIBE 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:

  • Non-degeneracy: 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 Diffie-Hellman Exponent (BDHE) assumption of Boneh, Gentry, and Waters [6].

Assumption 1 (Multilinear Diffie-Hellman 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 (Three-Leveled Multilinear Diffie-Hellman Exponent, -Mdhe).

Let be the description of a three-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 .

3 Revocable HIBE with History-Preserving Updates

In this section, we first define the syntax and the security of RHIBE. Next, we propose an RHIBE scheme with history-preserving updates from three-leveled 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 (long-term) 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 (short-term) 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 history-preserving 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, SRL-IND).

The SRL-IND security of RHIBE is defined in terms of the following experiment between a challenger and a PPT adversary :

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

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

  3. 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 non-decreasing order of time, and an update key implicitly includes a revoked identity set derived from .

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

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

  6. 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 SRL-IND 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 collision-resistant 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 key-encapsulation mechanism (KEM) version of HIBE.

HIBE.Setup():

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

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

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

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