Security researchers Dan Petro and Allan Cecil from Bishop Fox Labs recently shared their findings regarding an RNG vulnerability in the foundation of IoT (Internet of Things) security. The critical flaw resides in hardware number generators (RNGs) and affects 35 billion devices worldwide.
“Basically, every IoT device with a hardware random number generator (RNG) contains a serious vulnerability whereby it fails to properly generate random numbers, which undermines security for any upstream use,” the researchers’ report says.
At the heart of the RNG vulnerability lies the inability to properly generate random numbers, thus crippling IoT devices’ security and exposing them to attacks.
What’s RNG, or random number generator?
RNGs are needed for most security-related operations that computers perform. These generates create the so-called “secrets” which form the basis of cryptography, access controls, authentication, etc. How these are generated is dependent on the end goal. However, the canonical example is the generation of an encryption key. “In fact, in many cases, devices are choosing encryption keys of 0 or worse. This can lead to a catastrophic collapse of security for any upstream use,” the report notes.
What’s the core of the RNG vulnerability in IoT devices?
Apparently, as of 2021, most new IoT systems-on-a-chip, shortly known as SoCs, contain a dedicated hardware RNG peripheral designed to solve this issue. However, solving it is quite complicated, and as it turns out, the current IoT standard can be described as “doing it wrong.”
One of the greatest perils takes place when developers fail to check error code responses, resulting in numbers less random than what is required for a security-related use.
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).
These are the most important parts of the hardware abstraction layer (HAL):
- An output parameter called out_number. This is where the function will put the random number; it’s a pointer to an unsigned 32-bit integer.
- A return value to specify any error cases. Depending on the device, it could be Boolean or any number of enumerated error conditions.
Almost nobody checks the error code of the RNG HAL function. Depending on the hardware, this could lead to one of the following problems: running out of entropy, the number 0, and uninitialized memory.
For example, “if you try calling the RNG HAL function when it doesn’t have any random numbers to give you, it will fail and return an error code. Thus, if the device tries to get too many random numbers too quickly, the calls will begin to fail,” Petro and Cecil say.
What are the solutions to the RNG vulnerability?
Since the two available solutions – aborting and killing the entire process, and spinning loop on the HAL function – are not acceptable, developers tend to ignore the error condition altogether.
Why is the RNG vulnerability only specific to IoT devices, and not laptops and servers?
The issue is unique to the IoT world, as the low-level device management is typically handled by an OS that comes with a randomness API.
The report also sheds light on the benefits of a larger entropy pool associated with a CSPRNG subsystem (Continuously Seeded Pseudo Random Number Generator) which removes “any single points of failure among the entropy sources.”
Full technical disclosure is available in the original report, titled “You’re Doing IoT RNG”.
Last June, a severe vulnerability, known under the CVE-2020-12695 advisory, was discovered in a core protocol in nearly all IoT devices – the Universal Plug and Play (UPnP) protocol. The flaw, dubbed CallStranger, could allow attackers to take over IoT devices in DDoS attacks. The bug could be exploited in other types of attacks, where security solutions are bypassed and internal networks are reached.