[Cryptech Tech] Some thoughts and questions on the RNG strategy

Fri Feb 7 15:41:12 UTC 2014

On Feb 7, 2014, at 4:38 24AM, Joachim Strömbergson <joachim at secworks.se> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Aloha!
> 
> Randy Bush wrote:
>> As for the specific choices: the part about injecting seed values 
>> scares me, since that’s an open door for malware to inject known 
>> state.
> 
> Inject as in injection of test values in the production system? It is
> quite possible to remove that kind of functionality. It is one of the
> features people has been asking Intel to add into RdRand in order to
> make the Bull Mountain black box a little bit more opaque. I therefore
> saw this a way for us to provide control and thus build trust in the
> Cryptech system. Be able to sample raw entropy sources and in a
> controlled way inject test values into the CSPRNG and see that it
> functions as expected.
> 
> The normal operation of the system should be suspended when this is
> happening to prevent injection attacks leading to keys being generated.

OK -- I'll propose a requirement without giving a solution: have a
high-assurance way to make sure this is disabled.  That is, it should
be all but impossible to run normally with this feature enabled, and
no compromise of other software should allow it to be enabled without
disabling everything else.  

I'll give a counterexample: the warning light on the camera on MacBooks.
What you really want is a configuration where the camera CANNOT be on
without the light.  Apple tried for that, but they implemented it via
camera firmware. The normal firmware responds to a host request to turn
on the camera by also turning on the light; however, there are proof of
concept replacement firmware packages (which malware could install) that
don't have that feature.
> 
> 
>> Normally, I’d suggest using a NIST-standard PRNG; right now, that 
>> scares me a bit, for some reason… For ChaCha, though, I’d like to
>> see published analyses of its output randomness; the lack of that was
>> one of the early warning flags for RC4.
> 
> DRBG_CTR from SP 800-90 should be a pretty conservative choice then.
> Regarding ChaCha it is true there aren't that much analysis on it (yet).
> And we could use any other stream cipher, hash function or block cipher
> in proper mode we want. Some of them are are easier and more compact to
> implement in HW than others.
> 
> The reason for suggesting ChaCha is that it is based in Salsa20, which
> has been analyzed quite a lot through the eSTREAM project (where it was
> selected as one of the ciphers in the portfolio). And also because it
> has been designed to have little side channel leakage and is very fast
> even in slow and cheap FPGA chips. IACR ePrint Archive lists only two
> papers with analysis on ChaCha:
> 
> http://eprint.iacr.org/2012/065
> http://eprint.iacr.org/2007/472
> 
> And then of course DJB provides some analysis himself:
> http://cr.yp.to/chacha.html
> 
> My take on the state of ChaCha is that it is fairly well analyzed and
> has provenance from Salsa20, HAIFA and the ARX constructions that makes
> it pretty trustworthy. That is why we are proposing it as a replacement
> for RC4 in TLS.
> 
> https://datatracker.ietf.org/doc/draft-mavrogiannopoulos-chacha-tls/
> 
> But again - we as a team must decide on what we will use as CSPRNG.
> DRBG-CTR based on AES-256 is a good choice.

The link to Salsa20 is reassuring.  djb's analysis should, of course,
be discounted...
> 
> 
>> “Ample time to collect and curate” randomness is not a feature,
>> since it means that this state is lying around the system.  A major
>> point of injecting new randomness is to deal with transient access
>> by attackers.
> 
> It is a feature if we have a slow entropy source and would have to stall
> the CSPRNG due to lack of collected entropy to seed it with. I'm not
> suggesting that we should build huge pools of collected entropy.

Oh, the slow source means it's a requirement, not a feature...
> 
> And lying around suggests that it would be placed at different memories
> in the system when it in fact would be a few small memories inside the
> FPGA (or a MCU if using a SW solution). Unless we do a faulty design,
> the active tamper proof fails and we (or implementer) retain a JTAG
> interface these memories should be physically inaccessible.

Good.
> 
> If the collector-mixer-structure used in a lot of RNGs are to be
> accepted as a good general strategy, then collecting entropy and having
> it laying around in pools is part of the solution. We will not be doing
> anything different. In the Fortuna, having several pools and thus
> collecting a lot of state is part of the security feature since it
> protects agains injection attacks. At least according to the Fortuna
> designer Bruce Schneier.
> 
> - -- 
> 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/
> 
> iQIcBAEBCAAGBQJS9KmQAAoJEF3cfFQkIuyNSUAP/jxMgwgryBnIkz1d5WyrLu2i
> D3xP+lgkmJqnObWQaYCANbU07QE5trEC3IVRYUVwp417B16QbH7DDq66gynaQ13h
> y36G9eL6aiLURDpj6ABacrw5GzS0uXVNAX8Ci7Vn2de7U6QtRCtCxTbiMoZnUycy
> 359g5scN/ueAsKKvFqllbmSBAL7iRldxHantRcipffvzwLFPaHIJFF/EVhvdjjAn
> yvs9xugrkHEKQ2y1W095y/wmk+hNZOiSKQDu9P8RTLZk9s7dUeL3q1xStbmkaWRl
> Ed9yKNM1wAEjAcOnUGNcfdPcuHrKj5NSAYoFPoATJIYmKqfFA+7YalxEvSgjmL/a
> s9Tw8OsaKcpb2Iq+9t1pQv9UR8h9cATaMSOXfB3Hl+/X7CnXzVwDkdCvd5w0801Q
> 4m8Iqiac/hdJuvv2YD9wnRSfy5+71O5hEWw1DtsoRl8g21EAAruLIbpk+wJ/8JfV
> 7GvIdGMqzRd9Y+coXRNNECA6diqfSX0zphap0Q997yhkRjXOYEc7aEl/4ivT3fXq
> VbakX3+tcvtnGlBjXKwkrLjhbYDSLtrRHwMOeUnpBfKFro/yWWYYWMA+Ysh4dOpX
> d++6oq8EJUXnx9/NFDBunrkyivVMW27l/Lof63w4Lb2EmHgZZqpCM0kZ61ra32g0
> iYNhgPavXbQJIh/9kqcL
> =LmhW
> -----END PGP SIGNATURE-----
> 

		--Steve Bellovin, https://www.cs.columbia.edu/~smb