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.
It's always wise to get entropy from as many places as you can; in light of the NSA revelations, it's time relying on just one becomes something people don't even consider anymore.
Is OpenBSD, the 'security first' BSD, ahead of, or behind the curve with this?
if the idea is not to trust the hardware implementation then why use it alongside "Yarrow" in the first place? This just seems like the glorious Foundation using recent news about the NASA as a self-promotion tactic and even to a layman it's a poor one. "Trust FreeBSD, we still use rdrand et. al., but we filter it through some vague algorithm called Yarrow that makes it safe!"
You'll forgive me for not being entirely convinced, particularly when even the latest release of 10 still refuses to boot and install properly on my UEFI-based system.
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.
We have known for some time it is not impossible to hardcode a backdoor into a chip. I thought we already decided a while back that we cannot trust chip protection, in the past it was china chips but with the information given by snowden it only makes sense not to trust a chip from intel
have you seen my sig? there are many others like it but none that are the same
for violating secret orders they never even heard of :-)
http://dilbert.com/strips/comic/2001-10-25/
That's the problem with randomness, you can never be sure.
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.
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.
More likely its just going to get the random numbers generated for a video game.
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.
Why not just hook a microphone on the inside of the computer to pick up the fan noise, and use that as a random source? I'm sure there's some entropy in there.
Well, if the chip is using its encryption circuit to create the RNG output...
http://cryptome.org/jya/cg071599.htm
"If any question why we died, Tell them because our fathers lied."
It strikes me as concession packaged up as stand-offishness. But it still reads like concession. If you don't trust the chip, don't use the chip. Why all the song and dance just to say "well we're still relying on the chip, by the way" at the end? Can anybody say "sugar coat"? I would take them to task over it, if I had some kind of bargaining power of my own. I would say, "if you claim you don't trust the chip, then either you don't utilize the chip, at all, or I in turn don't trust your routines."
"Stratigraphically the origin of agriculture and thermonuclear destruction will appear essentially simultaneous" -- Lee
I am TheRaven on Soylent News
FreeBSD has been using Yarrow for 10+ years, and no FreeBSD release has ever shipped with the option to feed the stream from a HWRNG directly to /dev/random. The only news here is that we have a new framework in the kernel for plugging hardware pseudo-random number generators into Yarrow, and an explicit policy (issued in my capacity as FreeBSD Security Officer) to not expose HWPRNGs directly to userland. There was some pressure from corporate users who want the raw feed for compliance reasons, but they were told to use RDRAND etc. directly rather than through /dev/random.
I wouldn't trust chip based encryption either, and I wouldn't trust anybody else that did.
Assuming we're only talking about ciphers and not protocols: by definition, there is one and only one possible ciphertext for any given combination of key and plaintext. Thus, there is no way to introduce a weakness in an implementation which would not be trivially detectable by comparison with any other implementation; in fact, the result would be unusable as it would not be interoperable with other implementations.
(With a caveat for algorithms which require a random initialization vector; don't let the implementation choose the IV for you.)
Linux initially trusted RDRNG unconditionally to provide streams of random numbers, then backtracked to only using it as an input to whitening.
There was a patch offered to allow linux to solely use RDRNG for /dev/random, but it was roundly rejected on the lists. I don't think you can find any point at which the kernel ever trusted it. It's only on newer Intel chips anyway.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Yes; this is mostly right -- except for the fact that a stream of zeroes can still be completely random; just highly unlikely. The trick is whether that stream of zeroes can be accurately predicted or not, not what the actual value is. As such, not affecting the output is a perfectly random thing to do.