[Cryptography] RAM memories as one source of entropy

Joachim Strömbergson Joachim at Strombergson.com
Fri Feb 7 07:37:45 EST 2014


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

Aloha!

I'm currently involved as pricipal HW designer in a project called
Crypytech, a project that aims of providing a platform for building open
HSMs. Platform in this case includes FPGA hardware design, SW design,
tools, documentation, test framework, guidelines etc.

https://cryptech.is/

Using Cryptech anybody should be able to assemble a HSM that they can
trust with high confidence.

One of the key issues is of course the RNG. My very loose ideas for the
architecture of the RNG follows the general multiple entropy sources
with collector, mixer and finally a CSPRNG that is reseeded with data
from the mixer. Something pretty close to what IanG describes here:

http://iang.org/ssl/hard_truths_hard_random_numbers.html

The platform should support two or more, different entropy sources and
our example implementation will use two (that is at least what I think
right now).

I would like to be able to have one purely internal entropy source, and
there has been some quite interesting research presented at CHES etc on
entropy sources within FPGAs. But this might not be feasible in a robust
way (too much reliance on layout which would require a lot of testing
for a given FPGA platform.)

For external entropy source PN avalanche noise is a solution. The one
problem I see with this source is that it requires analog circuitry as
well as A/D conversion to achieve the desired effect. This is harder to
build and needs to be tuned to work properly.

The question is then if there are other external sources that could be
used. One wild idea is to use decay effects in DRAM or initial state in
powered up SRAM memories as source of entropy. There has been some
research into this:

[1] http://goo.gl/25TFov
[2] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.164.6432
[3] https://eprint.iacr.org/2013/304.pdf

As can be seen in the articles, DRAM decay is slower and more sensitive
to device temperature than the SRAM initial condition behaviour. There
are also cells that due to process variance will strongly bias towards a
given state. This is why there are some abilities to extract a
fingerprint for a given physical device by averaging over multiple
readings of the initial state from SRAM memory. But judging by the
papers there seem to be real entropy that could be harvested.

The benefits of using a RAM based source is that the device and
interface is digital making it easy to integrate and would not require
any tuning. Also the device can be compact and cheap. As an example, it
might be possible to use a small, serial connected SRAM memory such as
this sub 1 USD memory:

http://se.farnell.com/microchip/23a640-i-p/ic-sram-serial-64k-1-7v-pdip8/dp/1695544

Reading the contents of the whole memory takes less than 5 us. Gating
the power supply (to switch it on and off) can be achieved for any
number of cycles between readout. The data extracted would the be hashed
using a suitable hash function and the result used as entropy from the
device.

Is using this solution as one of several entropy sources a crazy and bad
idea or somewhat sane? What would be the big caveats and gotchas? If it
is crazy, why is it so?

I'm assuming that the HSM will have active tamper protection and ability
to check its ambient temperature and detect if it has been put in a
freezer. And the SRAM memory used as entropy source would be dedicated
to entropy generation and not used for anything else.

Oh, and how about taking the some output and (possibly via a hash
function) write a random patterns into the memory before powering off,
this eliminate problems of residue patterns between power off-on-cycles.
Bad idea?

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

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

iQIcBAEBCAAGBQJS9NOZAAoJEF3cfFQkIuyNq9MP/0rugjL3po3+DGYG+FmEkuZb
27cLeDbRmWPswAnX1m2On1PNdRmcvobesy55KCUCgM+XBlrjqlMXVzd9KSaJdrKk
I++OMlgO47nl1f8KiVYBCJNrnmeKEtSDCRxCQ5YRXEqxK/uovB6N4dlIdMRKvZe3
A3CyCLSsWABMzXKj4J2p/XXWXpIdY74Y38HnuMgMfsjDUahah4ue1GuPAALHMiUO
Ys+2EKdWU5qq6CmTznV3XFTiBhE3Z3CU92R2mvlFICik7uVwGav66T9b4N+bQiHe
cWfOeyeaM2dF4NdZsWRWD+hadqhLMuIbeONtOuG4Yd2bFgz+C4aXWwedFAVZajGT
3Y7ov7vTIbyd+QS8G+TouiURRS0GoqyI0WWUDmk3YANw5YZbjO0xeblRv+1FUsTz
FtvQa8/oEfcSirW4g9qautQoMB3t/i6TszvBMHhP+eKFzfzAp/eXJO4owhe35vJn
V9A97sE3hTTf1Yfw2jqsJMPfnBqPYXoVdPYYO1qzmcjAS3KPnrJANL7Y2ozbL382
Xv09wspzFyO4j6+4NUmNXXjdsKdZ7PpjgbEiCjp/RXuEyZNL/S9owNE0bZ2qi+Vm
rVIQX0lyyM9L2/9fAJFVAYVX5YtJryKGcEduiHNg1WpVYQWfXMmM3SsQcFLb2mgu
d7tFg1enfixUn5UaYfzV
=sxhK
-----END PGP SIGNATURE-----


More information about the cryptography mailing list