Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intel In Bed with NSA?

cryptome.org

Post reply on HN
Print view View original

61–70 of 73 posts

Re: Intel In Bed with NSA?

#61

Post by anonymfus »

binderbizingdos wrote: post #57
enkrs wrote: post #49

Earlier quoted context omitted.

Definitely paranoia. If you want to believe NSA is spying trough your Intel system, they could do it trough vPro and not some RNG calculations. One might assume that NSA can easily tap into the built in VNC server[1] of the CPU. [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 RealV…

Basic Assumptions: > 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...

Because you don't reflash firmware every time you enable/disable this technologies, it's obvious that there must be some code which checks configuration flags to activate this features.

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...

Re: Intel In Bed with NSA?

#62

Post by rooster8 »

One reason it would be a poor decision for the NSA to recommend Intel backdoor the RNG: Intel would be in a position to sell/leak the backdoor secret to other governments.

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.

Re: Intel In Bed with NSA?

#63

Post by skore »

gizmo686 wrote: post #25
gmuslera wrote: post #9

Hanlon's razor help in this kind of discussions. Maybe when Linus took that option didn't saw Intel as something that would intentionally make predictable its RNG for following government orders, and just choose to not reimplement the wheel where it was already available. Would he take another option since last month? Maybe in the light of this he could take back that choice.

Linus does not have the option to reimplement the wheel. Software cannot generate random numbers.

> Software cannot generate random numbers.

Can hardware? [0]

[0] http://en.wikipedia.org/wiki/Hardware_random_number_generato...

Re: Intel In Bed with NSA?

#64

Post by nodata »

nknighthb wrote: post #47
kllrnohj wrote: post #36

Earlier quoted context omitted.

You know who else cooperates with the NSA? The Linux community. You know, that whole "SELinux" thing? Yeah, that's an NSA project. 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.

> You know, that whole "SELinux" thing? You mean that damned monstrosity I always disable? You're claiming it's not a plot to make Linux utterly unusable?

SELinux works well nowadays. You'd know that if you hadn't disabled it.

Re: Intel In Bed with NSA?

#65

Post by twoodfin »

EthanHeilman wrote: post #60
kllrnohj wrote: post #36

Earlier quoted context omitted.

You know who else cooperates with the NSA? The Linux community. You know, that whole "SELinux" thing? Yeah, that's an NSA project. 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.

Yes and no better example than DES in which the NSA hardened DES against differential cryptanalysis and then reduced the key size from 128 bits to 54 bits so they could break it. Given the prior actions of the NSA is doesn't seem unbelievable that they would both harden and backdoor linux.

Who was arguing for 128-bit DES? Wikipedia says IBM wanted 64.

Re: Intel In Bed with NSA?

#66

Post by nknighthb »

nodata wrote: post #64
nknighthb wrote: post #47

Earlier quoted context omitted.

> You know, that whole "SELinux" thing? You mean that damned monstrosity I always disable? You're claiming it's not a plot to make Linux utterly unusable?

SELinux works well nowadays. You'd know that if you hadn't disabled it.

If I hadn't disabled it... which of the dozens of times it's gotten in my way on a new image? Most recently last week, by the way. I disable it because it prevents correct code from running in an already-secure environment. I don't bother beforehand, because I inevitably forget. And then waste ten minutes before I realize I need to turn off the magic "break everything" switch.

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.

Re: Intel In Bed with NSA?

#67

Post by zanny »

humanspecies wrote: post #33
zanny wrote: post #29

Earlier quoted context omitted.

This is why I show preference towards AMD chips even when they have the competitive disadvantage. Any sufficiently large company ends up, through their will or the gov'ts, wrapped up in politics. Which is the one of the larger issues of our age.

AMD is probably cooperating with the government on the same level as Intel.

Any company with over 1k employees probably is. I'm just saying if there are any systemic backdoors in Intel chips, AMD probably doesn't have them because they are 5 - 10% of the market and the gov't doesn't care to jump through hoops to get them implementing whatever backdoor they want.

Re: Intel In Bed with NSA?

#68

Post by rozap »

IvyMike wrote: post #55
barbs wrote: post #22

Earlier quoted context omitted.

> The feds used to fight civilian crypto tooth and nail. Curious. I'd like to read about this. Can anyone post any links?

Read up on the Clipper chip: A chip which sort of being promoted to be the "official" way to do crypto in the US. Specifically designed to be decryptable by the NSA via "key escrow". 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.

" Then-Senators John Ashcroft and John Kerry were opponents of the Clipper chip proposal, arguing in favor of the individual's right to encrypt messages and export encryption software."

Wow. What happened?

Re: Intel In Bed with NSA?

#69

Post by jlgaddis »

lifeguard wrote: post #7
spindritf wrote: post #2

I upvoted but the current title ("Is Linus Tovalds 'evil'?") is downright horrible and I hope a mod will revert it to the original one soon.

Linus is (was?) one of my living heroes. But he controls the Linux kernel. 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.

JFTR, that quote is from Matt Mackall.

(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.)

Re: Intel In Bed with NSA?

#70

Post by comex »

rorrr2 wrote: post #54
comex wrote: post #3

It is really, really hard for me to see this as anything other than utter paranoia. As one of the messages in the thread stated: > 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 s tstorm…

That's an argument from ignorance fallacy. "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.

"It would be difficult to implement effectively, therefore it is likely to not exist."

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.

Post reply on HN