OneRNG

It has a Tin-Foil Hat

It has a Tin-Foil Hat

Entropy Generator

The cake is a lie …

By default, OneRNG measures unpredictable physical events
from an avalanche diode circuit
and returns the results — but this is a bit too raw to be used directly

Whitened data

This raw data is then whitened through a CRC16 function which makes it good enough to be fed into your system

There is an AES hardware module available, but it is not used

Keep topping up the pool

There's a 7.5KB pool of data that is kept full

New data is mixed in over the old data all the time

A LED on the board tells you when the pool is full
and warns you when it is getting empty

/dev/random

The results are fed into /dev/random as an additional entropy source for the system, and you should read them from there

If you RTFM, you'll read from /dev/urandom most of the time on Linux, but not necessarily on other OSs

And there's more …

You can also enable the RF monitor to get another source of entropy data with a higher quality — but at the cost of a little paranoia

The flow of data

PRNG

Most of the time you can get away with pseudo-random data

Don't use the default <INSERT_LANGUAGE_HERE> random() function!

Don't use PID, or μsecs since epoch, or wall time

By default, use /dev/urandom

True RNG vs PRNG

Even if your PRNG is a CSPRNG, you'll feel the need for seed

Get your seed values from a True RNG

Generate your long-lived private keys from a True RNG

How much random can a /dev/random random?

Never mind the quantity, feel the quality

… unless you needed quantity, that is …

If your True RNG returned sufficient data, why use PRNGs at all?

Known Badness

• RSA SecurID token breach
• The entire Certification Authority system
• Dual EC_DRBG, $10 million NSA/RSA deal
• RdRand and the Sigint Enabling Project …

Known Badness II

• Supply-chain interception
• BIOS Chronomancy; will persist across reflashing
• Supercookies, Evercookies
• NSA vs Vodafone (aka "We are the 43%")

How far is too far?

When risks are “addressed” they are usually pushed either up or down the stack

They end up requiring trust in End-User Behaviour (unpatchable) or in the Hardware

No Trust Needed

You should not trust this device — you do not need to trust this device

You should VERIFY that what you physically hold is what you need to have

How to verify the hardware

1. Remove the Tin-Foil Hat (ours, not yours)
2. Identify the components
3. Identify the connections, top and bottom
4. Research the one complex component, the CC2531 chip
5. See how much storage it has (256KB or 128KB)

How to verify the software

1. Plug the device into a machine
2. Dump the firmware into a file
3. Confirm the data is the full 256KB
4. Validate the GPG signature
5. Confirm the data is ‘uncompressible’

Scripts on your server should do steps 2,3 & 4 on startup

What does verification tell you?

• The hardware you received conforms with the description
• The firmware that is used matches the source
• Tampering would be detectable

Image Credits

Icons used are from The Noun Project, http://creativecommons.org/licenses/by/3.0/us/ licensed

Arrow and Bent Arrow by Thomas Le Bas, Dice by Weston Terrill, Toothbrush, Radio by Joe Harrison, Avalanche by Louis Dawson, Swimming Pool by Sitara Shah, Clock by Nick Green, Guy Fawkes by Christopher T. Howlett, Pac-Man by Luigi Di Capua, Surveillance by Luis Prado, Audit by Miroslav Koša, Skydiving by Jual Pablo Bravo, CPU by iconsmind.com, Certificate by Alex Auda Samora, Incognito by Alen Krummenacher, Layers by Cornelius Danger, Search by Melvin Salas, Seed Packet by Anton Gajdosik (Public Domain)