Slashdot Mirror
FreeBSD Developers Will Not Trust Chip-Based Encryption
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)."
They have every reason NOT to trust the chips. Trust, but verify is always the correct way.
One of the features of open source software is that the code, thus the algorithms, can be examined by a third party. In the case of chips, this is very difficult to do. Most people are stuck trusting that the designer implemented the algorithm they said they did, and that they implemented it properly (the former implying no malice and the latter implying competence). That is particularly true for something like random number generators, which are intended to be non-deterministic as far as the software is concerned so any testing the implementation can only be done statistically. Very few people have the ability to examine the physical design of the chip to check the actual implementation.
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 ;))
I don't care if it's 90,000 hectares. That lake was not my doing.
Every time an OpenBSD system needs a random number, instead of trusting any hardware device, it phones home and asks Theo to provide one.
https://www.schneier.com/yarrow-qa.html
your ignorance is unjustifiable
Because true random in software is computationally expensive. Adding a layer of obfuscation on top of the untrusted hardware gives you a better random cheaply, and avoids potential back-doors in the hardware generator.
I think it phones to this place. However some developers don't trust that random number generator and instead opt for this implementation.
The Tao of math: The numbers you can count are not the real numbers.
http://dilbert.com/strips/comic/2001-10-25/
That's the problem with randomness, you can never be sure.
Not to mention insecure too.
There are only so many milliseconds on the clock to use on the seed. Even if you use the mic statistically silence or a clicking sound will be heard for 90% of the users so that makes that seed bad too. Network? At home there is little traffic and even at work there are the same patterns from Cisco and HP for 80% of the packets.
SGI had some interesting encryption methods that dealt with quantam mechanics on their servers and workstations. Man I miss them.
http://saveie6.com/
One of the first things Ted Ts'o did when he took back maintainership of /dev/random in Linux was to stop depending solely on the hardware RNG.
https://plus.google.com/117091380454742934025/posts/SDcoemc9V3J?e
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
random numbers tend to be treated almost as a religious argument rather than a technical one.
Hail Eris!
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
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" 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.
Yarrow is hardly vague.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
you just...answered why it wouldn't work. If that much garbage is actually coming into the conditioned power, it will kill the system in very little time.
You know I had a problem with BSOD occuring frequently in a large call center.
Turns out hte problem was the big UPS for the whole floor spiked things and the power strips always tried to smooth things. Over a period of time the soldier would crack and burst due to the UPS doing hard rectangular patterns rather than waves when it alternated back and forth.
Real power from the wall was cleaner than the UPS for the power strips.
http://saveie6.com/
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.
"They redundantly repeated themselves over and over again incessantly without end ad infinitum" -- ibid.
What is needed is are seed inputs. When a key is hit, get a super-accurate clock sample of it, hash it with MD5 [1], and toss it in the pool. Mouse movements, similar. If the computer is idle, this won't help much, but while it is in use, it should help provide enough unpredictable data to be up to par for security purposes. I'm sure there are other inputs that can be hashed over time and the hashed bits tossed in. Of course, the RNG from the chip can be easily tossed in as well. The good thing is that the most random factor "wins" in this case.
[1]: MD5 has its issues, but it is being used in this case as a bit blender, so hash collisions can happen, and not really matter. It would be wise to move to a newer algorithm like SHA-1024 or SHA-3, for more bits though.
A webcam with the lens cap on works for that kind of thing. (I'd link to lavarnd.org, but it is mysteriously down...)
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
I would mod you up if I wasn't out of points.
And I too think lavarnd.org being down at this moment in time is semi-spooky.
for i in `facebook friends "=bday" 2>/dev/null | cut -d " " -f 3-`; do facebook wallpost $i "Happy birthday!"; done
The big problem is that it's very hard to get good entropy early on in the boot process (when things like TCP sequence numbers and sometimes when SSH server keys are initially generated). You can use a hash of the kernel, but that's shared between other machines with the same kernel. You can use the time, but that's likely known to the attacker (and in some embedded systems will always be the same on every boot, until it queries an external source and corrects it). You can use interrupt times, but the ones from the disk / flash are likely to be similar, if not the same, across boots of the same kernel and the early network ones are susceptible to attack by people on the local network.
The hardware RNG definitely gives you some entropy, and so using it to stir the pool for Yarrow helps a lot here. Later on, there is a lot more entropy. As you start to get disk access patterns based on system use and network connections from a variety of sources, interrupt times give quite a lot of entropy. It still helps to mix in the hardware RNG, however.
As I said in another post, it's quite unlikely that the hardware is intentionally compromised (although it's a nice attack, so I wouldn't guarantee that future versions won't be), but it's very likely that it provides less entropy than advertised. This makes it fine for input into a PRNG like Yarrow of Fortuna (I think Fortuna made it into FreeBSD 10, if not it should be in 10.1), but not adequate for general use. The point of a PRNG algorithm like Yarrow is to generate an unpredictable sequence of numbers from some source entropy seed, which can change over time. As long as you have enough entropy, you will get a cryptographically secure sequence of pseudo-random numbers. All this work is doing is saying 'we trust the hardware to give us some entropy, but we don't trust it to give us all of the entropy that we need'.
I am TheRaven on Soylent News
Trust in a random number generator is not a binary thing. All of the current hardware RNG implementations produce some entropy. The question is how much entropy you trust them to produce. If it gives 256 bits of entropy, then you can just use it as your random number source and be done with it. One that produces 16 bits of entropy is very useful as one (but not the sole) source to an algorithm like Yarrow of Fortuna, but would be a disaster if you used it as the random number generator without such an algorithm in the middle.
I am TheRaven on Soylent News