 Welcome to the presentation of our paper Key Assignment Schemes with Authenticated Encryption Revisited. I am Jeroen Peinemberg and this is joint work with Bertram Puttering. This paper is going to be about access control and if you're familiar with this area you might intuitively think can we just combine a Key Assignment Scheme with Authenticated Encryption and indeed it turns out we can. In this paper we formalized this so we specified the security model and the requirements that's the combined primitive has to satisfy for security but we also identified the second use case where Authenticated Encryption will not satisfy the security requirement but more on that later. So let's first talk about access control. Access control is about the protection of resources that we will also refer to as objects against unauthorized access by specific users. Now additionally we would also like that authorized users can access our objects otherwise we could just delete the data and now this is specified by an information flow policy. So the information flow policy will exactly specify which user is allowed to access the object and which user is not allowed to access the object and since this information flow policy can be represented by a hierarchy this is also called hierarchical access control. Now what exactly is this information flow policy? So an information flow policy IFP for short for a set of users U and a set of objects O is a tuple where we have a set L of security labels and a relation less or equal than which together forms a partially ordered set and we have two security functions. We have nu from the users to the security labels and omega from the objects to the security labels and now we say that the user U is authorized to access an object O if the security label associated with that object is less or equal than the security label associated with the user and in particular we say that the user is unauthorized if this is not the case and we need to phrase it like this because it is not the same as saying that the object has a security label greater than the user and that is because it is only partially ordered set so some labels may not be comparable. Now an example of this hierarchical access control so in this diagram an arrow represents that the user is above another user in the hierarchy so for example Brock has access to all the files that Dahlia can access but also Arya has access to all the files that Dahlia can access because Arya is above Brock who is above Dahlia and this relation in particular is transitive. Now note that Celine is not above Dahlia in the hierarchy because there is no part from Celine to Dahlia so there may be files that Dahlia can access but that Celine is not able to access and also vice versa so in particular these two users are not comparable and you can see the same also holds for Brock and Celine so they have some users that are below them in the hierarchy like Ethan but as I said before like this uses that Brock can access but Celine cannot like Dahlia and vice versa so also Brock and Celine are not comparable and on the top we have Arya who is above everyone in the hierarchy because from Arya to everyone there is a part. Now we have identified two use cases the first one is read only enforcement and in this scenario you have all your files ready at setup and what you want is that you want to specify which user can access which file but you don't want the users to be able to make changes to your files so everything is defined at setup and it is set in stone from that moment. The other use case scenario is where you do want to allow your users to make changes so we call this the read write enforcement and this is say an employee is working on a file say Brock is working on a file and he makes some changes he edits this file he saves the new version and then he saves this file so he basically writes to it and then the next day Dahlia who also has access to the file wants to continue working on it make some more changes and again save a new version of the file so in that case we would use the read write enforcement so here we have the diagram of the read only and just observe that no one is allowed to write to this file so this file is specified at startup no one can make changes authorized users can view it and if you're not authorized you should not be able to view the file. In the other case we have the read write and I think the only thing to note here is that if a user has access to the file it can read and write to the file so there's no sort of read only to this file they can either access it when they can read or write or like Celine they cannot access it and then they can do neither. Now I don't want to dive into the technical details of the model but I think it's interesting to talk about some of the modeling assumptions that we have made so in particular we assume that any algorithm may fail or abort and with that we mean that it gives an output that was not specified in a syntax and you can think of this as authenticated encryption say it gets a ciphertext but this ciphertext is not authentic in fact it's forgery so the algorithm would like to reject this so instead of outputting a message it will just output a say a rejection symbol or whatever error message it will output. Now we feel like if every algorithm is allowed to do this or it would just clutter the notation so instead what we have done is we assume that any algorithm may fail and then it will just output an error message and left it undefined what that error message could be could be anything that's up to the scheme but the game oracle would forward this error to the adversary and the reason we do this like if the adversary would actually run the scheme in the real world it would also observe the error message so if the adversary now queries say the decryption oracle and then the decryption oracle runs the decryption algorithm and this fails then the algorithm will output an error message then the oracle will forward this to the adversary. Note that in particular this implies that the algorithm should not leak any information because if say the algorithm says oh I failed because I was checking the tag and I bit number 20 it didn't match if this is the error message then the game oracle will forward this error message to the adversary the adversary gains his information could adapt its queries learn from this and win our security game. So indeed it is bad practice to leak information in the error messages but now our model actually captures this as well so this such a scheme may be secure in other models but in our model this actually leakage of information is actually forwarded to the adversary and the adversary can use it to win the game. So in particular any algorithm that does not leak any information with this error error message will be fine but if an algorithm actually leaks information then the adversary should learn about this because the adversary should be allowed to use this information and then if it wins the security game in our model this algorithm that leaks information will not be secure as one would intuitively expect. Now how did our constructions end up? As one would expect we used a key assignment scheme so a key assignment scheme has a setup algorithm that takes in the information flow policy remember the information flow policy has all the information about who is allowed to access what object and the setup algorithm outputs a state of sorry a vector of states and public information so sigma u here is the vector of states that holds a state for every single user and pi would be the public information. Now if a user wishes to derive a key for an object it uses its user state sigma it uses the public information pi it specifies the object and additionally could specify some associated data and then this derive algorithm will output the key and now for security it is required that if the user was not authorized to access this object then the key should just be indistinguishable from uniformly random so this should just be a random key and otherwise if the user is authorized to access the object for correctness we would like that this derive algorithm actually outputs the correct key. Now this public information is a bit interesting in the literature because it's not always clear how the adversary is allowed to play with this public information because again it is the public information just some constant value that everyone has that's always authentic and that everyone has access to or is the adversary allowed to alter it and provide it to a specific user it's not always clear. Intuitively you can easily fix the problem by always storing the public information in the user state but for efficiency reasons that's not what you want to do because then you have this public information and it needs to be even though it's all the same it needs to be stored by every single user so in fact what you'd rather do is maybe store it somewhere on a central server and then let users access it but this is kind of a different problem it's more of a storage problem and we've also written a paper on this called encrypt yourself securely outsourcing storage that solves exactly this problem this was presented at azurex 2020 and if you're interested in this storage problem I'd like to refer you to that paper but very briefly what you could think of here is say you basically you store some sort of tag in your user state and what you could do is you just hash the public information and you store the hash of that in your user state now when you want to derive a key you obtain the public information from the central server you hash it you compare it with your stored hash and if it matches you continue and otherwise you abort now this is all formalized in the other paper for but for the purpose of this talk we will just assume that the public information is authentic so the other primitive we use this authenticated encryption with associated data and I've again specified the syntax here so it takes in a key and associated data and a message and this encryption algorithm uses this and outputs the ciphertext and similarly the decryption algorithm takes in the key and the associated data again and then this time it takes in the ciphertext and it will output the message so again because we have assumed that algorithms are implicitly allowed to fail we don't need to say like it either outputs a message or a rejection symbol or something oh if if the decryption algorithm wants to reject the ciphertext then it can just abort and whatever error message the algorithm has will be forwarded to the adversary and otherwise if it's an authentic ciphertext then it will output the message so this is um what our read read write solution does it basically uses the key assignment scheme to derive a key for each object and then I just use authenticated encryption to encrypt the object and decrypt the object as expected now the read only primitive um is slightly different because if we used authenticated encryption here it would not be secure and to see this you need to kind of think about it that we need to somehow protect against insider attacks because authorized users they are going to receive the key to decrypt this object but they should not be able to replace it and if we used authenticated uh encryption then they have the key to decrypt the the object but they could just as easily use that key and the encryption algorithm to create encrypt a new object replace it and then the next user who retrieves the encrypted object will just happily decrypt it since it was correctly encrypted with the with the correct key the decryption would just pass and the new user would not notice that the file has changed so what we did here is um we're going to use something we've called binding tags so you see again the encryption algorithm takes in a key and a message and outputs a ciphertext but additionally outputs this binding tag and the way you can think of this is just a regular encryption that outputs a ciphertext but then additionally you hash the ciphertext and you store this hash value in your user state and now decryption takes in the key and this binding tag and with the ciphertext the decryption algorithm will first hash the ciphertext and it will compare the hash value compared to the binding tag you have stored and if it doesn't match it will abort and otherwise if it matches it knows the ciphertext was authentic and then it will just decrypt now note that even if a user has the key because they are allowed to to access the file then if they compute a new encryption for a different message then the ciphertext would be different so if the next user now tries to decrypt it it will hash the ciphertext it will realize it doesn't match the stored binding tag in its state and it will just reject this so in this scenario users can only read and they cannot change the files because the next user would immediately reject the file as unauthentic now again this encryption and then hashing is not as efficient because we'd have to go over the data twice but again i'd like to refer you to our other paper securely outsourcing storage at azurex 2020 where we do solve this problem with one pass over the data and if you're interested in that you should read that paper so what we've done here is we have two identify two separate use cases to read only and the read write and we have carefully modeled these different use cases and formally defined the security requirements and i think the interesting part about the modeling is the algorithm failures so again the adversary in our model learns about the algorithm failures while normally people people don't don't do this so then if an algorithm outputs it leaks information through its error messages then the adversary would never learn about this and in their model it would be secure and while in our model such schemes would be caught out because the adversary learns this information can win the security game and thus the scheme would be insecure so in particular the algorithm should not leak any information because otherwise they would not be secure in our model thank you all for your attention and i hope you enjoyed the talk