 The next delegation for attribute based encryption by Amit Sahai, I can say Leoglu and Brent Waters and Amit is going to begin at the top. All right, thank you very much. So I'll be talking about dynamic credentials for attribute based encryption. This is joint work with Akhan and Brent. And thankfully Allison gave this beautiful talk to for me so I don't need to give too much background but let me just remind you. In fact our work refers to both key policy and ciphertext policy ABE but I'll focus on CP ABE, ciphertext policy ABE. So what's the situation? We have users in the system and the users have credentials. They have certain attributes that describe them. For example, Bob here has top secret and forensics, let's say, as his attributes. And now someone, and we provide him with a personalized secret key that somehow encapsulates the exact attribute set that he has and that's given to the user. Now a user, another, some external party potentially comes along and wants to encrypt a message but he wants to specify a policy that describes when and who should be able to, well sorry, who should be able to encrypt a message and let's say he does it by means of an and or a tree such as here. And now of course if Bob comes along he will be able to decrypt it because the exact set of attributes do match this tree and everything will work out. So that's why he should be able to decrypt. That's the basic setup Allison already talked about, the notions of security here. So what this talk deals with is the setting of attribute based encryption but where users credentials change over time. And really this is something that is unavoidable in real life. People are hired, fired, transferred, these kind of events happen all the time and we will need in any real system we would of course need to be able to support dynamic keys, dynamic credentials. So how will we deal with this? That's what this talk is about and we're going to deal with it in the usual way. Our community has dealt with dynamic keys for many, many years and the way we think about it typically is that if a user's credential changes then what we'll do is we'll revoke his old key and then issue him a new one. So really the problem is reduced to the problem of revocation and revocation has a long history. So we'll use some of the usual frameworks, the usual framework that our community has developed to deal with dynamic keys. So we'll imagine that there is a periodic broadcast that are issued by the key authority and we want these broadcasts to be efficient. We want them to essentially only depend on the number of users who are getting their keys revoked, not on the total number of users in the system. That's some basic efficiency property we would want. And what's the purpose of this broadcast? The purpose is so that unrevoked keys, so people whose keys are still valid should be able to look at their old key, look at the public broadcast, put them together to form a newly valid key for the current time period. So they can update their key to make it still valid today. And of course the people who are revoked can't do this and so they won't be able to update their keys. And so they'll end up being revoked. And now the other difference this engenders in the system is that when you encrypt a message you don't just specify a policy, you also specify the current time, the time at which you encrypt the message and only someone who satisfies the policy and has a key that is valid for a time greater than or equal to t should be able to decrypt. These are kind of the standard ideas in revocation that we want to bring to bear to the ABE setting. Now the question that really pushes this talk forward is so I've talked about all the stuff that we've done before as a community, does that actually capture the security concerns we would have in the ABE setting? And in fact the main point of this talk is that we think the answer is not quite. So there are some additional security concerns that we have to deal with in the ABE setting which I'm going to spend most of this talk on. And the reason for this is the following, that when we've looked at revocation in the past in this community typically we've either been looking at a per-party communication setting where the message is going to a single party, or a broadcast setting. And in each of these settings you can only worry about the future, right? Because the messages that I've already sent were already broadcast. You already have them if you had a valid key. So there's no sense of protecting the past, it just doesn't make sense. So we don't think about that problem. But as I'll argue in the ABE setting in sort of the prototypical examples of applications of ABE, this issue of protecting the past is actually important. So we'll illustrate this with a motivating example that I'll give in a moment. I want to mention this was inspired by a wonderful conversation with Thomas King and Daniel Manchalla over at Xerox in Los Angeles and we definitely thank them for inspiring this work. So what's the motivation? We have a company. It has a server setup that's going to use ABE for access control. So the server will only host encrypted files, right, ciphertexts that are encrypted using ABE. And we have users that are going to access it. Now, the situation that we consider, though, is one where a good employee, let's consider some particular good employee, he can go to the server and download files and decrypt them. But these servers, they log access, there are other mechanisms in place which incentivize the good employee to be careful, right? So when he needs a particular file, he goes to the server, he downloads that particular file, he decrypts it, and he makes use of it. He may have the authority to access thousands of files, but because of other incentives in the system, he only accesses the files that he actually needs. So there are many files that he doesn't access. And now let's consider the bad scenario. So the employee goes rogue, perhaps he's fired or he does something that causes him to be fired, and at that point we revoke his key. Now, let's again think about the standard security guarantee here. The standard revocation idea would say that at the moment he's revoked, any files that are encrypted and added to the server in the future would be inaccessible to him. But you can see there's a problem now, right? Because there are all these files on the server that existed beforehand. And in fact, the user did not have access to them before, and now he could potentially hack into the server, download all these files, and use his old key to decrypt, right? Because we didn't think about that. We didn't think about protecting the old keys. So that's the essential problem about protecting the past that we want to also address. So if you want to summarize what the security property is that we need to put it in a single phrase, we just want that after a key is revoked, the employee shouldn't be able to access anything that he doesn't already have. So if he already had the files and he can decrypt, otherwise he shouldn't be able to do anything. And as I mentioned, it breaks down into two guarantees. The new issue that we're dealing with is the issue of files encrypted in the past. We want to make sure that old files that he used to be able to access are no longer accessible. And to our knowledge, it's the first time this kind of issue has been considered in our community. The other problem is this more standard one of files in the future. I also just want to mention this has been looked at in the context of IBE by a nice paper of Boldareva, Goyal and Kumar. They also looked at it in the context of IBE where they were only able to get the selective notions of security. So one of the contributions of our paper is also to get the first scheme even with the older notion that has full security. And in fact, we achieve a single scheme that gets everything together. So we are able to more comprehensively address the issue of dynamic credentials for attribute-based encryption. All right. So let's look a little bit deeper at what's going on. Let's say for the moment that we were able to solve the second problem. I want to focus on the newer aspect of it. So let's say that we do have security for new files. In other words, we have a way to encrypt to a particular time t, and it can only be decrypted by users with secret key for a time greater than or equal to t. So if you have a time t plus 2 key, you can decrypt 2 minus 1 key, you cannot. So this again is solving the future problem, and let's say we've already done that. And now we want to see how can we get security for these old files. So what are some natural straightforward solution ideas? So perhaps the most straightforward solution idea would be to just tell the server, look, why don't you just decrypt all the files and then re-encrypt them with a new time. So just tell the server to go through all the files and server, decrypt and re-encrypt. Now, this is a terrible idea from an ABE standpoint because the whole point of using ABE in this sort of prototypical application scenario is to make sure the server doesn't need to host any secret information. He doesn't need to have any secret keys in the server. And this solution would exactly require him to have secret keys in fact even to have the master secret key, which is terrible. That's not what we want. Another, perhaps, natural solution which doesn't require any secret information would just be to re-encrypt all the ciphertext. So the server could just take the old ciphertext and just attach a wrapper around it and encrypt the time t ciphertext with the time t plus one ciphertext. This was great, it would definitely work. The problem is that the overhead would be disastrous. The size would grow with t, the decryption time would grow with t as the onion layer is decrypted one level at a time. So these are sort of the obvious solutions. They have various drawbacks. And so basically this leads us to ask and the main question we ask in the paper is can we allow the server to do this essential refreshing of the time without needing to either have any secret keys or grow the ciphertext, right? So essentially what we're asking is that we want to be able to have an encryption to a time t and somehow with some public update procedure update it to time t plus one, right? And if we can do this and the server could do this for all the files every night and this would prevent a user whose key has been revoked from hacking into the server because they would have been updated to time t plus one and he only has a time t key, right? And indeed really the critical thing to observe is that this process of changing time t to time t plus one is something that is making the ciphertext only more restrictive, right? What you need in order to be able to decrypt the ciphertext only gets more demanding and because of that of course, right? Because we are only making the job harder for the adversary, the existence of such a procedure does not conflict with the security of the encryption scheme, right? If we had the opposite problem then that would be disastrous. If you could update from t to t minus one then that would be of course a really bad idea. Okay, so this is what we wanted to do and what we did was we stepped back a little bit and, sorry, and we call this a revocable storage scheme because it allows us to revoke storage that was already present. So what we did was we stepped back and thought about this more generally and if you think about it more generally what we're really asking for here is a way to have an ABE scheme where if I encrypt to some policy P I want there to be a public procedure it only needs the public key that takes the ciphertext and a more restrictive policy P prime than P and it should be able to convert the ciphertext under the policy P to a ciphertext under a policy P prime which is more restrictive, right? This is just a special case of what, I'm sorry, this is a generalization of what I said before because the time constraint is such a policy that you should have a greater than or equal to time and by moving up the time we're making it more restrictive we want to now look at the entire question, okay? And this is the problem that we call ciphertext delegation it's similar to key delegation but on the ciphertext side and we initiate sort of a systematic study of this question in the context of ABE so I wanted to give a quick example of how ciphertext delegation works which essentially shows the basic trick which then works in essentially all known ABE schemes that currently exist so this is the BSW scheme with John Bethancourt and Brent from 2007 the way it works is that we have a master's secret key which consists of two exponents used to think of it this way two numbers, alpha and beta and the public key has some number of things in it don't worry about these beta things the main thing it has is this E that uses a pairing which stores EGG to the alpha and suppose now we have some ciphertext that has just a simple AND policy so it needs the top secret it was a TS property and the accounting property in order to be able to be satisfied now how does it work? well you pick secret S and you split it you use a linear secret sharing scheme this gets a simple additive secret sharing into two shares and the key point main thing I wanted to point out is that the way the ciphertext works is it allows you to recover S in the exponent in order to be able to decrypt by storing these shares in the exponent so somehow these things are stored in the exponent so they're not directly visible the shares are not directly visible but the key property is that they are linearly operable because they're in the exponent so you can raise to a constant you can multiply things together and you get linear operations and that's going to be the key thing for us so now if you wanted to delegate this to a more restrictive policy let's say by adding another criteria like AND director you also need the director attribute then we can do it in a fairly straightforward way all I need to do is take the secret S that used to only be split into two shares and now split into three shares and I don't know what these shares are but it's still easy enough to do I just pick a new random element and I stick that into S I just add it on which I can easily do based on the public information and this will have the right properties it will be a new sharing of the same secret and everything will work out I'm skipping over some silly details of course we need to also re-randomize in the standard usual way when you want to refresh a secret share so that sort of stuff is there it can all be done again crucially it's because in all of these schemes the secret shares are in the linear secret sharing scheme and they're in an exponent where they're linearly operable and so we show how we can do this type of delegation in essentially all the current A-B schemes and we support a number of efficient Cyphertex delegation operations if you think about policy as being specified by a tree of thresholds so an AND or a tree of a special case then we can increase the node threshold for example we can turn an OR into an AND we can increase the node threshold and add a new child that would be like taking an AND of two things to an AND of three things like we just saw and we can also just delete subtree so we can eliminate certain ways of satisfying the policy and these operations are a nice set of operations you can use this together with some tree structures to implement time and that's how we solve the problem of time in a way that's only logarithmic in the number of time epochs that we can support we also look at the more general case of just linear secret sharing schemes based on matrices and we give a number of operations there as well so to conclude what we do in this work is we define this notion of Cyphertex delegation and we give a number of efficient methods for Cyphertex delegation we use this idea of Cyphertex delegation to solve the problem of revocable storage of protecting the past in revocation we also construct something I didn't mention at all in the talk a fully secure ABE scheme that achieves revocable security against future encryptions a more standard notion of revocation and then we try to combine all these things together to get a single ABE scheme that has all of the nice properties and supports dynamic credentials so with that I'll end my talk, thank you