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.
The NSA has an innocent-looking honeypot right here for all you wise-guys.
If you want proper random numbers, get yourself a radioactive source.
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.
The summary itself says it's just the RNG that they're not trusting; it doesn't say anything at all about not trusting the encryption. (Probably because the question of whether or not the encryption works correctly, is actually verifiable, unlike the RNG.) So why the dumb headline, which contradicts its own summary?
I wouldn't trust chip based encryption either, and I wouldn't trust anybody else that did.
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.
That order is too obscure, you probably never heard of it.
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.
No. None of this matters so long as you use XOR
That's really all it takes.
Check this out, I have some hexadecimal dice (yes, I'm a geek) so I will roll two of them to get me an actual random number from 0x00 to 0xFF
Then, I will use XOR to merge with two other random random bytes, which unfortunately, have been tampered with by the NSA. The NSA were able to choose 0x12 and 0xFA for their two bytes. But feel free to try this with any other bytes, or more of them, if you like.
OK, the dice gave me... 0xA5. The NSA don't know that, they just know the values they were able to choose, 0x12 and 0xFA. I XOR the three numbers and I get 0x4D. But how do the NSA guess what number I got? They have no way to know from just their two numbers 0x12 and 0xFA what the result will be.
Let's try it again, this time the NSA are able to know that the two other bytes were 0x58 and 0xE0, and I'm telling you as well. But... what's the resulting random byte? If you were right you should be able to guess, despite not knowing the dice roll that was XOR'd in. But you don't, because you were wrong.
XOR. To combine two or more streams of hopefully random bytes you use XOR and then you automatically get AT LEAST as much randomness as was in the most random of the sources and usually more.
http://cryptome.org/jya/cg071599.htm
"If any question why we died, Tell them because our fathers lied."
People still use BSD?? Poor bastards
All measures are pointless when the Intel chipsets on the motherboards have backdoors called vPro or Business Advantage.
One secret command sent to the chipset through the onboard NIC and it's over, you get access to ram/storage/video, all happening behind the OS, even when the machine is turned off.
It is our understanding that if the cpu has vPro / Small Business Advantage in it, it is backdoor'd, that means almost all the new Intel cpus in the past 5 years are backdoored, if not the past 10 years.
Intel Small Business Advantage is a security nightmare
New Intel Chips Contain Back-Door Processor, Hackable Even When Computer is Turned Off
Nothing is safe.
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
http://www.gnu.org/distros/common-distros.html#BSD
Yet, oddly, when the Linux Kernel's use of extra randomness was central to a topic on slashdot, it was talking about Linus calling people complaining about the Linux Kernel's treatment of random numbers being wrong as, paraphrased "You're too fucking dumb to understand, the developers writing that code are a lot smarter than you, so either write your own or shut the fuck up".
Now, I posted at the time that Linus was being a shit for this, but the complaint I have here isn't about Linus, but the fawning version of the same sort of story that BSD gets not only for doing the same thing as the Linux kernel did (but not lauded for) BUT DID IT MUCH LATER TOO (which it isn't being called out on).
OK, you have good crypto. But someone planted an interrupt, and the video card is using direct DMA to snaffle memory
a) tamper with routine
b) Copy it somewhere
c) read kbd buffer
d Call home
Clearly the objective is to log private keys and a stream ,instead old old passwords.
This make the undo-able, quite doable and cheap.
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.