 Okay, so now the question you will tell us about how to strengthen the security of the ACP. Okay, thank you. So, yeah, this paper is called Strengthening Access Controlling Corruption, and it's shown in work with SEM Baaletsha and Uri Maower. And yeah, so the other question is also here in the audience. If you want to talk, you can talk to both of us. Okay, so, yeah, as was introduced in the previous talk, Access Controlling Corruption. Oh, seriously. Okay, so, sorry. So, yeah, as was introduced in the previous talk, Access Controlling Corruption is a rather new primitive, which was introduced by Dhangar, Thak and Olami last year. And so syntactically it just consists of these five algorithms. And so there's a setup that gets some predicates that basically specifies who is allowed to send information to who. And given such predicates, you then generate a master secret key and some sanitiser parameters. And then with the master secret key, you can generate sender and receiver keys. With the sender keys, you can encrypt. With the receiver keys, you can decrypt. But as you don't decrypt directly, but the ciphertext first goes through the sanitization, which gets the ciphertext and the sanitiser key. And then you have a sanitized ciphertext, which is then decrypt. And the basic idea is that if this policy predicate allows to decrypt, then you should get the message, and otherwise you shouldn't. So that's the basic idea of Access Controlling Corruption. And so we thought about whether you can actually use this in practice, whether the existing security notion is strong enough to achieve something meaningful. So to try to understand this, we first have to think about how one would actually use this. So the natural use case is as follows. So here's a simple example. On the left and the right, we have two users. In practice, there would be many more. Then we have two special roles. On the top is a guy with a trusted authority to generate the keys. And on the bottom, we have the sanitiser key. Now basically, what you do at the beginning is trust the authority, specify some policy, and then generates using the setup available in the keys. And then basically, he needs to send the sanitiser key to the sanitiser. And to do this, we kind of need an authenticated channel, which means that no one can change this sanitiser key. And then the trusted authority can also generate sender and receiver keys, and they need to be sent to the corresponding users. And this needs to be done over secure channels, which here means that it's not only authenticated, but also confidential. It's also clear that we need this because we don't want bad guys to get additional keys. So in this example, the left guy gets a sender key for this role R, and we can give the right guy a receiver key for the role R prime. It's just an example. And now the guy on the left can encrypt the message and basically send the cybertext to the sanitiser who sanitises the cybertext and then writes it into the repository. And as was pointed out in the previous talk, it's really important that this goes through the sanitiser, so we cannot allow the sender to directly put the cybertext in the repository. So this is also why there's this pencil at the bottom that's supposed to show that only the sanitiser can write to the repository. Because if we allow anyone to write in the repository, then just someone can send a plain text in the repository and everyone can see it. And we want to disallow people who are not allowed by the policy to write to do that. Now that's why everything needs to go through the sanitiser. Okay, but if the guy on the right is now allowed to read, then you can basically just get the cybertext from the repository equal and get back the message. So this is the basic idea of how one would use an ACE scheme in practice. And now for security, we need to think about what the assumption here is. So who is supposed to be honest or dishonest and kind of what is clear that the guy at the top, this trusted authority needs to be honest. Either the one who generates all the keys, but he needs to do this properly and not give out the master secret key to anyone. And so senders and receivers both can be dishonest. This is also where this is different from normal encryption that the sender also is supposed to be dishonest. And also here what's special is that the sanitiser can be kind of semi-honest as was said in the previous talk, the goal of ACE is basically to minimize the trust in the sanitiser. And so we will explore basically what this means, how much trust we still need. And so I will just very briefly look at the original security definitions for ACE. So as was said before, also there are basically two kind of rules, the no-read and the no-write rule. And so this is the no-read rule, which essentially is like CKA security. So what happens is that first keys are generated and then the adversary gives two messages and two identities and then like a bit is randomly chosen and depending on that bit, either the first message is encrypted for the first identity or the second message is encrypted for the second identity and then the adversary gets the cybertext that means to guess what the bit was. And till that, the adversary basically has access to two articles, the kitchen article that allows the adversary to send out all the secret keys and there's also an encryption article to get other cybertexts because basically if you use this, then maybe you see other stuff that's going on. And essentially the bidding prohibition is you need to guess the bit, but also we basically need to prevent the case that the adversary has access to the encryption key that allows to be encrypted because then, of course, you can distinguish it. So that's basically the privacy and then there's also anonymity. It's not so important, but this is kind of a stronger anonymity property that says even if you can't be encrypted, as long as the messages are equal, you cannot say which identity it was. Okay, so this is basically the no read rule and the no write rule. Essentially the equation behind that is that an adversary cannot cook up some cybertext that can transmit some information to someone else who should not be allowed to decrypt. And this is formalized by saying the cybertext cannot be distinguished from a fresh encryption or a random message. So formally there's again the setup, then the adversary chooses some cybertext C0 which should contain some information and there's an identity and then either the C0 is sanitized and given to the adversary or a fresh message is sampled and encrypted sanitized and this is given to the adversary. Okay, so here now the difference to the no read rule is that here the adversary only has access to this oracle, again OG, but here OES. So there's no access to an encryption oracle. This ES encrypts and then sanitizes the cybertext. So basically this can be justified by the fact that if you think about the application, then the repository only contains sanitized cybertexts. There's no unsanitized cybertext in the repository. So yeah, maybe that's why also the adversary doesn't need to get access to an oracle that gives unsanitized cybertexts. But yeah, so if you think about this then, so also there's a technical reason because if you would give access to an encryption oracle that one could easily win this game, right? Just basically you could ask this kitchen oracle for a key that allows to decrypt and then you could ask for some cybertext that you can decrypt and then you see what could be this cybertext and then you could later find out what this was. So it's a bit technical, the reading condition, but if you think about this and you know these definitions then you see that you cannot just give access to the encrypt oracle. So it seems to make sense, but if we now again think about the fact that we want to minimize trust in the sanitizer then this might be problematic because if you look at this scenario again there's one guy just sending some message how the sanitizer basically knows the unsanitized cybertext of course. So what he could do is to just give this cybertext to some bad guy or maybe it could also leak because this channel was not secure for some other reason. So it's not too hard in practice to think about a setting where this unsanitized cybertext actually gets into the hands of some dishonest guy. What he could now do is he could try to massage this cybertext somehow in a different cybertext and then send this back to the sanitizer who would then sanitize it and put it in the neuroprosthetic. So the question is now how bad is this? So it's basically clear that this is not kind of captured by the previous definition than a right rule because there was no encrypt. So there was no right to basically that gives an attacker access to this unsanitized cybertext. And so there's at least a definition of the issue, but there's also an issue in the existing schemes we looked at. So both the scheme by Thamka et al. and also by Fuchs-Bauer et al. They have a problem that the cybertext there are malleable which basically allows you that if you're given such an unsanitized cybertext and you know for which message the cybertext is you can produce valid cybertexts for arbitrary messages of your choice. In practice, once you have access to a single unsanitized cybertext the securities is completely broken. You can from now on arbitrarily communicate in a policy of violating them. So this is actually a really bad and yeah, so we tried to fix that. And basically our idea is to introduce a new algorithm to the access control encryption which we call a like a text modification and the basic idea is that you're given two cybertexts and you can basically then decide whether the second cybertext is a modification of the first cybertext or whether it's just a fresh encryption. So what this precisely means is to find a label but this is basically the graphic version and now if you have this magic function then the sanitizer can just before sanitizing the cybertext check whether this is actually a fresh cybertext that you should sanitize or whether this is some malicious modification that you should recheck. Okay and if we do this then we can also in the security definition give a access to this encryptor and basically just say well A does not win if this modification is detected. So this excludes the trivial attacks that you would get if you don't have this e-mart algorithm. Okay, so this is the basic idea. And so there's a second issue with the definition and this is basically that it does not consider chosen cybertext attacks and they're actually also very natural if you think about the application. So as I said before in the application it's inherent that the sender can be dishonest. So we can have the setting where there is a dishonest guy who can send a cybertext but then the cybertext will be sanitized by the sanitizer and now some people can decrypt this sanitized cybertext. But then this is precisely what the chosen cybertext attack looks like. You can have some cybertext that's cooked up in some way and then some guy will decrypt it. So basically one should consider this kind of attack by including an oracle that basically just does this which is first sanitize it. And we also do that by just finding this oracle that takes a cybertext and an entity from which we want to decrypt and then sanitizes the cybertext and decrypt. And then basically in the definition we give the adversary access to this oracle in all definitions basically and so forth in no read which now basically becomes CCA definition we kind of get CCA but here we can also relax this a bit because we have this detect modification algorithm which means so in normal CCA security we don't allow to ask the challenge cybertext to the decrypt oracle and here we can also additionally exclude all cybertexts that are detected as modifications of the challenge cybertext because in the application they would also be rejected by the sanitization so you would never see the decryption of that. So this is the second way of how we strengthen the definitions. There are actually more things we do in the paper but there's not enough time to discuss them all. So let's briefly look at how we can construct a scheme that actually satisfies our stronger definition. And essentially our construction follows the overall structure of the construction by Volkswagen. So this is proceed in three steps. The first step is we have what we call an enhanced sanitizable public key encryption scheme which is essentially a public key encryption scheme that is anonymous and CCA secure and also sanitizable. So what this exactly means is also defined more precisely in the paper but intuitively we want to be able to re-randomize cybertexts. So if you have a cybertext you can turn it into another cybertext that looks like a completely fresh and you cannot link it to the original cybertext. So there's also this concept of re-randomizable public key encryption but the thing is that this cannot be CCA secure or re-randomizable because if you think about the CCA game if you get the challenge cybertext you could just re-randomize it and give the re-randomized cybertext to the decrypt oracle and you could then win the game. So to prevent this issue basically the sanitizable version of sanitized cybertext is different from the original one. So you cannot sanitize it twice to this syntactical difference between cybertext and sanitized cybertext. Again as I said for details please and then if you have such an SPKE scheme then from this we can build an ACE scheme for the equality policy which basically allows me to send messages to myself or basically to everyone who has the same role. So this step is well it's frustrating because this public key scheme already is something like this. If you generate a key pair then you could say the public key is just the encryption key for this role and then the other key is the decryption key and then you already have this. You can decrypt only if you have the key that matches the one in that pair. The only difficulty is here that we have to include the roles somehow but there are roles in ACE which we don't have in public key encryption so we essentially do this by just generating the randomness depending on that role and using signatures but this is more or less straightforward and then the last step is to basically lift this ACE scheme for the equality policy to more general policies and this is also I mean essentially the idea is there to just use many keys and encrypt the same message for different keys and then use some clever encodings. So this step is basically the same as in the scheme by Volkswagen at R. So I will here now only explain the first step because that's kind of the most interesting thing as it's the one that requires new ideas. So how does this work? So the first step that we do basically is we start with essentially a Gamal scheme. So we have some group to generate a key and to have a prime order and then the public key is just the G to the X for some uniformly chosen X and the decryption key is X. Now to encrypt the message as I said it's essentially like a Gamal we have some uniform S and then we multiply the message by G to the X which is the public key to the power of S and we also include G to the S and to allow the decryptization we have an addition some random R and have G to the R and G to the X R which we can also compute. And then to sanitize what we do is we take basically the third a Cypher-Tex component and multiply it by the first to the power of T which is the first component of the sanitize Cypher-Tex and then the second component will be the second component of the original Cypher-Tex to the power of T times the last original component and then to decrypt you can basically just take the first component of the sanitize Cypher-Tex to the power of X which is the decryption key invert this and multiply it by the first component and then you see everything except the which cancels out. So this scheme now is anonymous basically so the X is hidden from from the Cypher-Tex if you cannot so if you assume DVH and also it's sanitizable so the sanitization you will think about is this T basically cancels out the other randomness but this is not CCA secure for instance only CCA secure to make this CCA secure so how do we do this basically we use the now young paradigm that is we encrypt the message twice using two independent keys and then prove in zero-knowledge that we did that so we encrypt the same message twice so now there are several technical issues in our case because the first thing is that normally the decrypt algorithm would verify the zero-knowledge proof but if you want to do this then the sanitizer would also need to re-randomize the proof because we want that the sanitization basically completely makes it impossible to link a Cypher-Tex original one so we would also need to re-randomize the proof and this is kind of not so easy so we chose the other option and say the sanitizer already can verify the proof and then only output the sanitized Cypher-Tex if the proof is that but now this again raises another issue because we want anonymity so we don't want the sanitizer to know what the keys were to produce the Cypher-Tex so this means the topic keys that we use for encryption cannot be part of the text so essentially what we do is we put these keys also in the witness of that we verify in zero-knowledge and then basically the sanitizer does not learn these keys however now we have the problem that we don't want an adversary to basically break up the connection between key pairs so we have so these keys here kind of belong together there are one key pair it should not be possible to now generate Cypher-Tex where you just change the second component for example to use a different key there so we kind of need to bind these keys together and we do this by essentially signing these key pairs and adding the signature but again now we have the problem we cannot add the signature to the Cypher-Tex itself because this would break anonymity and the signature in zero-knowledge and then we do all this you can basically see that this works out in the end this is the rough idea of our construction so that to sum it up we have new definitions for access control encryption that exclude the Cypher-Tex revealing a text which is how we call the attacks where an attacker gets access to an unsettling type Cypher-Tex those include chosen Cypher-Tex attacks and we have additional strengthenings that I didn't have time to discuss here and we have a new scheme for our stronger definition and so there are many problems left also so our scheme is not particularly efficient which is essentially mostly because of the zero-knowledge which so we need the simulation sound zero-knowledge in a general setting not super efficient in practice it would be nice to do this in a more efficient way and also to have schemes for more general policies as in the previous talk it would also be interesting and finally it would be nice to understand what are the real limitations of access control encryption in which settings can you actually use it and maybe do you need even stronger definitions than the ones we have thank you Questions? Finally you should mention the use cases do you have any intuition as to what would be the prime use case for AC in general? Yes so I mean basically so the most natural use case would be to use this in some company maybe where there's some access control policy you have some I don't know some parties have access to some medical information for example and they should not be allowed to send this to other parties so you could kind of use this but one question that arises here is basically who is the sanitiser and how much do you trust this in practice is maybe not so clear and so in the original paper this was motivated by you could basically have like outsourced everything so you don't want to store all your data and the sanitiser locally but you outsource this to the cloud or to some other company and then they do all the sanitization so this could be one use case and later you can store it elsewhere and you don't want to control who can send information to you Other questions or comments? Let me know as soon as possible again