FreeBSD Developers Will Not Trust Chip-Based Encryption 178
New submitter srobert writes "An article at Ars Technica explains how, following stories of NSA leaks, FreeBSD developers will not rely solely on Intel's or Via's chip-based random number generators for /dev/random values. The values will first be seeded through another randomization algorithm known as 'Yarrow.' The changes are effective with the upcoming FreeBSD 10.0 (for which the first of three planned release candidates became available last week)."
Is there any way to gain trust in a chip? (Score:5, Interesting)
Just out of curiosity: Given a "black box" implementation of a random number generator, is it possible to test its output sufficiently to gain some faith in its proper randomness?
Seeing as such a piece of hardware need not (and hopefully would not) have any inputs, only an output, it's hard to imagine how someone might hide (and later trigger) a back-door mechanism that could change its behavior post-testing. (But I'm sure there is some way to do it that I'm not thinking of ;))
Re:Very Smart Move (Score:3, Interesting)
You know 6 months ago such a comment would be modded -1 and this story would have the foot icon for humor.
My have things changed. Microsoft was not that bad DRM monster we feared 12 years ago. First it turned out to be Apple in which we cheered them 10 years ago here on /.
But both companies fail far in comparison to the US government and this is something I would not have imagined in my wildest nightmares.
Re:Is there any way to gain trust in a chip? (Score:3, Interesting)
Ok, I'll take a shot, here's two of them for you:
1: Chip outputs the digits of pi starting at some crazy number of decimal places out that only the NSA has had enough hours on the supercomputer to find. Your chip now puts out data that you cannot distinguish from random, but that the NSA can perfectly predict. They go to their giant database of all of your internet traffic ever, and can now read whatever they would like, as all of your keys are now utterly, hopelessly broken.
2: Chip internally stores the last n random numbers that it has output. Later, the NSA can confiscate your computer, subject the chip to some undocumented state that causes it to barf up its secrets, and again all your keys are now utterly, hopelessly broken.
TRNG using discrete components? (Score:5, Interesting)
Given that it's stated that you can't trust a chip's encryption routines, which at the basis means that you don't trust its random number generator, and given that 'a chip' extends down from the latest Intel to a relatively lowly PIC, is anybody aware of an actually available TRNG (true/hardware random number generator) built out of discrete components?
Comments to a Bruce Schneier post titled "Surreptitiously Tampering with Computer Chips" [schneier.com] once suggested this would be the only way to 1. be certain* of no tampering and 2. have reasonably sufficient output bandwidth to be used in practical applications.
However, I haven't seen any actual implementation. My Google-fu may be failing me, though.
* Barring some pretty sweet shenanigans like those pulled by Henryk Gasperowicz; [Spoiler video](https://www.youtube.com/watch?v=-KMLmpC7-Ls). I can't see manufacturers including any crypto-defeatery bits into a basic transistor thinking that it just might possibly be used in an actual crypto application, and eat the cost somehow.
Re:Wise (Score:5, Interesting)
According to the OpenBSD link, OpenBSD uses the Intel and Via random-number generators, but not as the sole source of randomness. The nice thing about mixing random number generators is that if you do it right (like OpenBSD does), the result is at least as random as the most random source: a bad RNG does not reduce the overall quality of randomness.
Re:Is there any way to gain trust in a chip? (Score:3, Interesting)
All of this can be conveniently calculated by this tool [fourmilab.ch], and neither of this will help you to distinguish actual randomness from a result of cryptographic algorithm working on extremely predictable input.
For example, here's what it says about 32M of random bytes:
Entropy = 7.999994 bits per byte.
Optimum compression would reduce the size
of this 33554432 byte file by 0 percent.
Chi square distribution for 33554432 samples is 257.80, and randomly
would exceed this value 43.91 percent of the times.
Arithmetic mean value of data bytes is 127.4968 (127.5 = random).
Monte Carlo value for Pi is 3.140698143 (error 0.03 percent).
Serial correlation coefficient is 0.000015 (totally uncorrelated = 0.0).
And here's what it says about 32 megabytes generated by SHA-256 hashing of 'Intel Intel Intel Intel Intel' concatenated with a 24 bit counter:
Entropy = 7.999994 bits per byte.
Optimum compression would reduce the size
of this 33554432 byte file by 0 percent.
Chi square distribution for 33554432 samples is 269.79, and randomly
would exceed this value 25.08 percent of the times.
Arithmetic mean value of data bytes is 127.4839 (127.5 = random).
Monte Carlo value for Pi is 3.141798922 (error 0.01 percent).
Serial correlation coefficient is 0.000266 (totally uncorrelated = 0.0).
See how different the results look?.. Oh, wait, they don't :(
For comparison, here's results for 32MB of simply ('Intel Intel Intel Intel Intel' concatenated with a 24 bit counter):
Entropy = 3.465109 bits per byte.
Optimum compression would reduce the size
of this 33554432 byte file by 56 percent.
Chi square distribution for 33554432 samples is 1153826816.00, and randomly
would exceed this value less than 0.01 percent of the times.
Arithmetic mean value of data bytes is 91.5781 (127.5 = random).
Monte Carlo value for Pi is 3.948254105 (error 25.68 percent).
Serial correlation coefficient is 0.079051 (totally uncorrelated = 0.0).