Efficient identity-based encryption with Hierarchical key-insulation from HIBE

Hierarchical key-insulated identity-based encryption (HKIBE) is identity-based encryption (IBE) that allows users to update their secret keys to achieve (hierarchical) key-exposure resilience, which is an important notion in practice. However, existing HKIBE constructions have limitations in efficiency: sizes of ciphertexts and secret keys depend on the hierarchical depth. In this paper, we first triumph over the barrier by proposing simple but effective design methodologies to construct efficient HKIBE schemes. First, we show a generic construction from any hierarchical IBE (HIBE) scheme that satisfies a special requirement, called MSK evaluatability introduced by Emura et al. (Des. Codes Cryptography 89(7):1535–1574, 2021). It provides several new and efficient instantiations since most pairing-based HIBE schemes satisfy the requirement. It is worth noting that it preserves all parameters’ sizes of the underlying HIBE scheme, and hence we obtain several efficient HKIBE schemes under the k-linear assumption in the standard model. Since MSK evaluatability is dedicated to pairing-based HIBE schemes, the first construction restricts pairing-based instantiations. To realize efficient instantiation from various assumptions, we next propose a generic construction of an HKIBE scheme from any plain HIBE scheme. It is based on Hanaoka et al.’s HKIBE scheme (Asiacrypt 2005), and does not need any special properties. Therefore, we obtain new efficient instantiations from various assumptions other than pairing-oriented ones. Though the sizes of secret keys and ciphertexts are larger than those of the first construction, it is more efficient than Hanaoka et al.’s scheme in the sense of the sizes of master public/secret keys.

called key-insulated IBE (KIBE) [30], and the security which should be achieved in this approach is: (1) even if many decryption keys are exposed, KIBE can guarantee the security of nonexposed decryption keys; (2) even if the helper key is exposed, no information on any decryption keys is leaked as long as no decryption keys are exposed.
The key-insulation structure can be extended to a hierarchical one, and IBE with the hierarchical key-insulated property is called hierarchical KIBE (HKIBE) [30]. 2 In HKIBE, helper keys are separated into multiple levels. Helper keys can update lower-level helper keys, and the lowest-level helper keys update decryption keys. Thus, the impact of key leakage can be significantly reduced by storing helper keys at different levels in different devices.
Although HKIBE seems to provide practical applications as above, an efficiency issue in HKIBE constructions remains unsolved. Hanaoka et al. [30] showed a generic construction from any HIBE scheme. It can be instantiated from various assumptions, however essentially sacrifices sizes of ciphertexts and decryption keys; it requires at least O(L) HIBE ciphertexts and O(L) HIBE secret keys for the resulting ciphertexts and decryption keys, respectively, where L is the maximum depth of hierarchical key-insulation. Therefore, even if the underlying HIBE scheme achieves compact ciphertexts and/or secret keys, those of the resultant HKIBE scheme cannot be compact. Although Hanaoka et al. [30] also showed a concrete HKIBE scheme from computational bilinear Diffie-Hellman (CBDH) assumption, which is more efficient than the generic construction, it relies on the random oracle and do not have compact parameters, in the sense that sizes of ciphertexts and decryption keys are not constant. The work of [52,55] proposed adaptively secure HKIBE schemes with compact ciphertexts and decryption keys from pairings; however, unfortunately, we found a flaw in the security proofs (which we communicated to the authors). 3 Thus, there are no secure HKIBE constructions that achieve compact ciphertexts and decryption keys.

Our contributions
In this paper, we successfully make significant progress in constructing efficient HKIBE schemes. Specifically, we show two generic constructions of HKIBE schemes.

Generic construction from HIBE with MSK evaluatability
We take note of the similarities in security games in HKIBE and revocable HIBE (RHIBE) [9,49,51]; unlike standard (H)IBE, an adversary is allowed to get (a part of) a secret key of a challenge identity in both games. Based on the observation, we take a similar approach to the recent RHIBE construction [24], and propose our first construction from any HIBE scheme that satisfies MSK evaluatability, which is the special algebraic property introduced in [24]. Although the property restricts an applicable class of HIBE schemes to our construction, most pairing-based HIBE schemes, including most-efficient-ever ones [17,18,28], meet it. Our generic construction provides several concrete HKIBE schemes with new features as follows.
-The first HKIBE schemes with compact ciphertexts and decryption keys from [17,18] under the standard k-linear assumption. Note that there are no known schemes with Table 1 A comparison between Hanaoka et al.'s generic construction and ours. "Generic HHSI05" means the generic construction shown in [30] Construction Generic HHSI05 [30] O  Therefore, we compare the number of the ingredients that constitute each parameter. ROM and Std. stand for the random oracle model and the standard model, respectively, and L , and Q denote the maximum hierarchical size, a hierarchical level, and the number of helper-key generation queries, respectively. let α be the ciphertext overhead, which mainly includes an one-time signature and its verification key, caused by the CPA-to-CCA transformation technique [11] similar efficiency even when we ignore the adaptive security, standard assumptions, and the standard model. 4 -The first HKIBE scheme with compact master public keys in the standard model from [28] under the k-linear assumption.
Generic construction from any HIBE Our second construction aims to get rid of the special property required in our first construction, and is a generic construction from any plain HIBE schemes. While this construction is based on [30], it achieves compact master keys 5 and does not require random oracles. We get the following concrete HKIBE schemes with new features from the second construction.
-The first (almost) tightly and adaptively secure HKIBE scheme with compact master keys from the k-linear assumption in the standard model from [36,37]. -The first selectively secure HKIBE scheme with compact master keys from the various assumptions in the standard model: the learning with errors [4,16]; learning from parity with noise [14]; computational Diffie-Hellman without pairing; and factoring Blum integers [22].
Achieving CCA security Although we basically consider CPA-secure HKIBE schemes, we can easily extend them to CCA-secure schemes as follows. The first construction can be lifted to a CCA-secure scheme by just replacing the underlying CPA-secure HIBE scheme with a CCA-secure one. Note that since there is a well-known transformation [11] from CPA-secure HIBE schemes to CCA-secure ones that preserve almost the same efficiency, the CCA-secure version of our first construction achieves similar efficiency to the CPA-secure construction. Unlike the first constrution, we obtain a CCA-secure version of our second construction by applying the transformation technique to multiple ciphertexts of the underlying CPA-secure HIBE scheme at once, not each of them. Note that as observed in the HHSI05 paper [30], it is also applicable to their scheme.

Efficiency comparison
We compare our constructions with previous schemes. Table 1 provides efficiency comparisons between Hanaoka et al.'s generic construction [30] and our constructions. Our first construction preserves all parameter sizes of the underlying HIBE scheme. Our second construction has similar efficiency to the HHSI05 scheme but achieves constant-size master keys. Although our first construction, which is more efficient than others, requires the special property for the underlying HIBE scheme and the factor Q, which is the number of queries in the HKIBE security game, for its security reduction, our second construction requires neither of them. Table 2 shows concrete efficiency among existing schemes and instantiations of our first construction, which is more efficient than our second construction. The state-of-the-art pairing-based HIBE schemes [17,18,28] provide efficient HKIBE schemes. In particular, the instantiation of the first construction from [17,18] is CPA-secure under the k-linear assumption and achieves the same efficiency as the SW18 scheme [52] when setting k = 1, i.e., the symmetric external Diffie-Hellman (SXDH) assumption. We again would like to emphasize that the security proof in [52] was flawed. Furthermore, the first scheme can be easily extended to CCA-security by replacing the underlying CPA-secure HIBE scheme with CCA-secure one. Note that, as we noted above, we know the transformation [11] for HIBE that lifts CPA security to CCA security without sacrificing efficiency.

Table 2
A comparison among previous CCA-secure instantiations and the CCA-secure version of our first construction. Scheme

SXDH OTS
"Concrete HHSI05" means the direct construction shown in [30]. We compare the number of group elements that constitute each parameter in this table. Note that we do not instantiate the underlying OTS scheme in all instantiations except for Concrete HHSI05, and the ciphertext overhead (i.e., the OTS elements) is denoted by α as in Table 1 1

.3 Related work
The notion of key-insulated cryptography was first introduced by Dodis et al. [20]. Specifically, they formalized two kinds of key-insulated security notions: the one is weak security, which only satisfies the condition (1) described earlier; the other is strong security, which satisfies both (1) and (2). Bellare and Palacio [7] showed that weakly secure key-insulated public-key encryption is equivalent to (a restricted form of) IBE. Thus far, the key-insulated security have been considered in the IBE setting (with additional properties) [58,59]. The key-insulation structure was extended to the hierarchical one by Hanaoka et al. [30], where the security captures the strong security, and they proposed an adaptively secure HKIBE scheme both with and without random oracles. Watanabe and Shikata [55] proposed an adaptively secure HKIBE scheme with compact ciphertexts and decryption keys. Later, the same authors [52] found out a bug in the security proof in [55] and fixed it and the corresponding construction. However, it contains another bug in their security proof, and our proposal fixes it as mentioned earlier.
Another key-updating approach is forward security [15], which guarantees that even if the secret key is leaked, no information of previously-encrypted plaintexts is leaked by updating the secret key by themselves. However, it is inapplicable to the IoT scenario since it only prevents the leakage of data previously encrypted before the key leakage, and the exposed secret keys will not be able to be used.
R(H)IBE [9,49] is (H)IBE with efficient revocation functionality, and has a similar keyupdating procedure and security notion to HKIBE. Each user needs to periodically update their decryption key, and the update is successful unless the user is revoked. In the security game, an adversary is allowed to get some decryption keys associated with a challenge identity. A lot of constructions have been proposed in the context of RIBE [9,26,32,38,39,45,50,54] and RHIBE [23,24,34,40,47,49,51,53] thus far.
Organization In Sect. 2, we briefly review hierarchical time-period map functions, which make us consistently deal with several layers of time periods in HKIBE, and HIBE with MSK evaluatability. We give the definition of HKIBE in Sect. 3, and show our two generic constructions in Sects. 4 and 5, respectively.

Hierarchical time-period map functions
To properly deal with key-updating functionality, we consider (discrete) time periods, which are time spans during which a specific secret key is authorized for cryptographic operations such as decryption or in which the secret keys may remain in effect. Let T be a set of time periods. It is natural to consider that such a time period for key updates is related to actual time, i.e., clock time that we usually use in our daily lives. For instance, we can set a set of time periods T as days, say, T := {2020_Sep_1, 2020_Sep_2, . . .}. To connect time periods and actual time, we consider time-period map functions [30]. A time-period map function T : T act → T maps actual times to time periods, where T act is a (possibly countably infinite) set of actual times.
Time-period map functions can be extended so that they have a certain hierarchical structure. Let L := poly(λ), and T for ∈ [0, L] be a finite set of time periods. We assume |T L | ≤ · · · ≤ |T 1 | ≤ |T 0 | and |T L | = 1 (i.e., T L (t) = 0 for any t) for simplicity. The reason why we consider several layers of time periods is that in HKIBE, we consider several secret keys, called helper keys for T L , . . . , T 1 and decryption keys for T 0 . More specifically, we consider different time intervals for the helper and decryption keys; the helper key at the highest level (i.e., T L ) is never updated, and other helper keys are more frequently updated as the level decreases. The decryption key, which is related to T 0 , is most often updated. The hierarchical version of time-period map functions for the depth L captures this situation, and can be defined as a set of L time-period map functions T L , . . . , T 1 , T 0 for distinct timeperiod sets T L , . . . , T 1 , T 0 . We use the hierarchical time-period map functions to manage several time periods consistently; one actual time t ∈ T act produces an (L + 1)-dimensional time-period vector (t L , . . . , t 1 , t 0 ) ∈ T L × · · · × T 1 × T 0 via the functions T L , . . . , T 1 , T 0 . Let us give an example for readers: for L = 3 and t = 2020_Sep_10_23:59, we have T 3 (t) = 0, T 2 (t) = 2020, T 1 (t) = 2020_Sep, and T 0 (t) = 2020_Sep_10. T 3 in this example indicates "no update", and T 2 , T 1 , and T 0 capture yearly, monthly, and daily updates, respectively. For notational convenience, we use a shortened form of time-period vectors for t ∈ T act : 6 Note that the order of [·] of T [·] (·) is reversed compared with the order of [·] defined in Sect. 2.1.

Hierarchical identity
Let an -dimensional identity vector ID := (id 1 , . . . , id ) denote an identity at a level (or, a hierarchy depth) . In this paper, we may sometimes call ID = (id 1 , . . . , id ) and each id i a hierarchical identity and an element identity, respectively. Let I be an element-identity space which is determined only by the security parameter λ, and therefore, a hierarchical-identity space at level is I .
We define several notations for ID = (id 1 , . . . , id ) below. For a non-negative integer k ≤ , an k-dimensional prefix of ID is denoted by ID [k] := (id 1 , . . . , id k ). We denote by prefix + (ID ) := {ID [1] , ID [2] , . . . , ID [ −1] , ID } a set of all prefixes of ID and itself. We often omit the subscript from ID and simply describe ID for simplicity, and use |ID| := to denote a hierarchical level of the hierarchical identity.
Syntax An HIBE scheme with the depth L consists of four algorithms (Init, Enc, GenSK, Dec). Adaptive security Intuitively, HIBE requires that it is hard for an adversary who adaptively obtains polynomially many secret keys SK ID such that ID / ∈ prefix + (ID ) to extract secret information from C ID .
More formally, let be an HIBE scheme, and we consider a game between an adversary A and the challenger C. The game is parameterized by the security parameter λ and the maximum hierarchical depth L. The game proceeds as follows: C first runs (MPK, MSK) ← Init(1 λ , L) and gives MPK to A. A may adaptively make the following secret-key reveal query: upon a query ID ∈ I |ID| from A, C returns SK ID ← GenSK(MPK, MSK, ID) to A. A is also allowed to make the following challenge query only once: upon a query (ID , Note that A is not allowed to make the secret-key reveal query on ID and its prefix in this game. At some point, A outputs b ∈ {0, 1} as its guess for b and terminates. In this game, A's adaptive security advantage is defined by Adv HIBE ,L,A (λ) : The selective-identity CPA security (selective security for short) is analogously defined except that the challenge identity ID is submitted to C at the beginning of the game, instead of the challenge query. Furthermore, CCA security is also defined by allowing A to submit the following decryption query: upon a query (ID, C ID ) ( = (ID , C ID )) from A, C returns Dec(MPK, SK ID , C ID ) to A. [24]. We require that an HIBE scheme used in our first construction satisfies the MSK evaluatability, which is a special algebraic property introduced in [24]. In the following, we use a notation SK ID [MSK], instead of SK ID , to explicitly describe the MSK-part of SK ID , i.e., which element of MSK is used to compute SK ID .

MSK evaluatability
Intuitively, MSK evaluatability has the following two properties.
(1) Anyone can sample a random element MSK ∈ MSK, called a pseudo-MSK, where MSK is a space of possible master secret keys. We describe the sampling procedure as a pseudo-MSK sampling algorithm SampMSK. Furthermore, anyone create secret keys SK ID [ MSK] for any ID ∈ I |ID| under a pseudo-MSK MSK. This pseudo-MSK MSK is, of course, different from the true MSK MSK with overwhelming probability. 7 (2) Suppose that MSK has some algebraic structure and allows one to compute MSK 1 · MSK 2 and MSK 1 / MSK 2 for any MSK 1 , MSK 2 ∈ MSK. Note that MSK 1 and MSK 2 might be the true MSK. Let SK ID [ MSK 1 ] and SK ID [ MSK 2 ] be HIBE secret keys for the same identity ID ∈ I |ID| but under MSK 1 and MSK 2 , respectively. Then, there exists an efficient algorithm EvalMSK which merges the two secret keys into one secret key SK ID [ MSK 1 · MSK 2 ] (resp., SK ID [ MSK 1 / MSK 2 ]) with a label mul (resp., div).
Formally, MSK evaluatability is defined as follows.
Definition 2 (MSK Evaluatability [24]) Let be an HIBE scheme. We say that supports MSK evaluatability if there exist algorithms SampMSK and EvalMSK: -SampMSK(MPK) → MSK: This is the pseudo-MSK sampling algorithm that, given MPK, Moreover, the following two requirements are satisfied: Note that most pairing-based HIBE schemes can satisfy MSK evaluatability. For example, as noted in [24], several state-of-the-art pairing-based HIBE schemes [17,18,28] have this property. Let us give an intuition with the following abstract example. Let G 1 , G 2 , and G T be cyclic groups (group operations in all are written in multiplicative forms) of primeorder p, and e : G 1 × G 2 → G T be a non-degenerate bilinear map. We use the implicit notation [25]: for a ∈ Z p and generators

Pseudo-MSK indistinguishability
In several pairing-based HIBE schemes based on the k-linear assumption (e.g., [17,18]), the MSK is in the form of is a certain public function and r ∈ Z p is a randomness. It is obvious that since anyone can compute a pseudo-MSK MSK := [ k] 2 for uniformly sampled k ∈ Z k+1 p , there exists the SampMSK algorithm. Moreover, it clearly satisfies pseudo-MSK indistinguishability since even given 2 ) and [ k] 2 are identically distributed. Furthermore, it is easy to confirm that it also provides EvalMSK: for any +r 2 (other components can be computed in a similar way). It is clear that the component [ k 1 + k 2 ] 2 · F(ID) r 1 +r 2 is identically distributed to a secret key directly computed by GenSK with MSK 1 · MSK 2 . 8 Hence, it satisfies evaluation correctness. We omit the case of the division since it is straightforward.
On the other hand, it seems difficult for HIBE schemes over pairing-free groups [21] and lattice-based HIBE schemes [4,5,16] to satisfy MSK evaluatability since they do not have such a simple algebraic structure.

HKIBE
We review a definition of HKIBE based on [30,52,55] which present the most strict security model. Please keep in mind that an identity id ∈ I in HKIBE is always a (non-hierarchical) one-dimensional vector.

Model
There are two types of keys, i.e., helper keys and decryption keys, and they depend on an identity id and each of the hierarchical time periods T L , . . . , T 0 . Every user id has a levelhelper key hk ( ) id,T (t) for = 1, 2, . . . , L and a decryption key dk id,T 0 (t) . The upper level- Similarly, the decryption key dk id,T 0 (t) is updated by using a key update derived from a level-1 helper key. A ciphertext ct id,t of HKIBE depends on a receiver's identity id ∈ I and actual time t ∈ T act , and can be decrypted by a decryption key dk id, Specifically, HKIBE consists of six algorithms (Setup, Encrypt, GenHK, KeyUp, Upd, Decrypt) and proceeds as follows. First of all, the key generation center (KGC) runs Setup to generate a master-key pair (pp, mk). Upon a request from a user id, the KGC runs GenHK to get a set of initial helper keys (hk ( ) id,0 ) ∈[0,L] as a secret key for id. Suppose that each helper key is stored in a different (physically-secure) device. The level-0 helper key hk (0) id,t 0 is used as a decryption key, and we often write it as dk id,t 0 . A plaintext M is encrypted by Encrypt with not only an identity id but (current) time t. The resulting ciphertext, which is denoted by ct id,t , can be decrypted by Decrypt with id's decryption key dk id,t 0 (= hk Here, we describe how to update helper and decryption keys as follows. Suppose that the user id has (hk ( ) id,t ) ∈[0,L] and wants to update it for t. The level-L helper key hk id,0 is never updated, and therefore, hk id,0 for any t ∈ T act . For every = L − 1, . . . , 0, the user id first runs KeyUp to generate id's levelkey update ku The user then runs Upd with the key update ku At the end of this updating procedure, the user obtains a decryption key dk id,T 0 (t) (= hk Syntax An HKIBE scheme consists of the six algorithms (Setup, Encrypt, GenHK, KeyUp, Upd, Decrypt) defined as follows: -Setup(1 λ , L) → (pp, mk): This is the setup algorithm that, given the security parameter λ and the maximum depth of the hierarchy L ∈ N, it outputs a master-key pair (pp, mk). -Encrypt(pp, id, t, M) → ct id,t : This is the encryption algorithm that, given pp, an element identity id ∈ I, current time t ∈ T act , and a plaintext M ∈ M, it outputs a ciphertext ct id,t .
-GenHK(pp, mk, id) → (hk ( ) id,0 ) ∈[0,L] : This is the helper-key generation algorithm that, given pp, mk, and an element identity id ∈ I, it outputs a set of initial helper keys (hk ( ) id,0 ) ∈[0,L] . The level-0 helper key is also called a decryption key and set as dk id,0 := hk T (t) or ⊥: This is the key update information generation algorithm that, given pp, actual time t ∈ T act , and an id's level-( + 1) helper key hk id,t : This is the helper key update algorithm that, given pp, an id's level-helper key hk ( ) id,τ at a time period τ ∈ T , and an id's level-key update ku ( ) id,t at a time period t ∈ T , it outputs an updated helper key hk This is the decryption algorithm that, given pp, an id's decryption key dk id,t 0 at a time period t 0 ∈ T 0 , and a ciphertext ct id,t , it outputs M or ⊥ which indicates decryption failure.
Remark 1 (Update Frequency) For simplicity, we assume that the lower-level helper key is more frequently updated than the upper-level helper key. Namely, several level-helper keys hk (m) ). This assumption of use frequency captures actual situations: the upper level of helper keys is, the more rarely they should be used, i.e., the more isolated they should be from the Internet.

Correctness
We require a ciphertext ct id,t associated with (id, t) to be properly decrypted by a decryption key dk id,t 0 for the same id and t 0 = T 0 (t) if dk id,t 0 is correctly generated from any updating path.

Definition 3 (Correctness)
We say that an HKIBE scheme with depth L satisfies correctness, if the probability M = M in the above experiment holds with overwhelming probability.

Security
Let be an HKIBE scheme. We consider the adaptive-identity CPA security for HKIBE (the adaptive security for short), which is defined via a game between an adversary A and the challenger C. The game is parameterized by the security parameter λ and the maximum hierarchical depth L ∈ N. Intuitively, A is able to receive all helper keys as long as they are insufficient for deriving a decryption key dk id ,t for the target tuple (id , t ). The game proceeds as follows: C first runs (pp, mk) ← Setup(1 λ , L) and gives pp to A. C prepares HKList and stores all identity/initial helper keys (id, (hk ( ) id,0 ) ∈[0,L] ) generated during the game in HKList while we will not explicitly mention this procedure.
A may adaptively make the following four types of queries to C: Helper-key generation query Upon a query id ∈ I from A, C checks if (id, * ) / ∈ HKList, and returns ⊥ to A if this is not the case. Otherwise, C executes (hk ( ) id,0 ) ∈[0,L] ← GenHK(pp, mk, id) and returns nothing to A. We require that all identities id appearing in the following queries (except the challenge query) are "activated", in the sense that (hk ( ) id,0 ) ∈[0,L] is generated via this query and hence (id, (hk Initial helper-key reveal query Until the challenge query, upon a query id ∈ I from A, C finds (hk ( ) id,0 ) ∈[0,L] from HKList and returns (hk After the challenge query, C checks whether id = id and returns ⊥ if this is not the case. Otherwise, C returns (hk ( ) id,0 ) ∈[0,L] to A in the same way. Key-insulation query Until the challenge query, upon a query (id, t, ) After the challenge query, when id = id , C checks whether there exists the following special hierarchical level after answering the query: id ,t of any t ∈ T are not revealed to A. Namely, no level-helper keys have been revealed to A ever.
If this is not the case, C returns ⊥ to A. Otherwise, C returns hk ( ) id,T (t) to A in the same way. Challenge query A is allowed to make this query only once. Upon a query (id , t , M 0 , M 1 ) from A such that |M 0 | = |M 1 |, C checks whether the following conditions simultaneously hold: -A does not make the initial helper-key reveal query on id . -There is a special hierarchical level as explained in the key-insulation query.
If the conditions are not simultaneously satisfied, C returns ⊥ to A. Otherwise, C picks a bit b ∈ {0, 1} uniformly at random, runs ct id ,t ← Encrypt(pp, id , t , M b ), and returns the challenge ciphertext ct id ,t to A.
At some point, A outputs b ∈ {0, 1} as its guess for b and terminates.
The above completes the description of the game. In this game, A's adaptive security advantage is defined by Adv HKIBE ,L,A (λ) : Why we need the restrictions We briefly explain the restrictions ( i ) and (ii) appeared in key-insulation query, i.e., why we need the special hierarchical level . To define as strong security as possible while preventing trivial attacks, we should allow A to make as many queries as possible unless A can trivially create dk id ,T 0 (t ) . As for the restriction ( i ), if at least one level-i helper key for id is leaked at every level i ∈ [0, L], it also means that A can create all decryption keys including dk id ,T 0 (t ) . As for the restriction (ii), suppose that for some via key-insulation queries. Then, one helper key hk id ,T (t) for any t ∈ T act . Hence, we need the restriction about the special level to the key-insulation query for id . For the same reason, we, of course, disallow A to make the initial helper-key reveal query for id .
Selective security and CCA security The selective-identity CPA security is analogously defined. The only exception is that A should send a challenge identity and time (id , t ) to C before receiving a master public key pp. Moreover, CCA security is also defined by allowing A to submit the following decryption query: upon a query (id, t, ct id,t ) ( = (id , t , ct id ,t )) from A, C returns Decrypt(pp, dk id,T 0 (t) , ct id,t ) to A. Remark 2 (Weak vs. strong security) The security defined above is referred to as the strong security [20,30], which is the standard security requirement in key-insulated cryptography in the sense that A is allowed to get helper keys at a higher level than the special level . In the weak security definition, the special level turns to the threshold level . Namely, A cannot get any helper keys at level ∈ [ , L]. As we claimed earlier, Bellare and Palacio's work [7] implies that any HIBE scheme can be transformed into an HKIBE scheme with weak security.

Remark 3 (A variant of security definition)
One may consider a stronger variant of our security definition so that A can designate a derivation path of helper keys with a key-insulation query on (id, t, ); that is, A is allowed to designate how the helper key hk ( ) id,T (t) is derived. Since such a strong notion makes formalization complicated, we do not consider it for simplicity. Nevertheless, our constructions satisfy such a strong definition.

Generic construction from HIBE with MSK evaluatability
We propose a generic construction of an HKIBE scheme with key-insulation depth L from an HIBE scheme with identity depth L + 1 supporting MSK evaluatability. We assume that I, T 0 , . . . , T L ⊆ I hibe holds, where I hibe is an element identity space of HIBE.

Construction idea
The basic idea is quite simple: to encrypt a message M with an identity id and time t, run the HIBE encryption algorithm Enc with M and a hierarchical identity (id, T [L−1,0] (t)) (i.e., ct id,t := C (id,T [L−1,0] (t)) ). Therefore, to make the decryption procedure consistent, we set a decryption key dk id,T 0 (t) ∈ SK (id,T [L−1,0] (t)) . However, if we set each helper key hk L hk

Fig. 1 The intuition of our first construction
Our construction's core spirit is that we use L pseudo-MSKs MSK id,0 , . . . , MSK id,L−1 to mask the highest-level helper key hk id,T L (t) and gradually remove them with EvalMSK as the hierarchy of key-insulation levels is lowered. 9 More specifically, when executing GenHK with any id, we mask the true MSK MSK with all the pseudo-MSKs MSK id,0 , . . . , MSK id,L−1 (in the fraction form) and set the highest-level helper key hk (1) Run GenSK with its higher-level helper key hk In the end, the mask is entirely removed at the lowest level, i.e., dk id,T 0 (t) ∈ SK (id,T [L−1,0] (t)) [MSK]. We illustrate the idea in Fig. 1. As can be seen above, all the masks cannot be removed unless an adversary gets secret keys at all levels; the adversary is not allowed to do so due to the security definition (i.e., there exists a special level that the adversary cannot access).
Note that without loss of generality, we assume 0 ∈ T act to describe initial helper keys simply. Output -KeyUp(pp, t, hk and output ku As the special case for = 0, hk

Run and output
Correctness. Thanks to the evaluation correctness of MSK evaluatability, decryption keys of our HKIBE scheme follow the same distributions as those of the underlying HIBE scheme; hence, the correctness of our HKIBE scheme readily follows from that of the underlying HIBE scheme.

Security
The security of the HKIBE scheme is reduced to from that of the underlying HIBE scheme supporting MSK evaluatability. Proof overview First of all, we divide A's attack strategy into L + 1 types with respect to a special hierarchical level ∈ [0, L] defined in the key-insulation query. Let A be an adversary A that makes key-insulation queries so that there exists a special level . Since this covers all the possible strategies, the proof against a fixed A is sufficient for a proof against A of a general strategy with (L) reduction loss. Now, we use A as a building block and construct a reduction algorithm B against the underlying HIBE scheme. The main observation is that B can answer all A 's queries by making HIBE secret-key reveal queries for the corresponding identity, say, (id, T [L−1, ] (t)), as long as it holds even without the knowledge of the challenge tuple (id , t ). Obviously, B answers all queries for id ( = id ) by making HIBE secret-key reveal queries since such a case always satisfies the condition (1). Therefore, the challenge is how B answers A 's queries for id , which might not meet the condition (1). Roughly speaking, we look at the MSK-part of (hk ( ) id ,0 ) ∈[0,L] differently: In the construction, for every ∈ [0, L], the MSK-part of hk The above simulation can be done only when B knows id (i.e., selective security). Nonetheless, it is applicable even to adaptive security by guessing when the target identity id is queried at the beginning of the game: let id q be an identity on which A makes q-th helper-key generation query, and B first guesses the number Q ∈ [Q] such that id Q = id with (Q) reduction loss. 10 Then, B sets the pseudo-MSKs for id Q as above, instead of id , although it will turn out id Q = id after the challenge query.

Proof of Theorem 1
We formally describe the proof as follows. As above, let B be a reduction algorithm against the underlying HIBE scheme. We show how to construct B by using A as follows. First of all, please keep in mind that B will set as the challenge identity in the HIBE security game. Therefore, B does not make HIBE secret-key reveal queries on the challenge identity itself and its prefix identities during the game. At first, B is given an HIBE's master public key MPK from an HIBE challenger C. Then, B initializes HKList = ∅ and sends pp := MPK to an HKIBE adversary A .
Let id q be an identity on which A makes a q-th helper-key generation query. Then, B guesses the number Q ∈ [Q] such that id Q = id . If the guess is incorrect, B outputs a random bit and aborts the game. The guess is correct with probability 1/Q. In the following, we assume that the guess is correct.

B answers A 's queries by interacting with C as follows:
Helper-key generation query Upon a query id q from A , B checks if (id, ·) / ∈ HKList holds, and returns ⊥ to A if this is not the case. Otherwise, B proceeds as follows: Case for q = Q ] To get (SK (id q ,T [L−1, ] (0)) ) ∈[0,L] , B makes secret-key reveal queries on and stores an initial helper key (id q , (hk Observe that the helper keys created by B are properly distributed as follows: For every

Case for
and stores a part of an initial helper key (id Q , (hk B does not create the rest of the initial helper key (hk ( ) id ,0 ) ∈[0, ] at this point, and on key-insulation query, helper keys for any t ∈ T act and ∈ [0, − 1] will be computed directly from the pseudo-MSKs, not the corresponding initial helper keys.
We show that the level-helper keys for ∈ [ + 1, L] and the pseudo-MSKs created above and are properly distributed as follows. Since the above procedure is the same as that of the construction if = L, we consider the case for = L. In the case, B implicitly sets Case for ∈ [0, − 1]: The level-pseudo-MSK MSK id Q , = MSK id Q , is created in the same way as the construction by running SampMSK algorithm. Case for : The level-pseudo-MSK MSK id Q , is created by running SampMSK algorithm in the construction (i.e., MSK id Q , is the output of SampMSK). In the reduction, we assume that the level-pseudo-MSK is in the construction. The difference between the construction and the reduction is that the Therefore, thanks to the evaluation correctness in Def. 2, the level-L helper key follows the same distribution as in the construction. Similarly, for ∈ [ +1, L −1] the main component of level-helper key hk in the construction, and its MSK-part is replaced with i∈[ ,L] MSK id Q ,i in the reduction. It is easy to see that the level-helper key follows the same distribution as in the construction thanks to the evaluation correctness in Def. 2.
Initial helper-key reveal query Upon a query id q from A , B finds (hk ( ) id q ,0 ) ∈[0,L] from HKList and returns (hk ( ) id q ,0 ) ∈[0,L] to A . B can answer all A 's queries since A does not make the query on id (= id Q ) due to the restriction in the query. (id q , t, ) from A , B proceeds as follows:

Key-insulation query Upon a query
Case for id q = id Q : B finds the initial helper keys (hk Observe that the level-helper key is properly distributed thanks to the evaluation correctness in Def. 2. (t ))) due to the restriction on the special level . 12 As we already observed, B perfectly simulates the adaptive security game against A with probability 1/Q. Since the probability that β is a correct guess is the same as that of b , B 's advantage is Adv If the underlying HIBE scheme is selectively secure, our HKIBE scheme then satisfies selective security. Similarly, if the underlying HIBE scheme is CCA-secure, our HKIBE scheme meets CCA security. We omit the proofs since they can be done in the same manner as Theorem 1.

Generic construction from plain HIBE
We provide a generic construction of an HKIBE scheme with depth L from any plain HIBE scheme with depth L +1. This construction is based on Hanaoka et al.'s HKIBE scheme [30], and can be easily extended to an adaptive-identity CCA secure scheme (see Sect. 5.4). We suppose that the first log(L + 1) bits of each identity of our HKIBE scheme is used for indicating the hierarchical level , and the rest expresses the identity (i.e., id ∈ I hibe ≈ [0, L] × I). For instance, if the bit-length of identities in the underlying HIBE scheme is 256 bits and L = 250 (i.e., log(L + 1) = 8), then the identity in our HKIBE scheme is 248 bits.

Construction idea
The aim of our second construction is to get rid of MSK evaluatability from the first construction while keeping the security. The basic idea is to employ an (L + 1)-out-of-(L + 1) secret sharing scheme for plaintexts, where as the first construction employs it for MSK-parts of helper keys. Specifically, this construction's core spirit is that a ciphertext ct id,t consists of L + 1 HIBE ciphertexts M . The plaintext and all pseudo-plaintexts can be viewed as shares of an (L + 1)-out-of-(L + 1) secret sharing scheme. We design the scheme so that each user id can decrypt a ciphertext ct id,t only if the user is able to decrypt all the L + 1 HIBE ciphertexts. Indeed, the similar design concept is employed in the HHSI05 scheme [30]. However, our design requires only one HIBE scheme with the hierarchical depth L + 1 while the HHSI05 scheme consists of L + 1 HIBE schemes for the different depth ∈ [L + 1]. This design improvement makes master public/secret keys be constant sizes.
We illustrate the overview in Fig. 2. As mentioned above, we consider L + 1 hierarchical identities for ciphertexts in the underlying HIBE scheme: , and a new HIBE secret key SK id . Since there exists a special level such that no level-helper keys are compromised, an adversary does not have SK id . In addition to this, the adversary cannot obtain any secret keys which can derive SK ( id,T [ ,0] (t )) due to the restriction in the security game, the adversary cannot decrypt the challenge ciphertext.
and output ku Correctness. Since ciphertexts and decryption keys of our HKIBE scheme consists of those the underlying HIBE scheme, the correctness of the HKIBE scheme readily follows from that of the underlying HIBE scheme.

Security
The security of the HKIBE scheme is reduced to that of the underlying HIBE scheme.

Theorem 2
If the underlying HIBE scheme with hierarchical depth L +1 satisfies the adaptive security, the above HKIBE scheme with hierarchical depth L also satisfies the adaptive security. Specifically, if there exists an adversary A to break the adaptive security of the above HKIBE scheme with advantage Adv HKIBE ,L,A (λ), then there exists a reduction algorithm B to break the adaptive security of the underlying HIBE scheme with advantage Adv HIBE ,L+1,B (λ) ≥ Adv HKIBE ,L,A (λ)/ (L).

Proof overview
In the proof, we divide A's attack strategy into L + 1 types and define A for every ∈ [0, L] as in the proof of Theorem 1 with (L) reduction loss. We show the proof against A for fixed . We use A as a building block and construct a reduction algorithm B against the underlying (plain) HIBE scheme. The challenge ciphertext for (id , t ) includes L +1 HIBE ciphertexts C (L id ,T [L−1,0] (t )) , . . . , C 0 id , and one of them should be the HIBE challenge ciphertext to reduce to adaptive security of the underlying HIBE scheme. Since A does not make any key-insulation queries for (id , t, ), B submits as the HIBE challenge identity. Therefore, B can answer all A 's key-insulation queries, say, (id, t, ), by making HIBE secret-key reveal queries for the corresponding identities (( j id, T [ j−1, ] (t))) j∈[ ,L] as long as it holds even without the knowledge of the challenge tuple (id , t ). Since B can obtain all HIBE secret keys such that ( , id) = ( , id ) via HIBE secret-key generation queries, the condition (2) can be more specific: Therefore, we should care only about the key-insulation query (id , t, ) that produces ( id , T [ −1, ] (t)). In the construction, only level-helper keys hk All the above pseudo-plaintexts are properly distributed.

Proof of Theorem 2
We formally describe the proof as follows. Let B be a reduction algorithm against the underlying HIBE scheme. We show how to construct B by using A as follows. At first, B is given an HIBE's master public key MPK from an HIBE challenger C. Then, B initializes HKList = ∅ and sends pp := MPK to an HKIBE adversary A . B answers A 's queries by interacting with C as follows: Helper-key generation query Upon a query id from A , B checks if (id, ·) / ∈ HKList, and returns ⊥ to A if this is not the case. Otherwise, B makes an HIBE secret-key query on id for ∈ [0, L] \ { } to C, receives (SK id ) ∈[0,L]\{ } , and stores a part of an initial helper key (id, (SK id ) ∈[0,L]\{ } ) in HKList. Clearly, the part of the helper keys (SK id ) ∈[0,L]\{ } are created in the same way as the construction.  holds, the distribution of C 0 id is the same as that of the construction.
After B receives b from A , B returns β ← b as its own guess to C. The above completes the description of B . Observe that B can answer all of A's queries with C. B makes the HIBE challenge query on while B can make HIBE secret-key reveal queries in any case for the following reasons.
-The initial helper-key reveal query on id.
Case for id = id : It is obvious that B can make HIBE secret-key reveal queries on id for every ∈ [0, L].
Case for id = id : This query is not allowed in the game. - The key-insulation query on (id, t, ).
Case for id = id : B can make HIBE secret-key reveal queries to return hk ( ) id,T (t) . Case for id = id : We take look at the following three cases. As we already observed, B perfectly simulates the adaptive security game against A . Since the probability that β is a correct guess is the same as that of b , B 's advantage is Adv HKIBE ,L,A (λ) = Adv HIBE ,L+1,B (λ). Therefore, B's advantage against A of general attack strategy is Adv HKIBE ,L,A (λ) = ∈[0,L] Adv HKIBE ,L,A (λ) = (L + 1) · Adv HIBE ,L+1,B (λ).
As in the first construction, if the underlying HIBE scheme is selectively secure, our HKIBE scheme then satisfies selective security. We omit the proof since it can be done in the same manner as Theorem 2.

Achieving CCA security
Unlike the first construction, we cannot obtain a CCA-secure construction by just replacing the underlying CPA-secure HIBE scheme with a CCA-secure one. In other words, simply applying the CPA-to-CCA transformation [11] in a naive way is insufficient for updating our second construction to be CCA-secure. The reason is that the second construction requires L + 1 HIBE ciphertexts for each HKIBE ciphertext, while the ciphertext of the first construction consists of only one HIBE ciphertext. If we just replace the underlying CPA-secure HIBE scheme with a CCA-secure one, there is the following trivial attack: an adversary A replaces C 0 id of the challenge ciphertext ct id ,t with Enc(MPK, 0 id , 0 |M 0 | ) (the modified challenge ciphertext is denoted by ct id ,t ), makes a decryption query on (id , t , ct id ,t ), and receives (the modified challenge ciphertext is denoted by ct id ,t ), makes a decryption query on (id , t , ct id ,t ), and receives M b ∈[L] M . Therefore, A can get M b and win the game with probability one. To circumvent the above attack and achieve CCA security, we apply the CPA-to-CCA transformation technique [11] to all (L + 1) ciphertexts of the underlying CPA-secure HIBE scheme at once, not each of them, as in the previous work [30]. or ⊥: given the verification key verk, a message M, and its signature σ , it outputs , which indicates "acceptance", or ⊥, which indicates "rejection".
We require that for all security parameters λ, (sigk, verk) ← SSetup(1 λ ), and messages M, it holds Vrfy(verk, M, Sign(sigk, M)) = with overwhelming probability. We define a security notion for OTS. Let be an OTS scheme, and we consider a game between an adversary F and the challenger C. The game is parameterized by the security parameter λ. The game proceeds as follows: C first runs (sigk, verk) ← SSetup(1 λ ) and gives verk to A. F is allowed to make the signature generation query only once: upon a query M from F , C returns σ ← Sign(sigk, M) to A. F outputs (M , σ ) and terminates. In this game, F 's adaptive security advantage is defined by  Proof We can prove this theorem in the same manner as Theorem 2. We divide A's attack strategy into L + 1 types (with (L) reduction loss), and show the proof against A of the Type-strategy (denoted by A ) for fixed . Let B be a reduction algorithm against the underlying HIBE scheme. We show how to construct B by using A that does not make any decryption query that includes valid verk . At first, B is given an HIBE's master public key MPK from an HIBE challenger C, and computes (sigk , verk ) ← SSetup(1 λ ). Then, B initializes HKList = ∅ and sends pp := MPK to an HKIBE adversary A . B can answer all queries except for decryption and challenge queries in the same way as in the proof of Theorem 2. Therefore, we here describe how to answer decryption queries (that does not include valid verk ) and challenge query.
Decryption query Upon a query (id, t, ct id,t ) from A , B checks the following two conditions:  As we already observed, B perfectly simulates the adaptive security game against A . Since the probability that β is a correct guess is the same as that of b , B 's advantage is Adv

Conflict of interest
The authors declare that they have no conflict of interest.
Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article's Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article's Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.
To view a copy of this licence, visit http://creativecommons.org/licenses/by/4.0/. distribution, and the other is distributions that only appear in the security proof, called the semi-functional distribution. Although normal secret keys can decrypt both normal and semi-functional ciphertexts, semi-functional secret keys cannot decrypt semi-functional ciphertexts. During the security proof, we first change a challenge ciphertext to be semifunctional, then change all secret keys queried by an adversary to be semi-functional one by one. Essentially, the reason why the changes succeed is that, in plain HIBE, the adversary is not allowed to query the challenge identity or its ancestors. Since the adversary completely loses decryption capability after the changes, it is easy to replace the underlying plaintext of the challenge ciphertext with a random one without being noticed by the adversary.
The overview of the bug To the authors' credit, the SW18 scheme is the same as our first construction instantiated by [46]. It means that the flaw is due to the proof methodology they employed, not their construction. The proof of [52] employs dual system encryption in a naïve manner; the challenge ciphertext is first changed to be semi-functional, then all helper keys and decryption keys are changed to be semi-functional one by one. However, the latter changes failed in the sense that the changed keys do not distribute properly as the authors expected or an adversary is able to detect the changes. What is essential here is that the HKIBE adversary is allowed to make key-insulation queries on the challenge identity id , whereas the HIBE adversary does not make any secret-key reveal queries on ID . We explain the details below.
HIBE proof using dual system encryption If the adversary is allowed to make a query on the prefix of the challenge identity, the simulation fails since the randomness of the secret key for the query would be correlated to the randomness of the challenge ciphertext. Nevertheless, such a query is not allowed during the security game. Therefore, the dual system encryption goes through since the reduction algorithm does not need to create and reveal information on ID except for the challenge ciphertext C ID ; the randomness for C ID is independent of randomness for any secret keys from the viewpoint of the adversary.
Proof of [52] The HKIBE challenge ciphertext ct id ,t can be regarded as a ciphertext for (id , T [L−1,0] (t )) in the HIBE scheme proposed by [46]. The randomness of the challenge ciphertext ct id ,t := C (id ,T [L−1,0] (t )) is correlated to the randomness of level-helper keys hk ( ) id,T (t) for the key-insulation query on (id , t, ) such that > . This is due to the form of hk ( ) id,T (t) : roughly speaking, the level-helper key hk ( ) id,T (t) is the HIBE secret key of [46] for a hierarchical identity (id, T [L−1, ] (t)) masked with a random group element. The adversary is allowed to make the key-insulation query (id , t , (> )), and hence can obtain the HIBE secret key of [46] for a hierarchical identity (id , T [L−1, ] (t )) ∈ prefix + ((id , T [L−1,0] (t ))) (with a random mask). As mentioned above, in the standard HIBE game, a query on such a hierarchical identity, i.e., the prefix of the challenge identity, is not allowed and spoils dual system encryption. The authors seemed to expect that the random mask of hk ( ) id ,T (t ) would help to resolve the issue, however, it does not; the query still leads to the correlation. Thus, the simulation fails when the adversary obtains both ct id ,t and hk