[Cryptech Tech] RAM as source of entropy

[Warren Kumari]

On Mon, Feb 10, 2014 at 4:52 AM, Joachim Strömbergson
<joachim at secworks.se> wrote:
> -----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.

So, one interesting observation (at least for me) is that, if we have
to store keys in RAM (inside the envelope!), SRAM is probably better
than DRAM.
Yes, we still need to do things to decrease stickiness and active
zeroization if tamper is detected (and I like the tie power the ground
as a final step) as well.

This has probably been blindingly obvious to everyone else, but wasn't
something I'd though of...

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

Yah. That sounds really interesting / fun. I'd also like to try a dark
CCD vs SRAM test (both simply powering / off and PRNGing the SRAM).
The CCD test I can probably do fairly easily (USB webcam), the SRAM
one might be a bit trickier. I've got a TI MSP430 dev board in a USB
thumb drive form factor (http://www.ti.com/tool/ez430-f2013 ) -- this
with a small SRAM attached seems like it might be a good way to play,
because I can take it along and play with it on a plane (a while back
I was sitting on a plane with an Arduino with a few LEDs on it...
Flight attendant came over and asked me to put it away, because
apparently it had freaked out some other passenger....)

W

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