Intel In Bed with NSA?(cryptome.org) |
Intel In Bed with NSA?(cryptome.org) |
> Right. How exactly would you backdoor an RNG so (a) it could be effectively used by the NSA when they needed it (e.g. to recover Tor keys), (b) not affect the security of massive amounts of infrastructure, and (c) be so totally undetectable that there'd be no risk of it causing a ststorm that makes the $0.5B FDIV bug seem like small change (not to mention the legal issues, since this one would have been inserted deliberately, so we're probably talking bet-the-company amounts of liability there).
Just because you are paranoid doesn't mean that they aren't out to get you!
If you random number generator isn't then all of your crypto is basically useless. Paranoid is the correct state of mind for these systems.
Before 1988, if you were paying attention. So the idea that the NSA was watching everything you did is almost 30 years old now.
The feds used to fight civilian crypto tooth and nail. Then they allowed it, and in one of the crypto books a story was related that the feds were bummed about RSA and friends. The listener questioned why, when surely their efforts were feeble compared to the government's. The response was the pace of development was much faster than expected.
Curious. I'd like to read about this. Can anyone post any links?
I want hackers, cypherpunks, and cryptographers to be utterly paranoid.
[1] Computers with particular Intel® Core™ vPro™ processors enjoy the benefit of a VNC-compatible Server embedded directly onto the chip, enabling permanent remote access and control. A RealVNC collaboration with Intel's ground-breaking hardware has produced VNC Viewer Plus, able to connect even if the computer is powered off, or has no functioning operating system. http://www.vnc.com/products/viewerplus/
> You have activated Intel vPro technology on the PCs through configuration of the Management Engine BIOS extension (MEBx).1
http://www.vnc.com/products/viewerplus/ViewerPlusUseCases.pd...
It is really really hard for me to imagine Intel not beeing 100% cooperative with the NSA.
Turns out cooperating with the NSA doesn't automatically mean spying on the public, it could instead be hardening crypto security. Which is the NSA's other job, it turns out.
"I can't imagine how that (potential) backdoor can be abused, therefore it doesn't exist".
Random generators controlled by a third party are ABSOLUTELY a problem for any crypto system based on them.
Your (b) argument is even more ridiculous, considering the NSA events that just unfolded.
Your (c) argument makes zero sense, considering it got detected.
Of course, the judgement also takes into account the extreme consequences for the company implementing it if discovered, and the unlikelihood that that company could be legally compelled to do so, which was the case with all recently revealed examples of companies cooperating with the NSA. (Never mind that we have not even seen hidden /software/ backdoors forced by the NSA - merely systems that were known to be interceptable being intercepted.)
The same argument also applies to trusting the CPU itself: although it would be more difficult to insert a generic backdoor and ensure it could be exploited easily without compromising performance than to backdoor a random number generator, this is a matter of degree, not a fundamental difference in the argument. Though you may not trust the CPU either, I suppose, but in that case not using rdrand won't save you.
I have no idea if RdRand is the only source of entropy for /dev/urandom in the kernel these days but that does seem quite silly. Especially as RdRand is documented as having two error conditions, not enough entropy, and that the hardware appears to be broken.
In any case, here's the LKML thread where it was merged too http://thread.gmane.org/gmane.linux.kernel/1173350
If I understand correctly, the idea is to use RdRand to feed the entropy pool (which is also fed by other noise)[1] from which urandom pulls. So it doesn't seem RdRand would be the sole source of entropy if it were to be used in this context.
You can buy one of these http://www.entropykey.co.uk/ which are unlikely to be NSA "certified" instead.
Relevant talk: Hardware Backdooring is Practical - Jonathan Brossard https://www.youtube.com/watch?v=j9Fw8jwG07g
The core concern seems to be the idea that an RNG embedded into Intel's latest kit might actually be a PRNG that could be backdoored by NSA on command somehow with resultant catastrophic effects to crypto primitives on that box, if the Intel RNG were the only source of entropy on the box.
FTA:
"It's worth noting that the maintainer of record (me) for the Linux RNG quit the project about two years ago precisely because Linus decided to include a patch from Intel to allow their unauditable RdRand to bypass the entropy pool over my strenuous objections. " -- Eugen* Leitl
Linus has close ties to Intel and has for a long time.
He may have a lot of Intel connections, but he doesn't seem to be committed to any specific vendor.
(OT: Eugen Leitl simply forwards posts from one mailing list to another, almost always without any reason for doing so, commentary, explanation, "value add", etc. He's in my kill file for that reason.)
Feel free to edit the question if you have anything to add!
Would he take another option since last month? Maybe in the light of this he could take back that choice.
Can hardware? [0]
[0] http://en.wikipedia.org/wiki/Hardware_random_number_generato...
This email could just as easily be the musings of an insane person, which is what's suggested by the contents of the website.
The NSA would have no way of blocking it from being used to attack the US. And you can't roll out a hotfix for billions of CPUs worldwide.
Twist is that such code is executed on dedicated specialised processor in chipset/CPU with own firmware and it does much more:
http://www.blackhat.com/presentations/bh-usa-09/TERESHKIN/BH...
Do these put a different slant on the whole "current-day computation" angle? Not necessarily these machines, but isn't it feasible that custom hardware could be manufactured using current tech, that upsets the notion of AES brute force feasibility?
Edit:
This is not to say that the NSA was aware of linear crypto analysis when they made their recomendation. Indeed the fact that their s-boxes also happened to be just good enough to beet differential, and the fact that an independent government investigation (the details of which are classified) cleared them of wrongdoing, are enough to convince that they did not intend to introduce a hole. Furthermore, the NSA has also now published the requirements they used to generate their s-boxes. Schneier suggests in his book that the s-boxes were weakened unintentionally by the act of introducing structure to them, without knowing to defend against linear analysis.
[1] Bruce Schneier, Applied Cryptography
Was that the result of the last-minute "black box" change? I never heard the result of that, so any light you shed would be welcome.
You can read more about their involvement here: http://crypto.stackexchange.com/questions/16/how-were-the-de...
Thanks for the pointer.
https://en.wikipedia.org/wiki/Clipper_chip
It died when Matt Blaze figured out a way to trick the clipper chip doing encryption that the NSA could NOT decrypt.
Wow. What happened?
This was one of my favorite shirts, but it finally gave up the ghost a few years ago.
The NSA choose the key size of DES since they were running the process (making DES 256 times weaker than a 64 bit key).
You mean that damned monstrosity I always disable? You're claiming it's not a plot to make Linux utterly unusable?
In the last seven days, has the fundamental incompatibility between SELinux's design and traditional Unix permissions and tools been suddenly corrected? Has tooling been created to allow us mere mortal sysadmins and engineers to understand and manipulate the byzantine SELinux configuration?
I didn't think so.
What was one recent example?
> an already-secure environment
Not possible.
> has the fundamental incompatibility between SELinux's design and traditional Unix permissions and tools been suddenly corrected
You mean labels? No, that's pretty fundamental to SELinux.
> Has tooling been created to allow us mere mortal sysadmins and engineers to understand and manipulate the byzantine SELinux configuration?
Try setroubleshoot.
System Apache unable to listen on non-standard port.
> Not possible.
Tell me of a vulnerability on a fully-updated RHEL 6 image running only SSH and a basic Apache configuration serving static files which would be prevented by the stock SELinux configuration.
> You mean labels? No, that's pretty fundamental to SELinux.
Exactly. So my explicit decisions about file permissions must be duplicated. No thanks.
> Try setroubleshoot.
So, no.