[Cryptech Tech] User auditable hardware entropy source/random number generator

[Benedikt Stockebrand]

Really really sorry...

Bernd Paysan <bernd at net2o.de> writes:

> [Overloaded USB interface on Youtube]
> Fair enough, this is a MacBook air, which signals the iPhone that it is 
> capable of charging it with those 1.7A using special Apple
> technology.[...]

so even with some high-end Apple gear the voltage drops by half a volt!
Now imagine what happens with some cheap Chinese fake gadgetry on a
non-Apple host...

> Hm, I'd rather use something like the MAX734 [...]

Several answers:

* I hadn't heard of it before.

* The MAX734 is much harder to get and an order of magniture more
  expensive.

* The MC34063 is widely available, cheap, used in all sorts of other
  devices, and many people (like me) have a few of them in their junk
  part box.  So even if everybody used it, that would make it an
  expensive target for a large scale attacker.

* That's why my stuff is modular.  You use a MAX734, I use a pre-built
  Pololu module (http://www.pololu.com/product/2117), Fredrik uses a
  wall-wart PSU, and to whoever wants to subvert the design at a large
  scale it would be three times the effort already.  We need that
  diversity.

>> And then of course, there's the *real* problem: How can we possibly test
>> for the relevance of such effects?
>
> By making a hypothesis and measuring things.  E.g. if you know that the MAX734 
> has a fixed frequency under constant load, [...]

Now let's take this a step further: How do we ensure that that
hypothesis is reasonable? And as per your example: Can we safely rely on
that property of the MAX734 if it may have been replaced with something
else by an attacker?

Again, this is where modularity enters the game, for testing individual
modules, for replacing suspect ones and for modifying designs to
increase diversity.

>> My guess is that the best bet is to make sure that whatever error
>> enters the game gets propagated in such a way that it is easily
>> detected on the output.
>
> If you know what you are looking for, you'll usually find it.

The important word here is "usually": I want to make sure I know by
design what to look for.

For example, with a HWRNG built like this, I can test/audit it with
rngtest and dieharder, and in various failure scenarios the device would
simply stop.  

But if I embedded the HWRNG in a CSPRNG and only allowed access to the
output of the CSPRNG, then the only way to find out if the HWRNG was
broken would be to first break the crypto algorithm in the CSPRNG.  In
other words, that's designed *not* to be auditable because the error
isn't propagated properly.

> In the end, the goal of a trustable noise source means that the device should 
> come with all the "measurement equipment" that is necessary to perform the 
> tests to show that everything is fine - that's more than simple health 
> monitoring.

Correct, but again, there's more to it: How do I audit the measurement
equipment?  If it is built in, it can be as easily subverted as the
device itself.  But this is a huge topic really, so I guess we leave
that for after the holidays.


Cheers,

    Benedikt

-- 
Benedikt Stockebrand,                   Stepladder IT Training+Consulting
Dipl.-Inform.                           http://www.stepladder-it.com/

          Business Grade IPv6 --- Consulting, Training, Projects

BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/