Hallo Du!
Bevor du loslegst den Talk zu transkribieren, sieh dir bitte noch einmal unseren Style Guide an: https://wiki.c3subtitles.de/de:styleguide. Solltest du Fragen haben, dann kannst du uns gerne direkt fragen oder unter https://webirc.hackint.org/#irc://hackint.org/#subtitles oder https://rocket.events.ccc.de/channel/subtitles erreichen.
Bitte vergiss nicht deinen Fortschritt im Fortschrittsbalken auf der Seite des Talks einzutragen.
Vielen Dank für dein Engagement!

Hey you!
Prior to transcribing, please look at your style guide: https://wiki.c3subtitles.de/en:styleguide. If you have some questions you can either ask us personally or write us at https://webirc.hackint.org/#irc://hackint.org/#subtitles or https://rocket.events.ccc.de/channel/subtitles .
Please don't forget to mark your progress in the progress bar at the talk's website.
Thank you very much for your commitment!




======================================================================






OK, thank you very much for the introduction. I'm Sebastian. I used to be a penetration tester and so on and so on. Now I went back to the to the university and now I'm a professor at the University of Applied Sciences where I teach and I and I do research in information security. I did two formal talks at CCC at this very premise. One was three years ago. Time is on my side and one was two years ago. And both are have a related topic because we're going to look at timing attacks in this talk as well. This talk is based on an academic paper and I've linked it over here. If you just Google it, you will find a link to the presentation of of of the academic paper. If you're interested in that. Obviously, it's joint work. What I'm presenting here. So this is not solely my work that I'm presenting here, but there's like a large amount of people who helped. And basically what I was doing is the timing part of the attack. But we will we will see that later on. OK, so there were lots and lots of as little as spox in the in the last years, so you all probably have heard of of Heartbleed and poodle and crime and beast and so on. So there's like a huge amount of research and breaking SSL research in the last years. It's not a thing of only the last few years, but also like maybe something like 10 years ago or so or more than 10 years ago that we saw other types of attacks. So, for example, the Brenly bunny attack, which was a timing attack against SSL and also oblation bathetic, it's named after Danny Oblation because I think he's from Switzerland. Um, and he found this attack in 1998 against a very early version of of SSL. And what we are going to do today in this talk is we will have a look whether the the attack this the exact same attack, steelworker's, some of the bugs that were discovered, like in the in the past, some of them were protocol level bugs and some of them were implementation level bugs. That's an interesting distinction. So can we fix Abuk just from the impl
ementation side or do we have to fix the protocol? Generally speaking, people refrain from fixing a crypto protocol because it requires a lot of work and it's not compatible to all versions and so on and so on. But generally speaking, when you design a crypto protocol, it will pretty much stay the same or it has to be supported for the upcoming years. And also, depending how you design the the crypto protocol decides how much effort it is to implement the protocol. And not that I'm not speaking about effort in terms of lines, lines of code, but something like how fragile is the protocol to implement. So how careful have to do you have to be at the at the implementation level? And what we are going to see today is some kind of. So we have like in 1995 when SSL was proposed, the SSL version three was proposed. They made some decisions that we now know are vulnerable and they never changed it. So the SSL protocol itself is still a protocol against the Blazin Bahais attack if you don't be very careful in the in the implementation phase. And we're going to look at the implementation. So just a quick primer of how SSL really looks like this is really a very short introduction. There's a new book by Evan Restitch. He's he's explaining very well all the foundations of SSL and how it works and so on. So if you want to take a deep look at SSL, you might want to look at this at this book. I'm just going to present these parts which are relevant for this talk. So what is relevant for this talk is some kind of a hybrid protocol. So it has some symmetric crypto and some symmetric crypto. And generally the symmetric crypto is used for for an ciphering, the actual content. So when we use HTP, for example, the traffic itself will be encrypted with a symmetric cipher, for example, A-S and with a random session key. And this random session key will be exchanged between client and server using asymmetric crypto. Um, so this is like the client since a client or the server since a server
. Hello. He sends a certificate and this certificate contains a public key. So the client receives the public key. Then he randomly, randomly chooses a certain key. It's really just random and encrypted with a public key of the server and sends it over to the server. Now both have the same session key and can talk encrypted when an attacker is able to somehow decipher this session key. Obviously, the the decision is broken because the attacker can then decrypt the whole session and you don't have confidentiality anymore. This session ticket, as I was saying, is called the Prima's a secret or RPM's. And, uh, yeah, as I said, the the client encrypted with a service public key and sends it over to the server. And then the actual session key is the master secret. And this depends on the Prima's a secret, right. So this is the most this is anything that you have to understand in order to to to follow this talk. You don't have to know more on this. OK, the attack that I'm going to present here is old, it's 14 years old, it was developed by Danny Oblation back in 98 and it works like this. You have a client and a server and they do they do a handshake and they exchange the Prima's a secret. Right. So the session Kiffer, if you want, the attacker is a passive man in the middle, which means he just eavesdrops on the on the connection and now has like he has recorded the encrypted handshake. And what he wants to do now is break this like the premise, a secret, the session keep. And he does that solely by requesting but by doing certain requests to the server and measuring response times, for example, or analyzing our records and anything that comes from from the server. So that's our ataca scenario, and that's a very general attack scenario, um, if you look at ataca scenarios, for example, for a crime or a beast, which were former attacks in the last few years, they have a very different a model so that it only works in the context, for example, because the attacker has to fo
rce the victim to perform many encrypted connections of the same channel. Right. So he requires that we don't need this in oblation attack. We just need to record the handshake. And we have to we must be able to issue requests to the server and measure something. Right. And what we what we measure that we're going to see it later on. And this scenario means that our attack is not only applicable to https, but also to pop three S or IMAP s. So anywhere in any context where telexes used or attack can be applied potentially depending on the implementation. Um, now, it's not that we have broken all the ciphers that that are used since that's not the case. So there's like various ways of doing the encryption and doing the handshake and so on and so on. And what we can break with our attack is this list of ciphers. Most of them are still used quite often, at least before like like it changed in the last one or two years since Snowden told us what what the NSA is capable of. So since then, things changed. But before that, those were, I guess, the most used ciphers everywhere. Basically, we can break all the ciphers, but none of the elliptic curve suites because they have a different type of of key exchange and none of the Helgeland suits. So if you're using these and you should use these because they're in generally more secure and also at least it's more it's more performant. OK, um, the RSA encryption algorithm, it's really it's really very elegant, very short. So when you want to encrypt something, you take your message, raise it to the power of E and E, the public key mod. And, um, and when you want to decrypt em, you just take the ciphertext, raise it to the power of D and D is the private key, uh, modulus. And then you get the then you get the message back. One thing that is also very important in order to understand Bahasa tech is that RSA is malleable, um, malleable in German form, umba means that an attacker can make predictable changes to the ciphertext without k
nowing the clear text. So I give you a ciphertext or you give me a ciphertext. Let's put it this way. Then I can make changes to the ciphertext that have predictable effects on the clear text, even thought I don't know the clear text and even thought I don't know the result of my computation that agisted. Right. So you can, for example, do multiplication. So that's an important that's an important thing that we have to keep in mind when we when we go further. Another thing that is a very important I guess the second thing that is very important, we need to use some kind of padding because the, um, the Prima's a secret that we use for asymmetric encryption is very short. We just we just need forty eight bytes. So it's very short. But RSA is some kind of a block cipher. So when we have two thousand forty eight bits are is a kiss, we always have to encrypt two thousand forty two thousand forty eight bits. Right. So um we have a forty, forty eight bits over here, but the whole thing is like 256 bytes. So we need to use some kind of padding. And until the decision was made in 1995 to use a standard, a petting standard that is called Peake's one inversion one dot five. And always when I say Pickus one in this talk, I mean version one, dot five. There's also a version two, which is much more secure, but always when when. So it's like Peake's one in version two. Right. So this is secure. But always when I say Pickus one, I mean Worsham one, dot five. OK, such as that, you know, and the the padding scheme is very, very easy actually. It always has to start with a 0002, at least for the encryption type. So you always have 0002, then you have two hundred and five bytes with non-zero padding. And this, this is supposed to be random. Whatever comes in here should be somehow a little bit random and it must not contain zeros because the the end of the padding will be denoted by, by a terabyte. And right then then comes the Prima's a secret and the Prima's a secret is a forty six b
ytes of of a random string like that's the section key that we use that we use for the symmetric encryption. And this is the part that the attacker wants to, wants to break. This is the important part. The zero three zero one is somehow deterministic. It means in this case that the protocol version was tearless 1.0 at. So very easy, very easy to understand. Now, what does Marcus attack mean? And unfortunately, I do not have enough time to go very deeply into a heart attack, but only from a bird's eye view, it means when when a service is susceptible to a black box attack, it allows splashing. Barhoum, who is in possession of an RC ciphertext, I call it sea, to recover the plain text of it M0 under certain conditions. And the condition for this is that it requires an oracle. So we need to have we call it oblation, the Oracle. And this Oracle does a very specific thing. It decrypts the ciphertext and responds with one or zero or true or false. You can take whatever boolean answer you want, depending on whether the decrypted message starts with 0002 or not. I also remember PKC as one inversion one that five requires that it always starts with a 0002. And when we can construct from this oblation the oracle that tells us exactly this. So true or false, does this ciphertext start with 0002? Then we can decrypt the whole ciphertext just by issuing many requests. Right. So we have to agree with the Oracle many times. And the reason for that is when the Oracle answers with one, the adversary knows something about the, uh, about the range, the possible range of the hours, a clear text, and it will be in this range. And you don't have to understand exactly why this here is the case. The important part is here is a two and here's a three. And we know that when when the Oracle tells us one. Yes. This was PKC US one complaint. It starts with 0002. Then we know that the clear text, which is just an integer RSA works with integers, is larger then something, something with two. So i
t starts with a leading to and it's a smaller then something with a with a with a leading three because otherwise it would be zero zero zero three. That's not the case. So we have to issue many, many Oracle requests. And for each request we learn a little bit more about the clear text. OK, this was the theory part. Now we come to the to the practical part, we have to talk about the strength of the Oracle. In an ideal world, we just want to have an oracle that we can fit any ciphertext in. And it will tell us, yes, it starts with 0002 or not in in reality, this is a bit this is a bit different because I told you PKC has won the format. It starts with zero zero zero two, but it performs some more. So there's non-zero padding. And when there's non-zero padding, you should check whether there is a zero in the non-zero padding because otherwise it would be not a non-zero padding. Right. So we just want to have one oracle that tells us, yes, this starts with 0002. But what happens when we have a zero in here? Then this might fail. Or if this zero byte here is not there, this might fail. Or if this zero three zero one is not there, then it might also fail. So these are all additional checks that a test server might perform in order to find out whether the ciphertext decrypts to has one conferment clear text. That's a problem, and the more checks we have, the worse performs the Oracle because we could have ciphertext that decrypt to a to a plain text that starts with 0002. But because of the additional checks, the Oracle says, no, this was not because it's confirmed. Right. So fewer checks result in stronger oracle and it's better for the attacker and the other way around, the more checks we perform, the worse is the attack, right? OK, so now, 1998, let's go back to 1998, an abortion ban came with his with his famous paper. What did people in the Tiller's consortium say? Well, they said, OK, let's just stick to this one in version one, that five perring for compatibility re
asons, everything is for compatibility reasons. That's a problem, right? That's really a problem. But they made the decision. No, we just stick to the padding. We know that it's vulnerable. But let's just look whether we can find an implementation that is not vulnerable. And this is what they did. They just said we make the requirement for the implementations that PKC as one conferment and nonconformist messages must be treated equally. They must be indistinguishable for the attacker. So that means, for example, we had to unify all our conditions because the, um, in the, uh, in the first blush in Bihar, uh, paper, in the original Blankenbaker paper, he exploited error messages. So the SSL implementations told the attacker specifically, no, this was invalid. All this as well petting, but it worked because of something else. It didn't work. Right. So they prevented this by saying, OK, we just send one error message and the error message just says something went wrong. So we sent over a ciphertext. The server makes this thing and does all the checking. It just says, no, something went wrong. But we don't know which. Right. We don't know whether the wedding was correct or not. But something else could have could have gone wrong. Something like this. Right. So this is what they said, unify all our conditions. We checked for this, so we tried, so we created a lot of test cases, something like fuzzing you might you might call it fuzzing and tried to find out whether we can find Oracle in different test implementations. So this is an example for Java, for example, where we can provoke some error condition, where we can create oblation by Oracle. Right. And this is a very weird oracle in a sense. Right. So it will throw a very specific error. And it's called an internal error. If the clitic starts with 0002 and the clear text contains a zero by proceeded with a non-zero by it and somewhere in in this area here. So it's only valid if it if it happens in this area. So some pro
graming error that happened there. Because of this, we could apply these straight 14 year old attack against this against the server. But we have to talk about the Oracle strength, right. Oracle strength. You remember we have a clear text that starts with 0002. That's the one that we want to have for the attack. But we do additional checks because of these additional checks. The Oracle might still say, no, it's not valid or something like this. And here the Oracle strength really depends on the bit size on like on the key size of the RSA keys. So for 1024 bits, we have only two to PROMETA success rate. That means for, let's say, four for 1000 ciphertext. That all start with zero two. We only have two where it really says, OK, this is a this is a Pickus, one compliant, apexes, one compliant keep. And the interesting thing is the Oracle strength increases with a bit size. So that means when you use four thousand ninety six keys, which is the most secure, this is the worst in our case because the Oracle is very good. So in three of four ciphertext that start with zero zero zero two, the Oracle tells us, yes, the speaker because one compliant. Right, so, um, usually people tell you that for a bit like the bigger the bit, the bit sizes, the bigger the key sizes, the the more secure encryption scheme is. And here it's just the other way around. This is often the case for, um, for sexual attacks. Right. So the attack performance, we couldn't attack in reality, um, 1000 keys because it just has a very low ratio. So the Oracle is very bad. It required us 12 hours for to recover. Prima's a secret of a two thousand forty eight key and only six hours for four thousand ninety six keys. OK, um, so here we just checked for the obvious, so we just took the 1998 paper and created a few test cases, did some fuzzing and tried to find out whether it worked or it didn't. When you look closely at linebacker's paper from 1998, he will tell you that he created his his oracle using error me
ssages. So it just only looked at the error messages and nothing more. And there's a small sentence where he said, in theory, it could be possible to make one of these oracles over a timing subchannel. And this is where we got the motivation to look to to dig a little deeper and look whether we could construct a black oracle just from timing information. We had some experience with timing based attacks because we applied it against a standard called XML encryption. You will find the details in my in the top three years ago. So from 28, 28, C, C three was it. But just in a nutshell, I will explain how this worked. So basically, XML encryption is a standard that allows you to, um, to cut out a part of an of an ex, some lairy encrypted symmetrically, let's say, with A s and a random key. And then you take this random key encrypted with the receiver's public key and put it to the to the same document. And this is what you see here. So down here you have the actual symmetrically encrypted part that you want to hide that where you want to guarantee the confidentiality. And over here you have this random the random session key quotes that is itself encrypted with a public key of the receiver. Right. So we could attack this because all the implementations that we looked at worked as follows, decrypt the session key in the first step. So this is this part return an error if, uh, if M does not comply with Peake's one else, decrypt key data and key data. Is this part down here. So the whole symmetric decryption only happens if the key that was there was used there was this one conferment, which is great because we can measure the timing between. Between these two steps, right? So when we can measure this, then we have one and we can construct a circle from this. The good thing is we can the attacker can influence how long it takes for the of the decryption to finish because he can just put arbitrary garbage down here megabyte wise. So it will take hundreds of milliseconds, eve
n seconds to decrypt. And it just it can be garbage. It doesn't have to, like, be passable at all or something like this because it will be passed later on. We just want the decryption to be happening. And this is where we constructed the the timing, the timing. Erkel right. And here you see just this not only worked over the over local network, but also over the Internet. So we did some measurements over the Internet and that also worked. And so that was just a short shot. Yeah, of course. OK, so we have already experienced timing based attacks blasting the attack was applied against Tlas, so it's somehow natural to go back to Tlas and try with the timing. This thing works against tearless as well. Let's look at the standard, what the people said, how to, um, how to prevent timing attacks against blankenbaker, we take the last standard of tearless in version 1.0 and they said, well, we make the processing of valid records and invalid records indistinguishable. And this is just a snippet of the standard. So they had some kind of some kind of pseudocode where they explain how the PKK has won. Verification is supposed to be happening so that no timing, so no timing can arise. So we generate a random string out of forty eight random bytes. This is a random PMAs that will be generated any time. Then we decrypt the message to recover the plaintext. And if the PKK as one kid padding in the plaintext is not correct, we use our that is the randomly generated string as the Prima's a secret and just continue with with the with the SSL protocol. This has the advantage that it will well server and client now have different keys. So as soon as they start a like talking on on a symmetric level, it will fail. And what will also fail is like the schmick, um, authentication. So there is one part that I haven't explained yet, and that is also not necessary. Just know that it will it will fail later on somewhere in the protocol. It will later fail. And this failure does not correspond
 to whether it's pixelation, confinement or not. So that's a good thing. What they proposed here. This is how it's supposed to work. He is just I want to repeat this one more so we generate a random key, a random RPM's PMAs are, and in case of a Pickus one in Bellizzi proceed with RPM's are in the protocol. The good thing here is the random RPM's will always be generated always independently, whether the the key that was received from the client was because, as one confirmed or not, and provokes an error condition in the later stage. OK, but what about tell one, not one and one, not 1.0. These are older. So right now I have shown you the the newest version of the standard. In the older standards, there was no pseudocode listed. It was just this sentence that was in here. So the best way to avoid vulnerability to this attack is to treat incorrectly formatted messages in a manner indistinguishable from correctly formatted RSA blocks. This this we all understood, right? So there must not be any difference between a PKC as one conferment, a cipher text and pixels, one conforming ciphertext. And then they said Afar's. When it receives an incorrectly formatted RSA block, a server should generate a random forty eight byte value and proceed using it. And there's a difference. Do you see the difference? Exactly. So only when it receives and incorrectly formatted RSA block, a server should generate a random forty eight byte value and proceed using it. So the forty eight random bytes will only be received if the key that was coming in is not PKC one conforming. So that's interesting. What does it mean, right? So we have a differently we decrypt the ciphertext, we do all these PCAs one heading checks, and if they fail, we generate a random prima's a secret and proceed with a random prima's a secret. And if it's not the case, if it is because one informant, then we just proceed with this particular RPM's. This has one advantage that is that makes it clear for me why they chose t
his approach and the former standard. It's much more efficient or maybe not much more efficient, but more efficient. So when it comes to tearless performance, it's very important. And when all of a sudden for each and every incoming tearless handshake, you have to get a forty eight byte random string. This will take some time depending on the hardware and so on and so on. But this might be in the milliseconds area, right. Can be a few microseconds, can be a few milliseconds. And this, this obviously if they informa versions of the standards they thought, no, it's not worth it. Right. So nobody can construct a timing from this. And we checked. All right, let's do some timing measurements, how to perform timing, Charles itself is the talk is a whole talk is right. And I always keep saying this. I thought I should do an on talk. The good thing is I did an on talk for this. Right. So you can just look at the video recordings from 2083 there. Explain how to do timing measurements with a normal computer over a network. And how do you cancel out the jitter and how can you deal with statistics and so on and so on. How can you not prevent timing trends? Right. That's the the talk that came that came later. If you're interested in that, you can have a look at this as well. The first thing that we did is we used a testing framework, it's called time. I don't know what the abbreviation really, really means, but it's credit to Christopher Meyer. He did this in his PhD thesis. And it's basically a framework for fuzzing tearless implementations so you can generate various requests and and do testing. So it's very easy and convenient to do testing for tearless. The problem is it's written in Java. That's really a problem, right? And I mean, I was expecting some trouble when it's written in Java, but I am so basically I didn't know that it's that difficult to the timing measurements in in Java. And so we had to do a different approach. And here is just I try to condense all the thin
gs that I've learned in between, like in the years of doing timing attacks over networks. What should you do in when you want to do timing attacks? Right. So no memory menaged programing languages, no Java, no personal perl, no. You name it. Just you see, just use a sampler where you have a single threat. That's exactly what you want. And and so on and so on. And there you have already some you might have some issues there as well. Right. But you have these memory managed programing languages as well. Choose your part of the network wisely. So there's really no there's really no use of doing it over wi fi or your 3G modem or whatever. Just go as near as you can to the target that you want to attack. When your attack is somewhere buried in a in a data center. You might want to rent hardware in the same data center, for example, write short paths, Thoroughgood, disable the power management on your on your measurement machine. So when you use Linux as a measuring platform, you should, like, disable, for example, until speed step and there's some equivalent from AMP. It goes under a different name, but it has the same effect there. You can use the CPU, Freck utils, its user, and so you can just install them and set your CPU to a fixed frequency. And there's also something which are called spacy states or sleep states. Um, they will just like Puti or certain, they will put certain Kooris to sleep and in order for them to wake up, this takes some some time. And it's Jeta to your measurements so you can just disable this with a kernel put parameter on Linux. What I haven't put on this list is you can also fix a process to a certain core so you can disable certain course, um, and so that it only that your measurement script only runs on this particular core. You should do this as well. Um, don't use fancy server hardware because they do something that is called interop coalescing and interrupt coalescing means um or in the old days when one packet arrived at your, at your, 
at your network card, it sent an interrupt to your kernel for each and every packet. And you want exactly this. The modern hardware and not only the server hardware but also in laptops, it's building and so on and so on. And there's something called intellectualizing. So whenever a packet comes in, um, the hardware will still wait for, for some microseconds. That's configurable. Whether other packets are also coming in so that it only sends one interrupt for many packets and you don't want this. So you use very old and cheap network interfaces. And we did this stop all tasks and demands on your local machine. No, your idea should be self-explanatory. And what you also want to do, you want to do so with timing measurements. You have to repeat the same measurements over and over again in order to do statistics on it, in order to filter out the the noise. And you want to skip the first few hundred measurements because usually you have some some caches warming up. So you want to skip these. OK, start and end point for measurements is also something that that can be quite, quite interesting. So, for example, when the request that you're sending is very big, you don't want to press the timer. Right. And and then start sending, sending, sending, sending, sending and then waiting, waiting, waiting. And then come the first packets, come in off the response and then you then you set the timer down here. You don't want to do this. What you what you can do if if you have the possibility is you sent all the bytes of the request that you want to measure. You send all the bytes, but not the last one. So and minus one, if the messages and bytes big is sent and minus one, then you start the timer, then you start ascent, the last part of the request, then you wait for the receiver of the end of the response could be the first byte or something else. And then you stop the time and then you receive the rest of the of it. OK, this is our measurements set up, and basically it's our time 
frame work just showed in in a in a in a different angle and the timing critical part is somewhere somewhere over here. And I told you, it's like time is written in Java, which is very convenient for for programing, but not very good for timing measurements. And so we decided to just cut out the critical the timing critical part and and and build a module that is written in C and assembly. Um, so I didn't want to write a full blown tearless client in C, so I looked around what was there and then I looked at the SSL right for maybe an hour or two. Then I closed the editor and went for a walk. Right. The reason the reason for that is it's really, um, um, yeah, it's I mean, Krypto is difficult, right? And you see that Krypto is very difficult when you look at the at the code of SSL for SSL, um, uh, the API is very, um, it's very hard to understand. Right. And obviously there's no API for doing a timing attack on tearless in SSL. Right. So I wanted to reuse a part of an offer of another client and I found this with a very tiny embedded SSL implementation called Matrix SSL, um, have it written here. And we just patched this. So it's called the Code of Matrix SSL stippled. It's very small. And the good thing is there's no weird API thingy happening there. You just have to send and receive, for example. So you're doing operations really on the socket level, which is exactly what we want, very clean code base or maybe not very clean, but it's a clean code base, no complex API wrappers, and they even come with a client and a server just as an example. Right. So they bring their ship with examples. And we just patched the client so that it does whatever you want. And what we want is we want this client to do a handshake with a prima's a secret that we send him. Right. And so it was just we just created this command line tool that just idealize handshake with a basically four encoded pimsleur, which is generated. And it will it will just it takes the PMS and then you have just
 a lock here and then you grep over the lock and just get all the timings that you want. So you see, it's very inefficient. But what we called it here, but it's just research. Right. So we just so we called for each and every measurement that we did. We called a new process from Java land to the sea land here and there. Right. So it's so all the numbers that I'm showing to you, obviously not very not very good. You could probably make them faster by a factor of two, I guess, but still come on its research. Right. So how did I do? So this is really this is really a code that I pitched in there. You have some wire loop where it gets some data that it wants to send over to the, uh, over to the server. And here you have your sentence's call. And after that, we just, um, we we measure the skeptics. If you're interested in the details here, just look look, my my talk from three years ago. And then we get like the, um, the statistics like how many clock cycles were have passed until this until the CPU was initialized at this point, as is now in start. And here we have the end here we have just received threats. It's very easy. Just basic circuit programing. Very nice. And, uh, down here, we get the end now we have like the start takes and the antics, which are substract them and then we get the amount of takes that passed. Um, um, uh, and that it took for for the server to just to do its thing. So that was, uh, pretty much to set up, uh. Now let's look at the code. Let's look at SSL. OK, this is a real source code of SSL, I think it's half a year ago or so in 1.0 dot one dot e or I, um, and everything that is relevant for oblation Barcus attack happens within, let's say, 50 lines of code or so. So here this line is important because there we decrypt whatever came from the from, from the client. So the client since the encrypted RPM's, this will be a decrypted over here and we have some status here that is passed as E! Um, and this will be used over here. And then we just c
heck in this particular if statement here, whether some some decryption failure happened and if this decryption failure happened, what do we do? We get some Suddaby success. We got some random bytes. We generate a random prima's a secret and, uh, generate the Masaaki. So this is really the old way of preventing the attack. So if and only if, uh, the Prima's a secret that came in was not this one, confirm it. Then we then we generate a random key and continue with that. So how does this look like when we look at the measurements? We found that it's this generation of 40 of forty eight bits of random data is one and a half microseconds. This obviously depends on the on on the platform that is used and so on and so on. But one and a half microseconds, this is something that we can measure in a local network. And this is what we did. The problem that we found was open SSL did something very good, you don't hear this very often, but this is a presentation where we say they did something very good because they did a very strict pickiest one checking. So they not only check for does it start with 0002, they also checked out some non-zero petting, not contain any zero bites and it's to zero bite on the on on the ride space and so on and so on and so on. So they did everything right. And this led to the fact that the Oracle strength itself is very weak. That means even if we send a ciphertext, the decrypts to a plane takes starting with 0002, we still have a very low probability that the Oracle will tell us it's a valid it's because it's one relet, so therefore we couldn't attack optimizes. All right. So we didn't even try we just did the math and said that it will be a successful attack, will require us four times 10 to the power of 12 requests. And this is not not practical anymore. This is not something where I would sleep very well. Right. So this should be fixed and it is fixed in the meantime. But still, it's not something practical that we could do in our lab. Let's l
ook at the third channel, and this time again, we look at the Java implementation of of Tlas. So these were the same guys that had this like the different error message, right? 20 slides ago or so. And when you look at this so we have some master secret here and we want to generate the master secret so we get some information and try to generate the master circuit over here. And what you see here is there's a lot of, um, a lot of exception handling. Right. So what they did here is actually textbook Java implementation. This is how I teach programing beginners how to do how to do object oriented according. Right. The problem is this is not a really good idea to do this in a timing. Critical sense. Right. So it basically means you don't see this at the court here, only show this to to to show you that there's a lot of exception, handling and catching and throwing you acceptance and so on and so on. It led to the fact that we could exploit this so that we could execute a timing based attack against JSC. The Oracle strength was very strong, so they do very few checks. So when you send over a ciphertext and a decrypts to a plaintext, starting with 0002, we have a 60 percent chance that the Oracle will tell us, yes, this is a Pyxis one, confirm it. And it means that we could like break one single tearless handshake within just about 18000 requests and 20 hours, which is pretty good. Um, the fourth channel and maybe the most critical channel was, uh, when we looked at some hardware accelerators, um, concretely at those from the from the company cavium. So whenever you buy a big appliance for big money, that does the SSL termination for you. So let's assume you have a lot of requests that you have to process and you have a lot of application servers and a load balancer. Then usually the the servers behind the load balancer, they don't terminate. It makes some box before that does it. And if you buy such a box, uh, it is often it often contains a hardware acceleration for fo
ur tiles or at least for the underlying crypto primitives such as A-S and RSA and things like that, so that the process, the expensive part of the crypto operations is performed on separate hardware. This comes in various flavors for servers. You can you can also buy this and plug it in by a PCI. Then you need a driver and so on and so on. So, yeah, and it's then relevant when you have like a big installation and you have to deal with many thousands of incoming tearless handshakes and connections and so on and so on, then you need an appliance like this. So we analyze this as well. And concretely, we looked at the products of five big IP owned and IBM data power, so we didn't have the actual card. We just use products or measured against products that have these cards installed. And this is very interesting, a very interesting behavior, what we found here. So, for example, it doesn't verify whether the clear text begins with 0002. It just verifies that it starts with something zero two, which is weird. Um, but one possible explanation. I mean, we have talked to the developers, but we have we didn't ask them about this, but I guess it's, again, something performance so that they didn't care about the first part. They only care about the second. But this brings this brought us a little trouble because the linebacker's algorithm, the textbook algorithm requires that something starts with 0002. So we had to adapt this algorithm so that it also works with something or 02, which makes the Oracle somewhat weaker. But we could still apply the attack and we required four million queries. Which is which is which is a lot. But it took 41 hours to decipher tearless handshake of one like one single handshake. OK, let's just make a summary, so the first thing that this is not something new, but not many people have achieved this so far. Timing attacks against single digit microsecond delays in TCP connections are practical. So there are other papers who did this against details. 
For example, that is a diagram based ServiceSource, like Euterpe, for example, you send something and something comes back. It's a bit more involved and you want to do the same over over TCAP connections. But we found that it still works, which is good. A bad design and I should have quotes here in bad design, a cryptographic protocols might haunt you for decades to come. Um, when in 1995, they make the decision that RSA and PKC is one in version one, DOT five is a good idea. They brought a lot of trouble. They didn't know that this can be exploited that easily. During that time. They had to wait until 1998 and until all this. But the problem is we have been living with a protocol that is known to be broken for 14 years. And now I hope it makes sense when you when you remember the thing that I said on one of my first slides where I said protocol decisions like it can be very fragile. Right. So everything that you have seen here, like the implementation of tools in this specific part, it's very, very fragile. And you have to be very, very careful to do exactly the right thing. And then also what is taunting us is Makinen and encrypt. So obviously it's not possible and it's protocol to just send them random ciphertext over there and expect the server to do something useful with it. But also, you have a thing that guarantees your authenticity. So you have a message authentication code, and this is where where it will fail any time. But the problem here is, um, you have Mac then encrypt. That means the message authentication code is a pendant to the clear text and then encrypt it. Which I'm sorry, which. Yeah, so yes, sir, thank you very much. So the problem here, obviously, is in order to check the message authentication code, you have to decrypt the ciphertext beforehand. So there's a lot of code running before you can actually check whether this is a valid message. Right. So this is about what you want to do is encrypt then Mac. So you'll make like your encrypted cle
ar text. You have a cipher text and then you do your message translocation code on this. And then the authentication code is appended to the to the cipher text and sent over to to the receiver. Yeah, implementing classes is a minefield, and this may explain why everyone keeps complaining on the quality of of SSL, for example. Right. So, um, look at the Java code looks much better. This is really nicely object oriented and everything, but can also be broken. And it's broken in more ways, I think, than than ourselves. OK, guys, thank you very much. I'll be around at, uh, until the 30th. So if you if you want to talk to me, just just do it. I'm happy. Thank you very much. Thank you very much. Now, it's a little bit time for questions, I know that there's a one question on the Internet and there were discussion of this question for some time now. So even if they managed to answer it, maybe it's interesting for everybody else. So I think we should start with this. Yes, there was some discussion going on about, uh, how hard is it to prevent this kind of attack? And, um. Is it possible to do some random slip in the code to prevent the attacks? OK, so the question was, is it is it possible to fix it with just a random delay? Right. No, that's really a bad idea. I've spoken this at length at my 2093 talk so you can can have a look at that. The reason for that is you will decrease the performance and the attack will still be possible. So this is not not a good idea. You should just fix it in a code. It's possible. And at least for open source code, you have you have like the source code. So there are some more questions, and I ask everybody who's leaving to be a little bit more silent so that the people who want to get the answers can hear them. Thank you. I specifically am interested in hearing about how to mitigate these problems in the future. You were referring to sort of the the guys who worked on standardization. They did make some mistake. But on the other hand, the wo
rk is taking place in an open forum. So there's a possibility for people to engage and that would obviously help. But what are other ways to deal with those issues in the future? So the problem is really so Tlas was in 1995, SML encryption that exactly the same arose in in someone in the 2000s when it was long known that this is vulnerable. There's a new thing that is called Jason Vep Encryption Jocie. They did the same errors over and over again. So we just see the same errors in protocol design over and over again. And they always argue that you need to you need to support these broken ciphers for compatibility reasons. So they have like the they have the problem. If they don't support the broken ciphers, nobody will use the standard. That's the problem. Which is a pity. Sorry, the last question, when they are in your presentation, you talked a lot about PKC is 105. Did you have a look at the signature scheme as well? And can you tell us if this is somehow affected by this problem as well? Like the signature theme that is is one inversion, one that five. I don't think this is part of one point five. The question is if the piece a signature scheme has has a similar problem. Um, not not that I know of. Of.