 Thanks so much for coming out this morning. I want to be true to my Scott's heritage. I never turned down whiskey. I'm David McGrew. I'm going to be presenting some joint work I did with Andrew Chee and Brandon Enright here. And we're going to be assessing the security of certificates at scale. And the exciting thing, of course, is we're going to show an exploit against keys we got off the internet. So for the last decade or so, people have been aware that there's a problem that commercial and small business and consumer grade devices often have really poor entropy. And when they use this to generate keys, they can generate keys that are exploitively weak. And so Dan Bernstein and Nadia Henninger and their teams, you know, convincingly showed this a long time ago. And there's other teams that more recently showed that it's still a problem. In 2023, we are talking about migrating to quantum-safe cryptography. We have another problem to solve, which is this weak entropy problem, right? Because otherwise, we're going to have quantum-safe algorithms with weak keys, which is maybe an oxymoron. So what is the weak key problem? So here we've got a big set of devices. And in this diagram, they're wireless access points, right? There could be any device that generates a public-private key pair. And so each device has an entropy source in it, and the entropy source is gonna provide an output into a key generator. Very often, these devices generate a key when they first boot, which is often a problem because if you have a software-based entropy source, when you first boot, you probably don't have a lot of entropy. Probably it's a fairly deterministic process by which you boot. And so if you use that entropy, put it into a key generator and generate a key from it, then that could potentially be a problem, as we show. But our model is, we've got a lot of devices, they each have an entropy source, they each generate a public-private key pair. And then we're able to access the public keys and then analyze them. So if you have cryptographically strong entropy generators, then if you want to generate an n-bit key, all two to the n possible keys are equally probable, right? And that's what you want to be unpredictable to your adversary. But with weak key generation, you just have a really small typical set that's like a tiny fraction of the original size of the size you wanted, right? And this can make it predictable. And so we're gonna be detecting and exploiting some of these weak keys. Going back to our original picture, we have a bunch of wireless access points and their entropy sources, except device one and device three happen to have entropy that's similar, right? And so the similar entropy is fed into the key generation algorithm and then the keys are gonna be weak, right? So red on these diagrams indicates weak. And there's a key thing here is, which is there's a lot of devices that we want to assess the security of and we're gonna use batch processing on this. And it actually is kind of a birthday paradox thing. The more things we're analyzing, the more chance of success we're gonna have. So there are different public key crypto algorithms and they each have their own failure modes and the two really important ones are common keys and common factors. So common keys can be generated for any algorithm, right? It just means that the entropy input to the key generation was identical in two cases so you get identical keys out, right? So this can happen for any algorithm, elliptic curve cryptography, RSA, or any of the quantum safe things. And so detection is fairly easy in the sense that you're just doing an equality match but it also is difficult to go from that match to strong evidence of failure, right? Of exploitable weakness because there are, the same public key might be enrolled in multiple certificates and sometimes people actually take the same private key and they put it in multiple servers and they think they're being clever even though it's a poor security practice. And but the common keys can be generated by weak entropy but it can be difficult to distinguish it from that like poor security practice. The other thing that we're gonna focus more of our time on today is common factors, right? So in the RSA cryptosystem, there are two factors. I'll show you how the math works and it can happen that two distinct private keys have the same common factor. We can detect that using the batch GCD algorithm and this is very strong evidence of weak entropy and a serious problem with the entropy in the system and then also it's exploitable which is kind of fun to watch. So here's how the RSA cryptosystem works, right? The public key is the product of two large primes and those large primes are the private key, right? So the private key would be P comma Q and then the public key is their product M. And M is also called the modulus, right? Within the context of RSA. So multiplication is easy to do in a computational sense but factoring is very hard, right? So which is what makes the RSA cryptosystem secure when it's done properly. So when I talk about common factors, what I mean is like two distinct devices will generate the identical factors, right? You can see here, continuing our previous example, device one and device three have their Q factor in common, right? They happen to be equal because the entropy input was so similar. So we can find common factors, right? So in this situation where device one and device three happen to have this weak entropy problem, we can just perform the greatest common divisor algorithm and use that to find Q and then we can divide M by Q and we can find the other factor and then we've broken the key. So the GCD algorithm is easy. It's not hard in a cryptographic sense and there's this algorithm that Dan Bernstein came up with for doing batch GCD, right? So you can get a very large set of keys and find any common factors that those keys might have, right? Which is the real key to efficiency in this situation. To actually use this approach, your first step is you need to obtain certificates, right? That have RSA public keys in them. And so you could obtain these through active scans of the internet or through passive monitoring that for TLS 1.2 and earlier, you can just observe the certificates on the wire. And then if you have a friend that works at a certificate authority, then you can get the CA logs, right? And that's another really good thing. So we have some tools that we published, TLS scanner for active scanning, Mercury for passive monitoring and cert analyze for analyzing standalone certificates as well as the batch GCD program which isn't written on this slide, but these are all BSD licensed Linux oriented tools implemented in C++17 with native ASN1 code. So the TLS scanner tool can scan a list of hosts you provide in a file and it can write out the certificates as a PEM file. And so you can use this to obtain certificates from a set of hosts. If you have like a set of hosts, like say you wanna do a security audit for some bunch of stuff on the internet that you've deployed or somebody who's contracting with you has deployed, you can use this to grab all those certificates. So our certificate tool, you can use this to filter against a regular expression or an exact string match in the text fields of a certificate which is really useful if you have a giant batch of certificates like you got it from Shodan or Census or someplace like that, Rapid7. Then you can use it to filter out things like there's a particular vendor you wanna focus on for a security audit. Filtering the giant set of certificates down to a very large but manageable set of certificates can really help you by making the analysis go faster. So our tool can, if you're gonna filter you need to provide the PEM output format and it outputs the manageably small set of certificates. So in our work, so we wrote these tools so that we could assess certificates for devices that we were analyzing. And we applied this to a number of things including internet scan data and we found there's a lot of common strings in issuers that reveal different vendor names, right? So today we're gonna be picking on Dreitech and we kinda pick them at random but just to admit, right? So my employer is Cisco and Cisco small business routers did appear here and fortunately we no longer sell that thing. So the batch GCD tool is where the most of the interesting work gets done for RSA. So in this tool, which I have to give credit to Brandon and Andrew are the people that wrote this. I only wrote the ASN1 export functionality. Match GCD, you provided some giant set of certificates in a single file that has the PEM certificate format and then you have to provide it with the right keys option if you actually want it to generate some output data that you could use to demonstrate an exploit. So for each factored RSA key, it is going to write out the private key in a separate RSA private key format. It's another PEM format and it's also gonna write out the corresponding certificate, right? So if you're analyzing millions of certificates you don't wanna have to wade through that file in order to find the certificate file corresponding to your private key file. This tool does two passes over the input data because we wanna carefully manage our random access memory usage because RAM is a scarce resource when you're trying to do something like match GCD. So I wanna show a demonstration of this attack and let me explain the setup here, right? So we have a victim that owns a wireless access point that has an exploitable key in it and he has chosen to trust the self-signed certificate associated with this device. And the victim is at a browser and he's gonna visit the manufacturer of this device and we're going to perform a machine in the middle attack against his traffic. So I wanna acknowledge the MITM proxy tool which we used in this attack. Okay, so we're gonna start out, this is the attackers machine. So we've previously obtained a bunch of certificates that are all have this, you know, Dre-Tech string in their issuer and we're gonna run the batch GCD program with that file as input and we're gonna ask it to write out the private keys and you can see we've got about 158,000 distinct RSA keys here. A modulus is a key in this situation. And so I wish I had the laptop here today this was running on my framework laptop which has eight cores and you can see in the system utilization we're keeping all of the eight cores pretty busy at this point. And so this tool can analyze a batch of about 67 million RSA keys altogether that's assuming an average size of 2048 bits each which is commonplace. That's gonna require about half a terabyte of RAM if you actually go up to that limit. You can rent that on GCP for not too much money. So at this point it's a boring demo but we're about to get to the point where we find 55 week keys out of the initial set. So our tool writes out the lines corresponding to all of those week keys and we're gonna pick one of these things at random to use in a demo. The tool outputs, you'll see the line number is the number of the certificate and the input file and we have to use the line number so you can correspond the private key file with the certificate file and that's the sort of thing you use. Here we're piping the certificate through our tool so you can see that the subject alt name in the certificate includes www.draytech.com and this is a terrible idea to do, right? To say that the subject alt name for this device is on the, here I'm showing that we are substituting the, here I wanna replay that. I think I have time to do this. Sorry, my explanation's a little slow. So you can see we're gonna replace words like manage management VPN with the word hacked, right? That's what MITM Proxy is gonna do for us. So we're running MITM Proxy here and so this victim is visiting draytech.com and first he's gonna bring up his favorite search engine duck duck go and look up draytech and then we're gonna visit it. This is the victim's view at this point and so we'll visit draytech and we're surprised to see that our man in the middle proxy is working and we are intercepting the traffic and replacing the, we're revealing hacked routers and hacked switches and whatnot, right? So don't ever put the, your vendor URI in the subject alt name if you're gonna have a cheap device generate the certificate. That's one of the things that you shouldn't do. The other thing you shouldn't do is have weak entropy, right? So hopefully that attack made sense and I want to conclude the presentation with a few thoughts here. Batch testing is practical and effective and Dan Bernstein and Nadia Henninger showed that this stuff was a problem 10 years ago but we wanted to democratize this a little bit by making a full set of tools available and we found in our work that showing somebody an exploit is often necessary to get them to understand that yes, an exploit is possible. So for future work, we'd like to detect more failure modes. There's the two major ones we found now but there's other failure modes, weak keys, especially with RSA and we're working on analyzing a large batch of manufacturing certificates and we hope to share that information soon when we can and I want to mention that you can download the software tools and documentation. So on github.com slash Cisco slash Mercury please look in the documentation directory for the batch GCD file which has the instructions about the main tool here. And if I could make a shout out for people who would like to do crypto attacks, as the industry evolves away from RSA towards other crypto algorithms, it's gonna make it harder to detect weak entropy problems but it is not gonna make the weak entropy problem go away, right? So this is a very real thing, right? We should be looking for other ways that we can convict devices that have weak entropy. So that concludes our presentation for today. Thank you so much for your attention.