[Cryptech Tech] Suggested changes to TRNG

[Rob Austein]

At Wed, 30 Sep 2015 11:40:23 +0200, Joachim Strömbergson wrote:
> Rob Austein wrote:
> > 
> > The PRNG makes me a bit nervous.  I can see the arguments, but I can 
> > also see arguments for letting the user decide to exclude it.  Which 
> > brings me to the suggestion:
> 
> If you by "PRNG" mean the suggested third pseudo entropy provider

Yes.

> I can understand that there might be issues. But could you try to be
> more explicit what in it that makes you a bit nervous? Is it:
> 
> (1) Having an internal feedback path from the CSPRNG to the mixer?

No.

> (2) Having the pseudo entropy provider be exposed to SW to allow writing
> in your own entropy?

Yes.

> The basis for (2) is that a couple of people have said that the ability
> to inject your own entropy is something that might be useful and
> desirable. My suggestion solution tries to meet those wishes. It is also
> fairly close to what you can do to /dev/random in many OSes.

I can see arguments both ways.  My point was that I can imagine
scenarios in which one might not trust every line of software running
in the CPU, and therefore would like to minimize opportunities for the
CPU to mess with the TRNG.

> Sure. And for the two current entropy providers this would be quite
> easy. Basically the same method as we use for the core connector system
> with defines for things we want.

That would be the method that requires editing/patching version
controlled source code.  That method could be made more reasonable
(from the point of view of a build system) by moving the `define
statements to an external file which the version controlled code would
then `include; the file with the `defines would be generated by the
build script.

> For the suggested third entropy provider this can also work, but takes a
> slightly more work since if its disabled we want to ensure that the feed
> back path and read data mux at the CSPRNG end are removed too. The
> synthesis tool will happily remove them for us if we just remove the
> entropy provider, but the tool will complain about dangling wires and is
> not a very clean way of doing it.

I'm all for doing it the clean way.  What would that be? :)

> Also, the current entropy providers supports enabling/disabling from the
> API. I assume the third one would have this control via API too. So
> anybody that don't want to use it could simple disable it and it wont be
> used to provide values to the mixer.

Software control doesn't help for the case described above.

To be clear: I don't think that running any untrusted code on the CPU
is a good idea.  But we may not have a choice (read: we may not have
the luxury of writing our own operating system), and even if we do,
there's something to be said for least privilege.  If the use case
doesn't require software to be able to stuff bits into the TRNG,
tinfoil says it should be possible to configure the FPGA in such a way
that the software can't stuff bits into the TRNG.