 So I have the pleasure to introduce to you the speaker, the invited speaker of this session, so Karthik Bhagavan. So Karthik graduated from IT in New Delhi, if I saw this correctly, and then he did his PhD at the University of Pennsylvania, where he learned about programming languages, if I noticed this right. And then he went to industry at some point to Microsoft Research in Cambridge and got interested into cryptography. So his research is at the frontier between programming languages and cryptography. He got 2016 an award, so he's in France now, so I didn't mention that. So he moved to France probably as a good step, a good intuition in view of what happens nowadays in UK. So he's happy to be in France with India. And since 2009, I think, and leading the project Prosecco at INRIA, he's heading this project, and got 2016 an award as a young scientist of INRIA and the Academy of Sciences in France. So please, Karthik. Well, thank you for the kind introduction. So the very first conference I attended was FSTTCS, so it gives me great joy to come back here. And I wish there were more students like what I was then in the audience, but it'll still do. So today I'm gonna speak about a little bit of the work we've been doing in my group. And since it's Friday afternoon and you've all heard a lot of talks, I'm going to focus more on problems and solutions. So I'll show you what are the kinds of things we're trying to solve. I'll tell you a little bit about how we're trying to solve them, but maybe you'll have better ideas on how to solve them. Yourself, so these are problems that are very much still open. All right, so what do I mean by real world cryptography? So we're all using this stuff, okay? So you use WhatsApp, I guess. You use Skype. Underneath Skype and WhatsApp, there's actually a protocol. Well, if you use private conversations, which is going to give you end-to-end encrypted messaging. And this protocol is, well, for want of a better name called a signal protocol. Okay, it's a very fancy protocol. It tries to protect your conversations even if your device is stolen by somebody, they should not be able to read older messages. If they steal the device and give it back to you without you knowing it, they should not be able to read future messages. So they try to achieve lots of really fine-grained guarantees and they do this by using very novel constructions. So it's a very new protocol, but it's already ubiquitous. So WhatsApp, Skype, everybody uses it. A second example, which again is kind of invisible to us, but it's actually happening all over the place, is machine learning, of course, right? And a lot of people are now concerned that machine learning algorithms are not privacy-preserving, right? They don't really, they just suck up huge amounts of data from all our devices and they just putting into this black box, they don't even know what the black box does and outcomes are resolved, but we don't know what they have learned about us. They may have learned things about us that even we didn't know about ourselves. So there's a new field, which is getting growing a lot for called privacy-preserving machine learning and this involves a lot of cryptography. In fact, very modern kind of fancy cryptography. This is not working, so I'm going to stand here. Like secure multi-party computation. So just to give you an idea, so the model owner, like Google, owns a model, they don't want to show you the model. You have the data, you don't want to give Google the data and in between there's some cloud server, you don't want to give the cloud server anything. So you all want to hide things from each other but still do some fancy machine learning stuff. How do you do this? And there are protocols to do this. But these are still, both the protocols I've shown you are kind of fairly new, evolving, these are open, people don't really know how to think about them. So let's switch back to a very classic old protocol that we've all been using now for 15, 20 years and it's a backbone of the web. This is a protocol called TLS or transport layer security. If you go to your bank or whatever on Chrome or Firefox, you'll see this little green thing or a lock or whatever that will tell you that you have a secure connection with your server, with your bank or Gmail or whatever. In that case, this secure channel is provided to you by TLS. And this is a 20, 25 year old protocol. It should be like a very, very standard solved problem and there should be no problems left in this. Is that the case? Unfortunately not. So here's a selection. It's not a complete, it's a selection of attacks that came up on the TLS protocol, not too long ago, between 2011 and 2016. I haven't updated the slide. If I did it, it would go to another page if I continue updating it for the last three years. So there's a ton of attacks. The ones in red are the ones my team found. So we are kind of very familiar with this literature on these attacks. So this is a very well understood notion. I am going to my bank. I don't want my data to be revealed to the adversary and adversaries, anybody who's not me or my bank, we should be able to solve this problem. It's a classic cryptographic problem. So what goes wrong with things like TLS? And this is not just TLS. Every cryptographic system that is successful has attacks on it. And why is it so hard to get these things right? Well, there's three layers of things that typically go wrong. And for example, at the heart of your system is cryptography. And the cryptographic algorithm you are using, or the cryptographic scheme or construction you're choosing, may be weak. It may have some weakness in it that maybe cryptographers knew about, but you didn't know about, or maybe even they didn't know about, and suddenly becomes known, and then suddenly the scheme and the protocol collapse. That's case one. And this has happened for many protocols, and many algorithms at this point, and there's a brief list up there. A second example is, well, okay, the crypto is all fine, but the way we put it together to make this protocol where the client is gonna communicate with the server, the server is gonna do something, and so on, that protocol might have a design flaw in it. This is actually a rare error because people have been designing these protocols for 40 years now. So even before we had TLS, people have been designing these kinds of protocols, you understand how to design them, but there are still flaws in them because they're hard to get right. The compositions of these things, very easy to get them wrong. And the third kind of problem is actually the most ubiquitous one, the stupidest one, shall we say, but actually the hardest to get rid of, which is implementation bugs. You have done amazing crypto. You have done a beautiful protocol, but then there's an implementation bug that allows you to bypass all the amazing crypto you did, and so now you're back to square zero or whatever. And often we have found in the kinds of research you've done is that the system breaks down due to a combination of all three of these. So sometimes there's a little crypto weakness, a little protocol weakness, a little implementation bug, and they all come together in a perfect storm to completely break your protocol. And maybe we'll see an example or two of this kind of thing in the talk. So what shall we do? Well, we should try to remove these kinds of problems, but before doing that, because you're not so familiar with these things, let's actually take a look at some examples of what I'm talking about here. So some example attacks, okay? So here's the most simple core protocol that is taught in Crypto 101, which is the Diffie-Hellman Key Exchange. It's at the heart of IPsec, SSH, TLS, Signal, whatever you think about. Every protocol, every cryptographic protocol uses this at its heart. The idea is that there is A, let's call it the client, there's B, let's call it the server. They're going to communicate with each other, and at the end of the communication, they're both going to have a shared key K, and this key K is known only to A and B so that they can now use that to encrypt messages to each other without anybody else being able to see this. Okay, and so to do this in this protocol, A sends G to the power X modulo some large prime P, B sends G to the power Y modulo some large prime P, they both compute G to the power X, Y, and there is a nice assumption called the Diffie-Hellman assumption that tells us that the resulting key will be known only to A and B. Lying, of course, because in this case, there is no authentication, so there's a well-known attack on this protocol that I showed you, it's called the man in the middle attack on anonymous Diffie-Hellman, if you want the name for it, and the basic idea is the following. So A was sending the G to the X to B, right, but there's a network attacker, there's somebody on the network who intercepts this message, changes X to X prime and sends G to the X prime to B. Similarly, when the message comes back, G to the Y, it changes G to the Y to G to the Y prime and sends it to A, and at the end of it, both A and B think, ah, okay, we've connected, we've got our keys, but in fact, the attacker knows both the keys on both sides, so he's a, what they call a man in the middle, a person in the middle, who has completely taken over or hijacked this connection, and that's because A did never had to prove that its own identity never had to authenticate itself, and B never had to authenticate itself either, so this protocol was destined to be broken by a network attacker, an active network attacker would break this protocol, but there's a fix, there's a classic construction called Sigma, where Sigma stands for signatures, Ma stands for Mac, so Sigma, where you add a signature, a digital signature, and you add a Mac, and you need to add both, actually, if you add only one of them it actually, again, there are many other attacks that have appeared, so it took them a long time to figure this out, but finally, the cryptographers came to an agreement that what you needed to secure a Diffie-Hellman-like protocol is something like this, where you have a way of authenticating both A and B to each other, so they came up with this protocol, the details not so important unless you're interested in cryptography, and the security of that protocol basically relies completely on this one assumption, the Diffie-Hellman assumption, and let's look at it in a little bit more detail, so the key that you're going to be agreeing on is G to the power X, Y, mod P, where X and Y are two random numbers that have been generated between zero and P, P is some large prime, let's say it's 2048-bit prime, again generated as a large prime that has been generated, and everybody knows P, but X is known only to A and Y is known only to B, so the Diffie-Hellman assumption, the hardness of the Diffie-Hellman problem is basically the idea that if the attacker does not know X and does not know Y, then the attacker cannot compute G to the power X, Y, mod P, just given G to the X and G to the Y, so by looking at what's happening in the protocol, he cannot get the final key, and there are various many versions of this assumption that are written in different ways with different kinds of probabilistic assumptions made on them and so on, but this is more or less a high-level idea. Now, if I say that I've got the Diffie-Hellman assumption, I'm going to use my protocol that uses Diffie-Hellman, now you're going to ask next is well, yeah, but why is this problem hard? At what point does it become hard, and until what point is it easy? And in all things cryptography, you will find that things that are hard today will be easy tomorrow because the attacker's capability grows as our own computational capability grows, okay? So there is never a fixed thing, so today you're encrypting something with 2048 bit Diffie-Hellman, it does not mean that that is going to remain secure forever in 23 years from now, that 2048 bit prime might be very easy to break. So in particular, there are few groups around the world who are always going for the world record in breaking the discrete log problem, which is essentially breaking Diffie-Hellman. So in 2005, there was a record which they broke a 430 bit prime, which means if you give them G to the X mod P, they could give you X, but they could compute the discrete log for a 430 bit P, and this number has grown consistently, okay? Now we know for certain that we can do 768 bit primes, it is believed that the NSA can do 1024 bit primes, but we don't know, but maybe they can. Maybe bigger, we don't know. All right, so that gives us a bound. So it says that don't use primes up to that 1024 bits, otherwise you're screwed, right? So let's say 2048 seems safe, so that's why I put 2048 on the previous slide. But we have to be aware that there is this weakness if you use a weak P, yeah? So how do protocols get around this? So there are some weak P's and there are some strong P's, right? And the way they get around this is by doing negotiation, right? So 20 years ago when IPsec was first started to be deployed, they used primes which are 512 bit and 768 bits. TLS also had a 512 bit prime for export use, which means everything but the US was allowed to use 512 bits and people in the US were allowed to use 1024 bits, okay? So a lot of places, you'll see these old small weak primes lying around for backwards compatibility or regulations or whatever. But normally we never want to use them because as I said, 512 bit is too weak, okay? So every protocol out there, SSH, IPsec, TLS, whatever you use has a negotiation phase. In the beginning Alice is going to say to Bob, hey Bob, I support these two groups, one of them has 2000 bits, one of them has 500 bits. Which one do you support? So Bob looks at it and says here, I support 2048 bit group, so let me pick the good one. I'll pick the best one and we will both work on the best common group that we have between each other. This is a bit simplistic because there could be many different groups for 2000 bits. So it might say, I support these 3000 bit groups, you support those two, okay, let's pick one that we both support and we'll continue. And this is called negotiation. All protocols need to have this, otherwise you will never be able to communicate between a Microsoft device and an Apple device for example. Because they support different things, they have to find something in common, okay? And in this case, nobody really wants them to ever choose the 512 bit one and they will not normally because now if you take Google Chrome and you connect to Gmail, they both will support the strongest one, they will choose the strongest one and they're done. So normally this means that everything should be safe, right, except not. Because there is a man in the middle attack, remember the one anonymous defilement, the same kind which works on that kind of negotiation protocol, it's called a downgrade attack and the idea is the ideas are following. So there is a network attacker as before who's looking for messages that you're sending to your bank. So your browser sends to the bank and says I support these two groups, a strong group and a weak group. The attacker deletes the weak group and just, sorry, deletes the strong group and just lets the weak group go through. So the server looks at this and says, oh, this must be a really old client, maybe a printer or something. Okay, I don't care, if he wants a weak group, I'll give him the weak group. So the server says, okay, let's do the weak group. Now on the way back, the attacker just lets the weak group go back to the client and client looks at it and says, oh, this must be a really old server, maybe a printer or something and I don't care. So, okay, if he wants to do a weak group, we'll do a weak group. And they both downgrade themselves to the weakest group because the attacker tampered with the message and they continue with the whole protocol. The whole protocol is done with 512 bit security which the attacker knows how to break, okay? That was the basic idea behind this attack called the log jam attack that I and many of our colleagues found in 2015. For that, we had to use a specific crypto attack on 512 bit groups, for which we did a lot of crypto analysis with a group in Loria in France. Then we had to figure out how to get the protocol to downgrade which we did in there. Then we kind of found all kinds of groups around the world that people were using and showed that a huge number of these groups were vulnerable to this which is done in the US. And so this attack was actually practical against a significant chunk of the internet. You could break the connections to them by using this attack. And that's not the only one. These kinds of downgrade attacks where you support something strong and you support something weak for legacy backwards compatibility reasons happen all the time. So there are like four examples up there. You can get the attacker can basically force you to use the weakest possible option that you have, okay? And this basically makes it very problematic to fix these attacks. So if you upgrade your software the any software that you upgrade. So you had an old version and now you're getting a new version. The new version is never going to delete the old version. It's going to put the new version in addition to the old one. So now you always have this downgrade possibility that the attacker can force you to use the old version when you did not want to use the old version. So the only fix really for protocols like TLS and for other protocols like this is to really get rid of everything old. Make sure that anything which is known to be broken does not exist in the software anymore, okay? This is notoriously hard because things hide somewhere in the software. You think they're gone but they're not gone. OpenSSL is hundreds and hundreds of thousands of lines long. Chrome is a million lines long. You can't be sure that MD5 has been removed from everywhere and probably it is there somewhere because someone does have an old printer that they do want to connect to and they can't get rid of it. And the worst part of it is that even if you manage to get rid of all this crypto problems and fix all your downgrade issues you may still have implementation bugs. So let's take a look at that. So in TLS 1.2 there were two kinds of handshakes that everybody was using. A handshake is like a protocol for setting up the key like the one we saw for Diffie-Hellman, right? So one of them was not a Diffie-Hellman one. It's called RSA. The details are not so important but it basically had four messages and at the end of it you had a key, okay? And the flow of messages was something like the one I'm showing on the right. So there was a client hello, server hello, server certificate, server hello, blah, blah, blah. The sequence of messages going between the client and the server, at the end of it both of them have a good key. It also supported a Diffie-Hellman mode like the one I showed you which also had a similar flow of things which has slightly different cryptographic constructions but at the end of it again, you have a good key. If you just look at the messages that were on the wire there was only one difference between those two which is the one which is circled in green which is that in the Diffie-Hellman mode there was one extra message, okay? Which was a G to the Y that the server had to send back to the client. There's one extra message called the server key exchange otherwise all the messages more or less were the same which means that if you wanted to write an implementation of this and you wanted to write parsers for each message and the state machine for each message and what to do when you get this message or that message or what error to send and so on which is all this code that you had to write in protocols you really want to share all the code as much as possible between those two modes except for that one message which is extra here, right? So you want to compose the state machines that let's think of them as state machines, right? These two state machines for these two protocols and you want to compose them in a way that you share as much as you can. So this is what I would say is the composite state machine for those two the one in the middle, the one on the left is RSA the one in the middle is Diffie-Hellman and one on the right is a composite state machine it has one branch. So after the server certificate message if you are in Diffie-Hellman mode you go straight down and you do the server key exchange if you're in RSA mode you switch out, you skip the next message and you go to the next message in the protocol. Now this is just looking at the message flow, yeah? Inside the messages there is very different data going on here and we still have to do some interesting trypto and so on but just looking at the overall message flow what the state machine looks like and this is for just the two modes that we have looked here in reality TLS actually has many other modes it has this thing called resumption it has some other kinds of PSK modes and so on so if you take all the modes that are commonly used on the web the state machine looks a little bit like that on the right so it's a bit more complex it may have a few more branches but still more or less something that you could code up in almost any of the verification tools I can think of so that's I would say the state machine for TLS as it's used on the web, right? So it covers most of the features but the state machine I've shown you there is actually something I've invented it's actually not on the spec nobody really agrees on what the state machine should be it's something you can infer by reading the spec so it's a good question to ask is this what real implementations do? I mean this is my guess of what they should do but is this what they do? So you can take that as a spec and test existing implementations or in this case fuzz existing implementations to see if they follow that state machine and we found when we did this exercise in 2015, 2016 that a lot of implementations of this protocol even in your browsers and mainstream servers mainstream browsers did not follow the nice state machine structure I had before on the right is OpenSSL one of the most important implementations of TLS which is used on almost all web servers websites everywhere and it had these extra edges in the state machine an extra edge is when I expect you to not accept this message but you're accepting this message or I expect you to accept this message but for some reason you're not accepting this message that would be one less edge so what is some cases always the extra edges? Are you accepting something you should not accept? So the ones in green are the extra edges that are accepted by the server the ones in red are the extra edges that are accepted by the client in the OpenSSL then if you go look in Java because Java has a TLS implementation so if you ever do a HTTP connection from your Java program to PayPal or eBay or Amazon or whatever which a lot of people do because this is what Java APIs are for then you'll be using the Java TLS stack and the Java TLS stack has a ton more extra one pretty much you can go from any state to any state so it's not a state machine anymore it's just a fully connected graph so they have done this pretty bad implementation let's say where I just allow you to send any message after any message and the hope is their hope is that well doesn't matter at the end of the protocol if we screwed up then the keys will be different and so nothing's bad is going to happen and while the protocol is going on let's just take any sequence of messages we'll try to process it the best we can if something goes wrong we'll throw an error it's not a big deal so this actually can be traced back to this notion that came up in the early days of the internet where I think it's called Postals Principle which is it says be strict in what you send but be liberal in what you accept and this was at the heart of the interoperability that drove the internet which meant that if Microsoft was doing something crazy with that stack or Cisco was doing something crazy with that stack they would still try to accept some weirdness from the other side because they don't know what exactly you're doing so you have one extra bit okay I'll try to figure it out what you're doing so they would be willing to accept more crazy stuff from the other guy but when they were sending they would be trying to send straight up stuff so that could be one reason why these guys are willing to accept so many extra edges which should not be accepted but here's the question is this actually a bug or is it just a badly designed thing or maybe my spec was wrong well of course it's a bug and it's a bug which is exploitable so say you're using PayPal's Java SDK which a lot of merchants use online so if you click on pay with PayPal or something like that then it's going to use this Java SDK to do this payment with PayPal so the Java SDK your merchant side is connecting to PayPal your attacker is in the middle he wants to intercept this message but pretending to be PayPal of course he's not PayPal so he doesn't know PayPal certificate the first thing he does is when the client sends a hello he stops the message and he sends back PayPal certificate PayPal certificate everybody knows he can do this, no problem the next message after that is this thing called the server key exchange message that he's supposed to actually sign with PayPal's private key but he doesn't know PayPal's private key so he can't do this so what's he going to do but the Java state machine allows him to skip messages so he's going to just skip this message so let's see then he's supposed to send this message called a server hello done but if he does this then the client is going to start sending more messages and he doesn't know how to process them so he's going to skip the next message but once you skip the next message the client is still waiting which means you have effectively skipped the next four messages and now you're in the next message that the server is supposed to send called a CCS but if you send the server CCS message it means that everything from now on will have to be encrypted but we don't have an encryption key we have done nothing we didn't do any crypto whatsoever so there is no key we have not done nothing so far we just skipped everything so what are we going to do now so what this guy does is he says well let me try the same trick he's going to skip that message too now there is this last message which is the finished message which means that the protocol is finished if you don't send that message everybody is just waiting nothing has happened everybody is just hanging on the phone so you have to send that last message but that last message requires you to send a MAC and the MAC requires a key and the key was the key we were supposed to have agreed in this protocol but we have done nothing in this protocol we haven't agreed on a key but Java has this nice feature that Java is a type safe language which means that of course it has a slot for the key and of course the slot for the key is initialized to all zeros so maybe you can use all zeros as a key and try to send this message and if you do it will accept it and at this point we have bypassed the whole protocol in fact we didn't even turn on encryption so the client will start sending messages in the clear to PayPal thinking it's fully connected to PayPal but in fact it never even touched PayPal what's worse here is that at this point if you try to if the client tries to ask Java hey Java tell me what kind of connection do you have it will say oh don't worry we have 5,000 bit security we have the here's PayPal certificate which has this 4,000 bit certificate everything is like the best quality crypto that you can see but actually all the crypto was bypassed because of the state machine bugs so this is a particularly bad case where the protocol the implementation bug in the protocol which is a state machine bug allowed you to completely bypass the full protocol completely but there are many other cases which are more subtle than this where you bypass one message then you have to do some crypto trick then you bypass another message and so on so even if you find a tiny little one bug somewhere in an implementation you should never assume that oh this can't really be exploited this will lead to an error because you don't know there could be some combination of things that will allow you to break this so the summary of that stupid attack on the previous slide was that if you were using Java to do anything secure before 2015 you shouldn't have bothered you were pretty much completely at the mercy of the attacker and this is true between 1997 and 2005 for 16 years whatever something around that there was this bug which nobody noticed so let's get back so we saw crypto weaknesses for logjam we saw protocol flaws like downgrade attacks we saw implementation bugs like that silly thing in Java so this is just a sample so how do we be sure that the WhatsApp thing that I'm using on my phone or the TLS thing I'm using to have interacted with my bank is actually correct is actually secure so this is where we argue that you can't do this it's too complicated you can't do this just by staring at the documents you need formal verification so formal verb methods are the only method I know for getting any kind of confidence in complex systems like these and this is a very good and impactful area for you to apply your techniques as well if you have some new techniques that you want to try out because clearly if you break something here it breaks the security of something important so the impact is usually pretty straightforward so in particular in my group we've been looking at doing symbolic analysis and I'll show you an example to find attacks we took cryptographic proofs of security using tools like CryptoVeref and F-star we also developed CryptoProtocol software verified software using F-star but there are other groups who are using other tools like Coq, CryptoVST, Tamarin and VisaCrypt and so on and all of these tools are coming to a level of maturity that many of you should be able to use them to do effective things so let's take an example of what we can do with these kinds of tools so the first one is going to be how do we verify something like TLS that it doesn't have some of the kind of downgrade attacks that we saw before and in particular let's look at TLS 1.3 so last year, 2018 the new version of TLS 1.3 was released to big fanfare actually there's a lot of news articles and so on and that is because it took about four years of effort to standardize this new protocol 28 drafts, 12 meetings lots and lots of people were involved and primarily it took much longer than they expected because as they were developing this protocol more and more of the kinds of attacks that I showed you before started appearing in the old version of the protocol and then they realized that they had to throw away completely TLS 1.2 and start from scratch if they have to avoid these protocols these bugs in the future but what's more this time they did an experiment they invited academic security researchers including us but anybody who was interested to come and help them analyze the protocol as it was being developed the protocol, its implementations is cryptography and so on so even before the standard was finally published there were like 10 to 12 papers in major conferences analyzing the protocol saying this is good this is not good and so on so this really was a very symbiotic relationship between the researchers and the standardization body and I was involved in some of this work as well so what is new with this protocol? well the first thing they did and good thing they did is to throw away all the bad crypto so they killed all the bad crypto and they added new downgrade protection mechanisms which should actually be designed to make the protocol stronger so that was a good thing they did the bad thing they did is they tried to make it faster so they added this new mode called 0RTT which really allows you to do connections really very fast and it's a bit dodgy it's not really something I would recommend people use but they have a new mode called 1RTT which is already faster than the previous protocol and it's actually very good and that's the mode that I would recommend everybody use the third thing they did was they completely changed the way TLS works with its applications so that the composition of various modes of TLS and of TLS and its applications becomes cleaner and this we don't know whether it will actually have an impact in the future we have to see as new applications comes up whether or not this is going to make a big difference but all of this put together meant that this is a completely new protocol which looks nothing like what the previous protocol looked like so if you want to write the whole protocol out and if I was writing in my papers this is kind of what the protocol would look like it's too big, I'm not going to explain this here but it's basically, this is the 1RTT handshake which is the main key exchange kind of component it has 12 messages and three flights and 16 derived keys and then you can do messages, messaging so you have to like derive 16 keys before you can start sending messages and in addition to this of course you also have other modes which are faster but one important thing to remember is that TLS 1.3 was released last year TLS 1.2 was released in 2008 so this took 10 years for the next version to come out and TLS 1.2 only became ubiquitous in the last three or four years so it takes a long time for new versions to completely dominate the landscape so we expect that in another five years TLS 1.3 will be everywhere but until those five years are done you're going to have TLS 1.2 and 1.3 running side by side okay so now we have to worry about this because you have an old version and a new version which means possibly downgrade so we have to think whether or not there could be downgrade attacks from 1.3 to 1.2 so let's ask this question I showed you, I flashed you a protocol in the previous slide now is this protocol provably secure? for 1.2 I told you it is not provably secure there are lots and lots of attacks 1.3 is it provably secure? we can ask this question and we can try to formalize this so remember this was what we started off with this is my connection to my bank I have some very standard security goals I want a secure channel I want there to be confidentiality on my password which I type and my bank account details and I want authentication I need to know that I'm talking to my bank my bank needs to know that it's talking to me so we want mutual authentication between ourselves okay but this is a classic secure channel so how do we formalize it? so this is not obviously the formal statement which will take several pages but this is roughly what every formal statement of the secure channel would say so first you have a model of the protocol so in this case we are saying that the client and the server A and B are both, one is a TLS client one is a TLS server you'll see what that means we want them to be honest so let's assume that we are talking about only an honest client and honest server which means that their own key material is secret the attacker does not know their key material but the attacker and then we have to define a threat model is in full control of the network so anything that goes on the network the attacker can read, write, modify, whatever furthermore, the attacker is in control of all other clients and all other servers so let's just focus on these two guys who we want to protect assume that everybody else in the world is corrupt okay, all the other clients and servers then the security girl is that if A sends a message M to B the attacker should still not able to learn this message M okay so if the whole world was using a crappy version of TLS but you and I are using a good version of TLS that is probably secure then it must be the case that our messages are still secure between us so that's like the definition of a secure channel now in order to make this more precise we have to say what is our execution model what is A running, what is B what is the definition of the attacker and there are several different ways of defining this broadly classifiable into two classes there's a symbolic methods and there are other computational methods in the symbolic methods we say that A is a high level program that uses, that basically manipulates terms and sends terms on the network where a term is a symbolic term called doll of yaw term or a medium shoulder term which abstracts around cryptography so an encryption is a constructor a decryption is a destructor whereas the computational model which is what the cryptographers use says that the A and B are actually probabilistic polynomial Turing machines and what they're doing is all their computations are over bit strings so the things that you're communicating are bit strings the things they're computing are bit strings converts similarly if you're only modeling the attacker in the symbolic model it's another high level program which is also at the same level as A and B and it has the same computational power as A and B whereas in the computational model it's also a PPT machine it's also allowed to only do manipulations on bit strings and there are some very strong ways in which we limit what it can do with cryptography so among the security goals if I'm trying to say that M is secret in the symbolic model I say that in all traces of the model M cannot be obtained by the adversary in the computational model I try to say that even a single bit of M will not be revealed to the adversary up to some probability P so in the computational model all the statements are probabilistic in the symbolic model they usually are probabilistic or trace based so for TLS 1.3 what does this mean? it means that what you're going to do is you're going to write down concrete models as high level programs let's say in the symbolic model or in the computational model of the client in the server and there are many different ways you can do this and here's just a sample we're going to use the applied by calculus which is a source language for this verification tool called proverif but you can use any of these other languages as well if you're depending on what kind of analysis you want to do then you're going to write down your threats by modeling the precise cryptographic assumptions of what the attacker can do and what he cannot do again this is simpler in the symbolic model in the computational model they're very well known ways of writing these as probabilistic equivalences and you can do that too and we have done that as well and finally you're going to write your security goals so let's do this exercise this is what TLS 1.3 server looks like in proverif it's the applied by calculus so there are inputs there are outputs you can generate fresh keys you can call cryptographic functions and you can trigger security events the details of this code is not so important these slides will be online so you can start at them later or you can actually start at the full model they should be much more informative and so in this case this is applied by calculus which is verifiable using proverif if you take the full model including TLS 1.3, 1.3 and 1.2 the full protocol you can model in about 500 lines of applied by so it's not a very big model actually it's one of the larger models you will write in these tools but it's not so huge then you have to write your assumptions about the crypto and that will take you about 400 lines if you are doing a computational proof this part, the writing the assumption is the most hard part so that will take you maybe thousands of lines but you can still do it it's still analyzable and finally you'll write your security goals in about a couple of hundred lines so in a thousand lines or something you have your full model of TLS and you can press the button on proverif and ask is this secure or not and proverif will give you some answers so before going into how we call proverif here's, I mean remember, recall that we have to define a threat model in proverif this is the threat model we'll have the attacker is a fully powerful network adversary you can do anything on the network and we're going to add this fact that the attacker is able to exploit downgrade attacks which means that we're going to have not just strong cryptographic algorithms but also weak cryptographic algorithms so the weak ones attacker can break but the strong ones he cannot break normally symbolic dollavio models don't do this but you need this if you want to truly look for downgrade attacks like the ones like the log jam attack we talked about before so we have this new kind of model and now we can start analyzing stuff so what kind of goals can we ask from proverif we can say can you prove that M is secret can you prove that M is authentic can you prove that it's forward secret which means that even if my keys are compromised later M will still be secret and so on so here's the simplest one this basically is asking whether this message which is sent on a particular connection to a particular server is will ever be known to the attacker so this is called a security query in proverif you can ask this about our TLS-13 model and proverif will immediately come back and say oh yes there is an attack the attacker can get this message if the server's private key is compromised but you say yeah yeah but you know I'm only considering honest servers so let's assume that the server's private keys cannot be compromised and last ask a second query proverif will come back again and say oh no this can still be broken if the authenticated encryption algorithm you used is weak if I say okay but I'm using TLS-13 there are no weak algorithms anymore so let's cut that out and then we'll find the next problem and the next problem and so on the next problem after this it finds is that the Diffie-Hellman algorithm might be weak and this in fact is a log-jam attack and this you can't eliminate so easily because TLS-1.2 does use weak Diffie-Hellman algorithms so if you have a TLS-1.3 server that also supports TLS-1.2 and that TLS-1.2 part of it supports a weak Diffie-Hellman group then you can do two hops of downgrades to get down to the bad Diffie-Hellman group and then you can break the connection so this is actually a real attack and so on and the final the strongest query to which Proverif-Alans are true is this one and if you look at this carefully it basically is listing all the conditions under which your connection is secure or put another way all the conditions you must satisfy before TLS-1.3 become secure it says for example if you read it out is that messages on a TLS-1.3 connection are honest and this is a security theorem it's proving for us in the symbolic model but it's proving as theorem here if as long as the connection does not use bad algorithms and as long as it does not use weak Diffie-Hellman groups in any protocol and that's kind of some of these assumptions but not obvious to the designers of TLS-1.3 either but this has now become an advisory for how you should deploy TLS-1.3 and I would argue that this kind of problem where you're finding attacks on the combination of TLS-1.3 and 1.2 where each of them has five modes each and each protocol has like 15 messages is impossible to do by hand you definitely need formal tools to do this and you will never be sure that you've found all the attacks unless you actually have a formal verification tool that can actually give you a positive result at the end of things so that was one piece of the puzzle there are other people who did crypto proofs some people who did proofs by hand some people who used tools to do this but there was a whole bunch of proofs that came up for TLS-1.3 which is what gave us enough confidence to say maybe this is ready for publication it doesn't mean that the protocol doesn't have bugs it just means that we have bashed at it as much as we can with the tools at our disposal and new attacks that will come out hopefully will uncover new problems not old problems so now I'm gonna change tracks a little bit so so far we've been talking about protocols TLS, blah, blah, blah attacks, downgrade, fixing this and stuff but like I said all of these things are in the end going to be dwarfed by the kinds of problems you can have when you implement them we already saw the state machine bugs that come up when you try to implement the protocol but let's assume that was just a stupid bug everybody knows how to implement the state machine you know how to do it you will do it correctly maybe you can verify that the state machine is correct and in fact we do these kinds of things as well but the hardest part of any crypto library of any protocol library is actually the crypto layer because the cryptography that you're gonna use actually is fairly fancy mathematics and that fancy mathematics is hard to implement correctly so what you want is also a verified crypto library you can't trust that the algorithm that you're using whether it's RSA or Diffie-Hellman whatever has been implemented correctly there are tons of bugs if you go to any crypto library people are like constantly finding bugs in this thing so this is a different project I'm going to speak about which is taking most of our time right now which is we are building this verified crypto library called Hackle Star we've already released one version a second version is going to be released next month and let's try to see what the problem is what is the problem we're trying to address here okay so how do people write crypto code the first thing you start off from is some kind of standard so the NIST in America or the IETF which is international or somebody else publishes a standard so this is a standard called Cha-Cha-20 Poly 1305 it's fairly recent 2015 it's a encryption algorithm and a MAC algorithm Cha-Cha-20 is encryption Poly 1305 is MAC and put together they give you a nice construction called AEAD which everybody wants to use so this is one of the more popular new encryption algorithms that has come up so if you look in the code if you look inside the standard you will find some pseudocode so there is some pseudocode there says this is what you should do this is the block encryption function this is it's kind of almost looks like Python but it's not quite it's kind of semi-formal pseudocode which tells you what the code should be doing and then you're supposed to take that and you're supposed to implement it and typically in C some people implement it directly in assembly and so on and if you look at the C code it looks more or less like what the pseudocode looked like so you can argue that there is not much that can go wrong between the spec and the code except maybe okay now you're doing some memory allocation so you could have a memory bug for sure you also the algorithm that is specified in the spec only says oh here's how you do encryption of one big block but in reality you never do encryption of a big block you do it like chunk by chunk by chunk so you have to figure out how to do that chunk by chunk encryption the standard will not help you with that so there are some more things that could go wrong because you did this wrong okay but on the whole there's not very deep things that can go wrong here okay so let's accept that okay so we could have introduced a buffer overflow or there could be a timing leak we'll talk a bit more about timing leaks later let's look at the other algorithm there it's poly one three of five which is a Mac algorithm actually that's the full spec of that Mac algorithm it's very very tiny you can describe the whole algorithm in about what 15 lines of Python okay it's very very tiny okay and this is what is usually used if you're using your phone on chrome on phone to connect to gmail they're using this algorithm and if you look deep inside that algorithm there is two lines there where it says a equals a plus m and it says a equals r times a modulo p this p that they're speaking about is actually a 130 bit prime there are other standards like this where it will be a 255 bit prime some others for the 521 bit prime they're specific prime so this is a 130 bit prime so the moment you look at that you realize that when you're doing this addition and you're doing this multiplication and this modulo operation you are not working on 32 bit numbers okay you're not working on numbers that are available in your programming language 130 bit numbers doesn't exist in any of our programming languages we use right now so this is actually a big num computation it's a computation on a number which is larger than what your platform provides you so how are you going to implement just those two lines that those two lines account for most of the complexity of the implementation of poly so if you look at it it basically breaks it down it says 130 bit number I'm going to represent it as 532 bit numbers actually you only need it four and a bit but you have to use five so it makes enough that you can use put 130 bits in it and now when you do addition you have to add it like two arrays like a big num addition of two arrays of 532 bit numbers you're going to add them and you're going to propagate carries you're going to do all kinds of management and so on so there's a lot more code that's a very much larger implementation than char char 20 and they can have lots and lots of bugs and people have found carry propagation bugs arithmetic bugs buffer overflows timing leaks all kinds of problems in this code which was not there in the other code so this is the kind of place where you can very easily find problems in your crypto software and to see why let's go back not just to crypto 101 but class two or class one or whatever when you first learn how to do multiplication right this is textbook multiplication of bits so this is how we do it we all do it for digits but okay for bits and remember you have to do this carry and you have to do this add and the add might have another carry and so on there's actually two carry bits that you have to carry around when you do this kind of multiplication and you don't need to know the details but in fact it turns out that you have to go back to class two when you do this kind of coding because that's exactly the kind of computation you are doing when you're multiplying 130 bit numbers or 256 bit numbers so if you're multiplying 256 bit numbers it's gonna look something like this you're gonna break it up into 64, 64, 64, 64 so there are four bits let's say four digits and then you're going to multiply them you're gonna have to carry along and you're gonna have to carry down and you're gonna add everything and so on the only special thing is this is modular multiplication so at the end you're going to take your seven limb or eight limb number and you're gonna have to reduce it back modulo p to come back to a four limb number and there are many algorithms for doing this and more and more fancy optimizations for doing this some of our instruction sets give you special instructions that help optimize some steps of this because it's so common that you would want to do this for any big num computation whether it's in numerical computations or crypto and this multiplication right here is a dominant cost of cryptography on all your devices just multiplication and typically multiplication of 256 bit numbers it used to be multiplication of 2000 bit numbers which is more serious but with elliptic curves now typically it's 256 bit numbers that you're multiplying and that's the dominant cost of crypto for all the protocols that you use okay because here you're doing n square 64 times 64 multiplications and that's kind of costly if you do Karatsuba you can do a little bit less and so on but it's more like this but let's worry more about the correctness of these things now you're gonna have these long intermediate arrays every number is an array so now you have to allocate these arrays deallocate these arrays make sure you copy them correctly and you have many many carry steps that you have to do all over the place to make sure that the numbers you're computing are correct right so what can go wrong you could have integer overflow which is very common which in some places will give you a trap and in other places is okay but it'll just give you the wrong result you could have buffer overflow and underflow of course you could have missing carry steps which is surprisingly a common bug that people do in this typically when they're optimizing their code or you could have a side channel attack so let's look at what a side channel attack in this case would be going back to the simple multiplication there so when you're multiplying like this one zero one one zero one zero one zero one zero you might observe that when you see a zero bit you really have to do nothing there's nothing going to be added because you can just shift and you can move on you can just ignore the steps where there is zero because there's really nothing happening and if you do that you cut down the computations you have to do by half which is nice so it's much faster fewer additions, fewer carries the negative is that if somebody is looking at how much time it took you to do that multiplication they now know how many zeros are there in the second argument and since the second argument is often a key a secret key knowing how many zeros are there will allow them to mount an attack that will soon reveal your entire private key so that is a timing side channel where the time taken by a computation is revealing things about your arguments and that revelation is enough to break the cryptographic algorithm that you're going to do okay so almost all the crypto code you are going to ever want to write is going to be constant time in the sense that you never want the running time of the algorithm to depend on any secret input so that's a very important criterion so okay so we talked about buffer overflows all these kinds of carry bugs and so on let's start how do we verify this code so the idea here that we're using is that well don't just go straight from the standard let's write a formal spec which is halfway between the standard and the code okay and then we will prove that the code that we are generating is correct with respect to the spec so it's functionally correct it's memory safe and it has no timing side channels that's what you want to prove and that's what we do with this language called fstar and we have built this library called hacklestar which I'm that paper is about it and stuff like that and the stock is not long enough for that but you can go look at it and ask me any questions you like it already supports a wide range of algorithms and we're growing this in which we prove memory safety, secret independence and functional correctness and the code that we generate from it is C code which is fairly portable we can also generate WebAssembly code and this code is currently used in Firefox in the wire guard VPN which is in the Linux kernel and in the Tezos blockchain and the concordium blockchains so it's already kind of fairly widely used so what makes this as a formal methods project which is actually verifying code what makes this actually take that last step towards impact is performance so when we try to get our code into Google into Firefox and stuff the first question they ask was how much slower is your code than the code that I already have my code may not be correct but it's fast but your code is correct but it's slow I'll probably stay with my incorrect but fast code and they gave us numbers like you can't be more than 5% slower because for Google 5% translates to millions of dollars on their data centers so that if you take 5% slower down unless they are so sure that their old code is buggy they will not change but what's nice is that if you're doing your verification technology in the right way and you're generating code which is C which is also verified then you can cross this gap so the code that we generated for Firefox was 20% faster than the previous unverified C code so it was a no-brainer for them to accept it and now we have jumped that by two times or three times even so we are much faster than what they ever used to have and in fact if you want to go all the way to really hand coded, assembly code that people write to get maximum performance out of these algorithms you can even do that so there is a project called Vail where they verify assembly code for arithmetic programs like the ones we're writing here and you can compose verified code from Huckle and verified code from Vail to get essentially the fastest crypto implementations that have ever been seen and that's in our paper called EverCrypt which will come out in Oakland this coming year so the end result of this is that if you go to if you open up Firefox, you go to Google and you go to the console you'll see there it's using X25519 and that's our code and not just that there's another five algorithms that they have taken from us and so all connections between you and Google is using verified crypto done by us it's not just us though there's a group in MIT who have this project called Fiat Crypto and they've delivered code to Chrome so even in Chrome there is one component of it which is using verified software of this kind okay, stepping back just as kind of quick summary I've told you about verified crypto, verified protocols but there's of course tons of interesting problems here you're working on verified messaging and there are many other groups working on this as well which is like WhatsApp but also group messaging and lots of open challenges there they've also been working on verifying privacy preserving machine learning algorithms with Prasad and this is again a huge area increasingly important area that we need more people to pay attention to and work on and all of this is under these two projects that I participate in one is called Circus and one is called Everest and I welcome you to go look at the web pages and see all the various kinds of things that people have been doing around verified software and verified crypto in these projects okay, conclusion but I hope I have given you a little bit of a flavor to convince you that formal methods are at this have reached the stage where we can be effective on real world crypto protocols but also have a real significant impact so it's an exciting time to be because all these tools have come to maturity we know how we can really have an impact but there's still lots of nice important and open problems left like we don't know how to do zero knowledge proofs you don't know how to do group messaging and so on and the other thing is that on the software verification side we have I think at this point in our development as a field cross the bridge where we no longer have to sacrifice performance for correctness we can make high performance in fact higher performance than existing code which is verified at least in this domain so it's again a domain that I would encourage you to look at again many many challenges everybody who's ever doing any blockchain related research is very wants verified code here and they don't have enough people doing machine learning of course and then there is this whole new field of post-quantum crypto which is untouched so there's like nice open areas where you can do lots of interesting work here alright so I'm going to conclude with this last slide which is to say that we are hiring and we are always hiring we are looking for excellent students and PSE students and postdocs so and visiting researchers so if you're interested in any of the topics related to anything that has spoken of today do get in touch thank you thank you very much for this very interesting talk so we have now some time for questions what about I mean protocols like what's up where you have multiple participants in the protocol so where you have possibly multiple attackers so how do these tools and these formalizations work with multiple attackers? we just submitted a paper on group messaging so there is this new effort at the ATF called messaging layer security but what the question pointed out was an important one which is that we are all we kind of understand what point-to-point security is but security for groups is a completely different beast because even stating the properties there is hard and especially when you have WhatsApp groups well WhatsApp groups go to 256 but there are messaging groups that go to 10,000 people but what is the security assumptions here? how do you kind of protect the group against one malicious participant or maybe n by 2 malicious participants is a completely new set of challenges so there are new protocols including the one in WhatsApp which can be analyzed with methods similar to what I said here except that they very quickly grow to very huge state spaces so almost anything that is based on symbolic model checking or something finitary will immediately fail in these group settings so you need something verification method that can really handle induction and recursion and so on to do this and F-star is one such method Hock is another method which would allow you to analyze these things but there are lots of interesting challenges Hi so sorry I think part of it you covered in the last part of your answer that is in F-star you indicated the kind of functionality that your verification engine would have I wanted to ask you about the underlying technologies from formal methods side but you said induction but then you said it is completely mechanized right so I in that talk the first part I was talking about Proverif and Proverif is completely mechanized it is a HON clause based solver now the one thing maybe I should have mentioned earlier in the talk is that the essential sort of verification problem we are tackling here which is with an unbounded attacker is undecidable, instantly undecidable actually so it's very easy to prove that it's undecidable which means that almost that all the verification tools you can consider here either are computing are doing very heavy approximations to get it into a bounded state or even or more commonly what they do is they give up on completeness so if they say yes it is secure, if they say no there is an attack but they may say maybe or I don't know and so Proverif is one of the latter ones it can say I don't know and then you have to use some tricks to kind of nudge it in one direction or the other and that's up to your ingenuity so most of the time for many of the classic protocols it will always give you a yes or no answer so it's very lots of heuristics in there so that part is completely mechanized if you want to do crypto proof like a true crypto proof with probabilistic polynomial tuning machines none of those tools are fully automated, they're mechanized but not automated so you have to give them hints on how to do the how to do the proof now when you get to code like the one I was showing you for the crypto code that's why we're using F-star and the fiat crypto group in MIT uses Cok and there are some people who use some other tools and there it's a choice between how much automation you want to get so if you in our case we use F-star because we can get some automation out of the SMT solver which F-star uses in Cok you do it via tactics and so on but you get more a small or trusted computing base so that depends on what your choices are but people have been using all kinds of tools for these harder problems so you mentioned the keyword I wanted to ask you is how big the trusted computing base is and does it have to descend all the way into hardware that's right so the crypto library I showed you Huckle-star is in C okay C is already like a big distance from assembly so we say okay if you really care about that you should use comm-cert and then you can get down to assembly okay you can get down to assembly but it still doesn't account for any of the micro-architectural attacks like Spectre and Meltdown that came up last year in fact none of the libraries crypto libraries out there is secure against them right now because they completely break our abstraction over the hardware itself so there is more work going on now after Meltdown and Spectre of people trying to link like the RISC-5 architecture or more novel designs like Sherry and other things from the University of Cambridge then take a formal model of what the hardware is supposed to do and then link it up and that's very fresh and cool area to work on but we don't have the answers yet so my question is about ProVerif so it must use some kind of decision procedure to actually go through all the combinations and find out that the attacker cannot obtain the message let's say and I remember somebody was talking about a similar tool and my question there was and so that's the question for ProVerif as well which is do you translate this down to something like a CNF that I can use a standard tool for it or did you hand code your own decision procedure and the reason that I'm asking this question is because if you do actually do like translate it to SAT then what you can do is you say well obviously you're looking for on set so usually that's how you work and then if it's an on set then a SAT server will actually give you a proof trace which tells you actually which parts of the protocol are completely useless obviously the proof trace doesn't actually contain parts of a proof I mean parts of the protocol that means that part of the protocol was completely useless to prove that the attacker cannot so basically you can essentially remove messages from the protocol therefore shortening it without losing any guarantees that you want to provide right now that's a very interesting idea so there are two or three tools that do compile down from protocol descriptions like the one I showed you to SMT and then they do try to use pruning they also try to use like Z3 will give you a counter example which you can then reconstruct into an attack for example so there are lots of interesting things you can do once you're using these off-the-shelf tools Proverif on the other hand is sort of highly focused on crypto protocols so what it does is that it has its underlying it is a standard horn clause resolution algorithm with selection where the selection is actually programmable it's nothing you wouldn't have seen 20 years ago in some sense but the heuristics that are going into it are all about how to use the selection procedures to kind of grade it in a certain way and as part of those selection procedures and heuristics it is trying to prune by figuring out dependencies but it does this in a way where it uses the structure of the protocol and what it knows about how these protocols usually go to really encode a lot of heuristics and other tools that have tried to do this in a more generic way by just compiling to SMT2 or something and losing a lot of structure in the process have struggled to kind of handle the complexity because the resulting formulas tend to be too big and this has been a limiting factor so as we've used both SMT and Proverif so I'm seeing such big advancements now in the last few years in SMT that it might be the case that soon we may not need all of these special heuristics and we might be able to use something more generic but it's not yet clear I would say in that field the custom decision procedures are doing better still significantly better for the questions it's not the case so then let's link again Patrick