 Hello and welcome to this video that is recorded for EuroCrypt 2021. My name is Gers van Lij, I'm with Johns Hopkins University. I will be talking about abuse resistant law enforcement access systems. This is joint work with Matt Green also from Hopkins and Gabe Kappchuk at Boston University. So what are abuse resistant law enforcement access systems? So these systems allow law enforcement to legally access end-to-end encrypted systems and especially with the rise of end-to-end encrypted systems. This is something law enforcement badly wants. This is also known as back doors and have been a very hot topic in recent years and even longer before that. So what we're trying to achieve is giving law enforcement the ability to do legal searches. But obviously there is a risk of being overly invasive and the risk of mass surveillance. And this is something that we want to avoid and build into the system. So what is this discussion on the one hand? We have law enforcement and policymakers who want back doors in encrypted systems. But on the other hand, we have privacy activists and cryptographic experts. So law enforcement claims that end-to-end encrypted systems limit their ability to do constitutional searches. But privacy activists say that encryption became a fundamental part of doing business and also for privacy of the general population. They also say that back doors are going to be vulnerable to abuse and theft. But then law enforcement say that there are smart enough people in tech that can invent a secure back door. And they suggest some form of key escrow where there is some type of master key that can access encrypted ciphertext that is side or holds by the service provider or somewhere on a device or something like that. But then again, cryptographic experts say that it's going to be very hard to detect when failure happens with key escrow. And with failure, we mean the abuse of the key. So either for mass surveillance or even when the key is leaked that this is used by a malicious actor. So as you know, there is a lot of rhetoric on this topic, but there is actually very little dialogue. And moreover, there are no specifications for what such system should look like. And this is something that we like to address in this paper. Looking at the history of back doors, we can go back all the way to the beginning of the 90s during the first crypto wars. At that time, the NSA had a chip called the clipper chip that was meant to encrypt phone conversations, but also gave them access to these conversations. There are a lot of vulnerabilities were found with this chip and it was discontinued. When Edward Snowden leaked the classified documents from the NSA, it was only then that the general public became more aware of this issue and start caring about it. In 2015, the FBI asked Apple to access an iPhone from the San Bernardino shooter, but Apple refused, leading to a court case. The FBI later dropped the case when a third party actually helped them access the device. In 2020, the Earn It Act was proposed. In this law, it actually required companies to build a backdoor into end-to-end encrypted systems. This is a US law proposal, but in a lot of other countries, such laws were also proposed, making this a real threat on end-to-end encrypted systems. There was also during the Senate hearing in December 2019, a Republican senator from Iowa said, I think you'd rather find a solution than have Congress do it for you, and unfortunately, he's right. So in this paper, we tried to approach this problem from a technical side and show how to achieve some form of this and why this is so difficult. So the key escrow idea that law enforcement people propose and that some cryptographic experts actually investigated or did some research on is some form of this scheme, where law enforcement asks a judge or judiciary to get a warrant. Once they have a warrant, they can get some form of backdoor key with which they can decrypt communication between users or an encrypted device. And so this key can come from either a physical device, so meaning that the law enforcement actually have to possess the device before they can use the key, or it can be provided by the service provider who can then check if the warrant is actually valid. As mentioned before, this is very vulnerable to theft of key or abuse of the key. So what properties do we want in an abuse resistant law enforcement access system? So first of all, we want the warrants to adhere to certain properties, which we call global warrant policies. We want messages to be secure as long as there is no warrant for decrypting these messages. We want some form of transparency and abuse detectability. And we want all these properties to be cryptographically tied to the encryption. So a few examples of this, for example, global warrant policies, could include that warrants should list individuals instead of general groups or anything like that to make sure that any warrants are not overly brought. Also, if any warrants contain any sensitive subjects, we can require to have additional oversight before the warrant can be used. When talking about transparency and abuse detectability, the very least you can think of in this setting is the number of warrants that are activated, so that one can verify that the warrants are actually not, or the backdoor is actually not used on a massive scale. But also more advanced things can be added to this transparency, for example, any differentially private statistics, making sure that no minority groups are targeted or anything like that. And then the cryptographic enforcement, as I said, we want both these global warrant policies as well as this abuse detectability to be cryptographically tied to the backdoor. So some recent research has been done on accountability in backdoors, but nothing as full a definition as ours. So for example, Franco let all also used public ledgers is something that we are going to use as well. We'll get back to that for that accountability, but this was not specifically for end-to-end encrypted. Also, Penware at all did something similar, but it was never tied to the encryption. Right and Viria introduced this idea of doing cryptographic results to increase the cost for law enforcement so that they can not do mass surveillance. But you could argue that especially the NSA has enough resources to actually still do mass surveillance and still solve these cryptographic puzzles. And moreover, they probably don't want cryptographic puzzles to actually access encrypted messages. Then Scafuro in 2019 had a very closely related concept to ours, but this was based on trusted hardware instead of public ledgers. So what parties are we talking about in our system? So we have the judiciary. For simplicity, we call this one judge, but this can be easily extended to multiple judges. We have law enforcement that basically wants to access the encrypted messages and we have the user that actually uses the service to send end-to-end encrypted messages. But we have this one extra thing that I already talked about is the public ledger. You can think of this as a bulletin board. This is a well-studied concept and a lot of research has been done about this. You can think of this as a blockchain, but it doesn't necessarily have to be. The important properties that we require from this are the fact that it doesn't have any escrow secrets, meaning that we're not moving this idea of key escrow just to the ledger. The ledger needs to be publicly accessible, meaning everyone should be able to read whatever is on the public ledger. You can restrict this a little bit, for example, to allow only independent Turk parties to read the public ledger. And very importantly, when you post something on the ledger, you need to get a proof of publication and that proof of publication needs to be able to verify that offline. And now, even when law enforcement and the judge together collude, we still want some transparency to be guaranteed due to the fact that the public ledger is trusted. So what is the RLS paradigm? So two users are using an end-to-end encrypted communication system. But instead of just having one ciphertext, they basically add a second ciphertext that will be used by law enforcement to access the message. And we add proof that both ciphertexts actually contain the same message. This is a noninteractive zero-knowledge proof. So now law enforcement wants to access these encrypted messages and asks the judge for a warrant. If that is allowed, they get that warrant. They can put this through what we call a transparency function that there's still some information out of this warrant that can later be published. So that information gets published on the bulletin board. And once that is published, law enforcement gets a proof of publication back. And this basically together with the warrants becomes a key to then access the encrypted message. So this is very important. The key contains the warrants, the transparency information, as well as the proof of publication. And only if all these things are valid and the warrant is actually adhering to the global warrant policies, they can access the information. So what concepts do we use? We're, as I said, going to use proof of publication ledgers. We're going to have noninteractive secure computation. This is an idea where a receiver can post an encryption of whatever their input is. And a sender can then use just one message so that they can send f of x1, x2 to the receiver where x2 is the sender's input. This can be instantiated using garbled circuits. And this posted encryption will be a partial oblivious transfer, basically. We're also needing noninteractive zero-knowledge proofs. We need them to be simulation extractable. And then finally, we're going to need the very strong notion of extractable witness encryption, where basically encryption happens using a statement in an MP language. And you can only decrypt when you have a witness for that statement. And the extractability property basically says that if there is an adversary that can decrypt, then there exists an extractor that can actually extract a witness for the statement from the adversary. This is a very strong notion and there are actually some implausibility results for general languages. There exists some witness encryption for very simple languages. But nevertheless, it's a very strong notion. We're going to also show why we need such strong notion. So before we go into the implementation details, I have a few important things to note here. So first of all, we're looking at two data in motion and not just data at rest. And we're splitting this up into two different cases. Basically what we call prospective RDS and retrospective RDS. So imagine at some point law enforcement gets a warrant and activates it to actually be used at some point in time. Then the prospective RDS will be able to decrypt all messages that are created after the warrants activation. So all messages that are in scope of this specific warrants. While in the retrospective case, we will also be able to decrypt messages that were already encrypted before that warrant existed. So how did we build prospective RDS? So remember, the users didn't send any communication yet. They might have, but at least law enforcement cannot access that previous communication law enforcement gets a warrants. The warrant goes through the transparency function and the transparency information gets posted on the board on the public bulletin board. But together with this transparency information, they also post the first round messages for oblivious transfer that encodes the warrants. This is for the non-interactive secure computation. Now, the users at that second ciphertext, which basically becomes a garbled circuit that only outputs the message if the warrant is applicable and was indeed posted on the bulletin board. And then they add a simulation extractable music. And so basically this, the information that was on the bulletin board becomes a key to actually access the message. So basically we're building prospective RDS using these non-interactive two-party computation and simulation extractable physics as well as this public bulletin board. And we show that it is a realizable in the universal composability framework from can adding. So if we then look at the retrospective RDS, so importantly here, the communication already happens between the users before law enforcement actually gets the warrant. So the second ciphertext is actually an extractable witness encryption ciphertext and it only decrypts the message when there is a correct warrants and approve of publication of the transparency information of the warrants. So basically this becomes a witness to the MP language that we're using to encrypt the message. And again, there is a simulation extractable music to make sure that both ciphertext contain the same message. So now going quickly over this, but law enforcement gets a warrants puts it again through the transparency function publishes the information on the bulletin board, which only contains the transparency information. And the proof of publication together with the warrants will basically become a key to decrypt the extractable witness encryption ciphertext. So we built retrospective radius from extractable witness encryption and simulation extractable music. And we show again that it's secure in the universal composability framework from Canada, Kennedy. And our final results basically says that this extractable witness encryption is actually needed to build for respective artists. So we show that it also implies extractable witness encryption for a non trivial language. So to be clear, this is not for general languages, but at least for a very non trivial language. So in conclusion, we're getting the fact that getting abuse resistance is actually a very hard problem. Data in motion is also more difficult than data at rest. We show the difference between a prospective and a retrospective case and that prospective can maybe be achieved, but still needs quite some inefficient crypto. But for retrospective, you even need crypto that might even be implausible. Then we've shown the prospective or we've built the prospective and the retrospective case and both show them secure in the universal composability framework. And then we show that at least some form of extractable witness encryption is needed to achieve retrospective artists. OK, thank you for listening. If you have any questions, do not hesitate to contact us.