 Thank you very much. Thanks for coming. So this talk is going to be about secure communication And of course the most prominent example being Alice connecting to Bob the ICR web server wanting to establish some HTTPS connection and as we talk about secure communication Well, we expect there is an adversary spying on the IC web server or Alice maybe and Well in the crypto community as well understood that secure communication needs some form of a secure channel So in particular these two Alice and Bob will derive some shared secret for example through a key exchange But the topic of this talk will be what is this secured channel in practice precisely? So the first idea of course that comes to mind is let's encrypt but as we are at crypto let's encrypt authenticated So what we want to have is both Confian shallity either in a weaker chosen plain text attack in distinguishability sense on a chosen cipher tax attacks But you don't only want to have a confian shallity, but also integrity Either for the plain text or the cipher text or the cipher text integrity would be the stronger notion And this forms roughly what we call authenticated encryption Now if we engage in a longer communication then the order of messages becomes relevant And that's where statefulness comes into the game So you can lift these notions to a stateful setting capturing both confidentiality as well as integrity under First stateful encryption schemes, and this then would be called stateful authenticated encryption and which was in particularly Used to analyze the SSH protocol and confirm its security back in 2002 however, a few years later in 2009 there was a plain text recovery attack Discovered against SSH where the basic idea is that an adversary can use the fragmentation of the underlying network in order to Inject into a SSH connection cipher tax in a fragmented in a block wise manner and by doing so in a very careful way Observing mac failures that occurred to due to modifications to the cipher tax This can be used to leak cipher the plain text which will actually be sent So this clearly constitutes a confidentiality break, but hey, I just said SSH was analyzed to be Stateful authenticated encryption schemes so confidential integrity protecting So what's going wrong here? Well, the main point is the attack is essentially relying on Crucially relying on the adversary being able to feed in cipher taxed in a fragmented in a block wise manner where these models capture only Decryption only in an atomic fashion for atomic cipher text So this is why coming back to the models a few years later in 2012 Well, the river de grabiella Patterson and Stam came up with a notion of symmetric encryption supporting fragmentation Which is essentially a generic a general security model which captures such cipher text fragmentation So on the encryption side everything stays as before you have a standard encryption algorithm According with an according left or right oracle for the security notions, but on the decryption side You now require that this decryption algorithm is able to Process cipher text in a fragmented way and still should be able to reassemble the original messages as they were sent then in this model the authors define according notions for confidentiality as The SSH attack was primarily on confident with a confidentiality attack The question is are we buried does this already cover all the practical attacks? one could have on secure channels The answer is no because there are further attacks in particular. There is the kubicator attack from last year on the TLS protocol The basic idea here is that in TLS an attacker is able to truncate a TLS connection by closing the under some underlying TCP connection and by doing though in a Yeah carefully He's actually able to chop off certain parts of transmitted messages And if you have an HTTP connection running or this attack was focused on is the cookie that is sent and by cutting off parts of that cookie You get security attacks on the actual communication So the bit more be a bit more precise here the cookie cutter example is the following when Alice and Bob Communicates Bob being the server and Alice authenticated and at some point Bob will probably send over to Alice an Authentication token to remember her and say please send this back to me when you're talking to me again So that I know you that's still Alice talking to me, but be aware. This is a secure security critical Cookie, so this is what this secure flag indicates. So in particular, please only send this back to me over a TLS connected TLS protected communication channel The cookie cutter attack in the simplest Representation just means now that an adversary is actually able to chop off this part of the cookie string And then Alice interpret this cookie as a standard cookie and happily sends it back to the to the web server Even over a non-protected communication and there the adversary can just grab the thing from the wire So way again, this basically means that the adversary is able to delete parts from within a cipher text So how can this be possible? To explain this let's have a closer look at how the quick cutter attack actually works So on the server side at some point the server will with encrypt its response Including this cookie and what we expect and would more than crypto is that there is a cipher text coming out of that So if you go one step closer to the implementation layer There will be some SSL library doing that job for example open SSL But that's not specific to open SSL and you will use some function of open SSL to encrypt or write data into a street into the channel Turns out route that for properties of TLS that I'll come to in a second This encryption might actually turn after it might be turned into two separate TLS records And if they are now sent over the the wire the adversary is able to truncate the connection at the right point Shopping off the second record product the record packet and Ellis will be left with a fragmented cookie and Miss may misinterpret that in a way that it's not a secure talk token anymore Many important more main important point here is that this fragmentation in TLS is actually implementation specific So any library might do that fragmentation up to certain boundaries in its own way And this means that an adversary is actually able to enforce this split potentially at any point of the message you send So the receiver will not see messages anymore, but fragments of messages With no clear message boundaries preserved Well, this might sound a bit strange. It's actually a behavior That's okay because the data send is a stream and that's what specified even in the TLS IRC so if you go there and look at to Fragmentation specification says that message boundaries are not preserved within TLS Records or TLS ciphertext, which means that either two messages might go into one record packet or a single message might be split up to Into several ciphertext So in the end the support is that TLS actually never promised you to treat message in an economic way And TLS is not alone in that sense There are more and other important channel protocols which do treat data as a stream without boundaries so there's SSH in tunnel mode, which does that and also the Quick protocol proposed by Google two years ago does treat data in a stream-based manner So what we have here now is then a gap between What the channel models we have capture atomic message sending and receive our time message receivable basically and The behavior that this channel in particular here TLS actually exposes to the application And this is why we came up with a notion of stream-based channels and a model for that Where the idea is well first of all what you receive on the sender side What the channel receives and supposed to process is a stream And it might get fragments of that stream in an arbitrary way Then we have a sending of you wish an encryption algorithm Which takes these fragments and converts them into some ciphertext fragments and again forming a stream Important point here is that this in particular allows for buffering So not on every column of the sending algorithm might lead into a ciphertext being or ciphertext fragment being output But there might be the sending algorithm buffer until you provide enough output and then to allow the application to say Okay, now I'm done with what I'm going to send. There's a specific flash lag that we allow for in the sending algorithm telling Now I'm done. Please make sure everything is out on the wire So then this constructed ciphertext stream will be transported over to the receiver side Where some lower layer transmission protocol for example TCP But as there might happen fragmentation Bob on the receiver side will potentially see a Differently fragmented representation of the very same stream as long as there's no modification And we now ask that the receiving decryption algorithm Is able to process this stream again in a fragmented in this fragmented way and Reconstruct the message stream that was sent. However, notice that We do not require that message boundaries are preserved. So as While you will see the same stream if nothing goes wrong The fragments that you will see on the receiver side Will potentially probably not coincide with the boundaries you had on the sender's calls So for correctness We acquire that whatever you receive is a prefix of what you send. So basically there's nothing else coming out and to capture what the The flushing flag should do is well everything that you put into the sender side up to the last Flushing call should also appear on the receiver side. So for security confidentiality we define Indistinguishability under chosen plain text fragment attacks. So we allow fragments on the sender side Basically in a very straightforward way using a left-to-right oracle, which is additionally well the additionally the adversary is able to control the flushing flag More delicate is the chosen cipher text case So the general idea to step back for a moment in chosen cipher text attack You want to allow as much decryption as possible while preventing trivial attacks so in the standard in the standard Stateful authenticated encryption setting the idea was to have this decryption or receiving oracle So the oracle simulating this receivable algorithm that oracle can be in singer out of sync where in sync means It's still receiving the correct the original cipher text or in our case the original cipher text stream And well, this is the challenge cipher text stream. So there should be no output given to the adversary However, as soon as the stream goes out of sync. So as soon as there is a deviation from the original output cipher text stream The output of the receivable algorithm should be given to the adversary The interesting and complicated question now is at which point exactly should this receiving Oracle be considered out of sync. So to consider again the work from 2012 and cipher text fragmentation The definition there is consider you have four fragments received And processed and the adversary Flipped starts flipping bit in the third fragment then This paper defines synchronization to be lost at the beginning of this third fragment the affected fragment Basically meaning that the first two out outputs of the first two fragments will be suppressed That's those challenge cipher text Whereas the second two outputs will be given to the adversary You know think back to the at the cookie cutter attack and this way that a message is potentially split up into a cipher text containing independent parts What you might end up with is that you get two independent parts here and you can modify the second part while still keeping the first one basically untouched So this means in this mobile The first part the first TLS record will be given out to the adversary But that's then challenge message bits So in that sense TLS in this fragmenting way would be considered insecure as it's leaking challenge message bits So the key insight for having a fragmented encryption algorithm as well Is that there is no inherent structure on a stream in particular the boundaries the cipher text fragment boundaries Do not have an implicit intricate meaning So that's why we define the receiving the decryption oracle as follows First of all for the in sync or already out of sync case everything is as before as long as you're still in sync The output is suppressed. That's definitely a challenge message part Challenge cipher text part. Sorry If you already have gone out of sync the full output will be given to the adversary The interesting part is now the fragment which contains the deviation So here we first we process both the only the genuine part and the full fragment using the receiving algorithm which will lead to two message outputs Then we know from correctness that on the genuine cipher text part by correctness There will be only genuine cipher message bits coming out So now we can compare the longest common prefix or check for the longest common prefix of this challenge message part and The full output on the actual fragment that the adversary wanted to have received And we know this part must be challenge message bits So we suppress this this part of the output and give the remaining output back to the adversary To in order to leak the the modified part of the cipher text fragment and for the TLS example, well the unmodified part would be still a common Long a common prefix whereas the scrambled part would go to the adversary Coming to the relations of the notions we define our work. Well, first of all the classic implication Sorry implication still hold so for confidentiality the chosen cipher text Security notion implies the chosen plain text security notion and for integrity which I don't have the time to define and show you here As well cipher text dream integrity implies integrity of plain text dream By the way, this is the first non-atomic treatment of integrity as the 2012 cipher text fragmentation work focused on confidentiality And then there is the classic composition result for Channel so that CPA confidentiality and cipher text integrity gives you the stronger cca confidentiality Here the idea is that basically whenever in the cca in the decryption oracle The out the L the adversary is able to make anything else than an error come out it breaks integrity So basically you can simulate this oracle by outputting the error Then in 2003 that's what sorry in 2013 the multi-error setting was Considered so what happens if you have more than one error that potentially is output and there you can resurrect the composition result By assuming that at most one of these errors is actually visible to the adversary and then you can still simulate the output in this one So we would like to have the composition result also in our setting meaning that we want to have chosen plain text fragment attack security Confiniality together with cipher text dream integrity give us the stronger chosen cipher text fragment confidentiality However in this stream-based setting we are inherently in a multi-error setting Because the receiving output might be buffering and we don't know whether on a deviating Part of the cipher text stream it will already give you an error or it will still give you nothing because it's buffering and Both of these will occur with non-negligible probability depending on your input. So what we do to Get the composition result in our work. So we require an additional property, which we call predictability of errors Basically says if you're given the send cipher text stream and the receive cipher text stream as well as the next fragment to Be processed you can predict the errors coming out Together with this we can resurrect the composition Well, this notion might sound intuitively a bit strong It's actually achievable in my natural constructions and I will now present you with a generic construction. We give you We give in our work This construction is based on AAD authenticated encryption with certain data so state less Version and achieves both the strong confidentiality and integrity notions And the basic idea of this construction is well if you receive a message stream The sending algorithm will chop up the messages into blocks of a certain length and as well keep a sequence number So the idea is up to a certain length you put these the message blocks or parts of the message stream Into a single a AD call using the sequence number as authenticated data And you put an unencrypted length field in front of the construction If you have to flush maybe this encryption will get less bits in this call And then on the receiving side because the length field you can you know How long you have to wait until you get the full a ad block for a certain part and the ad Security will basically tell you well as long as everything is fine You will get this message part coming out Otherwise the ad scheme will tell you hey there was an error. This is the error of the stream based channel as well in particular this scheme Satisfies this error predictability notion and we need use it to prove security Which basically Results from the length field being unencrypted. So in this way you can predict at which point the ad scheme will come to an error notion Interestingly more over this construction But it's kind of the natural construction you can think of of getting state for a stateful channel running It's actually pretty close to what TLS does in the record layer design if you're using an ad scheme as your encryption algorithm So first of all you as well have an unsent sequence number, which is authenticated as the associated data field You have a length field with us, which is sent but not authenticated at least that's the case in the latest TLS 1.3 version drafts However, it's not claiming. This is TLS. There are definitely differences the most important ones There are more fields for example in TLS particularly version number for example in the content field which allows kind of a multiplexing of data These are both for the record send and authenticated So to conclude data is a stream and we believe that we should treat as such a model is that such in our works for Formula lenses So we formalize what we the notion of stream based channels and come up with adequate notions That cover security in the setting more over we're able to reconstruct the composition theorem also in this world And then should you sketch of the ad base construction? We have which is relatively close to the TLS record layer design proving kind of a validation of that for the stream based setting and Well in the end this work constitutes kind of a formal light on how where the where recent attacks in particular the cookie cutter attacks stem from which is basically the application as well as the models capturing received messages as atomic whereas the Channel in that case TLS actually provides a streaming interface and never promised to give you back atomic messages from the receiver side So this work can be considered a start. There's still ongoing work particularly we explore the exact relation Between the atomic notions for channels and the stream based one we come up now There are additional properties that might be worthwhile to consider first of all length hiding is established notion for Authenticated encryption in the atomic setting Question is however what length hiding can or should mean on a stream And I said several protocols allow for multiplexing TLS is an example quick is a more prominent example where several data like message data streams go into the same Secure channel and in the end well if your application is happy to send a stream That's fine. But what if your application actually wants to transport over atomic messages? How can that safely probably secure be done on a stream? This concludes my talk. Thank you very much