 Welcome to the presentation of a paper Unbounded Hierarchical Identity-Based Encryption with Tide Security. My name is Roman Lager and this is joint work with Chashin Pan. In the beginning of the talk I will briefly explain what unbounded HIP is and what Tide Security means. Then I will talk about related works, give a technical overview of our construction and finally some ideas for future work. Suppose Alice wants to send a message to Bob and use identity-based encryption to encrypt it. Then she needs a master public key that is issued by some trusted third party and an identity of Bob to encrypt the message. An identity can be any string that uniquely identifies a recipient, so for example an email address. And to decrypt, Bob proves to the trusted third party that he is the legitimate owner of his identity and then the trusted third party will give him a user-secret key for his identity and with this user-secret key he will be able to decrypt messages that were encrypted for his identity but not other messages. In hierarchical identity-based encryption we don't have a single authority that generates all the user-secret keys but the hierarchy of key generators. More precisely, identities are tuples and everybody can generate a user-secret key for someone else if his identity is a prefix of the other guy's identity. So for example, the user here can generate the user-secret keys for these guys down here but not for the ones over here. Now usually when you talk about H-I-B-E you actually mean bounded H-I-B-E, that is the hierarchy depth is fixed in advance. This is usually necessary because the master public key grows with L, so with the hierarchy depth or the user-secret keys have some delegation terms and these delegation terms grow with a number of remaining levels. Unmonet H-I-B-E however has no limit on the hierarchy depth. This is of course better because it's more flexible, you don't have to fix the hierarchy depth in advance and it's also better scalability because you only need to pay for the levels that you actually need. Here's the security game for H-I-B-E schemes, so in the beginning the adversary gets the master public key and then he gets access to two oracles. The first one is to corrupt the user, so there he sends an identity and gets back the user-secret key for this identity. The other oracle, he sends a challenge identity and two messages and gets an encryption of one of these messages under this challenge identity and which message depends on a bit that the challenger chooses in the beginning and the adversary wins this game if he can guess correctly the bit that the challenger chooses. Of course, the adversary is not allowed to ask a user-secret key for the challenge identity or any prefix of a challenge identity because then he can just decrypt the challenge ciphertext and trivially win this game. Now with CCA security, that is basically the same just that the adversary has access to a third oracle that can decrypt ciphertexts for him except the challenge ciphertext. It's easy to achieve once you have CPA security because there's a generic transformation for H-I-B-E schemes from CPA secure ones to CCA secure ones. And finally, we will also achieve key-dependent message security so that these messages can depend on the master-secret key because Gwark, Gaye and Hachi Badi presented at PK thesis year of work that showed how to achieve this for I-B-E schemes and it can also be applied to our unbounded H-I-B-E scheme. Now what does tide security mean? We usually don't prove that our constructions are secured directly but instead we give a reduction to some underlying assumption. And this reduction guarantees us that when the scheme can be broken with probability epsilon using some resources row the underlying assumption can be broken for a fair comparison let's say with approximately the same resources row with some probability epsilon divided by L and this L is called the security loss. Now as long as L is polynomial the scheme is considered to be secure but the larger L gets the larger you have to choose your security parameter for some specific level of security so you want this L to be as small as possible. The security loss can depend on all kinds of things for example the security parameter or the attackers resources so for example the number of user-secret key queries issues but for tide security we allow it only to depend on things that the adversary cannot control so not on the attackers resources. So in particular in our setting it may not depend on the number of users he corrupts not on the number of challenge cipher texts he receives and not on the actual hierarchy depth that is the maximum length of any identity that the adversary chooses because well an unbounded HIV the adversary can choose the hierarchy depth as large as he wants as well. Here's a brief history of unbounded HIV scheme. First construction was given by Luca and Waters in 2011 and composite order pairing groups and later generalized or modified by Luca to prime order pairing groups and Gong et al. later gave an improvement of the scheme that basically introduced the trade of between master public key size on the one hand and user-secret key and cipher text size on the other hand. Also Okamoto and Takashima gave a construction of unbounded HIV but they only achieve a weakly unbounded HIV namely they have a master public key that is independent of the hierarchy depth but the user-secret keys are not independent. That's basically because they have delegation terms. In our work we give a construction of unbounded IBE also in prime order pairing groups that is tied to secure. That is our security loss depends only on the output bit lengths of a collision resistant hash function in the multi-challenge setting and a security game that I presented before. The other constructions only have a security loss that grows with a number of user-secret key queries and the actual hierarchy depth, so LSE of course also something that the adversary chooses and they are also only in the single-challenge setting so only one challenge query is allowed. The single-challenge setting is equivalent to the multi-challenge setting but this transformation is not tied. So when you are interested in tied security it's better to look at the multi-challenge setting directly. Now to tied IV schemes. For IV schemes there are a lot of constructions that are known that are tightly secure. The first one was by Chen and we in 2013 in the single-challenge setting and later also some constructions in the multi-challenge setting followed. Now tied HIV schemes or the first tied construction of unbounded HIV scheme was given by Jatine Pan and me at PKC last year in the single-challenge setting and at PKC this year we gave a construction in the multi-challenge setting. Now let's forget to move from our bounded HIV schemes that are tightly secure to an unbounded HIV scheme. Well, here's one of the construction that we achieved that we presented at PKC this year and as you can see the master public key grows with a number of levels and also the security loss. So for bounded HIV this is okay because this L is not under the adversary's control but in the unbounded setting it suddenly is because now it's the maximum length of an identity that the adversary uses. So we need to get rid of this factor L and the security loss and the master public key. But luckily we can focus on getting rid of it in the master public key then it will basically automatically disappear also in the security loss. Here's the high level approach of our construction. So our starting point is a tight IBE scheme and the bounded HIV scheme is in some sense constructed by using a different instance of this IBE scheme for each level, of course there in some way and some sense connected together. And for our unbounded HIV scheme our high level approach will be to use the same instance of the IBE schemes for all the levels. Here's the basic structure of the IBE scheme that we use. So the user secret key consists of master secret key but this master secret key is blinded by some blinding term that depends on the identity and the spying term is also randomized. Now a cipher text looks as follows and has a dual blinding term for the identity also the dual blinding terms are randomized and the cipher text or you can think of this as the payload. Now this payload is encrypted with the same randomness as the blinding term and a property of these blinding terms and dual blinding terms is that the dual blinding term multiplied with a normal blinding term cancels out if the identity is matched. If not you will get some random output. So for the encryption you use this dual blinding term multiplied with the user secret key and what remains is basically the product of this randomness age with the master secret key and this is sufficient to decrypt the cipher text here because it has the same randomness. Okay, now more to these blinding terms. As I just explained they have the following property that the blinding term multiplied with the dual blinding term this multiplication is carried out with a pairing. They cancels out so they yield zero. Another property that is important for the security proof is that this blinding term is pseudo random so it will basically hide the master secret key in the previous example. But of course it's only pseudo random if you don't know a dual blinding term for the same value x because then you could use the first property to distinguish a real blinding term from a random value. Furthermore these blinding terms are publicly sampled but unfortunately that dual blinding terms are not publicly sampled. Well they can't be publicly sampled because then again you could generate one for a value x here and this could not pseudo random. So you might wonder how you could generate the ciphertext then in the previous example. Well actually you need these blinding terms only for a semi-functional ciphertext and the normal ciphertext that you normally use they will cancel out these blinding terms no matter whether it's an honest one or just a random value. But the semi-functional one that are ciphertexts that we use in the security proof they need this dual blinding term. And the first contribution of our paper is to give a tight realisation of these blinding terms. This is basically an abstraction of our PKC work. Now here's how you can use these blinding terms to get bounded HIV. So basically what we did in our PKC work. Namely you use L different instances and now for all the levels and the user secret key is now a sum of these blinding terms and namely for every level you sum up a blinding term that depends on the first i components of the identity. And finally add the master secret key. Now you might wonder why the first i components and not only the last one, only the i's one. Well that is necessary because only on the last level we will get the security guarantee that this is pseudo random because for all the other levels the adversary is actually allowed to query a challenge ciphertext so he can learn a dual blinding term for all the other levels except the last one. So we need on the last level all the information about the identity to ensure that this is pseudo random. Now delegation is here quite simple because these blinding terms are publicly sampled so you can delegate use secret key by just sampling a new blinding term for the next level and add it to your use secret key. Ciphertext now look as follows you have all these dual blinding terms they all use the same randomness h and also the payload is again encrypted with this randomness h and then you can use these dual blinding terms to cancel out all of these blinding terms you have here and again you will end up with a product of h and a master secret key and this can be used to decrypt this ciphertext over here. Now for unbounded h IBE the problem here is that now the master public key has size n times l squared well n times l because the size of the blinding terms or the terms that you need to publicly sample them grow with a bit lengths of the input so in this case this is up to n times l and the other factor factor of l comes from the fact that we use a different blinding term for each level or different instance of these blinding terms. Now the first improvement is simple namely we take a collision resistant hash function and use it to hash these prefixes of the identity here and here and this idea was already presented in our pkc work and this way we get this master public key size of gamma times l where gamma is the output bit lengths of the hash function. Now to get rid of this second factor of l is quite tricky. What we basically do is we use the same blinding terms for all the levels so we move this level i here it's the same one for all the levels but this causes some problems in the security proof and on a high level what the problem is is that we need to do different things with these blinding terms in the ciphertext because they are different blinding terms for different values before this was not a problem because these were completely independent blinding terms but now they have the same blinding terms and to deal with this problem the solution is basically to use a different randomness for each level so instead of this h that's the same for all levels we use a different randomness for each level but this causes more problems for example or basically you cannot sum up here any more of these blinding terms so here's the final structure of our unbounded HIV scheme and on a high level this is simple similar to what also Luca and Waters did so we have the blinding terms as before but this time they are not summed up instead we have them separately for each level and they don't hide the master secret key but instead we have here some additional in direction layer so to say namely they hide each of them hides a blinding term for some fixed value let's say 1 this blinding term has a different randomness and then we use another blinding terms for some fixed value let's say 2 that use the same randomness and they are summed up of all the levels and they hide the master secret key then now the ciphertext Luca's follows they have all these dual blinding terms for individual randomness on each level and also a dual blinding term for 1 that use the same randomness as for blinding terms here and this is added to a dual blinding term for 2 and these dual blinding terms for 2 they use now the same randomness for all the levels and this randomness is then also used to encrypt the payload now how does decryption work? well first of all you multiply these dual blinding terms with the values you have up here so that is stuff that depends on the identity cancels out what will remain is basically the product of this hi with these blinding terms for 1 the next thing you do is you take the values down here and multiply them with a first value here so then these blinding terms for 2 and the dual one will cancel out and what will remain is what you want namely the product of this hq term with the master secret key but also the dual blinding terms for 1 and basically the dual blinding terms for 1 get multiplied with the randomness ti q that we have here but these values are exactly the same that also remained in this multiplication before so we just need to subtract the result that you had before from the result here and then you get the value you want now to the security proof well at least on the last level these blinding terms are pseudo random so they basically hide the blinding term for 1 we don't need to care about the other levels than the last one because there we basically can use a normal way to generate the use secret key not the semi-functional one okay so this basically hides the blinding term for 1 and this means that we have some entropy in here because this is now the only place where the dual blinding terms for 1 are used we can now move this entropy to the dual blinding term for 2 to hide so to say these dual blinding terms well then the blinding terms for 2 appear at least on the last level gets random so the entropy moves up here and there the entropy finally hides the master secret key so that's the high level idea of the security proof now here's a comparison of our unwanted HIV to previous constructions so we have a very similar assumption but this time with a tight security reduction in the multi-channel setting the use secret key and ciphertext size is very similar to the previous construction namely it grows linear with the length of the identity but the price you have to pay for this tight security reduction is a larger master public key namely the non tight schemes had constant size master public key ours has a master public key that grows with a bit length output bit length of a collision resistant hash function basically with a security parameter but besides this tight security reduction our scheme is also the first one that achieves key dependent message security together with this work by Garg et al from PKC this year because they basically gave a construction that uses tight multi-channel secure IBE schemes to get master key KDM secure IBE schemes and the same idea can be applied to our scheme so it gives the first unbounded HIV scheme with master key KDM security okay finally here are two ideas for future work the first one is whether this inject and pack strategy that we use so inject means this blinding terms that inject randomness into a use secret keys and pack this mechanism of moving this randomness around until it finally hides a master secret key whether the strategy is helpful in a more general setting so like for example for general predicate encryption schemes and the second one is whether we can have unbounded HIV scheme with constant size to the secret key and ciphertext nice because as you've just seen all the constructions now suffer from use secret key and ciphertext size that grow with a bit or with a length of the identities this is basically the only thing that prevents you from using the HIV for very large hierarchies thanks for your attention