[Cryptech Tech] Hardware entropy

[Joachim Strömbergson]

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

Aloha!

Bernd Paysan wrote:
> Yes, disadvantage for external circuits: dead easy to tamper
> (replace by a pattern generator chip that doesn't produce entropy,
> but passes the health check).

Good that you pointed it out - Cryptech implicitly supports and
basically expects least passive tamper resistance. And we will support
active tamper resistance. Other parts of Cryptech such as key secure
storage will require external storage when using FPGA devices. Having an
external entropy source is therefor acceptable. But it should have been
more clearly and explicitly declared.

For systems and applications where this does not hold, FPGA internal
entropy sources will be required (Or if you trust the vendor, the
internal RNG of the MCU you are using).


> Suggestion: You can monitor one entropy source in total, but all the 
> other entropy sources go in unmonitored.

That is a really good idea. And if one have only one debug port you
would get the constraint directly but having n-to-1 MUX to select which
of n entropy sources you are observing, thus the other (n-1) provides
entropy to the PRNG without being observed.


> The injected entropy is potentially an attacker, so you have to make 
> sure it can't do harm.  It can be just another entropy source, but
> it should not be possible to gain control over the entire entropy
> pool.

Exactly.


> The problem with switching the power is that you have to wait for 
> quite some time until the cells toggle.  Depends on leakage, of 
> course, but if you use a small SRAM, it usually is a 
> ultra-low-leakage process (small SRAMs are optimized for power 
> consumption), and that means you have to wait for ~15 seconds before 
> you restart it.  The smaller the geometry, the faster the decay of 
> course (less charge on the gates, higher leakage).

I can send URLs for the papers I've looked at. But from the published
reseach the remanence-effect is _much_ shorter than seconds. You can
switch very fast and get good entropy. The big problem is bias in cells
and that differs quite a lot between makes of memories. What does matter
is the die temperature. But SRAMs are much less affected than DRAM.


> The modified SRAM I suggest is only viable for an ASIC, but it will 
> put the SRAM cells into metastable state right on the spot (i.e. 
> nanoseconds instead of seconds).

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?


>> A variant of this is to actually write random patterns into the 
>> memory before powering it off. Basically have fairly good PRNG 
>> (SipHash for example) that is seeded with some of the values 
>> generated from the main CSPRNG generate data written into the 
>> memory.
> That might be a good idea during operation, but for debugging, that 
> just obfuscates potential problems with the SRAM.  Therefore, I
> don't think you should do that.  Fill with a known pattern, and check
> for the toggled bits is more healthy.

It wouldn't be very hard to support both during production. And for
development and evaluation that would be a given activity. Good suggestion.


> The common practice is from a NIST standard that is written by the 
> NSA.

I would be surprised if FreeBSD and OpenBSD would consider themselves
following the practice written by NSA. OpenBSD btw is using ChaCha20 in
its random number generator as CSPRNG.


>> Regarding FPGA internal entropy sources (did you read the report?)
> Yes.  I'm not convinced that this is working well on all FPGAs; 
> free-running ring oscillators that don't stop are more likely to
> work everywhere (you'll have to change the readout frequency
> depending on jitter; unfortunately, the equation is that with half
> the jitter, you have to wait 4 times as long).

What I like with the report is that the design presented includes
on-line tests based on AIS31. Most random number sources in secure MCUs
includes much simpler tests, often just stuck at a fixed value. Also the
TERO presented is more closely related to the meta stability entropy
source in RdRand than a jitter based entropy source based on free
running oscillators.


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

iQIcBAEBCAAGBQJTeGiMAAoJEF3cfFQkIuyNM7EP/0GNuftQMqfk6UHKVrhqwW6y
ddaHUPswlzLsBuh2go8zsuG1iLw/p6V48Cl4aYx9p3Z1M332mTb6WuJ4WZzdDvLm
/pjs/Fwrp66kDOZjxjCto1dAcxS+pH1md6W8/V+WZMpYX3v1Rh8ntyYMctIdbjsl
61rKHusKgRhLUcd3uvR/N4PB3jlJEZsegzpsQxyhQMG40ApnsXKFLOnJOsai0AFt
qddQuGDu2Efvr3uj3qJx60JM6owc3TnBlUuBz4DXRIsjZxduXeaap870OMGuE7vW
9F2JkFwsZkx/srKQGzZ+1BD+EUJAujB2B/giKGXgHDQLUIpInaEcfTL8rIalJNfj
StzU9x6Y1e4EmlAN3GMPpACsiZX6jAMhkJ2Z9z1Ktsm34sk9e4GntrsXVcmoA3Zw
XGkdGV7V1lVfHciM9OjyKbwWplE230uVMPfC8i5p3pWCJfr0tOU85WP/5d0Ozbnl
MR04AZRrBf3eQXB5ejGmuCNf84oZpBouS440KR7Jrw7/J4bQ9A+OHwA6mWx+n6RM
M7OGJ4Q/5dmIQ6axtTbjv5EYk0aphFBPyOLiTB4N11rMnrjEW3HBmQ5iFScWYdut
HmfnHmCRX6S2idNxmWwWBEYfuwFnZkG0Y5p5Ch/kWy+YfybA/gSbkFcTIAjmIRtQ
RDCLp5fA4tiOI2/3eUzV
=spWD
-----END PGP SIGNATURE-----