The hardware-based random number generators used in most modern IoT devices have a serious fundamental weakness that undermines the security of the encryption keys they generate for communications: The RNGs don’t really generate random numbers.
That’s a fairly serious issue when the whole function of the RNG is to generate random numbers, which are then used as seeds for encryption keys. Researchers from Bishop Fox found that the overwhelming majority of the tens of billions of IoT devices in use today have flawed RNGs, a vulnerability that is not limited to a group of vendors or specific IoT operating systems. It’s a widespread problem that security researchers have been discussing in various forms for some time, and there’s no simple way to address it.
The root of the problem is the fact that the hardware RNGs in these devices throw errors relatively often, and the software usually doesn’t check those error codes.
“When an IoT device requires a random number, it makes a call to the dedicated hardware RNG either through the device’s SDK or increasingly through an IoT operating system. What the function call is named varies, of course, but it takes place in the hardware abstraction layer (HAL). This is an API created by the device manufacturer and is designed so you can more easily interface with the hardware through C code and not need to mess around with setting and checking specific registers unique to the device,” Allan Cecil and Dan Petro of Bishop Fox wrote in a post detailing their research, which they discussed in a talk at DEF CON 29 last weekend.
The errors generated by the RNG HAL function can vary, but the important ones in the current context are when the RNG becomes overwhelmed by too many requests for random numbers, which causes those requests to fail at some point. Depending on the implementation, that could result in the use of partial entropy for a random number, a random number of zero, or uninitialized memory. Partial entropy can be problematic because it weakens the key strength, and the RNG just choosing zero isn’t ideal either, but the creation of uninitialized memory is much worse.
“It can always be worse. No matter how bad you think it is, it can always be worse. What could be worse than encryption keys of zero? Uninitialized memory,” Petro said.
“This is a case of a missing feature and one across a very heterogeneous ecosystem."
A contributing factor to this issue is that IoT devices by design are generally fairly bare-bones when it comes to software and so they don’t have the safety net of an operating system to help handle serious errors.
“There’s no OS to smooth over errors you might make. You’re just running C or C++ on bare metal,” Petro said. “As it happens no one actually checks the return error codes on the RNG.”
Addressing the weakness in the RNGs on IoT devices will not be either simple or easy, and Cecil and Petro said the most straightforward and effective way to do it would be for designers of IoT operating systems to implement a cryptographically secure RNG (CSPRNG) in their OS. CSPRNG systems differ from RNGs in that they’re not hardware-based and are designed to be resistant to attacks. CSPRNGs also don’t have the failure states that other RNGs do.
“When an application needs a cryptographically secure random number on a Linux server, it doesn’t read from the hardware RNG directly or make a call to some HAL function and fight with error codes. No, it just reads from /dev/urandom. This is a cryptographically secure pseudo-random number generator (CSPRNG) subsystem made available to applications as an API. There are similar subsystems on every major operating system, too: Windows, iOS, MacOS, Android, BSD, you name it,” the Bishop Fox post says.
“Importantly, calls to /dev/urandom never fail and never block program execution. The CSPRNG subsystem can produce an endless sequence of strong random numbers immediately. This squarely solves the problem of HAL functions that either block program execution or fail.”
Cecil and Petro stressed that the problem is not due to errors by the various developers writing software for IoT devices. It’s a systemic issue with the way these RNGs work.
“This is a case of a missing feature and one across a very heterogeneous ecosystem. The IoT world needs a CSPRNG implementation,” Cecil said.