[Cryptography] True RNG: elementary particle noise sensed with surprisingly simple electronics

[Ray Dillinger]

On 09/16/2016 06:55 AM, Thierry Moreau wrote:
> On 16/09/16 02:54 AM, Ray Dillinger wrote:
>>
>>
>>
>> One small-ish problem with electromagnetic noise is that it can
>> also be described using the word "radio." ...

>> Still, whatever can be done with radio, they remain unpredictable
>> to anyone who isn't doing an expensive attack that requires human
>> time and attention (and risk) to monitor a single target.  That's
>> valuable.
>>
> 
> I don't understand this last sentence. Valuable to who?

The majority of users don't have a threat model that includes
sophisticated actors who are willing to devote time, attention, and
manpower to attacking their systems on an individual basis. Instead,
most people have to worry about untargeted, automated, attacks of
opportunity.  These attacks have the simple goal of suborning or
eavesdropping on as many systems as possible without regard to which
ones. Nobody is going to deploy expensive hardware and even more
expensive human agents in the field to further them with respect to any
particular system.

The majority of users who *do* have such a specific threat model (high
value targets) also have physical security that should make it extremely
difficult for such agents to put the equipment in place and then monitor
or control it.

And, as I see it, the device is valuable to both of these majority
classes of users regardless of any mild susceptibility to EM interference.

>> I think that, rather than building a complex device that
>> people then have to trust, we should be building very
>> simple devices whose entire functionality (and therefore
>> trustworthiness) can be determined by visual inspection.
>>
> 
> A device that start very simple (e.g. resistor current noise) turns not
> so simple when design details are turned into attack vectors in the
> discussion. In practice, which type of device is promising in the above
> perspective?
> 
>> Start with an RFC or a standard, that specifies a wire-
>> level serial interface for devices that generate "random"
>> bits.
> 
> Easier said than done. Such a specification document would need a
> definition of "random" ...

No.  What it requires is a specification of a wire-level protocol via
which such a device communicates with a computer.

Let the philosophers debate a definition of "randomness."  Let customers
and makers decide for themselves what definitions they accept and what
hardware they trust to fulfill  them.  A fully deterministic device
producing an infinite series of 1s could meet the communications spec.
It would have no value as a source of unpredictable or "random" bits,
but that is outside the scope of a communications protocol.

> Alternately, the digital I/O pins could be directly connected to the PC
> parallel port, but that is not fashionable these days (hence not
> "running any code" is not achievable in practice).

USB stands for Unsecured Serial Bus. Secure machines have their USB
ports filled with epoxy.  I would not buy a USB device for any security
purpose. I would prefer a device with a DB9 serial plug.  Preferably a
plug made of transparent plastic so I can see every wire and verify that
there is nothing else inside it, or one that I can cut off and replace
with a random DB9 plug that I take from a generic cable.

Serial devices are also simple enough to build with zero chips that
things can be hidden in, and USB devices are not.  If people insist on
using USB, adapters are widely available, but any built-in USB
functionality could be a place to hide things. The absence of a USB
interface would add significant value to any device intended to be
manifestly trustworthy.

>> If a paranoid is
>> supposed to trust the device, then either it will be
>> because s/he built it him/herself, or

> A problem I found when attempting to reduce the system integrity (visual
> or whatever) inspection property is the following one: once the system
> integrity finally rests on a very simple and small system component
> (e.g. the device you suggest), the inspection either turns into an act
> of faith, or requires sophisticated tools (not very practical). Indeed
> someone pointed at the attack vector of a high quality noise-free
> resistor hidden in the package of a cheap noisy resistor.


And most people are willing to trust makers at the component level for
an extremely simple device whose electronic components are visible.
Those who are not willing, are the very same paranoids I mentioned who
will insist on building a device themselves from individual components
they buy and test themselves.

This, IMO, is why there needs to be at least one very simple schematic
calling for widely available standard parts.  For the paranoids who
won't trust it unless they build it themselves.  The scheme you proposed
(current noise) presents a reasonable method for building one.

It needn't be the only schematic for devices meeting the wire level
communication spec and purporting to provide unpredictable bits, nor
even the only schematic simple enough to self-build; but at least one
such schematic needs to exist and be public so anybody can build it.

> Here you are asking for interoperability between HW and SW based on a
> specification. The definition of "random" (now "unpredictable bits") is
> challenging: 

Again, defining "random" is for philosophers.  It is the makers and
users who decide for themselves what definition they accept, and they
will not care what the philosophers say about it.

> beyond the O/S device driver, there is a randomness
> extractor software component that depends on statistical distribution
> hypotheses that the "simple device" would need to match.

Every OS comes with a functioning randomness extractor built into
dev/random that is better than the one you could create for another
driver.  Rolling your own would be stupid.  The device driver should
just write the bits produced to dev/random.

If you're worried about counting how much "entropy" you get from the
device, you can test it. Pipelining through gzip can compensate for
simple bias and any easily detectable statistics.  Measure the ratio of
gzip's output to its input from the device, and that's (about twice) the
amount of entropy you should credit via an ioctl call per that amount of
device input.  You don't need to run gzip during runtime; just keep
feeding raw device output to /dev/random, credit it for the appropriate
compression ratio revealed by your gzip test, and dev/random will do the
right thing.

You might even want a cron job that repeats the test at intervals and
updates the entropy ratio or raises a security alert if it changes
significantly.  But for god's sake don't do anything more complicated
than that.  dev/random works, and gets audited routinely.  Every
component you introduce for this specific purpose will need its own
expensive security audit for any professional use, or be seen as a place
to hide things.

Most people, most of the time, aren't attempting to count "entropy" any
more.  Aside from being another squishy concept suitable only for
philosophers, it has not been found to add much value to the subsystem
in practice.  They should be calling dev/urandom for almost all purposes
provided that it's more than a minute or so after bootup.


> May I stress the main point in my original post: the resistor "current
> noise" would be a good source of true randomness when sampled by the
> same electronics as in a digital weight scale. 

Yes, it's a fine source of unpredictable output. IMO such sources could
be made much more useful useful by a "standard" way for computers to
read the output and a way to build it so that it is _manifestly_ and
_visibly_ trustworthy.

To me the value of your idea is that here is a way to build something
that is visibly trustworthy because it's made of simple components and
can be built in a way that every component and circuit trace can be seen
from outside the device.

				Bear

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160916/2d374668/attachment.sig>