 Welcome to my talk on flexible, authenticated and confidential channel establishment, analyzing the noise protocol framework. This is joint work together with Benjamin Dowling from ETH Zurich and Jörg Schwenk, who is at Ruhu University Bochum as well as I am, and my name is Paul Rösler. In this talk, I will explain our analysis on the one hand, the results and on the other hand, the methodology that we used in four steps. I will first introduce the noise protocol framework that we analyze here. I will then talk about the history and our approach to model and define security of secure channel establishment. I will then give you an idea of what the results of our analysis are. And at the end, I will shortly discuss small fractions of how our security model looks like. The noise protocol framework is a framework for defining and deriving patterns for establishing confidential and authenticated two-party channels. It has been established and invented and also developed by Trevor Perrin since 2014. And due to its lightweight and modular nature, it has been adopted and deployed in WhatsApp, WireGuard, Slack and Amazon. So it protects the communication of multiple millions of communications per day. It is developed for homogeneous networks, which means that all entities communicating via this protocol within Vine environment all agree upon a set of parameters. So there is no parameter negotiation as it is deployed and implemented, for example, in TLS. It allows for a modular extending and defining patterns. And it is very lightweight because it uses very efficient and very few powerful building blocks like authenticated encryption, hash functions and the Fihelman groups. It exists or it contains 15 base patterns for specific features and properties, but it can be extended by multiple other features and multiple features and properties can be modulally combined. And when I say it is modular and it can be extended, then, for example, one way to modulally define patterns is by the authentication mechanisms. For example, it can be used for communication of entirely no authenticated users at all. It can also be used for unilateral authentication, but also bilateral authentication. And furthermore, it can be parameterized by whether the authentication keys are pre-established and pre-distributed or whether these authentication keys are distributed and sent during the communication within a session. Then there are multiple further extensions like pre-established or pre-shared symmetric keys, or the authentication keys can, for example, as indicated in the graphic on the right side, be sent confidentially such that the identities of participating members in a session remain anonymous or hidden towards outsiders. There have been multiple analyses of noise patterns and the noise framework in the past, for example, by Kobayci et al. who analyzed noise in a symbolic model in an automatic fashion such that they were able to derive multiple security guarantees and multiple security properties for almost all patterns that can be defined by the noise protocol framework. This work has been published at your S&P 2019. In computational models, there have been two analyses, both focused on the noise pattern that is implemented in the WireGuard VPN protocol. One has been conducted manually by Dowling and Patterson, published at ACNS 2017, and the other one has been published at your S&P 2019 by Lib et al. who analyzed the WireGuard protocol automatically. We will now look at different patterns within this protocol framework in order to understand how one can derive and obtain single protocols from this large noise framework. And we start with the N pattern that allows for unidirectional unauthenticated communication from initiator A to responder B. Already within the handshake, this pattern allows for the confidential transmission of payload M0, which is encrypted under a key derived from the Diffie-Hellman G to the lower A to capital B. So G to the lower A is an an ephemeral Diffie-Hellman share sent and generated during this first handshake message from initiator A and G to the capital B is the long-term secret or the long-term Diffie-Hellman share from responder B. Now, this first ciphertext, which already authenticates the G to the lower A as associated data, is now also authenticated within the associated data in the encryption of all following payload messages within this channel. So also after this handshake, multiple channel messages can be encrypted with the same key all taking the first ciphertext as associated data. This N pattern is now also part of this extended NK pattern which adds a second handshake message from responder B back to initiator A such that first of all, B's payload from B to A is now authenticated and additionally both A and B can now send payload to each other such that a bi-directional channel is established. Within this second handshake message from B to A, the B generates and sends a fresh Diffie-Hellman share G to the lower B to A such that G to the lower A, B is now also part of the key derivation for encrypting both payload from B to A within the handshake but also for encrypting all future channel communication between A and B. As said before, the last handshake message, the last handshake ciphertext is always the associated data put for all future channel communication between A and B. Now finally, in order to also authenticate A, the last pattern that we look at today is the XK pattern which adds a third handshake message to this protocol in which the long-term Diffie-Hellman share of A can be encrypted from A to B such that on the one hand, this G to the capital A is encrypted and thereby the identity of initiator A is hidden towards outsiders but also now A authenticates towards B by also using G to the capital A, lower B as part of the key derivation for all future encrypt and send payload. The question that arises from these three patterns already but one can imagine that there are multiple more different patterns within this framework is how to analyze such multiple kind of similar but still different protocols with different security guarantees at different stages within one single protocol in one computational model such that the analysis results can be compared. And in order to answer this question, we will now first look at the history of how channel establishment can be analyzed. Firstly, the most natural way how to analyze and look at channel and channel establishment is to differentiate between the channel establishment via a key exchange and a symmetric protocol that uses the established key for protecting payload. The problem arises if the established key for protecting the channel payload is already used during the establishment of a symmetric key. This problem has been looked at during the analysis of the TLSDHE protocol within the paper on the security of TLSDHE in the standard model. In this model, the author defined a method how to encapsulate and combine channel and key exchange within one framework which is called the authenticated and confidential channel establishment. Now still one only has the ability to exchange exactly one key that is then used for the entire lifetime of this channel. In order to allow also for multiple stages within one protocol and thereby allow for the exchange and establishment of multiple keys for having multiple different channels with different security guarantees, Fischlin and Günther proposed the multistage key exchange model which initially was used for analyzing the quick protocol. The problem is still if the key that is established for securing the payload of a channel is already used during its own exchange between two parties A and B, then this model, the multistage key exchange model gives no guarantees for the security of the payload as that is then transmitted. And as a result, in order to overcome this problem of both having multiple stages but also keys being used during the establishment of the channels for these stages, a multistage ACCE model, so a multistage authenticated and confidential channel establishment model has already been proposed in various works, among others also within an analysis of the quick protocol. In this first variant, it also only allowed for two stages within a communication but also in various other works, multiple stages have been considered. A significant problem of all these works is that for them, a stage always consists of first the establishment of a key and then the transmission of payload. Now in our work for two reasons, we entirely disregard the internal mechanisms for the key establishment in the model but rather define our model only with respect to the functionality that we analyze, which is the channel. The first reason for this is that the noise protocol framework allows for in every stage the transmission of confidential payload at this exact same moment at which the key for protecting this payload is also transmitted. So the establishment of keys and the transmission of payload is kind of entirely merged within noise. And on the other hand, we think that in order to define security for some primitive, it should play no role how this is constructed but rather what the construction is aiming to provide as functionality. In addition to messages encrypted to the channel and messages decrypted from the channel, we also consider it as a functionality that constructions output the level of security that the message that is going to be transmitted via the channel or that has been transmitted via the channel reaches. So the construction itself says which security it reaches for transmitted payload. From this information, we can then define a very simple and clear syntax definition for a channel establishment that consists of four algorithms. The first algorithm key gen outputs and generates a long-term authentication key pair for each party in the environment. The init algorithm then starts or initializes a local state for an instance that realizes the execution of a channel. For this, the init algorithm takes the long-term secret key of the party that initializes this channel plus the public key of the partner with whom this party wants to have a channel and the role that the instance that realizes this channel takes within this channel. Lastly, it also takes the data that is associated to this channel, for example, a port number of an underlying protocol or some further information that just gives some context. The encryption and decryption algorithm take the local state that is output from the init algorithm in order to process the real channel. In addition to this, they also take as input the authentication secret key of the party that they represent within the channel and they either take as input a message that is going to be transmitted via the channel or a ciphertext that is taken from the channel and to be decrypted as a payload. The output is in both cases the new local state of the instance that processes the channel and either the ciphertext giving to the channel or a message giving to an application that uses the channel. Lastly, as I said before, it outputs the security level that signals the security guarantees that hold for the message that has been decrypted or is going to be encrypted with the channel. With the security level, we then define our security with five parameters. Two parameters refer to the authentication that is to be reached. One parameter refers to the forward secrecy of a channel and two refer to the replay attack resistance of a channel. And these parameters are consistently compared to the security levels output by a construction during the security game. For example, if the security level is higher than the parameter of the security model that refers to the authentication of the initiator, then the initiator must indeed be authenticated within the respective channel. That means if the authentication breaks, then this either refers or indicates a successful adversary or a trivial attack, meaning that, for example, the initiator has been corrupted before and then impersonated. A second example would be if the security level of a construction output for a certain message is higher than the forward secrecy parameter, then this means that forward secrecy must be reached for this specific payload. As a result, after having output such a security level that is higher than this forward secrecy parameter, it means that the participating parties can indeed be corrupted without breaking the confidentiality of messages sent via the respective channel. In our security analysis, we consider eight out of the 15 base patterns of the noise protocol framework and provide reduction-based proofs for them. For the remaining seven patterns of these 15 base patterns, we also provide conjectures for the parameters that I just introduced at the last slide. But for now or within this talk, we will just ignore these remaining seven patterns. For the eight patterns, we provide fine-grained security guarantees and proof them with reduction. And these properties include, as I said, the authentication of parties, forward secrecy with respect to the long-term keys of parties, and security with respect to replay attack resistance. In an extended version of our paper, we also consider key compromise impersonation attacks and the security with respect to reveal of random coins of single instances participating in a session. For now, we will ignore these further properties and only consider authentication, forward secrecy, and replay attack resistance. In order to illustrate what the security guarantees means, we will now look at the three patterns that we introduced at the beginning of this talk. So the end pattern here on the left side and in the uppermost row, we see that the security achieved by this pattern only includes confidentiality of payload sent from initiator A to responder B. No authentication nor forward secrecy nor resistance against replay attack is reached. By just adding a second handshake message, the NK pattern reaches authenticity of the responder, forward secrecy, and replay attack resistance with respect to both participating instances. Finally, by just adding a third handshake message, the XK pattern additionally reaches authentication of the initiator. At the end of my talk, I will now shortly discuss how in general, security is defined in game-based computational settings but also specifically how this is reflected in our model. Usually in such settings, the security is defined via a game played between a challenger here on the left side and an adversary here on the right side. And this adversary has then usually the ability to control invocations of algorithms of the primitive that one considered. In our setting, this is the init algorithm, the encryption algorithm, and the decryption algorithm. Also, the adversary usually, as well as in our setting, has the ability to control and determine the public inputs of these algorithms when being invoked as a result of the query of one of these oracles. This is used to say or to reflect that an adversary can create its own victims and its own targets such that one can derive statements about the security of every victim and every target of an adversary. In addition to this, the adversary usually has access to the secrets that are used for algorithm invocations that are conducted as a result of the queries that are the oracles that I just mentioned before. In our setting, the adversary has the ability to corrupt the long-term parties within our environment that is simulated by the challenger on the left side. And in addition to this, the local states that are used for processing different invocations and executions of a channel. And this is used to demonstrate that, for example, different parties are independent of each other such that a different party can be corrupted while the other party still has secure communication and still secure channels. Also, for state reveals, this is used to demonstrate that different executions of the protocol derive different states and therefore, one cannot attack one channel with the local state of an instance that participates in another channel. Then in order to derive a security statement, one would need to define what the security goal is. And usually this is an event that should not trigger during the execution of an adversary with the oracles just defined above. In our setting, we consider confidentiality and authenticity as the security goals. So an adversary should not obtain information of transmitted payload and it should not be able to manipulate traffic sent via a channel. Now, all these oracles give an adversary so much power that it can conduct attacks that no construction can prevent. And as a result, one would need to declare such unpreventable attacks as non-successful towards the adversary. So the adversary when conducting such attack is not considered as a successful adversary against the previously defined security goals. In addition to these unpreventable attacks, usually security definitions and security frameworks include preventable attacks that are still not considered as successful attacks for the adversary. This is used to allow for more efficient constructions and it also allows for more precise security guarantees. In our model framework, for example, these exclusions of preventable attacks are controlled via the model parameters that we just previously discussed. And as a result from these exclusions of preventable attacks, one derives further soft security goals which we call them here. So for example, forward secrecy is just a soft security goal that is defined via when and under which conditions a corruption of parties can take place. Also replay attack resistance is just a soft goal as a derivation of authenticity. And all these soft goals are just a result of the treatment of preventable attacks. We now look at the relation between state reveal as an ability that an adversary has in the security gain and replay attack resistance as a soft goal that is the result of our security definition. State reveal on the one hand demonstrates and illustrates the real threat of attackers to obtain the local secrets of an instance that executes the protocol. So in reality, there are devices that run channels and executions of channels for a very long time. So it is practical that attackers can obtain the local secrets. And in order to demonstrate that this threat is or has effect only to the channel that is executed by the specific device, we should enable adversaries in our security game to obtain via state reveal the local state of single instances. Replay attacks are just a derivation of breaks against authenticity. So what they model or what they result in is the delivery of same messages via just one honestly sent ciphertext multiple times to multiple receivers. And in some cases, such attacks are even unpreventable. For example, if the participating parties of a channel have static long-term secret keys, then for example, the first ciphertext that is sent from the initiator to the responder is always replayable by attackers. Now, the relation is that such replay attacks do not only result in multiple messages being sent to multiple receivers, but also multiple secrets being established by these multiple receivers of the replayed ciphertext. So replay attack resistance does not only say that ciphertexts must not be replayable, but also that if a ciphertext is replayed, that different instances processing the ciphertext differently and replying to this replayed ciphertext differently must eventually become independent. And as a result, we need state reveal to be allowed for attackers to result in a meaningful notion of replay attack resistance because it also reflects how far the local states of receivers are dependent or independent throughout the execution of a channel in which initially a replay attack occurred. Okay, I will now shortly wrap up my talk. So it started with a short introduction into what the noise protocol framework allows and what it captures and what it contains. Then we looked at the history and our approach of how one can model channel establishment. Our idea is here to understand the primitive via its functionality and not as related work did via its potential constructions. We then looked at the analysis result and saw that we analyzed eight out of 15 base patterns and derived precise security guarantees for different properties at different stages within the protocol. And at the end, we discussed the security model, how it is usually designed and that different security guarantees are sometimes only derivations of each other and can therefore not be analyzed within independent security models. For further information, look at our extended version, which you can find at E-Print. And if you have any questions, contact me via Twitter, for example, via this handle röselpa or via email. Thank you very much for your attention and stay safe.