[Cryptech Tech] Hardware entropy

[Bernd Paysan]

Am Sonntag, 18. Mai 2014, 10:00:12 schrieb Joachim Strömbergson:
> I can send URLs for the papers I've looked at. But from the published
> reseach the remanence-effect is _much_ shorter than seconds.

Yes, for high-density SRAM, decay is pretty fast.  I did some measurements on 
0.5µ SRAM about 10 years ago, and most content did survive surprisingly long. 
Also, many bits have a deterministic result.  That's a few dumps of the 
external SRAM on the Altera DE1 board, turned on/off with the button:

8000: B539 2140 5487 0003 BA0E 86A8 73A3 C61B
8000: B439 2140 5487 4083 BA1E 87A8 63A3 C43F
8000: B439 2140 5487 0003 FA0E 86B8 63A3 443F
8000: B739 2144 548F 0003 BA0E 87A8 63A3 C63F

For quick and easily gathered startup entropy after power on, hasing the 
external SRAM (at least several kilobytes) is a good idea.   You should get at 
least one bit of entropy per word.

> It will be really interesting to see the design and test it. We will
> have the Novena board up and running and that includes a Xilinx Spartan
> 6 device. So we can test your source on several different Altera devices
> as well as on Xilinx FPGAs.
> 
> How far are you design and implementation-wise?

I've started with ring oscillators, and got them to synthesize.  I'm still 
testing them; files attached.  The rosc.v is a single oscillator cell, the 
rng.v is a module which can be attached to the b16 bus (that's what I do for 
testing).  The idea is that you have two of these oscillators xored together 
to give you one bit of entropy per sample (sample frequency depends on jitter, 
which I still have to measure).

The next step of testing is writing a small b16 program which subsamples the 
ring oscillators by copying them in a tight loop to memory; this subsampling 
will give jitter figures; if the subsampling with a program is too slow (i.e. 
the jitter is too high), I will have to add a small DMA controller... I 
certainly would be happy about too high jitte ;-).

As I use the carry chain as active delay elements, the layout engine gives me 
good results without manually interfering with it (pretty reliable placement).  
The two inputs (which have to be complements of each other) are just dummies 
to make sure the tool can't optimize anything away.

I will test different delay element lengths, too; the shorter the cycle, the 
less stable the frequency (and that's what we want here).  I suppose that 
ideally, one carry element plus the inverter should already result in 
oscillation.

BTW: If you want to extract more bits out of the noisy diode, we've done 
delay-based DACs in an FPGA some years ago.  You add the input signal to a 
sawtooth wave generated from the clock, and then feed that into a delay chain 
of these adder carries. Sample the "sum" (which is just delayed carries, i.e. 
a threshold 1-bit version of the sawtooth) at the next clock, and sum up the 
bits.  This is pretty fast (we did a 108MHz 8 bit DAC that way; that was 
certainly not a clock-by-clock exact sampling, but good enough for our 
purpose).  It has offset (and temperature dependent overlap over more than one 
sample), and non-linearities at the upper and lower ends of the signals, but 
that wouldn't be a problem for entropy gathering.  It makes tampering with the 
diode noise much harder, as the replacement would have to create deterministic 
"white noise", not just a random looking pattern.  Noise amplitude and 
frequency limits could be detected, as well.

-- 
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: rosc.v
Type: text/x-verilog
Size: 390 bytes
Desc: not available
URL: <https://lists.cryptech.is/archives/tech/attachments/20140519/dc6690d5/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rng.v
Type: text/x-verilog
Size: 1018 bytes
Desc: not available
URL: <https://lists.cryptech.is/archives/tech/attachments/20140519/dc6690d5/attachment-0001.bin>
-------------- 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/20140519/dc6690d5/attachment.sig>