[Cryptech Tech] Hardware entropy

[Joachim Strömbergson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Aloha!

Bernd Paysan wrote:
>> As Fredrik wrote we will kick of a sub project that will produce
>> the design of a stable, well tested PN avalanche noise based
>> entropy source.
> 
> Fine; that means an external circuit.  PN avalance noise is a good
> entropy source.

Yes external. PN avalanche noise sources are non controversial, are used
in a lot of security and embedded settings and will therefore be our
base entropy source.


> Modularity is good; the problem with RdRand and the internal entropy
>  collections in Linux and OpenBSD however is that you don't have
> access to the raw entropy pool to check if it is good - just to the
> conditioned output - which by definition looks good, even if it
> actually isn't.

Exactly. What we try to achieve is not only a good RNG, but a good,
transparent and testable RNG - without compromising security.


> The "debug access to the raw entropy" is definitely a must-have.  i
> would prefer not to have an injection path to the TRNG; you may use
> the CSPRNG in isolation with a separate state, and test it that way.
> Crafted injection into the TRNG should be avoided; the first blog
> posting of Dan Bernstein's blog was about entropy attacks:
> blog.cr.yp.to/20140205-entropy.html

Yes. Your comment shows that I need to clarify the presentation. The
idea is _not_ to allow injection by default, but only when the RNG is in
a specific debug/test mode. When in this mode you can only generate a
limited number of random values - enough to confirm that seed values
result in the expected values from the CSPRNG. When leaving debug mode,
the whole RNG state is discarded and reseeded based on entropy collected
after exiting the debug mode.

Access to the raw entropy is also done in debug mode, but you can
extract as much entropy as you want.

That is the idea at least.

Do you think that access to raw entropy should always be possible - even
raw entropy used for mixing and SCRPNG to generate production values?

There has been discussions in allowing injection of entropy from a
separate source. I can accept that if it is treated as just an entropy
source that is mixed with other source. I really am vary of RNGs that
allow mixing just pre of the RNG or at the random number output stage.


> ... SRAM as entropy source also works for embedded controllers: You
> can gather the entropy of the SRAM at startup, and then run a DRNG
> with enough internal state for the rest of the operation (make sure
> it is a history-keeping DRNG, see below).

;-) You should check the @tech archives - we had a some lively
discussions on this a few months back. I really think using SRAM as
entropy source is an interesting idea, few seems to agree though there
are some papers that shows some promising results.

The solution I want to test is to have a small, external SRAM outside
the FPGA. Using a MOSFET switch toggle the power to sram and in between
power off read out the contents of the memory. The contents is then
hashed to get a value out. Due to bias there will be memory cells that
always end up in the same state, but hopefully enough of them will not.

The good points with this entropy source is that it is cheap, easy to
build, have a simple, digital inrerface and should be possible to toggle
fairly frequently yielding good capacity. Also, as long as the interface
is protected against probing and/or injection, it is fairly robust
against manipulation.

A variant of this is to actually write random patterns into the memory
before powering it off. Basically have fairly good PRNG (SipHash for
example) that is seeded with some of the values generated from the main
CSPRNG generate data written into the memory.


> I'm using the Altera DE1 board. Not as new, but more than enough
> gates for the things I do (usually b16 stuff; any experiments I would
> do with an entropy source would first have a b16 core attached to do
> the data aquisition and then send the data to the PC).

That board should do fine. The TerasIC DE0 Nano is also nice. The
coretest-system I pointed to allows you to easily access cores from the
PC to read out data (or write to registers in the cores). This is how
I'm testing the cores on the DE0 and the C5G boards today.


> All the Merkle Damgard constructs have known structural weaknesses;
> that was the reason for starting the SHA-3 competition... so they are
> all broken, at least in theory.  There's no practiacal attack on
> SHA-512, though, but SHA-3 doesn't even have the theoretical
> weakness.  The comfort level with "old and proven to have a
> structural weakness" should be lower...

We are probably reading the results from the SHA-3 compo a little bit
different. I followed the compo quite closely (in fact I actually
supplied one of the papers that tested implementations of Keccak in
different FPGA devices as part of the compo).

If I understand the big guys correctly, the worries that triggered the
compo has been dampened during the compo. And based on the knowledge we
have today, the trust in SHA-256 and esp SHA-512 is higher today than
before the compo. Several of the finalists, Blake and Keccak seems
really good. The way NIST have handled Keccak after the completion of
the compo less so.



> I'm not fully comfortable with this construct; it's ok for crypto,
> where your security depends on a single key, but IMHO not ok for
> conditioning a TRNG, where your security depends on the entropy
> source.  In essence, the algorithm is that you have an input, which
> is key+counter+nonce (the key comes from the entropy source), and you
> generate an output for that, which is not related to the input (which
> comes from the entropy source).
> 
> This is fine for crypto (where the entropy source is your session
> key, and you have only one of that, and it has to be perfect), with
> the caveat that a constant starting point may provide ways for
> side-channel attacks, but the problem with conditioning a TRNG is
> that when the entropy source is poor (your "key"), it will result in
> predictable random numbers, when you also reset the counter when "new
> entropy" (which is actually mostly the same as the old entropy, as
> the attack vector here is a bad entropy source) from the entropy 
> source arrives.  Don't.  If you don't reset the counter, you still
> have the problem that infrequent use of the crypto device starts with
> a predictable counter...  The problem here is that there's no history
> of the entropy, and that it should be sufficient if the entropy
> generator produces about 512 bits of entropy at startup - there's no
> need for more bits than those if you accumulate entropy.

Yes and no. If you don't have good, unpredictable seed values after
mixing then you are in dire straits anyway. This mirrors the discussions
Matthew Green, IanG have had and it basically boils down to that if one
has a key stretcher (CSPRNG) like most modern RNGs in OS:s today do, as
long as you trust that the seed is good enough, using a good stream
cipher should generate good, unpredictable random numbers.

What DJB has been argumenting is that if the stream cipher is trusted
you really never need to reseed either and in fact might be
counterproductive.

For me it is also important to try and innovate within the bounds of
what a lot of people think are reasonable and good, mature solutions.
Not stay to far from common practice.

That is why I want to have multiple sources, having a two stage DRBG
with mixer/conditioner followed by stream cipher based key stretcher
that generates the values. Using ChaCha/XChaCha is a bit controversial
and AES-CTR has been suggeested. I think there are enough trust in
Salsa20, ChaCha to use it. And what I like with ChaCha is that I can
turn the knob, increase the number of rounds to get better security and
still get good performance even with much more rounds that even DJB
thinks is conservative.


Regarding FPGA internal entropy sources (did you read the report?) I've
decided to do a simple test run. Something to do in a weekend. ;-)

- -- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================
 Joachim Strömbergson          Secworks AB          joachim at secworks.se
========================================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJTdwFTAAoJEF3cfFQkIuyNRTUP/RsddlUBz52vWmCT82A3C0UR
TS3CvW1/o8+KBt0vfiYquCYT+ZuncpQNdXBTKV+aCwRbv72V03PAdukpXnYLuLos
DhVW1sKbFPG0EOfZUKL5EmOJ6Kioly6nqOIOJaYRv8gYV3EZb3DxB+4vVeQwDOHi
sloRRg0DGxniX89GuHoJy03lUKIw5VTSwbXL19LofRYLCoHCseLceQ5EKVQsYlHo
QV1hBezjTARsv3MUlRzZnDcBXwEyC9EMQAc84XK/EXGgDB+V4xPis1PcE/PCo807
7W/RC19FQWhOAf5ZMiTQGm8wEnrFGhXOh5jOM4L1E8iTrRtlrrywC+1m0kgSqb4O
X1wTXuuc1vtaDSSpGSIug+C6/lh3701tTvkQWb2US3Zw8uvsE3GQtRktvZksXJ6r
VIRabanwlovTpyL1U1sui9jWc+F8fdeKfptFmzotLo7Z8MQJAtHnPM6vK274ToNj
QgqP6NCGKjBZXU5jJjK043z2JOaQ65Hyd3oWpDxgQ/MarQY3eH0vMLIj0WYompON
q/KXad6r5i1Rb+1aKyUbxk0xh3U8vMo8sJvP69KCGwdDJpyRFeksyJiKu/JkuXAt
+JOrQzic1GX6BhgyaQbFVDJtrngptHAxFVt6+Ff/SwfRmaqFDZsn5KuA1rHi+NZf
JQfEhofEuH9hwkGT5FXf
=aYjH
-----END PGP SIGNATURE-----