[Cryptech Tech] RAM as source of entropy

[Warren Kumari]

On Fri, Feb 7, 2014 at 7:48 AM, Joachim Strömbergson
<joachim at secworks.se> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Aloha!
>
> Warren Kumari wrote:
>> This sounds very similar to the "CCD in total darkness" ideas... Last
>> I'd heard, apart from some cells that like to bias in one or the
>> other direction (imperfections, internally generated heat from
>> nearby A/D, etc) it was basically a quantum phenomenon. This is why
>> there has been so much (unsuccessful) research into removing noise
>> from CCD imagers. This also seems like it would generate much higher
>> (after some removal of known sticky bits / whitening) rates.
>
> I'd say that DRAM decay resembles CCD in total darkness.

Kind of, but I think that there are some important differences -- DRAM
is designed to be stable (well, to try minimize the leakage from the
capacitor). A CCD is designed to let the charge escape from the well.
This makes it (I believe) more susceptible to noise / quantum effects
-- the video showing using a smartphone camera as a radiation detector
supports this[0]  CCDs are also "more analog" -- there is an A/D step
that translates the charge to a value, this gives you more possible
values per cell (the "Is these still some charge here?!" in a DRAM
cell I guess could be viewed as an A/D with really bad resolution
:-P).

>  And SRAM
> initial state is more closely related to the entropy source in Intel
> Bull Mountain where a flip-flop-like construction is repeatedly powered
> off and on.

Ok, I'll buy that. Powering off and on a large SRAM and reading the
"initial" state might work really well, it would be interesting to
test both and see the entropy and bandwidth from both options.
One of the things that had made me uneasy about the memory option
(other than the slow decay shown be the "Lest we remember" paper for
DRAM) was the fact that many commercial HSMs (supposedly) continuously
move the keying information around in memory to prevent cells sticking
in a last known state. I'd thought I read something about this effect
happening in SRAM as well (but cannot find the reference at the
moment), because of long term diffusion effects. I had some vague
uneasiness that, over time flip-flops that happen to bias one way or
the other would increasingly prefer that bias.
But then agin, I've only been paying very slight attention to this,
basically what seeps in while idly flipping through IEEE Spectrum on
airplanes :-), and so this is probably all a rathole.


>
> And yes, there will be cells that due to variance in manufacturing are
> more or less heavily biased. But not all of them aren't, otherwise the
> memory stability would be a big issue.
>
> The idea is to extract the (for example 64 kbits from the memory) and
> then send it as a message through a hash fuction to create our "sampled"
> raw entropy of say 256 bits. With the farnell memory we could do this
> including having the memory powered off for several thousands of seconds
> and still get something like 64 kbps entropy.
>
> I had another idea too. One could actually take some of the outputs from
> the CSPRNG (output that is then not given to the user applications) and
> use it as random pattern written into the SRAM before the power
> off-power on-extraction operations. This would eliminate (reduce) the
> risk of latent values in the cells from one cycle to affect the data
> extracted in the next cycle.
>


Oooh! I like that. That's cool....

W

[0]: Yes, the DRAM is constantly being refreshed, but the refresh rate
is low enough (I think!) that some cells would have changed is they
were as sensitive....


> - --
> 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/
>
> iQIcBAEBCAAGBQJS9NYVAAoJEF3cfFQkIuyNBlAQALpojdlqTMdOh8vINvQ0kBb9
> ujshIi1BqQ+TF3KlL+TgdnRQ0Szypual0Z5UfWxv6dVtyIV/2hee6jpa3k3VcAVr
> SYgkk2doQkoxtRHJNvaY94RuuIYmP4Vuy+wKeKHm6slVC8V0E5nrS+I/EqjE+rf2
> Pz0yVJ5nj3Brhzi7USxc+YRJBFYm9rjiWldnzrJm0XuZsYamk3OoQPxROG3MR/E3
> xrlh4TgSMfF8iTzrM5La37qcJCmxMTZdN0OdUQOQIXNtPM193X84mP0YkovaDELX
> /DVunH+2OgtS2/2D+QU5r1FiVwZxLiaH+BnAd2rKcFb2qCDqo36JZCA5DAZNZ9XX
> lFl/MwFQgFJWXmEDR+du8McbWBWmbZbkntYheCyKjAhFYYdqFk6Xg4u7Z/PdXLQ6
> 6q10MTOReb8RobGxEJf5GTCE9Py+L6YM8Tn2Pnbi9/E5zwghrLdV+EO8AbHnJ+8b
> CVDNHB6A0xSqoUYHYNnF5BYMWkNcoFJNAx616mZws1fzfyxWasBG0qHfdRFyamQl
> Txm9gUfnXQ92vP+TwC8RuHdCgWvc5U9siRE+LAoc35G0qI+jymNLS1DUVXIk1YIh
> QbZ8iczdGsA0cD1qpiLITPtG/y51zcziDSnanR0UlrcXofGFt9UDkeHbdwkUqMW1
> rFcFhaUDZNmqPJn4nTVb
> =0CGr
> -----END PGP SIGNATURE-----