[Cryptech Tech] Hardware entropy

[Bernd Paysan]

Am Montag, 19. Mai 2014, 21:37:23 schrieb Joachim Strömbergson:
> Yes, interfaces are important and I hope what I've suggested as first
> draft is ok. But during the first year or so with say 1-5 entropy
> sources and a few mixers etc, we can change around things.
> 
> But let me just try to explain how I'm thinking and why I belive it will
> actually be pretty easy to add entropy sources, change the core used for
> mixer (SHA-512 vs Keccak vs Blake vs ...) etc.
> 
> If we ignore the debug support I've been discussing with Berndt, the
> data path from entropy source to generated random number look like this.
> 
> (1) The first stage consists of a number of entropy provider modules.
> One for each entropy source used in a given implementation. This means
> that there will be one to N entropy providers.
> 
> The entropy providers are digital HW within the FPGA and their purpose
> is to act like a driver for a given type of entropy source. This means
> that they contain the interface logic to control the entropy source and
> read sampled values. If the entropy source is a PN avalanche noise
> source this means controlling the reverse bias current and reading from
> the A/D to get ones and zeros.
> 
> The entropy provider might do whitening and will do on-line testing of
> collected values to observe that the entropy source is at least not
> dead. The entropy provider then collects these values into 32-bit words
> and feeds them into a FIFO.

From a transparency/debugging point of view, I would advice against whitening 
in the entropy provider.  Testing for "entropy source is alive" is a good 
idea, but from a design point of view there should be several modules which 
perform different tests.  The designer of the entropy source then can choose 
blocks to monitor his source.

> This means that there is a FIFO at the output end of each entropy
> provider and they are in a sense generic. The only difference between
> two types of entropy providers is how many 32-bit words they can provide
> in a given time.
> 
> I'm sure that the FPGA entropy source Berndt has been talking about
> could be wrapped into an entropy provider like that.

Sure.

> In short: All entropy sources have a companion entropy provider core.
> Each entropy provider core is different in terms of interface towards
> the entropy source. But the interface towards the mixer is always the same.
> 
> 
> (2) The mixer has a number of input ports, each look the same - the read
> access interface to the FIFOs in the entropy sources. The mixer looks at
> the FIFOs for available 32-bit words and extracts them. The suggested
> way of doing this is round robin to get fair queueing.

There are two attack szenarios you can assume: An untrustworthy entropy source 
(e.g. the injection source) might want to take control.  That szenario means 
you should avoid taking entropy from that single source only, when the other 
entropy sources are slower.  But on the other hand, if you do a 100% round 
robin scheme, you'll get stuck if one of the entropy sources gets stuck.  
Getting stuck is always possible when the health monitor detects a defective 
input (e.g. assume your diode is zapped).  I would suggest a m of n scheme, 
try to read at least m different sources out of n selected per round.

> In my implementation using SHA-512 i basically extracts as many 32-bit
> words as needed to create a 1024 bit message block. This is then fed
> into SHA-512 and processed. After X message blocks the digest is
> extracted and fed into a FIFO.

Looks fine, though there is one thing I'd like to recommend: when the digest 
is extracted, don't re-initalize the SHA-512 state, keep the digest there (so 
that entropy accumulates forever).

> That is basically it for the mixer. Shanging this to Keccak will change
> how many words are consumed for each 512 bit word generated and how many
> cycles it takes. But the interfaces does not have to change.

Keccak can also be used as expander.  I.e. if you have a switch matrix to 
connect things together, you can use the Keccak block both as normal mixer 
(output goes to another CSPRNG), and as combined mixer and stretcher (output 
goes to the rest of the Cryptech system).

I wouldn't take more than 1024 bits of input in one go with Keccak either 
(capacity 576 bits).

> And the only difference between mixers are how many entropy sources it
> can use and thus how many interfaces it has.
> 
> 
> (3) The CSPRNG has a 512-bit interface connected to the FIFO in the
> mixer. When it is time to reseed and there is a 512-bit word available,
> it is extracted from the FIFO in the mixer and is used to initalize the
> CSPRNG. The CSPRNG then starts generating random numbers. These numbers
> are fed into a 32-bit FIFO which can be accessed by the rest of the
> Cryptech system, applications (via calls into Cryptech SW and down into
> HW register reads.
> 
> In short, the CSPRNG accepts 512 bit words and generates 32-bit words.
> How many cycles it takes to generate new words and how often reseed
> happens depends on the algorithm used, how the system is configured. But
> the interfaces should be possible to keep the same.
> 
> > By the way: I am amazed that hardware development is now starting to
> > be Open Source.
> 
> There isn't that much compared to all SW projects but OpenCores has been
> around for many years and esp the OpenRISC procsessor core is cool and
> today pretty mature:
> 
> http://opencores.org/

Indeed, open hardware is nothing new.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.cryptech.is/archives/tech/attachments/20140520/70cf06a3/attachment.sig>