 Thank you for the introduction. Good morning, everybody. So in this talk, I will talk about the security of TLS, which is a two-party protocol, which is typically used in a client-server setting. And as the name suggests, the purpose of TLS, sorry for this question mark here, this is an error, as the name suggests, TLS operates on the transport layer of the OZ reference model for network communication. And it can be used to protect all higher-layer protocols, like, for instance, HTTP protocols related to email, file transfer, voice over IP, et cetera, et cetera. The goal of TLS is to provide a confidential and authenticated communication channel for all these higher-layer protocols. Historically, TLS originates from the SSL protocol, which was developed by Netscape in 1994 and later merged with the protocol of Microsoft. And in 1999, SSL became an AETF standard and was then renamed to TLS. So this was TLS version 1.0. And since then, there have been two minor updates of the standard. So the current version of TLS is version 1.2. Of course, not everybody is using the most recent version of TLS. So in particular, version 1.0 is still widely used. And even though there are some security critical differences between versions 1.0 and 1.1, so maybe you remember the beast attack from last year of Zhuang and Tritzo, which exploited the bad choice of IVs and the record layer of TLS, I will focus in this talk mainly on a different part of TLS, namely the handshake. And in the handshake, there are only small difference between these versions here. So when I refer to TLS in this talk, I mean any version from 1.0 to 1.2. The TLS session consists of two phases. In the first phase, a handshake protocol is executed. And the purpose of this handshake protocol is first to negotiate cryptographic parameters. So in particular, a so-called cipher suite is selected. I'll explain this concept on the next slide. Second, authentication of parties is performed. And third, a session key case is established. And in the second phase of the protocol, the so-called record layer, this key is then used to encrypt and authenticate data, so the actual payload data, which is transmitted between client and server. Cipher suites are a very simple concept. They are basically just a standardized selection of algorithms for the various cryptographic tasks that have to be performed during a TLS session, like for instance, a key exchange, signature scheme, and so on. And here is an example of a cipher suite. So this is a mandatory cipher suite for versions 1.0 and 1.1 of TLS. And this cipher suite prescribes the use of Diffie-Hellmann key exchange, a female Diffie-Hellmann key exchange. I'll explain that later. The DSS signature scheme, as a signature scheme, to sign messages. And this is used in combination with triple S in encrypted decrypt-encrypt mode, in CBC mode, and SHA-1 SS hash function. Of course, this is not the only cipher suite, but there are many, many cipher suites which are standardized. But one can categorize all cipher suites into three groups, three categories. The first one are cipher suites based on ephemeral Diffie-Hellmann. And these cipher suites simply perform the standard Diffie-Hellmann key exchange where both parties choose their Diffie-Hellmann exponent fresh for each execution of the protocol. The second class of cipher suites are based on static Diffie-Hellmann. The difference here is that the server uses always the same Diffie-Hellmann share, and only the client uses a fresh Diffie-Hellmann share for execution. And finally, there is RSA-based key transport. So where the client picks a random string, a key, encrypts it, sends it to the server, and this key is then used in a key derivation function at later as the key. And the handshake protocol differs slightly for each group. So in this talk and in the paper, we consider cipher suites which are based on this ephemeral Diffie-Hellmann key exchange. So let's have a closer look at TLS-THG-based handshake. We consider a setting where both the client and the server have a long-term secret signature key pair, and the TLS handshake then consists of three phases. In the first phase, both parties agree on a cipher suite. So the client sends a list of supported cipher suites and the random nonce. The server picks one of these cipher suites and sends its own random nonce. In the second phase, essentially a Diffie-Hellmann, a scientific Hellmann key exchange is performed, which gives shared secret, the so-called pre-master secret on both sides. And this pre-master secret is then used in some key derivation process. So first, the pre-master secret is used as a seed to observe the random function together with some constant label, L1, and the random nonces, and this gives the master secret. And then the master secret is used with a different label and again with the nonces to give the actual session key. And finally, the third phase of the Diffie-Hellmann DHE-based handshake are the finished messages. So the server computes its finished message by applying the pseudo-random function on the master secret, some label, and all previous data. And then this finished message is encrypted together with some constant, constant S. And the cipher text is sent to the client. The client decrypts the cipher text, checks the validity of the finished message. So this is actually essentially a MAC over all previous data. So the client checks the MAC, and if this verifies, then it accepts the key K with communication partner S. And the client essentially does the same. It computes its finished C message, transmits it to the server, and the server accepts if the finished message is correct. And the question is, of course, is this a secure protocol? Then so, yeah. Before we can talk about security of protocol, we have to talk about what we mean by security. And one natural choice for a security model for the TLS handshake is a secure authenticated key exchange or secure AKE for short. And from a secure AKE protocol, we expect two properties. First of all, the protocol should authenticate both communication partners properly. And second, the protocol should provide a good cryptographic key. And by a good cryptographic key, we mean that the real key should be indistinguishable for an adversary from an independent random value. And there are several security models which formalize this intuitive notion. And the model that we use is basically an enhanced version of the classical Belarroga Ray model, adopted to the public key setting with a strong adversary, which can forward, alter, drop, et cetera, any message, which is able to corrupt parties adaptively, and which provides strong security guarantees for key exchange protocols like perfect forward secrecy and security and against KCI attacks. Unfortunately, it turns out that the TLS handshake is not provable secure in this model or in any similar model. And the reason is the following. Here's again the handshake protocol, a bridged version. So the interesting part is here, the finished messages. And the problem is that if you want to argue with key indistinguishability, and we use this key within the protocol, then this gives us a problem because an attacker can simply distinguish a random key from the real key by taking one of these encrypted finished messages, decrypting it with the received key, checking whether the decryption is equal to this constant here, and if it's equal, then he has received the real key, and if it's not equal, then it's, well, yeah, if he has received an independent random key, then it's very likely at least that this constant will not be equal. So this encryption of the finished message is the reason why we cannot prove security of the TLS handshake in any indistinguishability-based security model for authenticated key exchange. And this is not a nice situation, because on the one hand, TLS is one of the, or maybe the most important security protocol in practice, but we cannot analyze it in any indistinguishability-based security model. And this is very unsatisfying. And we see two approaches to resolve this issue. The first one is we change TLS. So we consider a so-called truncated TLS handshake, which has appeared in the literature before when a paper by Morise Smart and Walensky, and the difference is that this truncated TLS version does not encrypt the finished messages. And the second approach is that we can try to develop a new security model, which provides reasonable security guarantees for TLS, and which allows a security proof. So the first approach is to consider truncated TLS, which is identical to the TLS-DHE handshake, except that the finished messages are not encrypted. And this allows us to prove the following result. The TLS-DHE handshake is secure. If we make several standard assumptions on the PRF, on the digital signature scheme, if you make the DDH assumption in the Diffie-Hellmann group, plus one additional non-standard assumption, the so-called PRF-ODH assumption. And I will talk about this assumption at the end of this talk. So I've said before that this truncated TLS protocol has appeared in the literature before. So let us compare our result with the work of Morise et al. So the security models in both works are comparable. The result of Morise et al. is a bit stronger in the sense that they consider not only TLS-DHE, but all three possible families of cyphro-suites. But they make quite extensive use of the random oracle model, while our model is in the standard, our result is in the standard model. But unfortunately, both results do not consider the real TLS handshake, because we have made this modification to the handshake, and TLS is not used in this way in practice. So let's have a look at the second approach. We want to define a new security model. And this new model is based on the following observation. A secure AKE protocol provides very good keys, indistinguishable keys, so indistinguishable from random. And the nice property of secure AKEs that this key can then be used in any arbitrary further application, as if it was an independent fresh random key. And this is unfortunately too strong for the TLS handshake because of this attack that I've showed you before. But actually this is stronger than necessary. And the reason is that TLS uses the key not in any further application, but only for the encryption in the record layer later. So the question is, can we describe a new security model, which on the one hand is strong enough to provide some reasonable security guarantees, and which second is weak enough to be achievable by TLS. And yes, this is the motivation behind authenticated confidential channel establishment, or ACCE for short, which is the new security model. And this model is a simple extension of essentially of the Balare-Rogaway model. We have the same first property. So again, we require explicit authentication of communication partners, but we replace the requirement that the keys should be indistinguishable from random with a different property. Namely, we want that protocol is able to establish a authenticated and confidential channel. So ACCE considers the combination of the TLS engine with the record layer, and it requires that encryptions are indistinguishable, which provides confidentiality of messages, and second, that ciphertext authentic, which provides authenticity of the communication channel. And then we get this result. We can show that TLS-DHE is a secure ACCE protocol. If you make all the assumptions from the truncated DLS case, plus one additional assumption that we have to make on the record layer, and we require that the record layer cipher is secure in the sense of stateful, length-hiding, authenticated encryption. And this is a security notion which was introduced at last Asia Crypt by Patterson-Ristonpart, and help me. Shrimpton, Tom Shrimpton, thank you. And this is just a security notion for semantic ciphers, which nicely captures exactly the properties that we require from the TLS record layer. And it was also shown in this paper that this security notion is achieved by CDC-based cipher suites in TLS 1.1 and 1.2. So finally, I want to talk about this non-standard assumption, PRF-ODH, that we had to make to give you an intuition about it. So in the sequel, let G be a group generated by lowercase g with order p, and let PRF be a function which maps an element of the group and some set, an element of some set, to an element of some set r. And the assumption can then be described by a security experiment played between an adversary and a challenger. The adversary selects a message m from this set m here. The challenger generates two random group elements, g to the u and g to the v, and sends these group elements to the adversary. And then it sends either the PRF evaluated with the Diffie-Hellmann key specified by these two values here, and this value m specified by the attacker, or it sends a random independent value. So far, so good. Now comes the ugly part of the assumption. The adversary is now allowed to submit a group element, w and some message m prime, and the challenger has to respond with the value of PRF evaluated with this key w to the u and this value m prime here. And finally, the adversary has to tell whether it has received the real or the random value up here. So the PRF or the H assumption states now that no efficient attacker can distinguish this value here from an independent random one. And this is actually a variant of an assumption which has appeared in the literature before, the so-called Oracle Diffie-Hellmann assumption by Abdallah, Belar, and Rogaray. Yeah, and as I said, the ugly part of this assumption is this additional Oracle query here. So if you somehow got rid of this query here, then this assumption would be fine. It would be probably satisfiable under DDH and some standard assumption on the PRF, but unfortunately we need this additional Oracle query here to make the TLS-based, to make the TLS-proof go through. So finally, is this PRF or the H assumption really necessary? Well, on the positive side, this assumption is not necessary and we get a proof on all the standard assumptions, DDH, PRF security, and so on. If we consider a security model where no corruptions of long-term secrets are allowed and for some applications, this might be a reasonable security model, but maybe not for the way how TLS is used in practice. And the second option would be to make some small changes to TLS, really small changes, just reordering two messages, for instance, would do the trick. And then TLS-DHE handshake becomes very similar to a protocol called Sigma Zero by Kennedy and Kravchik and the security analysis of Kennedy and Kravchik would almost carry over to TLS. But unfortunately, we would have to change TLS, which is not reasonable. And on the negative side, it turns out that this PRF or the H assumption cannot be avoided if we consider a security model which allows corruptions and if we can consider reductions which use both the attacker and pseudo random function as a black box. So to wrap up, we have given an security proof for the truncated TLS-DHE protocol. We have developed a new ACCE security model which aims at circumventing this problem with proving security of TLS as an AKA protocol. And this is only one possible approach to circumvent this problem. And I want to mention that there is a sector approach which is available on ePrint, a paper by Christina Bruschka, Mark Fischlin, Nigel Smart, Bogdan Warinski and Stephen Williams. And yes, so this is our approach, this is another approach. And finally, we have given a security proof for the full TLS-DHE protocol with a suitable record layer protocol in the ACCE security model. And we have some open problems. Of course, TLS is much more complex than the idealized cryptographic core that I've shown in this talk. So we have, for instance, session resumptions. We have not considered a secure agreement of cipher suites, et cetera, et cetera. So a better analysis or a more and more practical analysis of TLS is an open problem. And finally, another open question is also if we can employ or if we can make a similar analysis of the other two families of handshake protocols. That's the end of my talk. Thank you for your attention and I'll be happy to take questions. Thank you.