[Cryptech Tech] RAM as source of entropy

[Joachim Strömbergson]

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

Aloha!

Steven Bellovin wrote:
> https://www.usenix.org/legacy/event/sec08/tech/full_papers/halderman/halderman_html/
>
> 
might have some data on that.

Yes, and Warren pointed to that paper earlier in the thread. That is why
DRAM is less interesting than SRAM. The reason for this is that for DRAM
we need to wait a given time to allow the memory to decay "enough" - and
that might be a long time.

For SRAM it is basically the opposite, we try to trigger a fixed state
from a power down condition. But there are remanence effects for SRAM
too. And they are relevant to the discussions about using SRAM as a
source of entropy as well as the storage of keys during operation of the
Cryptrec system. Warren Kumari mentioned that HSMs move keys in memory
around to avoid remanence effects.

The paper "Data remanence in semiconductor devices" from 2001 by Peter
Gutmann is a very good and relevant paper. He describes the remanence
effects and specifically points to the problem of having keys in SRAM
memories at fixed positions. This is something we probably should plan
to handle.
http://www.cypherpunks.to/~peter/usenix01.pdf


Sergei P. Skorobogatov has written several papers on remanence effects
and points to the need to detect that the ambient temperature for the
system to not be lower than a given level. If that happens keys should
be destroyd. This applies for all memories:

"Semi-invasive attacks -- A new approach to hardware security analysis"
from 2005 is a good paper:
http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-630.pdf

But Skorobogatov also shows that just temperature detection is enough.
We really should do active zeroisation of memories when a relevant event
has been reached (temperature, breach of tamper protection, unplanned
movement of unit etc.)

And external SRAM power supply connection should be automatically
shorted to ground whenever the power is off. Floating VCC seems to
drastically increase remanence.


The paper "Data Remanence Effects on Memory Based Entropy Collection for
RFID Systems" from 2011 by Nitesh Saxena and Jonathan Voris (from your
university Steven) is probably the most relevant for the discussion of
using SRAM as basis for entropy. The papers shows that the remanence
effects are bad enough to make it impractical to use in RFID tags in
which the memory is also used for other processing. The extraction of
enough entropy simply takes too long time. Esp. when the temperature
drops. A good paper.
https://www.cs.columbia.edu/~jvoris/papers/ijis_11.pdf


Finally there are at least some design work being done to implement SRAM
cells with remanence protection. The paper "Security strategy of
powered-off SRAM for resisting physical attack to data remanence" from
2009 describes modified SRAM cells that reduces remanence effects. This
is not very applicable to Cryptech though:
http://goo.gl/7T8Sll


Remanence can even be used as a clock the TARDIS protocol uses decay
memory decay as part of a secure protocol for embedded devices. Really
cool research!
http://goo.gl/zgeS1y


Conclusion:
- -----------
No, SRAM as a source of entropy is probably not a really good idea. Esp.
as the only source of entropy. We can use a dedicated memory, ensure
that VCC is properly grounded and write PRNG-generated patterns into the
memory. All of this would probably make the SRAM memory a better
entropy. But I think the writing is still clear enough to not continue
with this.

But there are still some good issues regarding SRAM (and DRAM) memory
usage to be learned here. Issues we still need to consider, plan and
design for in order to mitigate remanence in all other memories we will
be using in the Cryptech system.


(And someday I will test my SRAM as entropy with PRNG feedback idea,
just to put my curiosity to rest.)

- -- 
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/

iQIcBAEBCAAGBQJS+KFAAAoJEF3cfFQkIuyNMGgQAKtcsI6WsT14TSHXFHeHxnaD
IgZC5Tle0sQGSiCslox5Ww5VEizqh/h9YeL9xzjG+FT7tS6rUXWxnoBj703MO0Ug
DPg7A6qQqkEFmXs9DhNIWRqJ33TbOUj+DZN6X2pmV3WZ1s1r+99OjfpH9tpPcgT9
Gcnt9mfHuu/s5I0zR0mMprwh8hM0xFLBYTos7YIQz+AcaryqB8ShtA4qAjt4iJGR
0PxOVhX6n4P3bm2WLHPJXucT04vb2PVDZNXT7+Pw3nA8XRBN9Yk1QJX133+vdykw
+GwuJALgCnVtYh0tfa7f5QmbfhivVShOiFqyrMd4F+q0jv1MTwCJw2ODoZDoy/f0
TaWDwWiKm4ZDpsqBxYFwysUaQZm9xIYK1cOuMRxmvrahnxIcfrNQyMuyC9HEnUz0
lOxEqhXKD/gJbdYLaLUDSdmZ0Qyz+Q3kFxpzcrwWLLqzJ136zzTSQn02qrITy2IZ
M6Q+OwvF7gQwDeykTV3hEKHPpr4fLJe6WSjwCE3xnOESwoQZgcaAI7IxeOV2WcdC
lJc2MA7H7yC4mtFe8ITEpf/Vm2mSJbpMEeDwo/yxjP1FlN2jnT+4xhllOz/Bmxwy
4G2utfjDWvfOxkuWDvvuwKGkmQZoWiUdm+NgWALISIqaLoQP7wf4OoBxqpYZ+rU1
J79g2uB3uXdcqohUMBpn
=TBLF
-----END PGP SIGNATURE-----