Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Random numbers are very important to security. For instance, they are used for encryption keys, authentication tokens and business logic. Even though random numbers are important, they are terrible at generating random numbers. By design, they are deterministic; 1 + 1 should always equal 2.

There are two types of random number generators: hardware and software. The hardware generators are the focus of this article/video. Hardware RNG design has two common implementations: analog circuit and clock timings. Analog circuit has a bit that flows between the two values: 0 and 1. As a result, this is mostly random. The latter way is to get the difference between two clock timings.

With hardware random number generators, there can be issues. With the analog circuit method, you must give it time to go onto the next cycle. Otherwise, the same number will be given twice. For the clock method, it is possible for the clocks to sync up. So, if you're not calling the function too much, you are likely okay.

Lots of IoT devices are not using operating systems. As a result, a call to a HAL (hardware abstract layer) is made to the hardware RNG. This function has two values returned: an output variable (random number) and the return code. It turns out that no one checks the return code. This undefined behavior can result to all 0's being performed or partial entropy throughout.

Instead, use a cryptographically secure pseudorandom number generator (CSPRNG). They never block execution, the API never fails and it pools from many sources. Most operating systems get hardware randomness, timing, network and many other items for randomness. Then, this randomness can be used to seed CSPRNG to get something mostly random. How do we fix this problem? Instead of just getting hardware random numbers, like most IoT devices do, there needs to be a built in CSPRNG subsystem.

How can this be actually exploited? It really depends on the device and business logic! One common attack against hardware random number generators is to generate a key for asymmetric encryption. This will likely eat up all of the entropy and cause non-random numbers to be returned.

In general, there are two ways for blackbox approaches:

• View the output of the RNG from the application. For instance, the RSA keys or certs mentioned above.
• Tax or constantly call the RNG. This will likely cause the RNG to be lower entropy or return 0's.

For whitebox approaches look for return codes not being validated and common security issues.

The authors claim that code that interfaces with the hardware RNG are also vulnerable. For instance, the hardware RNG output from some vendor mentioned on page 1006 and 1052 pages how to properly use the output for security based events. To get proper entropy, after getting a 32-bit number, the next 32 calls to the RNG had to be thrown out. Otherwise, they would not be using proper random numbers.

The authors took a look at a few chips to see the random number generation. When looking at the Mediatek 7687, they noticed that the statistical analysis of the numbers being taken out was no-where near completely random. Some numbers occurred much more frequently than others. The Nordie nrf52840 had a problem where the 0x50th (or slightly more) byte was always 0x0.

There are a lot of good tools for doing statistical analysis. For instance, dieharder, number circle and many other tools.