 Hi, I'm Alan Cecil and with me today I have Dan Petra. We are presenting you're doing it wrong We're talking about vulnerabilities that exist in virtually every device out there in the IOT world That's a critical issue that we need to talk to you about because random numbers are used everywhere Before we get too far though, let's talk a little bit about random numbers and why they're so important to security Numbers of course are kind of how computers work So a random number can be a stand-in for all sorts of things that we don't normally think of as numerical So encryption keys authentication tokens and our lovely friend business logic but one of the things you're going to notice throughout this presentation is that the vulnerabilities that we're going to describe here have a Lot to do with the specific logic of a particular application In a way that is hard to replicate on Mac So a lot of the vulnerabilities that we'll discuss here are kind of specific to particular applications or frameworks And aren't necessarily the kind of canned exploit that you might expect from like a widespread CVE One of the problems though is that computers are notoriously bad at making truly random numbers And that's because computers need to be deterministic if you did math and every time you got a different value out of pi Or you had a Pentium 2 processor that just kept messing up floating point numbers You'd have problems and we have seen this in the past. So we make computers to be very deterministic However, sometimes you need stuff that isn't deterministic You need some some entropy and that's where our hardware RNG comes in That's its job is to make entropy to make a source of randomness to it be a seed for Some way of getting random numbers. So that solves the problem, right? Now it's actually a good time to bring up that there's two major kinds of random number generators that you'll find a Pseudo random number generator and a true random number generator You might think from the names of them that you want the true random number generator or the TRNG That that's the good one and pseudo ones are the bad ones, but it's not that simple Really the distinction is only that one is made in software and one is made in hardware And the names could really lead you astray here I particularly hate the name true random number generator for the hardware ones It sort of implies a kind of quality behind them. That isn't necessarily present I suspect this naming comes from big RNG as a propaganda term But in any case the pseudo random number generators also come in two major forms the cryptographically secure random number generators or Cispinger guh for short and regular ones So the regular ones are things you'll find in like libc random or the percent twister that are meant to be fast They're really efficient. They're just pieces of software in both cases. They work work basically the same though you take an initial seed number that could be any length somewhere between the 32 bits all the way up to like 128 bits and then you stretch that entropy out indefinitely into the future you could produce some the stream of Seemingly random numbers from that seed right so it's an entirely predictable set of numbers given that initial seed And so the distinction between a cryptographically secure random number generator and a not secure one is basically that the Regular ones like the percent twister or libc random or any number of other common implementations We'll leak information about the internal state and therefore the seed as you go along So there's really no secure way to use those. There's they're never safe to use for security critical pieces of information anytime you actually need Like secure information like a crypto key or something like that You should definitely be using a CSPR and G and then the security of the hardware RNGs are something that we investigated in this research One unfortunate part about the design of these hardware random number generators is that there's not a lot of information Known on about the details of how they actually work. They're basically black boxes So if you wanted to find out about how your Favorite IOT device the hardware random number generator that actually works They're you know, you're kind of out of luck a one notable exception is the STM 32 want to give them a shout out from STM ST microelectronics They actually have a really great information about the details of the inner workings of their RNG as well as a proof of correctness a Kind of proof of the good quality random numbers that came out of it But there's two kind of basic Digital designs that you'll find for how to produce random numbers in hardware at least in a low-cost way that you'll find in IOT devices analog circuits and clock timings The first one is an analog circuit So you're probably more familiar with digital circuits. That is circuits that are gated by a clocking function Analog circuits are kind of the opposite. There's no central gate by a clock So what you can do is you set up a analog circuit that sort of looks like the diagram we have here on the top right and there's a Bit that flows back and forth between this not function So it's either a zero or one and a zero and a one kind of back and forth again It sort of spins in this infinite loop going back and forth between zero and one at a function at a rate rather that is Not exactly a random, but sort of arbitrary So if you were to pull that if you say Ask the analog circuit at any given point in time to you know find out what the bit is the value will be pretty random And that's a pretty good way of designing a hardware random number generator there's also a method where you're using multiple clocks at the same time to Get a difference between the two a delta between the measured Differences between those clocks if you had two clocks that were derived from the same source The result should in theory be identical So you would always get a one or a zero Depending on when you sampled it But if you allow them to run freely and measure the delta between the two you can get a pretty normal distribution of differences between the two sometimes this happens on On situations on it that you wouldn't expect where the designers didn't deliberately do that One of them happens to be the original Super Nintendo They had a 21 megahertz clock for the central processing unit and a 24.576 clock for the APU the audio processing unit the result is that speedrunners playing Super Metroid to have to deal with Random timings due to moving data across the bus when going through door transitions Sometimes these random situations happen on unrelated devices and in a hardware random number generator You're taking advantage of what just sometimes happens accidentally and using that deliberately to get random numbers out of it There are some issues that come up if you're calling too often if you're just running too fast You're calling too frequently for instance that output Call from that analog circuit method if you're calling it too often You're gonna get the same number twice in a row because you didn't give it enough time to transition the same thing could happen with The clock method if you're calling it too frequently you could also end up with accidental syncing It could just be that both of your clocks happen to align so they're both operating at exactly the same offset There's no guarantee that you're going to be perfect But it's usually good enough that it's it's fine as long as you're not calling it constantly How IOT does RNG is interesting most new IOT system on a chips have a hardware RNG device built into them as of 2021 that hardware RNG is an entire peripheral devoted to just RNG so it must be secure, right? so the thing about IOT and programming on IOT devices is that there's not really any operating systems to kind of smooth over the errors that you might make Typically, you just run C and C++ on bare metal. So if you needed a random number for a security critical piece of information like a crypto key You just call the hardware RNG peripheral directly usually through a howl function a hardware abstraction layer function And something that looks basically like this This of course is pseudo code, but it looks basically the same across basically every SDK and operating system So there's the howl get random number function and there's kind of two parts that we really care about here for one There's an output variable the out number. That's the actual random number that we care about if you're familiar with C it's an output variable basically you Send it a pointer to the number and then the function will overwrite the value on that that pointer And then the actual return code which has an error message the error message that I'll tell you in case something went wrong along the way There's lots of things that can go wrong when you are talking to a piece of hardware, right? The peripheral might be broken or something went wrong over the bus Maybe there are random number generator peripheral just wasn't ready yet The maybe the relative positions of Jupiter and Saturn for all we know are just not aligned in any case An error can occur in the calling of this random number generator function And it'll let you know about that in the return code So we want to ask the natural question. How many people out there in the wild actually check this error code? So as it happens almost nobody actually checks the return codes of these howl RNG functions basically everybody out there just sort of makes a call to the random number generator peripheral and just Uses whatever result that happens to give you You can see two results here from free rts. Just a popular IOT operating system and the media tech 1676 97 You could see both of these calls here are basically what we looked at earlier There's a return code that you're not seeing that is checked and then the output variable that's put into it So maybe you're wondering alright, so you you know didn't check the return code of the howl RNG function You know, what's the worst that could happen? undefined behavior We don't know what will happen and that is a pen testers Favorite phrase the worst that can happen might sound like it's the number zero and in fact We have seen examples of this the xkcd joke that you always have to reference when you're talking about random numbers is That you ask for a random number and it always returns a static value a constant That isn't quite what usually happens, but it's not far off We've seen large swaths of zeros in a one gigabyte file of supposedly random numbers And even in our own implementations when we were trying to do it properly We ended up with results that had large quantities of zeros in them But that's not the most insidious one. The worst is where you have partial entropy. It looks like it's random But it isn't as random as you thought it was a good example is you make a call you get a 32-bit unsigned integer back It has four bytes of random numbers and the first call looks fine. You call again. It still looks okay Then you call a third time and you get zeros and you call a fourth time and you still get zeros But if you're not looking carefully enough, you might not notice that you got a whole bunch of zeros in your calls This partial entropy can be really tricky because it substantially reduces The actual randomness that you're working for the strength of the random number that you're getting and it might seem like this is Not an issue, but this seems to happen pretty often So this is actually how this entire research project got started We do a lot of IOT engagements at Bishop Fox under what we usually call a product security review We like to say that if it breaks when you drop it, it's a product security review And so one time we had a client that was developing an IOT device that does a lot of cryptography in it that was kind of like a security device and I Was reviewing the code and looked at the code which used a lot of a random number generation in the process of doing a lot of this cryptography and Was curious about you know how it did random number generation on such a tiny low-power device and it turns out that there was a hardware random number generator on the sock that our client was using and On a lark I sort of asked to see like hey, what a what is the quality of the random numbers coming out of this thing? I you know was sort of curious. I hadn't actually Seen the output of one of these hardware random number generators previously and I didn't really expect it to be bad I was thinking that like you know the hardware random number generator surely is the gold standard for RNG, right? And so when we got the results back, I ran it through some statistical randomness tests and it failed basically all of them And then upon further inspection looking at the actual like binary files like a couple of gigabytes of Output from the RNG the large swaths of it were just zero Surely I thought that this was like a mistake that this can't have been right So we then embarked on this sort of longer journey to investigate to see was it just a single buggy chip Or was it some crazy buggy code and this entire thing kind of blew up from there? So you might think that encryption keys of zero or about as bad as you can get right I mean surely it can't get worse than that well I'd like to introduce you to Petro's law if I could have one eponymous law one law named after myself Help me out here Defconn. It would be this it can always be worse no matter how bad you think it is It can always be worse So what could be worse than encryption keys of zero uninitialized memory? That's what so take these three lines of pseudo code For example these are pseudo code, of course But if you just hop on to GitHub and look around you'll find lots of examples of this in the real world So you declare but not instantiate a number that you're going to be using as your holder for a random number This is declared on the stack You then pass this to the how random number function However, if the how function works in such a way that it Doesn't perturb the random number variable when there's an error condition like it doesn't set it to zero Say now what will happen is when you go to use it later on the value will just be whatever happened to be present in RAM Prior to the call So this can actually happen quite regularly in the real world too for instance If you're doing some cryptography with like a Diffie-Hellman key exchange This will involve generating a random number and then sending it over the network to a potential adversary So this is something that's quite realistic at practice So let's talk about some real-world instances in 2019 a study against over 75 million publicly available Certificates found that over 435,000 of them were vulnerable to attack in the study They specifically called out lightweight IOT devices are particularly prone to being in low entropy states and I'm not saying that our research here Directly points to what they found but it's a pretty clear Link that when you have this many devices that are producing such low entropy results It seems pretty likely that this was what they found So you might have thought this was gonna be a very simple case of just simply blame the users right there was pesky users aren't Checking the return codes and we just need to make sure that they're calling the functions correctly Well, it's actually not quite so simple. So take the this for instance This is a some pseudo code at the top here. The this is from the MediaTek 7697's Documentation you call the random number you check if the status code is not equal to okay And then you're sort of handle the error Well, the handling of the error comment right there is doing a lot of heavy lifting because when you need a random number for some Security critical code you can't just simply move forward without that random number It's sort of important to the core thing you're trying to accomplish there So generally speaking you're kind of given two options one is to spin loop So you can just kind of while loop call the random number generator function again over and over and over again until you get An okay status basically you're going to use a hundred percent CPU Indefinitely maybe forever if the RNG peripheral is broken waiting for a result. That's not very good But the second option is just to quit out entirely kill the entire process or like if you're in the networking stack if you're trying to make a TLS key for a TCP connection that you're in then it's going to involve killing the entire TCP connection like that's not a very good option either Both are so unacceptable that it really leaves developers with only option three which is YOLO You can't just spin loop because it'll lead to broken Buggy Useless devices same thing with quitting and killing the entire process and starting over This is going to make a device. No one would want to buy so we force users into this when unwinnable situation RNG and IOT is fundamentally broken and it's not the fault of the user So let's talk about the right way to RNG and the right way to do this is to use a Cryptographically secure pseudo random number generator. It's a mouthful, but a CSP RNG has some distinct advantages It never blocks execution. It has API's calls that don't fail It pulls from multiple entropy sources more in that in a second It always returns crypto quality results due to stretching out the amount of randomness that you have in short It's a much stronger system than just relying on a single source of entropy The way that the CSP RNG sub system works is you start with a number of entropy sources So these can include the hardware random number generator But also lots of other things that an operating system might have access to such as interrupt timing from various devices networking Receive times the like tiny nanosecond receive times has a quite a bit of entropy them to the network And you XOR them all together into this big entropy pool So what's important to know about this is all of them are XORed together So that it's not sufficient to break just a single one of these entropy sources in order to predict the output of the random number generator An attacker would need to simultaneously predict all of them. So that's very strong Additionally, what you can do is then read from the entropy pool by a cryptographically secure random number generator These are typically just like a hashing function like a Linux kernel will just MD5 the entropy pool and then in order to produce More numbers afterward MD5 the last output with the entropy pool itself So you can kind of chain basically key stretching your way out to produce a Functionally infinite amount of entropy from a static amount Also, because we can study these hashing functions like offline. We're very sure about the strength of the results So this also makes for mediation tricky here You see it's not a simple case of you know You zigged we should have zagged where there's a bug in a piece of software somewhere and whoever made the software can just kind of Fix that bug we patch it and move on with our lives This is a case of a missing feature and one across a very heterogeneous Landscape of devices and pieces of software The most likely place that you'd implement a feature like this a CSP RNG subsystem is one of the emerging The IOT operating systems something like free RT OS contiki NG right OS or one of many others We'd highly recommend using one of those if you're making a new IOT device from scratch Because the individual device SDKs Seeming like they're unlikely to get this kind of a feature those SDKs are usually very thin filled with example code That's mostly around hardware enablement and not so much around making a full device end to end So yeah, this is going to be a tricky Remediation process now this vulnerability might be with us for some time This is how RNG on IOT devices should work to but right now it doesn't and The rest of this talk is all about convincing you why you really do need a CSP RNG subsystem It's absolutely critical to have this now Let's talk a little bit more about using hardware RNG to seed an insecure PRNG because this will matter A lot when we start moving into the rest of this talk Nobody codes from scratch. We were talking really about blaming the users for doing it wrong Well, if you're a user and you're grabbing reference or example code and that reference library or that code that you're working with has Vulnerabilities it propagates those vulnerabilities out and One of the places this shows up is some IOT devices and operating systems use the hardware But only to seed an insecure libc pseudo random number generator What that looks like is you're getting a nice Potentially random number from the hardware random number generator. You're using that to seed libc But everything after that is not necessarily Cryptographically secure you're not really using the hardware even though you might think you are this shows up in the media tech link it 76 97 and specifically in the contiki in G I'm gonna let Dan describe this in a demo we have for you So for this demo we built an IOT security camera device It takes pictures every few minutes just like a real security camera and post them to a publicly accessible website So the only thing keeping an attacker from being able to view your photos is that each file is named to this? Long random file name here chosen by the camera now before you go thinking that this is unrealistically vulnerable This is how discord works and lots of other applications like it anytime you take a photo And send it to a friend over discord It's publicly accessible of the long random file name is the only thing that's keeping people from seeing your photos Our device however is built using contiki and G a popular IOT operating system When you call the operating system to get a random number It will use the hardware RNG on board, but only to seed the insecure libc random function So we don't know what the seed is, but we don't have to because we can derive it So suppose one day you take a photo with your camera and post it on social media Wow, what a cool camera you bought how fun But what you didn't know is that an attacker can use this file name to derive what the original seed was that generated it That's because that's how the libc ran function works Our attacker here uses untwister to find the seed once they have They can use that seed to determine every past and future value from the RNG So attacker can just plug in some of those numbers back into the camera website and view every photo that the camera has ever taken Even if they've never been shared before All right, so let's have a word about exploitability This comes up a lot anytime you give a talk about random number generation or crypto stuff is how exploitable Is this really and the answer here is very exploitable, but it's not going to be a canned exploit You're not going to see a you know You're doing it wrong dot pi that just sort of exploits things in the wild It's going to have to do with the particular business logic of the device that you're speaking to It's going to be very particular to individual Internet of Things devices, so there's not going to be just like a simple CV that you can kind of apply Universally across the board to you know every device that comes with one asterisk one possible exception here And that's with asymmetric keys. You see one of the things that often causes the hardware RNG functions to fail is calling them very rapidly in succession So you call them too quickly and then it runs out of entropy and just starts getting you zeros So one really common way to make that happen in the real world is to make a 2048 or 4096 bit RSA key right in order to get that many bits from the hardware RNG You're going to need to kind of call it in a loop in succession very quickly and those sorts of keys are very sensitive to low entropy It's not like an AES key where if you know you're missing 32 bits off of 128 bit key You're still you know probably fine Whereas with RSA keys that's not the case in fact There's a different talk at this DEF CON going on right now called the mechanics of compromising low entropy RSA keys We did not plan for this that was just a thing that sort of happened So this is actually a thing that you can check for empirically you can look at the RSA keys coming out of IoT devices and See if they are of poor quality or not and that's the sort of thing you can do from the outside black box as well So if you're a pen tester and you have an IoT engagement coming up How you're going to actually exploit this is going to depend greatly on whether it's a black box approach Or whether you have the source code to the application of the device itself As a black box approach, it's going to be much trickier You're going to want to look at the output of the RNG from however the application is using it The easiest way as we mentioned is using the asymmetric keys If the device produces an RSA key or a certificate of some form Then you can look at those cryptographically to see if any known attacks work against it That's probably going to be your best bet Second though look for any opportunities to tax the RNG So any opportunity for the attacker to influence how often the RNG is being called So for instance if the device is producing some ID value and that is done at the request of a user Then try you know requesting that very very quickly and see if the numbers start becoming zero or if they're lower entropy other than that I'm trying to actually measure the entropy of Values that come out of an application can be very hard because very often it's going to be Permuted in some way. You're not going to get the raw hex values that come out of the RNG Typically, it's going to be produced as like a a six-digit pin or something like that and in order to perform statistical analysis on The kinds of output of the RNG you're going to need a you know a very large sample size like a gigabyte or so and In order to get a gigabyte of you know six-digit pins. You're gonna have to make a lot of calls So that might actually be very difficult in practice With source code, however, things become a lot more visible You can look into to see how the hardware RNG is called and see if the return code is being ignored I hesitate to recommend actually implementing a CSP RNG subsystem on your own at this state Since there's a lot that can go wrong there. There's a lot of moving pieces that go on there There's certainly a lot that you can mess up, but at least consider it if it's critical enough Okay, you've done everything right you're spin looping you're blocking until the hardware random number generator gives you a valid non-zero results or Validated that you've used every library correctly and that your libraries aren't written in a bad way that are perhaps just seating libc You validated all of the code you're using Surely you've got it right now, right? Nope, there's still some usage quirks. You're still likely going to do it wrong. In fact, you will do it wrong This is the same level of difficulty as trying to write crypto code and for the most part we know not to try to write our own crypto code It's it's kind of a a well-known law. Well, this is my law My law is don't write your own RNG code. You will do it wrong now You might potentially have some documentation Maybe if you can find it on some usage quirks you run gonna run into for instance the LPC 54 628 has a warning on page 1106 out of 1152 that says when you're calling it you have to throw out 32 results Use one and then throw out the next 32 results and repeat the process It is the only way to guarantee that you're getting proper random numbers out of it But how would you know if you didn't sort through a thousand page document? And if you saw this code written down and you went through the comments Unless they specifically called out why they were doing it you would think that this was buggy code. This doesn't seem sane You can't try Writing RNG code on your own. It's as bad as trying to write crypto code and even worse This is absolutely a situation that emphasizes. You can't blame the user for this. There's no one that's gonna get this right One of the things we've touched on in this talk are hardware dev kits that SOC silicon on a chip vendors Release to allow developers to debug and flash their devices and IOT developer is going to build their advice around an SOC and They'll be writing their code in C or C++ or something similar on a PC and then flashing their device and testing it the dev kits provide a variety of different features for testing things and each vendor does it a completely different way for instance this is a spark fun board that is using an nrf based SOC and it has a USB port for debugging and flashing as well as an SD card each vendor implements it completely differently and for instance This is an older version of an STM 32 This particular design has a debugger at the top that can flash the device The actual device you'd be flashing is this SOC down here This portion of the board is still a dev kit. It has all of the functionality in that chip Exposed on the pens on the sides But you can do some interesting things you could flash this this chip and debug it with this portion And when you're satisfied to the device you can actually snap off this entire upper portion Sometimes you'll do this because you'll develop your device and then use the dev kit itself One of these designs that we did on the side on my taskbot project was with this Cypress PSOC 5 based board to flash this device you plug this end into a computer and to actually use it You're using a completely separate USB port on the other side in our case We connected the actual dev kit to a board we manufactured this was made by a total in the task spot community this allows us to connect to a Video game console and pretend to be a controller as in it for instance You can also just make your own hardware that doesn't have any of this extra debugging functionality at all That's what we did with this task team 32 board made by onosaurus same concept This allows us to connect directly to a video game console and pretend to be a controller We just have cables that go from ethernet to say a Nintendo or Super Nintendo but in this case we've taken the SOC right here and Incorporated it into a board of our own design and that's generally what a IoT device developer is going to do now There are a variety of different Advantages of doing that one of the boards we worked with was this newer version of an STM 32 that incorporated everything over just a single USB port Rather than splitting it out like the PSOC 5 did this has a USB serial interface It has debugging functionality. There's various different ways that you can talk just over USB This was a really interesting to work with And ultimately the bulk of our research time was working with devices like this to try to access the hardware RNG that was on the SOC This particular device had really good documentation So a lot of credit to ST micro for that they even went so far as to provide a proof of their randomness and When we started trying to reproduce the results we actually ran into several problems One of the issues we ran into was that even with a reference library and code and documentation We still ran into problems with not properly spin locking and blocking execution of the program For instance in our early tests. We were using something called bite circle Just an analysis tool that allowed us to throw the data at this this program And it would show the byte distribution in a nice circle so out of two hundred and fifty five possible different combinations what we found is that all of the values we were getting were very low numbers for some reason When you looked at the data in a file it looked like it was properly random But what we found was that we were actually calling it too frequently We weren't blocking properly and as a result we were calling the hardware RNG Too frequently and and starving it and getting bad results as out of it as a result One of the other challenges we ran into was some of the devices made it very difficult to even get the data off of Media tech could be flashed over USB, but to actually exfiltrate the data We had to use this crazy method over wireless and do various get calls It was pretty complicated and really the bulk of our research was just spending time trying to get Accurate numbers out of these devices. I Bring up all this complexity because I want to highlight duango ac's role as it were Don't try to make your own hardware RNG code. It's as bad as writing crypto code I've said it before but I can't emphasize this point enough We spent a long time trying to do this and still managed to mess it up several times in the process IoT vendors really have it rough because if they do release a device that is standalone like this How do you flash it in the field once you've released this you've broken off the debugger? There's possibly no debugger on it at all There's a lot of hardware out there that possibly has badly implemented hardware RNG that vendors simply can't fix So to pen testers This is going to be a perennial finding that will pop up for years to come because there's already hardware out There that's potentially using insecure RNG methods and it's not easy to fix Okay, so let's take a look at what the quality of the entropy looks like coming out of these hardware random number generators is raw No more bugs no more silly usage quirks and library shenanigans Let's look at the actual numbers coming from the hardware RNGs themselves. Are they good? Are they bad? so we Ran a bunch of the RNGs through some statistical analysis and got some cool results to show you What you're looking at here is a histogram for the MediaTek 7697 That is a diagram of all bytes and how often they occur 0 to 255 from left to right So what we should see is basically a flat graph very soon Everybody should occur just as often as every other bite maybe with a little bit of fuzziness at the top But that's not what we see what we see is this obvious sawtooth sort of pattern that occurs down the line And if there's two things that don't go along well together, it's obvious repeating patterns and crypto keys Do you feel comfortable using this for your encryption key like I for sure don't? Next up is the Nordic NRF 5280 40 For this there's this obvious repeating 12 byte pattern of just zeros. There's a zero zero zero It's a little bit hard to see in the picture there. The highlighting doesn't capture the third zero But this happens every in hex 50 bytes And that's super bad. Obviously repeating patterns of any kind is bad, but especially fully zeroed bytes Coming from the Nordic board was something that we saw that kind of stood out and made it fail all of this Statistical randomness tests there forward This example was so egregious and so peculiar that we thought for sure for a really long time that it was just our Instrumentation that was at fault, but we don't think it is for three reasons one We spent a really long time Investigating our code trying to figure out how this could possibly be happening from it and never figured out how but two It's a 12-bit pattern, which is a very weird if it was exactly one bite I know bite and you know, perhaps you'd think that it's just a null terminated string was kind of getting copied around incorrectly Somewhere but exactly 12 bits is really curious and also the the amount that it jumps by 50 bytes Sometimes it'll actually jump by a little bit more than 50 bytes Though which kind of offsets things a little bit So there'll be like maybe 80 bytes or something like that in hex and then it'll kind of continue on the pattern from there Which also wouldn't really make sense as an inconsistency in our instrumentation so aside from just a Distribution of values and side from just taking all of the bytes and putting them on a graph and seeing how frequent they are You can do a lot more statistical analysis There's a lot of tools out there including die-harder that you can use on large data sets to see if there are repeating patterns And we relied on this a lot when we were doing our omen implementation on the STM 32 When we first started we were failing all of the tests and it took us a while to get the code right We thought we were spend looping properly. We weren't it turns out It's very difficult to do this properly even when you think you know what you're doing Once we got through all of the other tests We still had one of the die-harder tests that continued to fail, which was the RGB minimum distance test So the minimum distance test what it's doing is it takes a bunch of random numbers interprets them as integers and plots them in n dimensional space and then calculates using a simple algorithm What the minimum distance between any two of those points are and it should fall within expected parameters What this is doing really is it's checking for repeats or nearly repeated values since any repeats would cause the Minimum distance to become smaller than it like normally should be so you're seeing here in terms of a failure as a p-value of Exactly zero, which means that it's a very confident that this should not have occurred Randomly or the chances of it having occurred naturally is very small At the same time you're watching this we'll be releasing our code that gathered and analyzed the hardware arm RNG entropy itself. It's nothing terribly special But took a long time to get right and working across a bunch of IOT dev ports And while we don't think that there's any errors that would have impacted the results Consider that even if it turns out that there's a bug in our code What does it say that two computer security experts spent months studying and analyzing RNGs and still couldn't get them to work properly? And what does that say about the state of IOT security more broadly? Okay, so what are the conclusions we've come to after talking through all of this? The first is that this affects the entire IOT industry. It's not a single to vendor. It's not a single device. It's not a single particular quirk this is widespread and If you take nothing else out of this talk The point we really want to make is that the IOT world needs a CSP RNG subsystem This can't be fixed by just changing documentation and blaming users You really need RNG code That is well vetted and you should consider it dangerous to write it on your own It's just like crypto code and also you should never use entropy directly from the hardware You don't know how strong or weak it might be as we just showed you Okay, so what can you actually do about this? Well, it depends on what camp you're in if you're a device owner keep an eye out for updates IOT devices aren't the best in general with software updates And you're gonna want to make sure that yours is ready to take them when they're available IOT device developers, we'd highly recommend using one of the emerging IOT operating systems We don't have a strong preference for one versus the other at this point But if you're making a new device from scratch or maybe even just updating a current one We'd highly recommend using those rather than writing raw C on the bare metal yourself If you're an IOT device manufacturer or an OS developer themselves Implement one of these CSP RNG subsystems. That's the only secure way to do it. There isn't a way to get around it You might even consider deprecating or straight-up disallowing users from using the hardware RNG raw itself And if you're a pen tester keep an eye out for this because it's going to be a perennial finding for years to come. I Am Alan Cecil de Wango AC. I'm Dan Petro and thanks a lot