[onerng talk] design decision questions

[Paul Campbell]

(sorry to take so long to reply, I'm travelling, slowly moving my timezone 
....) 

On Mon, 29 Dec 2014 01:07:50 Gerd v. Egidy wrote:
> you mean measuring the specific bias of your device when you bought &
> verified it and then later on during use checking for that specific bias as
> something like an id of your device?
> 
> I don't think that will work particularly well with the hardware design of
> onerng: it is using two separate transistors. When there is a small
> temperature gradient between them, the characteristics of them will change
> differently. Also they slowly drift with age and humidity.

We expect this - the thing is that this is a $50 device, not a $500 one - it's 
not just the bias at generation, but also down the amplification chain to the 
point where it's sampled into the digital domain - and the associated 
metastability at that point (actually a good thing!) - the design has been 
tweaked to be 'about right' with the knowledge that there's going to be a 
range, we could build something that had resistors tweaked on the 
manufacturing line but then it would cost a lot more than $50 to manufacture 
....

I actually build my first prototype with 3 noise sources , and discarded the 
ones that didn't seem to be stable (for example the thermal noise  RNG I built  
seemed particularly susceptible to external noise which is bad).

In the end I went with the internal RF noise source, it was essentially 'free' 
and there's already some analysis of its behaviour in the cc25xx data sheets.

Plus I added almost the generic avalanche circuit you find all over the web, 
even using the same parts - why? because I want people to be able to verify 
the circuit by comparing it with what they can find lots of other people using. 
I think that verification is as important as performance, maybe more so .

We do have a different way to solve the issues about making 7.5 bits/byte or 
even 7 (assuming the hardware degrades) - we keep the engine running all the 
the time, if you don't pull entropy from the device at the full rate we 
combine more entropy into the on board pool - if you're pulling data slowly 
(say 10k bytes/sec)  rather than 60kbytes/sec you're effectively combining 6 
bytes into one turning 7.5 bits/byte into ~7.9  etc 

(having said that I actually think that as far as confusing an attacker 7 
bits/byte of entropy and 8 bits are both probably pretty effective provided 
you're feeding them through an appropriate PRNG)

> To protect the device against hardware tampering or replacement against a
> fake device I'd suggest different methods like digitally signing and
> encrypting the usb datastream, combined with activating the readout
> protection and filling the shield with epoxy.

we sign the image in the device, the internal CPU doesn't have the oomph to do 
crypto in software, but does have an AES unit so it could .... but if we can't 
trust RNGs  we can't trust our own AES that we can't realistically validate 
... that doesn't mean that someone else can't use the AES to encrypt the USB 
connection - that's what the programmer is for :-)

As Jim mentioned we want people to be able to verify is what they bought by 
comparing the circuit with images - potting it stops that, and frankly the NSA 
can repot something if they really want to, and then you can't tell if they've 
hacked on it - once you've received the device and verified it's what you 
ordered, feel free to pour epoxy in there (make sure you choose a mix that 
doesn't overheat as it cures), or just drop a dab underneath on the 
programming contacts.

	Paul