 So this talk is going to be about secure channels and in particular what we call multi-key channels where a sender and receiver can update their keys during their communication. So suppose Alice and Bob share a symmetric key with each other and Alice wants to use that key in order to send some messages securely to Bob. For this purpose they need a secure channel. An essential primitive in cryptography to realize secure channels is authenticated encryption because it provides both confidentiality and integrity. So confidentiality means intuitively that the adversary should not be able to figure out what messages are being sent in clear and integrity means that the adversary should not be able to forward a message without the receiver noticing it. But because Alice wants to send a sequence of messages to Bob and not just one single message, the authenticated encryption has to be stateful so that the adversary cannot replay previously seen messages to Bob and she cannot change the order of messages. Another component that is often considered when building secure channels is the associated data because it captures our intuition that the actual payload has to be confidential and the payload together with some associated data for example some header information has to be authenticated as a whole. So to summarize a basic secure channel can be modeled as stateful authenticated encryption with associated data. And this gives rise to stateful notions for confidentiality against passive adversaries and against active adversaries but also to stateful notions of integrity of plain text and integrity of ciphertext. So the channel that I just described is basically a single key channel because the security in that channel originates from a single shared symmetric key between Alice and Bob. And you can imagine if that one single key is compromised then the security in the entire channel is going to be affected. And in fact the key compromise was a concern in the development of the upcoming version of TLS, the TLS 1.3 and what they did is to consider a multi-key channel instead where the senders and receivers can update their keys during the lifetime of the channel. And additionally TLS 1.3 deploys a two-layer deterministic key schedule where we have master secret keys and we have face keys. And the first master secret key is what is derived from the key exchange protocol or the TLS handshake. And the next master secret keys are derived from the previous ones deterministically. And we have also face keys here which are used to provide confidentiality and integrity in each phase. And they are derived deterministically from the current master secret key. And this type of multi-key channel allows us to define two advanced security notions which say that some security should be provided even if a master secret key or face keys are compromised. The first of these security notions is forward security. And it is concerned with the full compromise of the channel or the corruption of a master secret key. And if you're familiar with it, it is conceptually very close to the forward security that is defined in the context of key exchange protocols. So here if the adversary breaks in into the computer and exfiltrates the master secret key of the current phase which happens to be phase two, then we know that security from phase two on cannot be achieved because the master secret keys there are derived from a corrupted one. However, if the keys are securely erased after they are reused, we should be able to achieve security in the first phase. So in general, forward security for channels means that the communication that happens prior to a corruption of a master secret key should retain its security. The other security notion is called phase key installation. And it is concerned with the selective leakage of phase keys this time. So you can imagine that the adversary that breaks in into the computer cannot corrupt or cannot exfiltrate the master secret key because it's going to be probably stored in a more secure memory. However, the adversary is able to reveal the phase key. And here we want that the corruption of the face key in phase two only affects that phase and not the other ones. So more generally, face key installation means that uncompromised phases should retain their security even if past phases are compromised or even if future phases are compromised. So having these security notions in mind, I want to tell you a little story before I continue with the syntax and the security of multi key channels. And the story should motivate why we need a formal treatment of multi key channels and why it is not trivial to build them. So consider a quite natural construction of multi key channels where we have updating keys and the construction is based on stateful authenticated encryption and the center and receiver store a sequence number in their state. And the sequence number is increasing throughout the whole channel even from one phase to other phase. In fact, this construction is quite similar to what was proposed in TLS 1.3 draft 10. And the question that we want to ask here is does this kind of construction achieve phase key installation? So if the phase key in phase one is revealed, can phase two stay secure still? And perhaps surprisingly, the answer to this question is no. And this observation was made by the Meteorless team back in 2015. And they said that if here the phase key of first one is revealed, the adversary can go and of course drop some messages from the beginning of phase two. And then to cover up for the mismatch in the sequence numbers, the adversary knowing the phase key in phase one can just add some valid ciphertext at the end of it. So this kind of channel cannot provide phase key installation. And the fix also proposed by the Meteorless team is here quite simple. It was just to reset the sequence numbers at the beginning of each phase. However, this example shows why it is not trivial to build secure multi key channels and why a formal treatment was necessary. So let me show you the syntax of multi key channels. We of course have an initialization algorithm, which is going to produce the master secret key for us. You can think of it as the TLS handshake or in general key exchange protocol. And I have to note here that the initialization algorithm is going to produce also some initial states. But for simplicity, I'm going to omit all the states on this slide. So from the master secret key, we're going to deterministically derive a phase key. And this phase key can be used to send messages and produce some ciphertext. And those ciphertexts can be received using the same phase key. And this can of course go on. You can send and receive more messages. And at some point, the sender and the receiver can update their keys with an update algorithm and proceed to the next phase. From the next master secret key, we can again deterministically derive a next phase key. And for the future phases, the same pattern can continue. So that was the syntax of multi key channels. Let's take a look at the security notions. Of course, we have security notions for confidentiality and integrity. But because we have these more advanced security notions, we can, in addition to confidentiality and integrity, have forward security phase insulation, both of them or none of them. And of course we have notions for multi key channels. This MK shows that we can have, we can have multiple phases. But we also capture a setting where the channel, the entire communication in the channel stays in the first phase. So we basically practically have only a single channel. And all these different flavors for security notions can be captured with a parameterized security notion, which we call S I K attack, where S shows the advanced security. So forward security, phase skin installation, and both of them or none of them. And we have I for indistinguishability or integrity. We can have K, which was the key setting, multi key or single key and attack can be CPA, CCA, P-text and C-text. So now let's take a closer look at the strongest confidentiality notion that we define in our framework, which would be the multi key variant of indistinguishability under chosen ciphertext attack, which provides both forward security and phase skin installation. We define a game based notion where the adversary is able to interact with multiple oracles. So of course, because we want an indistinguishability notion, the adversary can query a left or right sending oracle, but the adversary can also receive ciphertext and proceed to the next phase with the update oracle. We assume that the adversary can corrupt some of the master secret keys and we assume that the adversary can selectively reveal some of the phase keys. At the end of the experiment, the adversary outputs a phase and its guess for that phase, which indicates whether the adversary believes that the left or the right message was encrypted. The adversary wins here if, of course, B is the correct guess for phase T, but only if that phase was not revealed and if the master secret key of neither that phase nor previous phases were corrupted. So like in many other security notions, it is very important here not to trivialize the win for the adversary because we want the adversary to be successful formally in the game only if the adversary has actually an advantage in breaking the security that we want in practice. So in particular, this means that the adversary should not be able to receive the corruptions of ciphertext that are still in sync with those that were sent because if the adversary can do that, then the adversary can just forward the ciphertext received from here and send them to the receive oracle and easily distinguish whether it was the encryption of the left or the right message. So the main technical challenge in defining security notions is to decide when the adversary is allowed to see the corrections of ciphertext. Equivalently, when should we declare the security game to go out of sync because once the security game goes out of sync, the adversary is able to see arbitrary decryptions of ciphertext. A more classical example of this happens in the receive oracle in the experiment and imagine that we have three ciphertext sent and the first two are received and then the adversary tries to receive a third ciphertext that is not the same as the one that was sent. Intuitively, the experiment here should go out of sync because the received ciphertext deviates from the sent one. However, we shouldn't do so if the phase key is compromised because if the adversary knows the key, the adversary could have generated this blue ciphertext here to be a valid ciphertext which is not going to decrypt to an error message. So if we go out of sync and the phase key is compromised, the adversary can win in the next phase trivially. Another example is in the left-to-right oracle. For example, three ciphertext are sent and all three are received and then the adversary does a key update on the receiver side. Then a fourth ciphertext is sent in the first phase already. Intuitively, here we can say that the receiver has proceeded to the next phase too soon and has no way of receiving this fourth ciphertext in the correct phase. However, again, there is a catch. We shouldn't do so if the phase key in that phase is compromised because if the adversary knows the key, she can go and receive the ciphertext already before the key update and before the ciphertext was sent in the first phase. So after defining the security notions, we explore the relations among them and this figure here shows the strict implications in the multi-key notions that we define. We have a notion that provides both forward security and phase key insulation implies a notion where we have only forward security or only phase key insulation and in particular this means that forward security and phase key insulation are two different and two orthogonal notions and these two both employ a notion where we have no advanced security notions. We also consider a notion that a single key and the entire communication stays in one single phase so basically we have a single key channel and for a single key notion we cannot provide any forward security or phase key insulation because if you have just one master secret key or just one phase key, if that key is compromised then no security can be achieved there. We compare our single key notion to the more established notion of security for stateful encryption and show that these two are basically equivalent of two some syntactical differences. With that the strongest notion that we have is the multi-key notions for for confidentiality we have indistinguishability against chosen ciphertext attacks with forward security and phase key insulation and equivalently for integrity we have integrity of ciphertext with multi-key and with all two advanced security notions and the weakest notions are those that are single key we have for confidentiality in CPA and for integrity in p-text and we also generalize the composition result for authenticated encryption by Bellaria and Nampere to the setting where we have multi-key channel and different invalid ciphertext may decrypt to different error messages. To show that the strongest security notions that we define in our model are actually achievable we give a generic construction which is based on non-spaced authenticated encryption with associated data and pseudorandom functions. The pseudorandom function is used in a key schedule where when we apply the pseudorandom function on a master secret key and zero we get the next master secret key and by applying it on a master secret key and one we get the current phase key and for defining send and receive algorithms we use a non-spaced AAD where we store a sequence number of the messages as the nonce to protect against reordering attacks and because of the attack that I told you about we reset the sequence numbers at the beginning of each phase and we also authenticate the number of send messages in previous phases to prevent suffix truncation and a receive algorithm is defined accordingly. So this construction is quite close to TLS 1.3 and the way that the key schedule is defined using the PRF and the way that the send and receive messages are defined with non-spaced AAD and resetting sequence numbers. However there are some differences for example in TLS 1.3 contents type can be included in the Cypher text to show that the message is an alert message or for example a application data and another important difference is that in TLS 1.3 the key update messages are actually authenticated and sent in the message so they can act as an end of phase indicator and we don't need any more in TLS to include the number of previously sent messages in previous phases to prevent the suffix truncation. So to summarize we formalized multi key channels we gave adequate security notions for them for confidentiality and integrity where we can additionally forward security and face the installation and we explored the relationships between them, showed that forward security and face the installation are orthogonal and we extended the known composition result for the multi key setting and the multi error setting and we also at the end defined a generic construction that is comparatively close to TLS 1.3. This concludes my talk. Thank you very much for your attention.