On Github OneRNG / MulticoreWorld2015
An open solution to a core security performance issue
Jim Cheetham
Information Security Office, University of Otago, NZ
<jim.cheetham@otago.ac.nz>
Security, Unix/Linux, Networks
Operations & Architecture
Who else has a copy of our data?
What if our data has been corrupted/altered/lost?
Failure to record valid observations?
Encryption prevents an unauthorised system from understanding any data that they have found
A single key is used both to lock and unlock the data
Two related keys are needed; one locks, the other unlocks
This is not my expert area …
Use known seeds when testing your simulation code
Use True Random seeds when conducting your research
It is a small USB-connected device
It speeds up & increases your computer's ability to provide you with high-quality random numbers
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
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
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 by the default firmware (trust issues)
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
The output from OneRNG should be used as an Entropy input to your existing systems (preferably OS)
We provide ~7.5 bits of entropy per byte of data
The user controls the choice of sources
The user controls the use of Whitening
The user controls where the results go
OneRNG was originally designed to help end-users improve their online privacy
Current demands for seed values outstrip the available Entropy
Online privacy advocates should be quick to distrust …
Being an Open Hardware and Open Source solution is a start
But the OneRNG is also designed to be verifiable
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
Scripts on your server should do steps 2,3 & 4 on startup
To get volume production set up, we used Kickstarter with an NZD$10,000 target over 45 days
Rewards Options
We offered combinations of:
As of mid February 2015:
The NSA-designed SHA-1 was not fully "trusted"
The blocking behaviour is a defence against this untrusted DRBG
Ted T'so, 2015 “… the paranoiacs were *right* that the NSA had introduced a back-door into a crypto algorithm which they gifted to the civilian world. It just turned out to be DUAL-EC instead of SHA-1.”Just use /dev/urandom :-)
These are fundamentally the same :-)
They will behave identically with sufficient entropy
Use /dev/urandom
Use /dev/urandom
Use /dev/urandom
If you already know better, you don't need me to tell you what to do
Even though you should use /dev/urandom
OneRNG helps to avoid the need to block
Therefore systems that use /dev/random run faster?
(Catalyst are simlating workloads to quantify this assertion)
A small quantity of good entropy is enough to improve everything
But the more sources of entropy you have, the better off you are
As well as OneRNG, please add other sources
Presentation resources :-
Software - reveal.js, hosted on Github
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, Infographic by Rob Gill, Seed Packet by Anton Gajdosik (Public Domain)