1.1 Our techniques

The dual system encryption framework [10] is usually for proving the adaptive security of HIBEs in composite-order bilinear groups. To achieve the adaptive security in the framework, the notion of semi-functionality is introduced [10] [11] and the proof strategy is that a normal challenge ciphertext is changed to be semi-functional, and then each normal private key is changed to be semi-functional one by one through hybrid games.

There is a paradox that need to be overcome. Since a normal ciphertext can be decrypted by a semi-functional private key but a semi-functional ciphertext cannot be decrypted by a semi-functional private key, a simulator can check whether a private key is normal or semi-functional by decrypting a semi-functional ciphertext(note that a simulator can generate a ciphertext and a private key for any identity). To overcome the obstacle, the nominally semi-functional type of private keys is introduced: the challenge semi-functional private key is constructed as a nominally semi-functional private key so that the semi-functional ciphertext of the same identity the simulator generates always can be decrypted by it. In addition, a detailed information theoretic argument should be given to argue that a nominally semi-functional key is indistinguishable from a semi-functional key.

Although the dual system encryption is maturing to exploit in normal HIBEs to achieve the adaptive security, it is more complex when dealing with revocable HIBE schemes. In HIBE, the essential restriction for the information theoretic argument is that an adversary cannot query a private key for ID that is a prefix of the challenge identity ID*. However, the restriction do not exist in RHIBEs. The private key of any prefix of ID* and the update key for the challenge time T* are both allowed to query for the adversary in RHIBEs. Recall that the simulator of an HIBE scheme can change the normal-private key to a semi-functional private key by using a nominally semi-functional key and the constraint ID ∉ Prefix(ID*) of the security model. The nominally semi-functional key is indistinguishable from a semi-functional key by an information theoretic argument using the constraint ID ∉ Prefix(ID*). However, in the case of (U-)RHIBE, a simple method cannot change the normal-private key to the semi-functional private key since the adversary can query and achieve the private key for any ID ∈ Prefix(ID*).

Moreover, an unbounded RHIBE scheme has so low entropy context that it is hard to execute an information-theoretic argument, which is different with those bounded RHIBE schemes. So the dual system encryption method in Lee-RHIBE [5] does not work. Although Lewko and Waters [12] has proposed a nested dual system encryption approach to allow a sufficient information-theoretic argument in a very localized context for unbounded HIBEs, the trival applying to a revocable extention scheme is inappropriate to hold the paradox information theoretic argument. Unfortunately Xing and Wang [9] have neglected this important change, so that the proof of their unbounded RHIBE scheme is non-rigorous with flaws. Obviously the attacker can distinguish between the oracles they design for the game hoppings in [9], which is not as they claimed in Lemma 4.

To circumvent the subtle obstacle and apply the dual system encryption methodology for our adaptively secure unbounded RHIBE with decryption key exposure resistance, our strategy is threehold:

(1) We use a modular design strategy like [13] and construct the private keys and update keys from smaller component keys. A private key consists of many HIBE private keys that are related to a path in a binary tree and an update key also consists of many IBE private keys that are related to a cover set in a binary tree. The HIBE and IBE private keys can be grouped together if they are related to the same node in a binary tree. So we change to deal with the transformation of component HIBE and IBE keys in the hybrid games instead of directly with the private keys and update keys of RHIBE which cannot be simply changed from normal keys to semi-functional keys.

(2) We design a nested dual system encryption for revocable and hierarchical IBE schemes with the concept of ephemeral semi-functionality for secret keys, update keys, decryption keys and ciphertexts. To demonstrate a hybrid process of games to chellenge keys and ciphertexts, we define several oracles to simulate the different forms of the component HIBE and IBE keys which construct the semi-functional or ephemeral semi-functional secret keys, update keys and decryption keys.

(3) For showing an information theoretic argument under RHIBE model successfully, we firstly classify the behavior of an adversary as two types under the restriction of the RHIBE security model. The Type-1 adversary is restricted to queries on the secret keys of any hierarchical identity satistying , so we carefully re-design a sequence of hybrid games to show several times of information theoretic arguments successfully for the secret keys and avoid a potential paradox for the update keys. The Type-2 adversary is restricted to queries on the update keys on the time T ∉ T*, so we carefully re-design the other sequence of hybrid games to show several times of information theoretic argument successfully for the update keys and avoid a potential paradox for the secret keys.

1.2 Our result

We propose the first adaptively secure unbounded RHIBE in composite-order bilinear groups under simple static assumptions. It removes the limitation of the maximum hierarchical depth in the encryption system and accommodate more levels of user adaptively without adding workload or restarting the system. Our RHIBE scheme also supports decryption key exposure resistance by the key-randomization method which meets the strong security notion for R(H)IBE [14].

Compared to existing RHIBE schemes, it is the first RHIBE to achieve simultaneously adaptive-ID security, decryption key exposure resistance and unbounded key delegation, as shown in Table 1. In Table 2, we discuss the comparison about the efficiency of key space and decryption computation, noted that l is the maximum level of the hierarchy, h is the level of a user in the hierarchy, N is the number of maximum users in each level, r is the number of revoked users, t_e is the cost for performing a bilinear pairing, |G| and |G_T| are the sizes of one element in G and G_T respectively. Our RHIBE scheme has the short and constant public parameter which is independent with the maximum level of the system hierarchy. Moreover, our RHIBE reduces the size of the update key from O(hrlog(N/r))to O(h + rlog(N/r)).

Download:

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

Table 1. Comparisons among RHIBE schemes.

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

Download:

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

Table 2. Comparisons among RHIBE schemes.cont.

https://doi.org/10.1371/journal.pone.0195204.t002

1.3 Related works

2.1 Revocable HIBE

Definition 1 We define a RHIBE scheme π = (Setup, GenKey, DeriveKey, UpdateKey, Encrypt, Decrypt, Revoke) as following:

1. Setup(1^λ): It takes a security parameter λ, and outputs a master public key PP, a master secret key MK, initial state ST₀, and an empty revocation list RL. Note that we don’t require the maximum number of users in each level as an input parameter, unlike the defination by all the bounded RHIBEs.
2. GenKey(ID|_k, ST_ID|k−1, PP): This algorithm takes as input ST_ID|k−1 and an identity ID|_k outputs the secret key SK_ID|k, and updates ST_ID|k−1.
3. UpdateKey(T, RL_ID|k−1, DK_ID|k−1,T, ST_ID|k−1, PP): This algorithm takes as input the revocation list RL_ID|k−1, state information ST_ID|k−1, the decryption key DK_ID|k−1,T,and a time period T. Then, it outputs the update key UK_ID|k−1,T.
4. DeriveKey(SK_ID|k, UK_ID|k−1,T, PP): This algorithm takes as input SK_ID|k of ID|_k and UK_ID|k−1,T, and outputs the decryption key DK_{ID|k, T} of ID|_k at time T if ID|_k is not revoked at T by the parent, else outputs ⊥.
5. Encrypt(ID|_l, T, M, PP): This algorithm takes as input a message M, ID|_l and the current time T and outputs the ciphertext CT.
6. Decrypt(CT_{ID|l, T}, DK_{ID′|k, T′}, PP): This algorithm takes as input CT_{ID|l, T} and DK_{ID′|k, T′}, and outputs the message if ID′|_k is a prefix of ID|_l and T T = T′, else outputs ⊥.
7. Revoke(RL_ID|k−1, ST_ID|k−1, ID|_k, T): This algorithm takes as input ID|_k and T, updates RL_ID|k−1 managed by ID|_k−1, who is the parent user of ID|_k, by adding (ID|_k, T).

Definition 2 We define an experiment under the adaptive-ID security against chosen plaintext attacks model in [5], as named “IND-RID-CPA” security.

In the above experiment, O is a set of oracles {SKGen_Q(⋅), KeyUp_Q(⋅, ⋅), Revoke_Q(⋅, ⋅), DKGen_Q(⋅, ⋅)} defined as follows:

• SKGen_Q(⋅): For ID|_k ∈ , it returns SK_ID|k (by running GenKey(ID|_k, ST_ID|k−1, PP)→ SK_ID|k).
• KeyUp_Q(⋅, ⋅): For T ∈ and BT_ID|k−1, it returns KU_{T, ID|k−1} (by running UpdateKey(T, RL_ID|k−1, DK_ID|k−1, ST_ID|k−1, PP) → KU_t).
• Revoke_Q(⋅, ⋅): For ID|_k ∈ and T ∈ , it returns the updated revocation list RL (by running Revoke(RL_ID|k−1, ST_ID|k−1, ID|_k, T)).
• DKGen_Q(⋅, ⋅): For ID|_k ∈ and T ∈ , it returns DK_{ID|k, T} (by running DeriveKey(SK_ID|k, UK_ID|k−1,T, PP)→DK_{ID|k, T}).

is allowed to issue the above oracles with the following restrictions:

1. Revoke_Q(⋅, ⋅) can be queried on time T if KeyUp_Q(⋅) was queried on T.
2. DKGen_Q(⋅, ⋅) cannot be queried on time T before KeyUp_Q(⋅) was queried on T.
3. If requested a private key query for that is a prefix of where k ≤ l, then the identity or one of its ancestors should be revoked at some time T where T ≤ T*.
4. A cannot request a decryption key query for the challenge identity ID*|_l or its ancestors on the challenge time T*.
5. cannot request a revocation query for ID|_k on time T if he already requested an update key query for ID|_k in time T.
6. must query to KeyUp(⋅, ⋅) and Revoke(⋅, ⋅) for same identity in increasing order of time.

The advantage of is defined as . We say that RHIBE is IND-RID-CPA secure if for all PPT adversary , his advantage is negligible in the security parameter λ.

2.2 Complexity assumptions

We generate where G and G_T be cyclic groups with order N and p = p₁ p₂ p₃, p₁, p₂, p₃ are distinct prime numbers, e: G×G→ G_T is an efficient, nondegenerate bilinear map. We denote the subgroup of G with order p_i as G_pi. We define a function for any PPT algorithm and parameters D, T₁, T₂.

Assumption 1. Let , , , , we say that satisfies Assumption 1 if is a negligible function of λ for any PPT algorithm is .

Assumption 2. Let , , , , T₁ be e(g, g)^αs, , D = , we say that satisfies Assumption 2 if is a negligible function of λ for any PPT algorithm is .

Assumption 3. Let , , , , , D = , we say that satisfies Assumption 3 if is a negligible function of λ for any PPT algorithm is .

Assumption 4. Let , , , , , D = , we say that satisfies Assumption 4 if is a negligible function of λ for any PPT algorithm is .

3.1 HIBE scheme

We define a key-group function κ(I, y, r) as the group elements and an expression g^λ κ(I, y, r) as

HIBE.Setup(GS): It selects and . It outputs a master key MK = α and public parameters PP = ((p, G, G_T, e), g, u, h, w, v, Ω = e(g, g)^α).

HIBE.GenKey(ID|_k, MK, PP): Let the identity , and be the identity space. It chooses where λ₁ + ⋯ + λ_k = α and outputs a private key .

HIBE.RandKey(ID|_k, SK_ID|k, PP): Let . It chooses where λ₁ + ⋯ + λ_k = 0 and outputs a re-randomized private key .

HIBE.Delegate(ID|_k, SK_ID|k−1, PP): Let . It chooses where λ₁ + ⋯ + λ_k = 0 and creates a temporal delegated private key . Next, it outputs a delegated private key SK_ID|k by running HIBE.RandKey(ID|_k, TSK_ID|k, PP).

HIBE.Encaps(ID|_l, s, PP): Let ID|_l = (I₁, …, I_l) ∈ I^l. It chooses and outputs a ciphertext and a session key EK = Ω^s.

HIBE.Decaps(CT_ID|l, SK_ID′|k, PP): Let , . If ID′|_k is a prefix of ID|_l, it outputs a session key e(C_i,2, K_i,2))). Otherwise, it outputs ⊥.

Additionally, we introduce two algorithms for our modular RHIBE construction, the ChangeKey algorithm and the MergeKey algorithm, which are defined similarly with the algorithms in [5].

HIBE.ChangeKey(SK_ID|K, δ, PP): Let . It chooses where λ₁ + ⋯ + λ_k = δ and sets . It outputs a new private key SK_ID|K ← HIBE.RandKey(ID|_k, TSK_(n), PP).

HIBE.MergeKey: Let and be two private keys for the same identity ID|_K. It computes a temporal private key . Next, it outputs a merged private key SK_ID|K ← HIBE.ChangeKey(TSK, η, PP). Note that the master key part is α₁ + α₂ + η if the master key parts of and are α₁ and α₂ respectively.

3.2 IBE scheme

A trivial extension to RHIBE from the HIBE in [12] constructs the decryption key of (T, ID|_k) as . It remains some problem in the proof of RHIBE model, where the information theoretic argument is not easy to show as of the model of HIBE. So we modify the construction by defining a new update-key-group function as (1) and D₀ = , which is constructed from the component IBE secret key.

IBE.Setup(GS): It selects and . It outputs a master key MK = β and public parameters PP = ((p, G, G_T, e), g, u₀, h₀, w₀, v₀, Ω = e(g, g)^β).

IBE.GenKey(T, MK, PP): This algorithm takes as input a time T and the master key MK, and the public parameters PP. It chooses and outputs a IBE secret key SK_T = g^α κ_T(T, y, r).

IBE.RandKey(T, SK_T, PP): Let the private key be . It chooses and outputs a re-randomized private key .

IBE.Encaps(T, s, PP): It chooses and outputs a ciphertext and the session key EK = Ω^s.

IBE.Decaps(CT_T, SK_T′, PP): Let the ciphertext CT_T = (C₀, C₁, C₂, C₃), the private key SK_T = (K₀, K₁, K₂, K₃). If T = T′, it outputs a session key EK = e(C₀, K₀)e(C₃, K₃)/(e(C₁, K₁) e(C₂, K₂)). Otherwise, it outputs ⊥.

The contruction of IBE.ChangeKey and IBE.MergeKey is similar with HIBE.ChangeKey and HIBE.MergeKey and we omit them here.

3.3 The CS method

We exploit the complete subtree (CS) method to construct our RHIBE scheme. We follow the definition of the CS scheme in the work of Lee and Park [22].

CS.Setup(N_max): Let N_max = 2ⁿ. It first sets a full binary tree of depth n. Each user is assigned to a different leaf node in . The collection S is defined as {S_i} where S_i is the set of all leaves in a subtree with a subroot . It outputs the full binary tree .

CS.Assign: Let v_ID be a leaf node of that is assigned to the user ID. Let (v_k0, v_k1, ⋯, v_kn) be the path from the root node v_k0 = v₀ to the leaf node v_kn = v_ID. For all j ∈ {k₀, ⋯, k_n}, it adds S_j into PV_ID. It outputs the private set PV_ID = {S_j}.

CS.Cover: It first computes the Steiner tree ST(R). Let be all the subtrees of that hang off ST(R), that is all subtrees whose roots v_k1, ⋯, v_km are not in ST(R) but adjacent to nodes of outdegree 1 in ST(R). For all i ∈ {k₁, ⋯, k_m}, it adds S_i into CV_R. It outputs a covering set CV_R = {S_i}.

CS.Match(CV_R, PV_ID): It finds a subset S_k with S_k ∈ CV_R and S_k ∈ PV_ID. If there is such a subset, it outputs S_k. Otherwise, it outputs ⊥.

3.4 Construction

RHIBE.Setup(1^λ, N_max): The Setup algorithm takes a security parameter λ and a maximum number of users for each level N_max as input. It firstly runs to obtains two groups G, G_T of order p = p₁p₂p₃, where p₁, p₂, p₃ are distinct primes, and a bilinear map e: G×G→G_T. It sets GS = ((N, G, G_T, e), g, g₂, g₃) where g, g₂ and g₃ denote the generators of G_p1, G_p2, and G_p3 in order. It selects a random exponent α ∈ Z_p, set Ω be e(g, g)^α. It outputs a master key MK = α and public parameters PP = (PP_HIBE, PP_IBE, Ω, N_max), where PP_HIBE ← HIBE.Setup(GS), and PP_IBE ← IBE.Setup(GS).

RHIBE.GenKey(ID|_k, ST_ID|k−1, PP): This algorithm takes as input an identity ID|_k = (I₁, …, I_k) ∈ , the state ST_ID|k−1 which contains BT_ID|k−1.

1. If ST_ID|k−1 is empty, it obtains BT_ID|k−1 ← CS.Setup(N_max) and then it sets ST_ID|k−1 = (BT_ID|k−1, β_IDk−1, z_IDk−1), where β_IDk−1 is a false master key and z_IDk−1 is a PRF key.
2. It first assigns ID|_k to a random leaf node v ∈ BT_ID|k−1 and obtains a node set Path(ID|_k) ← CS.Assign(BT_ID|k−1, ID|_k) for ID|_k. For each S_θ ∈ Path, it computes γ_θ = PRF (z_IDk−1, L_θ) where L_θ = Label (S_θ) and obtains an HIBE private key SK_HIBE,Sθ ← HIBE.GenKey(ID|_k, γ_θ, PP). Finally, it outputs a private key SK_ID|k = (Path, {SK_HIBE,Sθ}_Sθ∈Path). Note that the master key part of SK_HIBE,Sθ is γ_θ.

RHIBE.UpdateKey(T, RL_ID|k−1, DK_ID|k−1, ST_ID|k−1, PP): let , the state ST_ID|k−1 = (BT_ID|k−1, β_ID|k−1, z_ID|k−1) with k ≥ 1.

1. It first obtains a randomized decryption key RDK_ID|k−1,T as (RSK_IBE, RSK_HIBE)←RHIBE.RandDK(DK_ID|k,T, −β_ID|k−1, PP).
2. It derives the set of revoked identities R at time T from RL_ID|k−1. Next, it obtains a covering set CV_R = {S_i} by running CS.Cover(BT_ID|k−1, R).
3. For each S_i ∈ CV_R, it computes γ_i = PRF(z_IDk−1, L_i) where L_i = Label(S_i) and obtains an IBE private key . Then It computes
4. It finally outputs an update key UK_ID|k−1,T = (CV_R, {SK_IBE,Si, RSK_HIBE}_{Si ∈ CVR}). Note that the master key parts of RSK_HIBE and SK_{IBE, Si} are η′ and α − η′ − γ_i for some random η′ respectively.

RHIBE.DeriveKey(SK_ID|k, UK_ID|k−1,T, PP): This algorithm takes as input a private key SK_ID|k = (Path, {SK_HIBE,Sθ}_{Sθ ∈ Path}) for an identity ID|_k, an update key for time T.

1. If K = 0, then SK_ID|0 = MK = α and UK_ID|−1,T is empty. It selects a random exponent η ∈ Z_p. It then obtains RSK_{HIBE, ID|0} ← HIBE.GenKey(ID|₀, η, PP) and RSK_IBE,T ← IBE.GenKey(T, α − η, PP). It outputs a decryption key DK_ID|0,T = (RSK_{IBE, T}, RSK_{HIBE, ID|0}).
2. If k ≥ 1, then if ID|_k ∉ RL_ID|k−1, then it obtains (S_i, S_i) by running CS.Match(CV_R, Path). Otherwise, it outputs ⊥. It derives SK_HIBE,Si from SK_ID|k and SK_IBE,Si from UK_ID|k−1,T.
3. It obtains PP) since ID|_k−1 ∈ Prefix(ID|_k). Next, it selects a random exponent η ∈ Z_p, obtains SK_HIBE,Si, η, PP) and obtains RSK_IBE,T ← IBE.ChangeKey(SK_IBE,Si, −η, PP) respectively. Finally, it outputs a decryption key DK_ID|k,T = (RSK_IBE,T, RSK_{HIBE, ID|k}).

Note that the master key parts of RSK_{HIBE, ID|k} and RSK_{IBE, T} are η′ and α − η′ for some random η′ respectively.

RHIBE.RandDK: Let , and β ∈ Z_p be an exponent. It first selects a random exponent η and obtains and PP). It outputs a re-randomized decryption key DK_ID|k,T = (RSK_IBE,T, RSK_{HIBE, ID|k}).

RHIBE.Encrypt(ID|_l, T, M, PP): This algorithm takes as input an identity , time T, a message . It chooses a random exponent t ∈ Z_p. Next it obtains (CH_HIBE,ID|l, EK_HIBE) ← HIBE.Encaps(ID|_l, t, PP). It also obtains (CH_IBE,T, EK_IBE) ← IBE.Encaps(T, t, PP). It outputs a ciphertext CT_ID|k,T = (CH_IBE,T, CH_HIBE,ID|l, C = Ω^t ⋅ M).

RHIBE.Decrypt(CT_ID|l,T, DK_ID′|k,T′, PP): This algorithm takes as input a ciphertext CT_ID|l,T = (CH_IBE,T, CH_HIBE,ID|l, C), a decryption key DK_ID′|k,T′ = (RSK_IBE,T′, RSK_HIBE,ID′|k). If ID′|_k is a prefix of ID|_l and T = T′, then it obtains EK_HIBE ← HIBE.Decaps(CH_HIBE,ID|l, RSK_HIBE,ID|k, PP) and EK_IBE ← IBE.Decaps(CH_IBE,T, RSK_IBE,T, PP). Otherwise, it outputs ⊥. It outputs an encrypted message by computing M = C ⋅ (EK_HIBE ⋅ EK_IBE)⁻¹.

RHIBE.Revoke(ID|_k, T, RL_ID|k−1, ST_ID|k−1): This algorithm takes as input an identity ID|_k, revocation time T, the revocation list RL_ID|k−1, and the state ST_ID|k−1. If (ID|_k, −) ∉ ST_ID|k−1, then it outputs ⊥ since the private key of ID|_k was not generated. Otherwise, it adds (ID|_k, T) to RL_ID|k−1 and outputs the updated revocation list RL_ID|k−1.

3.5 Correctness

If a user is not revoked at time T, the RHIBE.DeriveKey algorithm correctly derive his decryption key DK_ID|k,T as

The RHIBE.Decrypt algorithm takes CT_ID|l,T as input, where and computes B = C/M as

4.1 Definition of (ephemeral) semi-functional keys and ciphertexts

For constructing the different types of ciphertexts, secret keys, update keys and decryption keys, the challenger is initially given renadom elements g, u, v, w, u₀, v₀, w₀ ∈ G_p1, g₂ ∈ G_p2, g₃ ∈ G_p3, as well as random exponents ψ₁, ψ₂, σ₁, σ₂, a′, b′, s, δ₁, δ₂, γ.

We define the semi-functional ciphertext and five types of ephemeral semi-functional ciphertexts of a normal ciphertext CT_ID|l,T by changing the C₀ element into G_p1p2 and the l + 1 numbers of the ciphertext-element-groups (C_i,1, C_i,2, C_i,3) into different types. The definations of ephemeral semi-functional ciphertexts called ESF-1-CT, ESF-2^k-CT, ESF-3^k-CT, ESF-4^k-CT and ESF-5-CT where 0 ≤ k ≤ l are in Appendix.A. In the definations of the semi-functional ciphertext, we add G_p2 term on the first element of all ciphertext-element-groups.

RHIBE.EncryptSF: It firstly obtains the normal ciphertext CT_ID|l,T = (C, C₀, ) for an identity , a time and a message . It chooses exponents γ, δ₁, δ₂ ∈ Z_p and outputs the SF-CT as

As we mentioned before, our normal secret key and update key cannot be simply changed to semi-functional keys as same as in [11] one by one owing to the inefficiency of the information theoretic argument in our scheme. And we divide secret keys and update keys into samll component keys which are group together if they are related to the same node in a binary tree.

We only change the last element-group of our normal secret key for constructing the semi-functional secret key and the ephemeral semi-functional secret key like in [11]. We define one type of semi-functional secret key and five types of ephemeral semi-functional secret key. The defination of ephemeral semi-functional secret key called ESF-1-SK, ESF-2-SK, ESF-3-SK, ESF-4-SK and ESF-5-SK are in Appendix.A. In the defination of the semi-functional secret key, we add G_{p2 p3} term on the first 2 elements and the last element of the last element-group.

RHIBE.SKeySF : It constructs the correlative sub-key to the node θ ∈ Path(ID_j) in the BT_ID|j−1 as follows: It chooses random exponents y′, r ∈ Z_p and choose σ₁, ψ₁ ∈ Z_p, then it constructs κ^sf(I_j, y′, r) for the last element-group as

And the contruction of the other element-groups follows the construction of SK_HIBE,Sθ in RHIBE.GenKey.

We define one type of semi-functional update key and five types of ephemeral semi-functional update key. The defination of ephemeral semi-functional update key called ESF-1-UK, ESF-2-UK, ESF-3-UK, ESF-4-UK and ESF-5-UK are in Appendix.A. The constructions from the normal component update key to the (ephemeral) semi-functional component update keys are similar to that of secret keys, expect that we change the first element group of normal component update key to different types.

RHIBE.UpdateKeySF : It constructs the correlative component key to the node θ ∈ KUNode as follows: It chooses random exponents y′, r ∈ Z_p and choose σ₂, ψ₂ ∈ Z_p, then it constructs of the first element-group (U_0,0, U_0,1, U_0,2, U_0,3) as

And the contruction of the other element-groups follows the construction of RSK_HIBE and SK_IBE,Sθ in RHIBE.UpdateKey.

RHIBE.DeriveKeySF: Let be a semi-functional secret key generated by the RHIBE.GenKeySF algorithm and be a semi-functional update key for time T generated by the RHIBE.UpdateKeySF algorithm. If ID|_k ∉ RL_ID|k−1, then it finds a unique node θ* by running CS.Match(CV_R(BT_ID|k−1, RL_ID|k−1, T), Path(ID|_k)). Otherwise, it outputs ⊥. It derives from and from for the node θ*. Then the semi-functional decryption key is as Then we re-randomize it by running RHIBE.RandDK and output it.

4.2 Sequence of games

We define a squence of games to verify the advantage in distinguishing G_Real and G_Final is negligible. In Table 3, we give the types of key in the queries and the challenge cipertext in every game, and the decryption situation according to the types of keys and ciphertexts.

Download:

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

Table 3. Defination of games.

https://doi.org/10.1371/journal.pone.0195204.t003

G_Real: It is the original game in which all seceret keys, update keys, decryption keys and ciphertexts are normal.

G_C: The challenge ciphertext is changed to be semi-functional and all other keys are still normal.

G_C′: This game is exactly like Game_C, except for a added restriction about the challenge key identity vector. We explain the restriction in Sec.4.6.

G_E−S: The secret keys are changed to ESF-2. The update keys and decryption keys are still normal. The challenge ciphertext is semi-functional. This game is used in the proof of the security against Type-1 adversary.

G_E−U: The update keys are changed to ESF-2. The secret keys and decryption keys are still normal. The challenge ciphertext is semi-functional. This game is used in the proof of the security against Type-2 adversary.

G_E−S′: This game is almost as same as G_E−S except the challenge ciphertext is chaged to ESF-1. This game is used in the proof of the security against Type-1 adversary.

G_E−U′: This game is almost as same as G_E−U where the update keys are ESF-2, the secret keys and decryption keys are normal, except the challenge ciphertext is chaged to ESF-1. This game is used in the proof of the security against Type-2 adversary.

G_ESF′: The update keys and secret keys are all changed to ESF-2. The challenge ciphertext is changed to ESF-1. The decryption keys are still normal.

G_SF″: All secret keys, update keys, and challenge ciphertext are changed to semi-functional. The decryption keys are still normal.

G_E−D: The decryption keys are changed to ESF-2. The other keys and the challenge ciphertext are still semi-functional.

G_ESF: The challenge ciphertext is changed to ESF-1. The update keys and secret keys are all still semi-functional. The decryption keys are still ESF-2.

G_SF′: The challenge ciphertext is changed to semi-functional. The decryption keys are changed to be semi-functional. That is, all secret keys, update keys, decryption keys, and challenge ciphertext are now semi-functional. This game is exactly like G_SF, except for a added restriction about the challenge key identity vector. We explain the restriction in Sec.4.6.

G_SF: The challenge ciphertext and all keys are semi-functional.

G_Final: The session key is changed to be random and so the adversary has no advantage to distinguish the challenge massage.

Let be the advantage of in the real game. From the all the lemmas in this section, we obtain the following equation

4.3 Definition of oracles

We introduce seven oracles which answer queries from the challenger by sampling various distributions of group elements from a composite order bilinear group. The outputs of Oracle O_i will allow a simulator to produce different type of secret keys, update keys and decryption keys, different type of ciphertext and challenge keys for one corresponding game demonstrated in Table 3.

All oracles are defined with respect to a bilinear group G of order p = p₁p₂p₃ and initially choose random elements g, u, v, w, u₀, v₀, w₀ ∈ G_p1, g₂ ∈ G_p2, g₃ ∈ G_p3 as well as random exponents ψ₁, ψ₂, σ₁, σ₂, a′, b′, s, δ₁, δ₂, γ ∈ Z_n. They provide the attacker with a description of the group G, as well as the group elements (2)

Every oracle is allowed to simulate the semi-functional ciphertexts, normal and semi-functional (H)IBE private keys according to the provided group elements in Eq 2. We define the oracles from O₀ to O₄ in which the simulators will be allowed to produce a normal challenge decryption key. The outputs of Oracle O₀ will allow a simulator to produce a semi-functional challenge ciphertext, a normal challenge (H)IBE private key. The outputs of Oracle O₁ will allow a simulator to produce a semi-functional challenge ciphertext, a type-2 ephemeral semi-functional (ESF-2) challenge HIBE private key and a normal challenge IBE private key. The outputs of Oracle O_1⁺ will allow a simulator to produce a semi-functional challenge ciphertext, an type-2 ephemeral semi-functional (ESF-2) challenge IBE private key an normal challenge HIBE private key. The outputs of Oracle O₃ will allow a simulator to produce a type-1 ephemeral semi-functional(ESF-1) ciphertext, and a type-2 ephemeral semi-functional(ESF-2) challenge (H)IBE private key. Finally, the outputs of Oracle O₄ will allow a simulator to produce a semi-functional challenge ciphertext, and a semi-functional challenge (H)IBE private key.

We define the oracles from O₅ to O₇ in which the simulators will be allowed to produce a semi-functional challenge (H)IBE key. The outputs of Oracle O₅ will allow a simulator to produce a semi-functional ciphertext, and an ephemeral semi-functional challenge decryption key. The outputs of Oracle O₆ will allow a simulator to produce an type-1 ephemeral semi-functional(ESF-1) ciphertext, and a type-2 ephemeral semi-functional(ESF-2) challenge decryption key. Finally, the outputs of Oracle O₇ will allow a simulator to produce a semi-functional ciphertext, and a semi-functional challenge decryption key.

Oracle O₀ The first oracle, which we will denote by O₀, responds to queries as follows. Upon receiving a challenge HIBE-key-type query for I ∈ Z_n, it chooses r, y′ ∈ Z_n randomly and returns the group elements (3) to the attacker. Upon receiving a challenge IBE-key-type query for T ∈ Z_n, it chooses r′, y″ ∈ Z_n randomly and returns the group elements (4) to the attacker. Upon receiving a challenge decryption-key-type query for I ∈ Z_n and T ∈ Z_n, it chooses r, y′, r′, y″ ∈ Z_n randomly and returns the group elements (5) to the attacker. Upon receiving a ciphertext-type query for I* ∈ Z_n, it chooses t ∈ Z_n randomly and returns the group elements (6) to the attacker. Upon receiving a ciphertext-type query for T* ∈ Z_n, it chooses t₀ ∈ Z_n randomly and returns the group elements (7) to the attacker.

Oracle O₁ The next oracle, which we will denote by O₁, responds to queries as follows. Upon receiving a challenge HIBE-key-type query for I ∈ Z_n, it chooses r″, y‴ ∈ Z_n randomly, and also chooses X₂, Y₂ ∈ G_p2, X₃, Y₃ ∈ G_p3 randomly. It returns the group elements (8) to the attacker. It responds to a ciphertext-type query, a challenge IBE-key-type query and a challenge decryption-key-type query in the same way as O₀.

Oracle O_1⁺ The oracle O_1⁺ responds to queries as follows. Upon receiving a challenge IBE-key-type query for T ∈ Z_n, it chooses r″, y‴ ∈ Z_n randomly, and also chooses X₂, Y₂ ∈ G_p2, X₃, Y₃ ∈ G_p3 randomly. It returns the group elements (9) to the attacker. It responds to a ciphertext-type query, a challenge HIBE-key-type query and a challenge decryption-key-type query in the same way as O₀.

Oracle O₂ The next oracle, which we will denote by O₂, responds to queries as follows. Upon receiving a challenge HIBE-key-type query and a challenge IBE-key-type query, it responds in the same way as O₁. Upon receiving a ciphertext-type query for I* ∈ Z_n, it chooses t ∈ Z_n randomly and returns the group elements (10) to the attacker. Upon receiving a ciphertext-type query for T* ∈ Z_n, it chooses t₀ ∈ Z_n randomly and returns the group elements (11) to the attacker. It responds to a challenge decryption-key-type query in the same way as O₀.

Oracle O_2⁺ The next oracle, which we will denote by O_2⁺, responds to queries as follows. Upon receiving a challenge HIBE-key-type query and a challenge IBE-key-type query, it responds in the same way as O_1⁺. Upon receiving a ciphertext-type query for I* ∈ Z_n, it chooses t ∈ Z_n randomly and returns the group elements (12) to the attacker. Upon receiving a ciphertext-type query for T* ∈ Z_n, it chooses t₀ ∈ Z_n randomly and returns the group elements (13) to the attacker. It responds to a challenge decryption-key-type query in the same way as O₀.

Oracle O₃ The next oracle, which we will denote by O₃, responds to queries as follows. Upon receiving a challenge HIBE-key-type query and a ciphertext-type query, it responds in the same way as O₂. Upon receiving a challenge IBE-key-type query for I ∈ Z_n, it chooses r″, y‴ ∈ Z_n randomly, and also chooses X₂, Y₂ ∈ G_p2, X₃, Y₃ ∈ G_p3 randomly. It returns the group elements (14) to the attacker. It responds to a challenge decryption-key-type query in the same way as O₀.

Oracle O₄ The next oracle, which we will denote by O₄, responds to ciphertext-type queries in the same way as O₀, and responds to a challenge HIBE-key-type query for I ∈ Z_n, by choosing r, y′ ∈ Z_n randomly and returns the group elements (15) to the attacker. Upon receiving a challenge IBE-key-type query for T ∈ Z_n, it chooses r′, y″ ∈ Z_n randomly and returns the group elements (16) to the attacker. It responds to a challenge decryption-key-type query in the same way as O₀.

Oracle O₅ The next oracle, which we will denote by O₅, responds to queries as follows. Upon receiving a challenge decryption-key-type query for I, T ∈ Z_n, it chooses r, y′, r′, y″ ∈ Z_n randomly, and also chooses randomly. It returns the group elements (17) to the attacker. It responds to a ciphertext-type query and a challenge (H)IBE-key-type query in the same way as O₄.

Oracle O₆ The next oracle, which we will denote by O₆, responds to queries as follows. Upon receiving a ciphertext-type query for I* ∈ Z_n, it chooses t ∈ Z_n randomly and returns the group elements (18) to the attacker. Upon receiving a ciphertext-type query for T* ∈ Z_n, it chooses t₀ ∈ Z_n randomly and returns the group elements (19) to the attacker. It responds to a decryption-type query and a challenge (H)IBE-key-type query in the same way as O₅.

Oracle O₇ The last oracle, which we will denote by O₇, responds to ciphertext-type queries in the same way as O₀, and responds to a challenge decryption-key-type query for I, T ∈ Z_n, by choosing r, y′, r′, y″ ∈ Z_n randomly and returns the group elements to the attacker. It responds to a challenge (H)IBE-key-type query in the same way as O₆.

We define the advantage of an attacker in distinguishing between O_i and O_j to be . Here, we assume that interacts with either O_i or O_j, and then outputs a bit 0 or 1 encoding its guess of which oracle it interacted with.

4.4 Indistinguishability of G_C′ and G_SF″

4.4.1 Strategy for the indistinguishability of G_C′ and G_SF″.

For the proof of the indistinguishability of G_C′ and G_SF′, we cannot use the simple nested dual system in U-HIBE [11] that change a normal private key(or normal update key) to an ephemeral semi-fuctional private key(or semi-functional update key) one by one since the adversary of RHIBE can query a private key for ID|_k ∈ Prefix(ID*|_l) and an update key for T*.

To solve this problem, we firstly use a modular design strategy like [13] and construct the private keys and update keys from smaller component keys. A secret key SK_ID|k consists of many HIBE private keys which are represented as {SK_HIBE,Sθ}_Sθ∈Path and an update key UK_ID|k−1,T,R consists a randomized decryption key RSK_HIBE and many IBE private keys {SK_IBE,Si}_Si∈CVR where each HIBE private key (or an IBE private key) is associated with a node S_j in BT_ID|k−1. The HIBE and IBE private keys can be grouped together if they are related to the same node S_j in BT_ID|k−1 and a correct decryption key is constructed form the grouped (H)IBE private key.

To uniquely identify a node S_j ∈ BT_ID|k−1, we define a node identifier NID of this node as a string ID|_k−1||L_j where L_j = Label(v_j). To prove the indistinguishability of G_C′ and G_SF″, we change normal HIBE private keys and normal IBE private keys that are related to the same node identifier NID into (ephemeral) semi-functional keys by defining additional hybrid games. This additional hybrid games are performed for all node identifiers that are used in the key queries of the adversary.

Secondly, we give the equivalent model in which the challenger answers the secret(update, and decryption) key queries of the adversery by requesting the associated (H)IBE private keys from an oracle simulator , shown in Fig 1. When the adversary queries for the secret key, update key or decryption key for some identity and some time period, B constructs the key by the (H)IBE-challenge-key or decryption-challenge-key it queries from the oracle simulator . adaptively answers the corresponding group elements which it constructs by using the public paremeters given by some complexity assumption. Therefore, under the complexity assumptions, the oracle O_i that chooses to answer is indistinguishable and consequently the adversary cannot distinguish whether is playing the real RHIBE game or other variation games based on all the answers recieves after the adaptive queries to .

Download:

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

Fig 1. The query process in the proof of the indistinguishability of G_C′ and G_SF′.

*The group elements that the oracle simulator gives to the challenger are not only the public parameters PP_HIBE and PP_IBE, but also the group elements for constructing the (ephemeral) semi-functional keys and ciphertexts and the public elements given by the assumptions.

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

For additional hybrid games that change HIBE private keys (or IBE private keys) that are related to the same node identifier NID = ID|_k−1||L_j from normal keys to semi-functional keys, we need to define an index pair (i_n, i_c) for an HIBE private key (or an IBE private key) that is related to the node v_j ∈ BT_ID|k−1 where i_n is a node index and i_c is a counter index. Suppose that an HIBE private key (or an IBE private key) is related to a node NID. The node index i_n for the HIBE private key (or the IBE private key) is assigned as follows: If the node v_j ∈ BT_ID|k−1 with a node identifier NID appears first time in key queries, then we set in as the number of distinct node identifiers in previous key queries plus one. If the node identifier NID already appeared before in key queries, then we set i_n as the value of previous HIBE private key (or IBE private key) with the same node identifier. The counter index i_c of an HIBE private key is assigned as follows: If the node identifier NID appears first time in HIBE private key queries, then we set i_c as one. If the node identifier NID appeared before in HIBE private key queries, then we set i_c as the number of HIBE private keys with the same node identifier that appeared before plus one. Similarly, we assigns the counter index i_c of an IBE private key.

Thirdly, we divide the behavior of an adversary as two types: Type-1 and Type-2. We next show that the semi-functional key invariance property holds for two types of the adversary. Let be the challenge hierarchical identity and T* be the challenge time. For a challenge node v with the node index h in the hybrid games from Game_C and Game_SF, the adversary types are formally defined as follows:

1. Type-1: An adversary is Type-1 if it queries on a hierarchical identity for all HIBE private keys with the node index h, and it queries on time T = T* for at least one IBE private key with the node index h.
2. Type-2: An adversary is Type-2 if it queries on time T ∉ T* for all IBE private keys with the node index h. Note that it may query on a hierarchical identity ID|_k ∈ Prefix(ID*|_l) for at least one HIBE private key with h, or it may query on a hierarchical identity for all HIBE private keys with h.

We prove our dual system encryption RHIBE scheme via a hybrid argument over the sequence of games in Table 3. For the different type of adversary, the squence of games is basicly the same except that:

1. For the Type-1 adversary, we prove the indistinguishability of G_C′ and G_ESF′ by the transition from G_C′ to G_EK−S, and to G_ESF′ without the attacker’s advantage changing by a non-negligible amount.
2. For the Type-2 adversary, we prove the indistinguishability of G_C′ and G_ESF′ by the transition from G_C′ to G_EK−U, and to G_ESF′ without the attacker’s advantage changing by a non-negligible amount.

Theorem 2 Under Assumptions 3 and 4, our dual system encryption RHIBE scheme has the equation (20)

We will prove these indistinguishabilities between games G_C′, G_E−S (or G_E−U), G_E−S′ (or G_E−U′), G_ESF′, and G_SF″ by going through several intermediary oracles. The main properties of our oracles are summarized in Tables 4 and 5 for the Type-1 adversary and Table 6 for the Type-2 adversary respectively. We intend these tables to be used only as a quick reference guide, not as a definition. We give a complete proof for the Type-1 adversary, and a brief explanation of the proof for the Type-2 adversary is demonstrated then.

Download:

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

Table 4. Simulation of challenge keys and cipertext in oracles for the proof of the indistinguishability between G_C′ and G_SF″ under Type-1 adversary.

https://doi.org/10.1371/journal.pone.0195204.t004

Download:

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

Table 5. Defination of games between G_ESF′ and G_SF″.

https://doi.org/10.1371/journal.pone.0195204.t005

Download:

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

Table 6. Simulation of challenge keys and cipertext in oracles under Type-2 adversary for the proof of the indistinguishability between G_C′ and G_SF″.

https://doi.org/10.1371/journal.pone.0195204.t006

4.5 Indistinguishability of G_SF″ and G_SF′

In the game G_SF″, the type of ciphertexts, secret keys and update keys are all semi-functional, except the decryption keys are normal. In this section, we give the proof of the indistinguishability of G_SF″ and G_SF′ via a hybrid argument over the sequence of games G_SF″, G_E−D, G_ESF and G_SF′ to transform the type of decryption keys from normal to ephemeral semi-functional, and then to semi-functional.

The hybrid argument we conduct for the indistinguishability of G_SF″ and G_SF′ is following the process similar to the argument for the indistinguishability of G_C′ and G_SF″. But it is simpler since the transformation of challenge type only happens to the decryption keys and the challenge ciphertexts. So we just treat the decryption keys as a secret key of the identity (T, id₁, ⋯, id_j) and follow the proof strategy in the nested dual system encryption of the unbounded HIBE [12].

We show the oracles for proving the the indistinguishability of G_SF″ and G_SF′ in Table 7 which answer queries from the challenger by sampling various distributions of group elements to construct the decryption keys, challenge ciphertexts and also the secret keys and update keys.

Download:

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

Table 7. Simulation of challenge keys and cipertext in oracles for the proof of the indistinguishability between G_SF″ and G_SF′.

https://doi.org/10.1371/journal.pone.0195204.t007

Since these oracles initially provide the attacker with a description of the group G, as well as the group elements

So the simulation of semi-functional secret keys and update keys are achievable in all oracles and games.

(1) Indistinguishability of G_SF″ and G_E−D

For the security proof of the indistinguishability of G_SF″ and G_E−D, we define a sequence of additional hybrid games J_1,1, J_1,2, ⋯, J_hd,1, J_hd,2, …, J_qd,1, J_qd,2 where J_0,2 = G_SF″ and J_qd,2 = G_E−D, and q_d is the number of decryption key queries of an adversary. The games and a additional oracle O_9/2 used in the proof are formally defined as follows:

Oracle O_9/2 This oracle initializes in the same way as O₄, O₅ and provides the attacker with initial group elements from the same distribution. Upon receiving a challenge decryption-key-type query for I, T ∈ Z_n, it chooses r, y′, r′, y″ ∈ Z_n randomly, and also chooses randomly. It returns the group elements (55) to the attacker. It responds to a ciphertext-type query and a challenge (H)IBE-key-type query in the same way as O₄.

Game J_hd,1 This game J_hd,1 for 1 ≤ h_d ≤ q_d is almost the same as G_EF″ except the generation of the decryption keys DK_ID|k,T.

1. i_d < h_d: It generates a normal and converts the key to a ESF-2 DK_ID|k,T by using the element groups in Eq 17.
2. i_d = h_d: It generates a normal and converts the key to a ESF-1 DK_ID|k,T by using the element groups in Eq 55.
3. i_d > h_d: It simply generates a normal decryption key.

Game J_hd,2 This game J_hd,1 for 1 ≤ h_d ≤ q_d is almost the same as J_hd,1 except the generation of the decryption key is generated as a ESF-2 DK_{ID|k, T} by using the element groups in Eq 17. The first h_d decryption keys are generated as ESF-2 and the remaining decryption keys are generated as normal.

Lemma 21 Under Assumptions 3, no PPT attacker can distinguish between O₄ and O_9/2 with non-negligible advantage. So no PPT attacker can distinguish between J_hd−1,2 and J_hd,1 with non-negligible advantage.

Lemma 22 Under Assumptions 4, no PPT attacker can distinguish between O_9/2 and O₅ with non-negligible advantage. So no PPT attacker can distinguish between J_hd,1 and J_hd,2 with non-negligible advantage.

From the Lemma 21, 22, we obtain the following equation (56)

(2) Indistinguishability of G_E−D and G_ESF

We now prove the indistinguishability of G_E−D and G_ESF in a hybrid argument using polynomially many steps. We let q_c denote the number of ciphertext-type queries made by a PPT attacker . Firstly we define hybrid games L_−1,1, L_0,2, L_0,3, L_0,1, L_1,2, L_1,3, L_1,1⋯, L_k,2, L_k,3, L_k,1, …, L_qc−1,2, L_qc−1,3, L_qc−1,1, where L_−1,1 = G_E−D and L_qc−1,1 = G_ESF. The games are formally defined as follows:

Game L_k,1 This game L_k,1 for 0 ≤ k ≤ q_c is almost the same as G_E−D except the generation of the challenge ciphertext. The challenge ciphertext of is generated as EST-2^k-CT outputed by EncryptESF-2^k.

Game L_k,2 This game L_k,2 for 0 ≤ k ≤ q_c − 1 is almost the same as G_E−D except the generation of the challenge ciphertext. The challenge ciphertext of is generated as EST-3^k-CT outputed by EncryptESF-3^k.

Game L_k,3 This game L_k,3 for 0 ≤ k ≤ q_c − 1 is almost the same as G_E−D except the generation of the challenge ciphertext. The challenge ciphertext of is generated as EST-4^k-CT outputed by EncryptESF-4^k.

We will define additional oracles for each i from 0 to q_c − 1, for each i from 0 to q_c − 1, and for each i from 0 to q_c − 1.

Oracle This oracle initializes in the same way as O₅, O₆ and provides the attacker with initial group elements from the same distribution. It also responds to challenge key-type queries in the same way as O₅, O₆. It keeps a counter of ciphertext-type queries which is initially equal to zero. It increments this counter after each response to a ciphertext-type query. In response to the j^th ciphertext-type query for some , if j ≤ i, it responds exactly like O₆. If j > i, it responds exactly like O₅. In particular, is identical to O₅ and is identical to O₆.

Oracle This oracle acts the same as except in its response to the i^th ciphertext-type query. For the i^th ciphertext-type query for identity I*, it chooses a random t ∈ Z_N and random elements X₃, Y₃ ∈ G_p3 and responds with: (57) If i = 0, the i^th ciphertext-type query is for time T*. It chooses a random t₀ ∈ Z_N and random elements and responds with: (58)

Oracle This oracle acts the same as except in its response to the ith ciphertext-type query. For the i^th ciphertext-type query for identity I*, it chooses a random t ∈ Z_N and random elements X₃, Y₃ ∈ G_p3 and responds with: (59) If i = 0, the i^th ciphertext-type query is for time T*. It chooses a random t₀ ∈ Z_N and random elements and responds with: (60)

Lemma 23 Under Assumptions 3, no PPT attacker can distinguish between and with non-negligible advantage. So no PPT attacker can distinguish between L_k−1,1 and L_k,2 with non-negligible advantage.

Lemma 24 Under Assumptions 4, no PPT attacker can distinguish between and with non-negligible advantage. So no PPT attacker can distinguish between L_k,2 and L_k,3 with non-negligible advantage.

Lemma 25 Under Assumptions 3, no PPT attacker can distinguish between and with non-negligible advantage. So no PPT attacker can distinguish between L_k,3 and L_k,1 with non-negligible advantage.

From the Lemma 23, 24, 25, we obtain the following equation (61)

(3) Indistinguishability of G_ESF and G_SF′

For the security proof of the indistinguishability of G_ESF and G_SF′, we define a sequence of games G_ESF−1, G_ESF−2, G_ESF−3 to change the type of decryption keys from ESF-2 to ESF-4 and the type of ciphertexts from ESF-1 to ESF-5 and G_ESF−4, G_ESF−5, G_ESF−6 to change the type of decryption keys to semi-functional and the type of ciphertexts back to semi-functional. In Table 8, we give the types of key in the queries and the challenge cipertext in every game, and the decryption situation according to the types of keys and ciphertexts.

Download:

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

Table 8. Defination of games between G_ESF and G_SF′.

https://doi.org/10.1371/journal.pone.0195204.t008

G_ESF−1: The decryption keys are changed to ESF-3. The challenge ciphertext is still ESF-1. The secret keys and update keys are still semi-functional.

G_ESF−2: The challenge ciphertext is changed to ESF-5. The secret keys and the update keys are still semi-functional. The decryption keys are still ESF-3.

G_ESF−3: The decryption keys are changed to ESF-4. The challenge ciphertext is ESF-5. The secret keys and update keys are still semi-functional.

G_ESF−4: The challenge ciphertext is changed to ESF-1. The secret keys and the update keys are semi-functional. The decryption keys are still ESF-4.

G_ESF−5: The challenge ciphertext is changed to semi-functional. The secret keys and the update keys are semi-functional. The decryption keys are still ESF-4.

We firstly prove the indistinguishabilities between G_ESF to G_ESF−1, G_ESF−1 to G_ESF−5. And then we prove the indistinguishability of G_ESF−5 and G_SF′.

Indistinguishability of G_ESF and G_ESF−1. For the security proof of the indistinguishability of G_ESF and G_ESF−1, we define games G_F,1, ⋯, G_F,hd, …, G_F,qd where G_F,0 = G_ESF and G_F,qd = G_ESF−1, and q_d is the number of decryption key queries of an adversary. In the game G_F,h for 1 ≤ h ≤ q_d, the challenge ciphertext is ESF-1, all (H)IBE private keys are semi-functional, the i^st queried decryption key where i ≤ h are of ESF-3, the remaining decryption keys with i > h are ESF-2.

Oracle O_6.1 This oracle initializes in the same way as O₆ and provides the attacker with initial group elements from the same distribution. Upon receiving a challenge decryption-key-type query for I, T ∈ Z_n, it chooses r, y′, r′, y″ ∈ Z_n randomly, and also chooses and randomly. It returns the group elements (62) to the attacker. It responds to a ciphertext-type query or a challenge (H)IBE-key-type query in the same way as O₆.

Lemma 26 Under Assumptions 3, no PPT attacker can distinguish between O₆ and O_6.1 with non-negligible advantage. So no PPT attacker can distinguish between G_F,hd−1 and G_F,hd with non-negligible advantage.

Let be the advantage of in a game G_F′,h. From the Lemma 27, we obtain the following equation (63)

Indistinguishability of G_ESF−1 and G_ESF−2. For the security proof of the indistinguishability of G_ESF−1 and G_ESF−2, we define the oracle below.

Oracle O_6.2 This oracle initializes a bit differently from the other oracles. It fixes random elements g, u, h, v, w, u₀, h₀, v₀, w₀ ∈ G_p1, g₂ ∈ G_p2, g₃ ∈ G_p3. It chooses random exponents . It initially provides the attacker with the group elements: (64) What differs from the previous oracles here is the added and term: notice that this is uniformly random in G_p3, since γ is random modulo p₃ (and uncorrelated from its value modulo p₂). This oracle answers the challenge-key type query in the same way as O_6.1. To answer a ciphertext-type query for I, it chooses random values t ∈ Z_N and responds with: (65) To answer a ciphertext-type query for T, it chooses random values t ∈ Z_N and responds with: (66) It is crucial to note that these G_p3 terms arethe same for each ciphertext-type query response.

Lemma 27 Under Assumptions 4, no PPT attacker can distinguish between O_6.1 and O_6.2 with non-negligible advantage. So no PPT attacker can distinguish between G_ESF−1 and G_ESF−2 with non-negligible advantage.

From the Lemma 27, we obtain the following equation (67)

Indistinguishability of G_ESF−2 and G_ESF−3: For the security proof of the indistinguishability of G_ESF−2 and G_ESF−3, we define a sequence of games additional hybrid games G_F−2,1, …, G_F−2,h, …, G_F−2,qd, where G_ESF−2 = G_F−2,0 and q_d is the number of decryption key queries of an adversary. In the game G_F−2,h for 1 ≤ h ≤ q_d, the challenge ciphertext is ESF-5, all (H)IBE private keys are semi-functional, the i^st queried decryption key where i ≤ h are of ESF-4, the remaining decryption keys with i > h are ESF-3.