 So I'm David Wong but I'm going to skip the boring part and start right away. So I'll start with the timeline and I have a date here, it's 2007 but that's an arbitrary date and the point here is that back then nobody really used SSL or used correctly SSL. Especially before SSL was created but even after it was created in the 90s people would still use it incorrectly. And one of the first case I could find of public display of that point was in 2007 when Seal Graham gave a talk at Black Hat and showed how SSL was misused in websites. So most of the time websites use SSL to protect the login page and after they revert back to unsecure HTTP and that's bad because you can practically steal the session ID after. And I have a very short video of what happened on stage. So basically mine in the middle, everyone in the room and then you use one of the cookies sold to connect on the Gmail of that person. So I just thought it was funny, it's a very short video, doesn't really have a point but basically it's one of the first time it was shown to hackers or tech people that you could do that kind of thing and that SSL was important. And two years after there's this Moxie guy who is playing with SSL and trying to break it and he releases his tool SSL strip at Black Hat. And what SSL strip does is that basically even if you use SSL correctly, the very first connection you make to a website is usually unsecure. So for example, if you connect on Facebook.com, what you do is that you type Facebook.com in your browser and you never type HTTPS before that, right? So the first connection is made unsecurely and then Facebook.com in the example will reply with hey man, can you actually use my HTTPS website and that would be cool. And so your browser redirects you to the secure version of Facebook and then you're good. And if you're man in the middle of a victim, someone, you can basically remove that message, that redirection and successfully man in the middle of the entire website. And so that was pretty bad for SSL, right? It kind of breaks SSL. And so Firefox came up with the solution a year after and it's called HSTS. And what HSTS basically is, it's a header. And so imagine you're connecting to Facebook.com, same thing. You have this unsecure connection. And this time Facebook.com will tell you hey man, can you remember to connect to the HTTPS version of the website next time? And your browser will remember that and it will add Facebook.com to a list and next time it will directly go in the secure version of the website. It's also the year of Fireship. If you don't know Fireship, it was a plugin for Firefox that you could use, you could just install it, it was very simple. And you could go to the nearest Starbucks and sell credentials. And it was so efficient that I think it's one of the first moments where the layman, the normal people started understanding the importance of SSL and HTTPS. And this thing made the news and everybody started freaking out. Only three years after Facebook goes full HTTPS. I trust Facebook because everybody knows our, back then it was one of the biggest websites. So it kind of blows my mind that only three years ago, one of the biggest websites went full HTTPS. And it's also the year of Snowden. So we learn about Prism and we learn about TNSA spying on us and everybody started freaking out and we understand, everybody started understanding this HTTPS and what does it mean. This last point doesn't really have, it's not really important but I still want to talk about it. Whenever you use HSTS to counter this SSL strip attack, there is still one point of failure and that is the very first connection you make. So the very first connection you make to Facebook when Facebook will tell you, hey, remember me next time? Go directly to the HTTPS version. Well that very first connection is unsecure, right? And if you can break that, then you break HSTS as well. And so the solution came in 2010 from Chrome and it's called preloaded HSTS and you can basically guess what it is, right? It's a list that comes in your browser and your browser knows that if you ever connect to these websites, you have to use HTTPS. In 2010, you had to manually email Adam Langley and it was kind of not perfect. Two years ago, they released a form that you can use online and you can upload your, you can submit your websites and the next version of Chrome will ship with your website as the preloaded HSTS. So the point of that timeline or the point I'm trying to make is that back then it was very easy to spying people. You could just man in the middle people or be on the internet and you could just read what was happening and nowadays it's becoming hard, harder and harder, especially because of Snowden, etc. And I'm not even talking about mail encryption or end to end messaging, end to end encryption, which is also becoming more and more secure. Two more slides to prove my points that it's becoming harder and harder. Modelize is thinking about deprecating HTTPS all together and so in the future when you will visit an HTTP website, you will see something that tells you that it's not secure. And I cannot also talk about all of this without mentioning Let's Encrypt, which is a new, as of today, a root certificate, but it has been operating since last year, December of last year, I think, and has at the time of that screenshot, which was a few months ago, signed certificates, issued certificates for more than 7 million domains. So the issue certificates were free and it's very easy. You just have to install that client on your server and it will do all the hard work for you. So yeah, easy to spying people back then and hard. The next story is the story of Logjam. Logjam was a paper released last year and has a bunch of authors, which is pretty rare, but many authors. And there are a lot of things to say and one of the things they wanted to say was that if you have a website, you usually use a HTTP server to provide your websites and Apache is one of them. And you can use that. There is a mod in Apache that allows you to use SSL or TLS. And if you use that to protect your connection for your users and you use D-Filament to do a key-end check in this TLS thing, usually you will use D-Filament ephemeral because all implementations, actually I don't know any implementations that use plain D-Filament and all implementations use ephemeral D-Filament. And ephemeral D-Filament is just using D-Filament with fresh keys for every different users. So if you're a server, if you're websites and you have many users connecting to your websites, you will generate a different key to do a key exchange with every user. So the point here is that the point of Logjam is that everyone would use the same parameters to generate those fresh keys. And you don't have to remember D-Filament. I'll re-explain after how it works and where are those hard-coded parameters important. But those hard-coded parameters that everyone was using were weak and that was the problem. Another point that the paper made was that even 1024, so D-Filament 1024, was the first thought to be unsecure against the NSA or state-sized adversaries. And so we liked 1024 and now we're trying to move away from 1024. It's in particular with papers like Logjam that tells us that it's not as secure as we thought. But the point here or my opinion here is that it's too much work. If you're the NSA and you want to break those 1024 bits integer that are in D-Filament 1024, you have to do a lot of pre-computation and it's actually not that easy. And then if you change that number in D-Filament then you have to redo all the computation. And to prove that the NSA is very lazy and that they don't really want to do computations on numbers too much. Now let me talk about the U.S. export rules. So if you're familiar with that, that was a set of rules of laws that we had. They still exist today but they're way more relaxed. And basically back then if you had a product and you wanted to sell it to foreign countries, export it abroad, you had to weaken your cryptography. For SSL that means that you had to use these weak cipher suits that we called export cipher suits. And for example in D-Filament you would use these 512 bit primes which is a very small number. So D-Filament 512. And for symmetric cryptography you would use 40 bit keys for DS for example. And so nowadays we don't really have to do that besides a list of black listed countries. But it's still biting us in the ass. If you look at all the last attacks on TLS, all the major attacks like Freak and Logjam, they all pretty much done great attacks. So the implementations still have those weak algorithms in them. And you're using SSL but with secure parameters. And someone in the middle puts you back into these weak cipher suits. And so the NSA really liked at that time that they had to crack those 40 bit keys on DS for example. And they really didn't want to do more than that. For example Lotus Notes. Anyone use that software before? A few people. A few old people. So Lotus Notes made a deal with the US governments. The US government allowed them to use 64 bit crypto for encrypting stuff with DS. And only if they would give 24 bits of these keys to the NSA. And they would encrypt 24 bits of these keys that they would use to the NSA's public key. And for the story that key was called Big Brother. But basically they were using that public key so that only the NSA could decrypt this information and use it. And that kind of back door actually has a name. It's called a kleptographic back door. So you use some asymmetric crypto to send some information to the right person. And kleptography works well as long as your crypto system is a black box. If you don't know what's happening underneath the program then you cannot really see that back door. But if your system is a white box system or if you can reverse and generate, you're in trouble. It's pretty obvious, this kind of back doors. And it doesn't work very well because we're getting more and more, we're using more and more open source libraries, right? So you cannot really hide this kleptographic back doors in there. So we've seen that the weak crypto thing that the NSA, the US government tried doesn't really work anymore. Especially if you look at the list of supercomputers, China is the best right now. So the US might not be the only one being able to use those back doors. Kleptographic back doors, they don't work so much either because they're too obvious and we're using more and more open source. So the NSA came up with a different scheme to try and spice things up. They invented this algorithm called dual AC. And if you were in the previous talk at the crypto village, you heard a bit about that. And dual AC is a PRNG. It's a random number generator. Yeah. Someone ask a question? Oh. Dual AC is a PRNG. So you use it to generate random numbers. And this PRNG was standardized in that NIST document in 2007. It was 137 pages document. And dual AC was one out of four PRNGs being standardized. And the same year, we discovered that two guys from Microsoft discovered that there might be a back door inside this PRNG. We got the proof of that a few years after when Snowden, the Snowden documents got leaked. And we discovered that the NSA was running a program called Bull Run, which aims to back door products to spy on people. And for the story, the UK has the same kind of program called Edge Hill. And we discovered as well that the NSA paid RSA $10 million so that they would implement this dual AC back door PRNG into their B-safe products. Juniper, so it released a security bulletin last year in December around Christmas. And they say that two vulnerabilities were found. But they didn't say where or what kind of vulnerabilities. But it was around Christmas. So every researcher was home, bored and in two days it was reversed and we knew where the vulnerabilities were. And one was boring. I'll talk about the other one. The other one is interesting because you could spot it just by using that strings tool, just by analyzing the strings of the binaries. And so if you looked, I don't know if you can see, but if you look at the patched binaries and the vulnerable binaries, you can see that only one hex string was changed. And I was actually a point on a curve, which was a curve used in dual AC. And we found out that what was changed here was the owner of the back door, or rather, by changing that point, the back door changed of hands, basically. The point I try to make here is that dual AC is obvious. If you look at the construction of dual AC, it uses curves and it uses a very well-known property of curves. And basically if you know how the points that are used in dual AC are generated, then you have access to a back door. And if you look at it, it's obvious. So with crypto, it doesn't work, right? Because of, we're not the only super power being able to compute those big numbers. Cryptography doesn't work, it's too obvious. And these new back door algorithms like dual AC, well, it's too obvious. And we saw that when they tried that. It was a nice try, but on the same year we realized that there was a back door. So it didn't last a very long time. So something interesting happened January of this year. SoCats, which is a tool like, like, um, that cat, but much more. You can, um, and, and they released their security advisory of their own. And one thing was really strange in there. So apparently, they were using OpenSSL to secure the data, uh, to encrypt data. And OpenSSL was using D-Failman, this ephemeral version of D-Failman, right? And to generate those fresh keys, they were using hard coded parameters. So like every library is like Apache and et cetera. Of course you could generate your own parameters, but nobody really does that. And in those parameters, there is a number that is supposed to be a prime. And we'll see what number it is. But that prime was actually not really a prime. And they say basically that, uh, the existence of a trap door, blah, blah, blah. So they think there is a back door. I'm like, hmm. A back door in D-Failman? That's, that's interesting. That's interesting because everyone trusts D-Failman. That's the first public key crypto algorithm invented in the 70s. We've used that in, uh, in the past and nowadays. Everyone trusts it. Uh, most of the inventors of D-Failman are actual life. So that's, that's a good thing. If we can backdoor that, then it's better than, than you already see, right? Logjam told us that, uh, people use the same hard coded parameters when they use D-Failman. And so that's good. If we can backdoor them, we can backdoor a lot of, uh, implementations or a lot of, um, a lot of people. And the other good thing is that Logjam scared us from these, uh, 10, 24 bits, um, parameters. And now people are moving away from this and trying to migrate to 2048 bits, uh, D-Failman. And so that's like the perfect excuse to submit a patch and say, hey, look at my bigger number, it's more secure. Accept it. And then your back door is in place. Uh, yeah. So what I said. All right, so now I'll recap D-Failman. Imagine that Alice and Bob wants to encrypt some data between them. Uh, first they will usually do a key exchange so that they, they have this shared secret that they can use in AES, for example. So to do a key exchange with D-Failman, Alice will generate a number A. And then she will use two other numbers, G and N. And those are the hard-coded parameters that in TLS the server sends to the client. And the client has to accept them. And so when I was talking about Apache and everyone was using the same parameters, I was talking about this G and this N. And so basically Alice takes this G, the generator, raises it to the power A, her private key, takes that number mod N and that's her public key and she sends that to Bob. And in the context of TLS that would be, Alice would be the server and Bob would have to accept those parameters and Bob would be the client. So here Bob's do the, the same thing. He generates a number B and that's his private key, raise that public generator to the power B mod N and he sends that to Alice. He's public key. So far so good. And now Alice and Bob have enough information to compute the shared secrets. I'll just do that for Bob. But Bob can take Alice's public key, raise that to the power of his private key mod N and that's the shared secret. G raised to the power AB. So now that we've recapped D-Filament, let me explain a bit of group theory and I'm not sure of the level of everyone here. If you already know that then that's a good recap before we see the attack. If you don't know that then focus and it's not, it's not gonna be too hard. So I said that to use D-Filament you have to use parameters, right? And here the hard credit parameters are G and N. And G is called the generator for a good reason. It's because it generates all the possible public keys in a group. So if you take the generator and you raise it to the different powers you actually generates all the public keys, all the possible public keys in the group, okay? And in our example of Alice generating a private key A and having a public key, for example, if Alice generates a private key 4, here G to the 4 mod N would be her public key. But we don't have an infinite number of public keys. We have actually a bond on the number of public keys which is phi of N, which is a function of N. And we also call that Euler's torsion function, but it doesn't really matter here. And basically this function of N tells us how many, how many public keys we have in a group. How many possible public keys we have in a group. And so if you raise G to the power of phi of N, this function, you go back to the first elements. And then if you continue raising this number, you go back to G, G square. And basically you reiterate through all the possible public keys one more time until you reach the N and then it's a loop. So I talked about that phi of N, which is the number of possible public keys in your group. That phi of N is actually very easy to compute if your modulus is a prime. So it should be a prime in deferment, but we saw that in Socat it wasn't a prime, okay? But if it is a prime, you just subtract one to that number and it gives you the number of possible public keys. Very easy. Now imagine something else. Imagine that the modulus N is the multiplication of two primes, P and Q. So you might recognize RSA, right? Then it's a bit more complicated and if you don't know P and Q, then you don't really know how to compute this number of possible public keys. And that's actually how RSA works, right? So in RSA, nobody knows P and Q and so nobody can compute the number of possible public keys and nobody can reverse the RSA problem. So that's one important information. Let's go to the second and last important information to understand the attacks. So imagine that you have your generator G. It generates all the possible public keys, right? Until the last public key. But now imagine that you want to create another group and for that other group you take G square. And you say that G square is your new generator. So you take G square, you raise it to the power 2, then you raise it to the power 3, etc. And what you do is that you actually skip elements, right? There are some elements you're not going to have. And that is actually called a subgroup. And this is a very simplified explanation but it doesn't happen all the time. But sometimes you pick a random public key and you use it as a generator and it will generate a smaller group, a subgroup. And we have a method to obtain all the possible subgroups in a deferment group. And imagine the modulus is a prime P in a deferment. So I said that to compute the number of possible public keys you just subtract one to that number. So P minus one is the number of possible public keys. And now if you factor that number into P1 times P2, etc. It tells you what possible subgroups you have. So here you have a subgroup of size P1, maybe. You have another subgroup of size P2, etc. Okay, that's enough, uh, group theory. And now let's see how we want to attack deferment. So imagine that we have a public key. This is public key here. And we want to find what? We want to find A, right? We want to find RSS private key. And that's actually called the discrete logarithm problem, by the way. And one way of finding that private key out of that public key is to take the generator G and raise it to all the different powers and check if it's equal to RSS public key. That's a very naive way of doing it. It's called the trial multiplication. And it's of course not efficient at all. Uh, other better ways of doing it, if you're, uh, if you look at all the past records of, uh, the computing private keys out of public keys in large parameters, index calculus are the best kind of attacks we know, like a special number field sieve or the general number field sieve. Uh, the best attack was done this year in June, June 2016. And in a modulus of size 768 bits. So it's far from what we want to use. We, nowadays, we want to use D-flamen 2048. So doesn't work that much. We have better algorithms than that. We have algorithm that works well if the number of possible public keys your, your generator is generating is small. So imagine you, you choose another generator and it doesn't generate a lot of public keys. Then you can use this kind of attacks. Uh, shanks, baby step, giant step, polar row and kangaroo. And here we'll use polar row because it doesn't take a lot of memory and, and we have enough information to use it. Clever attacks exist. If you look at, uh, active attacks, you have the small subgroup attacks. And I don't really like this one because you have to send many, to do many TLS handshake with a server to steal his key. And usually the server will generate new keys every time. So because you use a thermal D-flamen. And so it doesn't work that well. Rather we can use polygelman which is a passive attack. You just have to look at one key exchange between Alice and Bob or a client and a server. And you can compute, uh, someone's private key and so you can compute the shared secret. Uh, let me, let me explain in details how polygelman works but that's what we're going to use. So remember we have this public key and we want to find that private key. And so we observed Alice's public key during this key exchange, right? And we could theoretically, uh, attack either Bob's or Alice's public key and then we would get the shared secrets but we could also attack both and see which one come up first. But here it doesn't matter. So we have Alice's public key and what we do is that we raise it to the power of something. And I won't go too much into the details. And once you raise that public key, uh, power of something it will, um, it will place that public key in a smaller subgroup. So remember when I was talking about subgroups I said that we have groups of smaller sizes. And when we place that public key in a group of smaller size we can do these new attacks like Polaro because there aren't, there aren't so many possible public keys. But what we get out of this attack is only a partial private key. We only obtain one information on the private key. But when, once we do that enough in enough subgroups we obtain enough partial private keys and we can stitch them together to form the real private key. And we usually stitch them together using the Chinese remainder theorem which we call CRT. Uh, but again, I won't go too much into the details here. So let's try to use Polygelman to do, to place a backdoor in a group, you know, Defelman group. So imagine that we have control over the modulus, that number P, and it's a prime, right? And we want to create many subgroups so that we can do the attack. So we create P prime such, such that P minus one which is the number of possible public keys can be factored into small subgroups, small factors. And here we're trying to find X, the private key, uh, from a public key Y. And so what we do is that we place that public key in all the different subgroups with our technique. We obtain a lot of partial private keys and then we stitch them together with the Chinese remainder theorem. Uh, it's a bit of, to be complicated the diagram doesn't really make any sense if you look at it too fast. But the point is that you can do Polygelman here because you have many subgroups. And the many subgroups are the factors of, uh, this number of possible public keys. The bad thing here is that if your subgroups are small enough that you can do the Polygelman attack, then they're small enough that anyone can factor P minus one and find the subgroups. And that means that anyone can use the backdoor. And it's not a no one but us backdoor. So what we want to do here is to hide all the factors of the number of possible public keys. And you, if you remember I said that if the prime, if that modulus P is not a prime, then we can hide the number of possible public keys. Right? Exactly like RSA. And if you hide that number of possible public keys, then no one can access the factors of that number, which are the small subgroups. And so only you can use the backdoor to compute Polygelman on those, on those subgroups. And here, uh, same thing, the diagram is a bit, uh, dense. But basically we hide, uh, the first line is the most important. We hide all the subgroups inside the factorization of a non-prime number. So this is basically how the nobody, uh, no one but us backdoor works. And I try to use Socat to implement it because, well, Socat is the perfect tool to test those things. And this is basically the, the code that Socat use. It's a copy and paste from, um, some page on internet. Everybody use the same code. And I just replace the modulus with my modulus. In a real situation, I would try to replace it with a larger modulus to tell the people that my number is bigger, so it's more secure. And they don't see that. And since nobody knows it has to be a prime, then it would, it would most likely pass. I have a demo. It's a very quick demo, but still a demo. On the left side you have the man in the middle. On the right side you have a client on a server using Socat to chat. And basically the, the man in the middle will detect the backdoor parameters and then will compute the private key out of one, uh, out of the client or the server's public key. And then we'll have the short secret to decrypt everything on the wire. So, yeah, it's very fast. So they both connect. Backdoor detected here. I derive all the keys. And here when they say something you can, I don't know if you can see that, but you can see everything in the clear. So I could have tampered with the message as well, but here I'm just observing the message, uh, messages passively. But it's a very efficient backdoor. And the only thing that blocks is that if they ever check if it's a prime. But if, if your patch is passed, then it's a win. The code is on GitHub. If you want to look at it, play with it. And I'll have one last slide on how to detect and protect against, uh, that kind of backdoors. I'll wait for pictures. All right. So how do you detect and protect against these kind of backdoors? Well, if you check if the server is sending you, uh, modulus that is prime, then you prevent this kind of no one but us backdoors. But you don't really prevent the other kind of backdoors that everybody can use. So to be sure, you have to detect if those primes are safe primes. And basically what safe primes are, uh, they are specific kind of primes that maximize the, that minimize the number of subgroups, but maximize the size of your subgroup. So that you cannot use these kind of attacks. Uh, actually no browsers check for that. So if you browse the web, you will actually never detect that kind of backdoors. Uh, I actually did browse the web myself. Well, parse the, uh, the internets to detect that kind of, uh, websites that would use composite modulus. I found like a dozen of them, but not really targets except one which was a French government testing page. So I don't know what they're playing with. But the problem of defilament in browsers is, uh, is more complicated than that. And if you look at Google Chrome, uh, they're completely deprecating in the future versions, they're deprecating defilament. Uh, because of the way it's used in TLS, it's not nice enough for us because we have to accept the server's parameters. And instead of defilament, they, they want to use elliptic curve defilament. So if you know elliptic curve, uh, to do a key exchange in elliptic curves, we don't randomly generate parameters, but we use parameters from a predefined set of curves. So the same kind of attacks don't work. They can work, but if you control both the client and the server, the server. So this is the end. Uh, open question, how many VPN libraries, closed source, open source products do you think have this kind of backwards? And what about elliptic curve defilament? It's open research, an open problem, and there might be things to, to be found in there. Follow me on Twitter and if you have many, uh, any questions, no, it's the right time. Yes. Right. So you, yeah, you don't have, it's not because you don't have a set of primes that you don't have secure parameters. And if you check for set of primes and you refuse websites that don't send you set of primes, you might not be able to browse the internet. Because not many websites use that. Yeah. Any other questions? All right. Again? Exactly. Also the server should itself check if it's using a prime. Okay. So if the server checks if he's using a prime, then that, that would be actually a very good fix. But yeah, but then you can always remove that check if you really want to implement your backdoor. But at least it should prevent people from doing things that they don't know and, and creating a backdoor by mistake. But for intentional, intentional backdoors, it might be, uh, not as good. All right. Thank you.