 Thank you. So I want to talk about signal and hopefully the provable security guarantees of the signal protocol. Could I have the slides? Thanks. So we just had a great talk from Trevor, explaining the challenges in building a protocol that can have strong security guarantees, as well as good usability. And open whisper systems have come up with the signal protocol. And before the lunch break, we heard from John Millican at Facebook how signal is being used in the real world. So John was talking about how Facebook Messenger have the optional feature for secret conversations, which is end-to-end encrypted in Facebook Messenger with signal. So we know how signal is designed because it's open source. And we know how it's being used in the real world. But how do we know it's secure? Where's the proof? And that's what this work aims to investigate. In particular, it's a very important problem because signal is used by default in WhatsApp. As John was saying, it's used in Facebook Messenger. Google Allo are using also optionally you can encrypt with signal. I use WhatsApp personally. I'm sure many people in the audience use WhatsApp or Signal. And so potentially the user base is billions of people. And so it's quite surprising then that in our community, there hasn't actually been any publications analyzing the provable security guarantees of the underlying key exchange mechanism of signal. And so this is a sort of hole in our theoretical understanding that we need to remedy. And so that's what we set out to investigate. So the team are the following people. So on the left are the professors, the bosses. And on the right are the PhD students, the Minions. So we have Cass Cremers at the University of Oxford. And Cass is two students on my cell phone, Catril Cohen-Gordon. And Douglas DeBilla at McMaster University with student Ben Dowling. So myself, Catril and Douglas here. So it'd be great if you see us around to say hello. We're very, very enthusiastic about this work. And it'd be great to discuss it in some detail. I should also say we had some really productive discussions with Trevor Perrin. So we're very appreciative for that as well. So with that in mind, what should signal achieve and does it meet its goals? That's really what we're aiming to investigate. So usual things that we can model for cryptographic protocols are things like we assume it should be secure if the adversary is a network attacker, can be a man in the middle. That's easy to model. Signal explicitly describes itself and its documentation as a protocol with forward secrecy. So check. We can model that as well. There are other things too. So if one message key is compromised, that shouldn't necessarily mean other message keys are compromised. These are all good security properties to model. And we've done it before in other protocols. So that's encouraging. It means we could possibly do it for signal. But the interesting thing about signal is that it may actually achieve another security property, a very novel, strong security property known as post-compromised security. So post-compromised security, the intuition behind this concept, it's the sort of recovering from compromise. And so I want to spend the next few slides explaining what this security concept is in more detail. And then I'll talk about how this is very useful and how this all applies to signal. So what's post-compromised security? It makes sense to look at what forward secrecy is. So this is a picture we're all familiar with. So if time is on the x-axis going from left to right, a forward secrecy is that you have your session represented by this padlock. And then after your session is over, something bad could happen, represented by the orange explosion. So if you have compromise, so Alice and Bob have their session, and then later on their long-term keys are compromised, forward secrecy says that the session you had in the past, it should still be safe. We're all familiar with this concept. So post-compromised security, by contrast, looks like this. It's in some sense the sort of opposite situation. But it's actually, it seems a lot worse, because now the compromise happens, and then you want to have a secure session. And this goes against sort of cryptographic folklore in some sense, because if Alice is trying to talk to Bob and Bob's long-term private key is already compromised, say the NSA already knows Bob's long-term private key, how can Alice be sure she's talking to Bob and not the NSA? And the answer is that you can achieve security, even in this case, by sharing state. So imagine that Alice and Bob not only exchanged messages and Diffie-Hellman values in each session to drive message keys, or session keys, but also that they share a symmetric key which lasts across sessions, and it updates and evolves with new keying material as Alice and Bob communicate. So what Trevor was talking about with this Diffie-Hellman ping pong is that as Alice and Bob send each other Diffie-Hellman messages, so Alice will send a Diffie-Hellman ratchet key and then Bob will do the same and then Alice will send another one. They're continually updating their root key, which is this symmetric key that continually evolves and updates with new keying material, and the root key and signal ultimately corresponds and ultimately is used to drive message keys. And so although they may be compromised at one point in time, this root key could change and evolve, and so Alice and Bob could in some sense recover from this compromise, and that's what post-compromise security is about. So why is this useful as the question? And it makes sense to look at three things. So older protocols have no forward secrecy, so think of the perspective for the adversary. Life is pretty easy because the adversary can be passive and all secrets depend on one key. So PGP or TLS with RSA has this problem. So the adversary can hoover up ciphertext traffic and then if one key, the long-term say if it's TLS, it could be the RSA key of the server, if that key is compromised, then all communications in the past, present, and future are also compromised. Newer protocols have forward secrecy, so there's a big push to have TLS 1.3 to have forward secrecy, so you introduce Diffie-Hellman ephemeral keys, for instance, and life of the adversary is therefore a bit more difficult because now the adversary has to compromise a long-term key and then also be an active man in the middle. But consider protocols with post-compromise security and life of the adversary is extremely difficult because now the adversary has to compromise Alice or Bob and then attack immediately and continue to attack because Alice's and Bob's shared state continually evolves. So a good analogy is that they're changing the locks. In fact, quite literally, they're changing the locks. So the adversary may know the root key, this shared state at one point in time, but because Alice and Bob played Diffie-Hellman ping pong and their state continually changes, the adversary may be locked out in the future. So life of the adversary is a lot more difficult if a protocol has post-compromise security. And this was an earlier paper called on post-compromise security that we got into CSF and it's about security guarantees even after your peers' key is compromised. I should point out that although we're investigating signal, this is a formally defined notion of security in a game-based definition and it could possibly apply to any number of protocols. So that's what I wanted to say about post-compromise security. Now let's talk about signal. So our security model is based on, it's a Bellarogway-style model. So it's a computational model, a game-based model and it's building on multi-stage key exchange models because signal has a lot of different keys and a lot of different ways message keys can be derived. So signal has medium-term keys, femoral keys, ratchet keys and so there are a lot of different stages to consider and so the reason why there hasn't been many publications analyzing the security of signal is because up until recently there just wasn't models that could describe a protocol-like signal. So what does our model capture in the real world? Well, going back to our checklist, we can model a network attacker, so that's good, one that can intercept a man in the middle at any time. We also model perfect forward secrecy. So we allow the adversary to have accession between Alice and Bob and then compromise Alice and Bob's long-term key afterwards. We also model key compromise impersonation attacks so we allow the adversary to compromise Alice's long-term key and then try to impersonate another party to Alice. We also capture a very fine-grained form of bad random number generator, so as I was saying, signal uses medium-term keys and ephemeral keys and ratchet keys, so signal uses a lot of random numbers and so it's conceivable that some combinations of random numbers can be bad and some can be good and maybe in certain situations you can still have a security guarantee. So we allow a very fine-grained, very strong notion of bad random number generator is a bad random number modeling. And we also capture this strong property of post-compromised security and signal is the first protocol that is a real world protocol that can be proven to have this property. And so our theorem is a theorem based on the random oracle model in the Gaptive Helm assumption and it's game hopping proof, which means we start from our original security game and we consider similar games and similar games until we eventually end up with games that clearly the adversary cannot win and we use this to bound the probability that the adversary will win the original security game, which is how we define security and we say, well, clearly because these games are similar in some sense, we can bound the probability of the adversary winning and say that it's negligible and our proof tree unfortunately looks like this, which is quite intimidating, but actually our proof isn't that complicated, it's just we have to partition over lots of different cases, that's why our tree is so large because as I was saying, signals a multi-stage key exchange protocol with different sorts of keys and different sorts of stages and so we have to partition over adversarial behavior, but actually a lot of these cases in our proof are all analogous to each other and so although our proof is long, it's not very complicated and hopefully it's not too difficult to read. That said, this isn't a stamp saying signal is secure, signal is perfect, there are some limitations to our work, so an interesting story is that when we published this paper, we put it on ePrint, which is the International Association of Cryptographic Research and so when the register and other news organizations wrote about that, they sort of said the IACR has verified the security of signal, which is like no, no, we don't work for them, we don't represent them, we're just sticky on ePrint, right? We don't, I think saying any Facebook status is directly from Facebook, it's not the case, you know? But anyway, we're not saying that signal is perfect anyway, so analysis is limited in some sense, so for instance, we're considering a theoretical analysis of the core of the protocol, so we're not considering WhatsApp or Google Allo or Facebook, which is good in some sense, because that means our work is generic, but it also means we're not giving a precise, we didn't look at precisely one particular protocol you might be using, because it will have slightly different implementations. Another technical point is that in signal, there's a medium term key, which is signed by a long term key and also the long term key is used in Tiffy-Hellman Key Exchange, which makes our proof even more long and complicated, so for simplicity's sake, we just assumed that the medium term key is authentic, we also assume an honest key distribution, so as Trevor was saying, usually what happens is you have to compare safety numbers, for our purposes, we just assumed key distribution is honest, and as Trevor and John have already pointed out, multiple devices is work to still be completed, so in our model, Alice has one device, Bob has one device, Charlie has one device, and that's all I wanted to say, so signal, it looks pretty good, but there are some caveats to our work, and if you're interested in reading our papers, the input links are there, so the on post compromise security and the formal security analysis of signal protocol, and that's all I have to say, so thank you for listening. Thank you, Luke. Any questions for the speaker? Here comes Morty. Yes, the field has to reinvent itself every 10 years or so. What you saw, the notion seems like the things that in the late 90s, the beginning of the 2000, notions of key evolving crypto systems, and in particular, the notions that you called post compromise looks very much like cryptographic tamper evidence of eight keys from 2003, just look at those papers. Okay. And I think the signal was not there, I'm not talking about your paper. Okay, well I mean the- Just the notion. See, signal sort of inspired in some sense the idea of chaining root keys, and that's where we got the idea for post compromise security, which I think is a strong property, but I have to check that out, I'm not very familiar with what you're, yeah. I'm not very familiar with that, but I'll have a look, thank you. I'll make sure he doesn't. Yeah, he definitely will. All right, okay. A utterly minor terminological quibble. I and certain other people are attempting to get people to say forward secrecy rather than perfect forward secrecy I agree with you actually. Actually, to be honest, personally, this is just my personal opinion. I don't like the name forward secrecy, I think it's not clear. I think a concept like post compromise security is not ambiguous, whereas forward secrecy, you could easily argue it should be called backward secrecy or something, and so I think, you know. There's no color for it. Yeah, I agree. Yeah, I actually agree. Well, I'm calling it perfect, that's just for some historical reasons, that's what we say, but I agree with you. It doesn't make sense to call it perfect, forward secrecy in my opinion. Just an opinion. A specific protocol to maybe look at is ZRTP. So this one, I think it's RFC 6189, fully specified and quite a few people put work into it and understanding whether that provides the, I think they call it self healing, key continuity, whether that's the, provides a post compromise security that would be an interesting protocol for your techniques to maybe. Absolutely agree, absolutely. Future work. You mentioned formal security. For me, formal implies the use of the CRM prover or something like that three. Did you use any such tools? No, this is a pen and paper proof, but in our group in Oxford, we do have, we use the Tamron tool quite a lot, which is a formal analysis tool, but this particular proof is a pen and paper, classic game hopping proof, but it could be interesting to see if you can model things like post compromise security at those tools, actually.