Random Number Generation Weaknesses in Embedded Systems

Embedded random number generation audit pipeline, from finding the source to assessing impact

Cryptography assumes good randomness. Keys, nonces, session tokens, and challenges all depend on it, and embedded devices are where it most often fails. A weak random number generator does not crash; it silently makes secrets guessable. Here is how to audit randomness on a device and what failure looks like.

Why Embedded RNGs Fail

A microcontroller has no mouse movements or disk timings to draw entropy from, and it often needs a key seconds after power-on, before any entropy has accumulated. Developers reach for the system tick, a serial number, or a fixed seed, and the result is a stream that looks random but is not.

Step 1: Collect and Test the Output

Capture a large sample of whatever the device generates, then measure its entropy:

Anatomy of an ent entropy test command run against captured device output

ent -b keystream.bin

Example output

Entropy = 5.21 bits per byte.

Optimum compression would reduce the size of this 65536 byte file by 34%.
Chi square distribution ... would exceed this value 0.01 percent of the times.

Healthy randomness sits near 8 bits per byte. A result of 5.2 with high compressibility means the stream carries far less entropy than its length suggests.

Step 2: Look for Reuse Across Devices

The most damaging finding is the same value on multiple units. Generate a key on several devices and compare; duplicates mean a shared or predictable seed:

sort device_keys.txt | uniq -d | wc -l

Example output

Seven duplicate keys across the sample means several devices share a private key. An attacker who buys one unit holds the key to others.

Three RNG Failure Modes

The usual ways embedded randomness goes wrong:

Three embedded RNG failure modes: a predictable seed, no real entropy, and a reused nonce

Fixing Randomness

Use the hardware RNG the silicon provides, seed the CSPRNG from it, and never generate keys before enough entropy is available. Where keys must be unique per device, provision them in manufacturing from a trusted source rather than generating them on first boot. Test the output, do not assume it.

Where This Fits

Auditing entropy sources and checking for key reuse across a fleet is part of a product security assessment. That analysis is the kind of work we do at Berkner Tech.