The article's title is misleading; Intel has answered this question. They deny collaborating with NSA.
To that, add that there's no evidence anywhere of any such collusion, and that Intel retained Cryptography Research to assess their CSPRNG design.
By pluralizing the word "question", the article injects further misinformation. There's one question people are asking about Intel: "why should we trust the RDRAND instruction?". The question is asked not because there's any evidence that RDRAND is compromised, but because CSPRNGs are a uniquely powerful point in a cryptosystem to insert a backdoor. Backdooring the AES instructions is harder; AES is deterministic, so there's not much you can do with an "evil" AES. Not so with an RNG.
But RDRAND is a stupid backdoor. On every mainstream OS, including the two mainstream mobile OSs, RDRAND is (at best) one of several sources of entropy. In the Linux kernel CSPRNG, in FreeBSD's Yarrow, and in WinAPI's CryptGenRandom, controlling one entropy input (or even all but one of them) doesn't make the CSPRNG's output predictable. So even if it is backdoored --- which would be silly --- that backdoor probably doesn't impact you in any meaningful way.
Cryptographers are wary of RDRAND. It's a closed, proprietary design. Cryptographers would rather you use urandom to get your randomness, and if the OS wants to use RDRAND as one of its entropy sources, whatever. Cryptographers would say this whether it was Intel's hardware RNG, Apple's, Samsung's, or Broadcom's.
RDRAND is a very good backdoor for code written by stupid people. There's a lot of application code which detects the presence of RDRAND and uses it directly instead of asking the OS for entropy.
(FWIW, I doubt RDRAND is backdoored in the traditional sense. I'm absolutely certain, however, that the NSA will take full advantage of the documented not-enough-entropy failure mode which returns all zeroes -- which most RDRAND-using software does not correctly handle.)
I've tried to diagnose when the RDRAND failures happen. From my experiments on Haswell, it only seems to happen when you have > N threads, where N is the number of physical cores, simultaneously reading continuously from RDRAND. But when that happens, nearly every read from every thread will fail.
This means a user process could easily deplete RDRAND's contribution to the kernel's entropy pool. So encouraging all kinds of application code to use RDRAND is really bad advice. It should at least be a privileged instruction.
> On every mainstream OS, including the two mainstream mobile OSs, RDRAND is (at best) one of several sources of entropy.
Actually DJB has a pretty interesting post about how RDRAND and microcoded instructions could work together to control the OS's RNG output, even if several sources are mixed in, by monitoring the entropy pool and brute forcing each bit:
<http://blog.cr.yp.to/20140205-entropy.html>
DJB's attack assumes that RDRAND does more than generate "evil" outputs, but that it also includes microcode that watches the entropy pool (which is constructed differently for every software RNG) so that it can know which output will generate a specific value. It's not just that it's an implausible attack (though it is; again, it assumes a hardware backdoor tuned to each OS's kernel CSPRNG). It's also the case that if the hardware is that thoroughly compromised, RDRAND is the least of your problems.
It's a great post. It just isn't as damning as you might think it is.
"First, let me be clear that Intel doesn’t participate in the NSA programs described in recent news reports. Intel does not participate in anyone’s efforts to decrease security in technology. We don’t provide methods for unauthorized access to our products….we don’t create back doors."
To me, that statement strongly suggests that Intel is participating in some sort of NSA program. What that is, I have no idea.
It's a barrage of pretty classic "non-denial denials": deny having done things you weren't doing, but which sound enough like the things you were doing, and presumably people will be mollified — or so the theory goes.
First, let me be clear that Intel doesn’t participate in the NSA programs
described in recent news reports. Intel does not participate in anyone’s
efforts to decrease security in technology. We don’t provide methods for
unauthorized access to our products….we don’t create back doors.
if it takes you 44 words to say "Absolutely not" my money is on you lying.
I don't think that's really fair. "Absolutely not" isn't even a good response to the question, which was essentially "Can you comment on these issues?" And if he had said that, people would be objecting, "But he didn't specifically say what claims he was saying 'Absolutely not' to, so my money is on him lying."
No matter what he had said and regardless of how true or false it had been, people would be reading in lies. He's too detailed, he's too vague, he's too forceful, too weak, too formal, too informal — once somebody is convinced you're a liar, there is very little you can say to change their mind.
the funny bit is "does not participate in anyone’s efforts to decrease security in technology" ...the phrase is truly A GEM. Just to start with, how do you define "not decreasing security"? maybe as "preventing unauthorized access"? But oops, what does "unauthorized" mean and who is "authorized"? And "participate in anyone’s efforts"?! Won't even try to split the possible meanings of that!
...hopefully they do a better job at keeping their hardware backdoors (if they exist) off the "market" than they do at press releases. Nobody needs this for their dirty deeds anyway considering the current state of software security, and even a state agency would be stupid to use such capability even if they had it, for obvious reasons.
I'm not knowledgeable in the intricacies of cryptography, so this is something that bug me, how can the Random Number Generator be backdoored in a way that would be usable for the NSA without being detectable?
Surely you could graph the numbers that the RNG output and see if it's random or not, no?
A sequence can be completely deterministic and yet pass all randomness tests. For instance, if I tell you I randomly chose numbers between 0 and 16, inclusive, and got 14, 13, 10, 1, 6, 5, 2, 9, in that order, as far as you can tell it looks random. However, x_{n+1} was generated by taking (3 * x_n + 3) % 16, and hence I can predict the next random number in the sequence trivially. [This is a bad random number generator for other reasons --- see Wikipedia on LCGs for more --- but a good demonstration of how random numbers can appear random but be usable by $attacker.]
Take this example: the output of a cryptographically secure pseudo random number generator (CSPRNG) cannot be determined without knowing it's seed(s) (the initial seed and, optionally, additional seeds if/when re-seeding is done).
Any CSPRNG must pass the "next bit" test or it is not a CSPRNG: the probability of the next bit being 1 is 0.5 (the probability of it being 0 is 0.5 too of course).
So, no, you cannot graph the output of a CSPRNG and see if it's random or not. Because by their very definition outputs of CSPRNG look random.
Yet CSPRNGs are fully deterministic.
Now that is another topic but... The NSA may have an history of also backdooring CSPRNG (Dual_EC_DRBG comes to mind) ^ ^
You could tell whether it is evenly distributed (with some probability, as you can only inspect a range and not all the numbers it will output), but you cannot test whether or not a sequence is random.
the world's largest cpu manufacturer, which also happens to be based in the US, _not_ having NSA-mandated backdoors is entirely out-of-the-question. even if the cpus are not backdoored, you can bet all the NIC firmware "happen" to have a remote update path enabled, despite it not having a legitimate application in non-development environments.
I'd expect that as Pentium M's were mobile class CPUs, they weren't expected to handle significant quantities of RAM and therefore didn't need PAE. I can't think of a single Pentium M machine I had that ever saw more than 2GB of RAM.
To that, add that there's no evidence anywhere of any such collusion, and that Intel retained Cryptography Research to assess their CSPRNG design.
By pluralizing the word "question", the article injects further misinformation. There's one question people are asking about Intel: "why should we trust the RDRAND instruction?". The question is asked not because there's any evidence that RDRAND is compromised, but because CSPRNGs are a uniquely powerful point in a cryptosystem to insert a backdoor. Backdooring the AES instructions is harder; AES is deterministic, so there's not much you can do with an "evil" AES. Not so with an RNG.
But RDRAND is a stupid backdoor. On every mainstream OS, including the two mainstream mobile OSs, RDRAND is (at best) one of several sources of entropy. In the Linux kernel CSPRNG, in FreeBSD's Yarrow, and in WinAPI's CryptGenRandom, controlling one entropy input (or even all but one of them) doesn't make the CSPRNG's output predictable. So even if it is backdoored --- which would be silly --- that backdoor probably doesn't impact you in any meaningful way.
Cryptographers are wary of RDRAND. It's a closed, proprietary design. Cryptographers would rather you use urandom to get your randomness, and if the OS wants to use RDRAND as one of its entropy sources, whatever. Cryptographers would say this whether it was Intel's hardware RNG, Apple's, Samsung's, or Broadcom's.