Ivy-Bridge Hardware Trojan???

[pm]

This could be exploited by anyone at Intel, from corporate management, to design, to the people actually making the litho masks. Or someone hacking into Intel, which is not as unfeasible as it sounds, given the potential advantage this kind of exploit would give to any espionage agency.

CPU-level cryptography attacks are currently probably the scariest ones, as motherboards no longer provide memory controllers, so extracting a key is no longer feasible to do in a way that is difficult to detect.

I've worked for Intel for 18 years, I've worked on chips with these random number generator units on them, and I've worked on mask design (a long time ago) and I've been involved in taping-in chips, and with all that experience, I still would have absolutely no idea how to do this sort of hack. The database is shipped to the mask shop - a totally different team from the design team in a process that is called "taping-out" - a historical term referring to the process of saving the data to large magnetic tapes and then taking them out of the building and moving them to the mask shop. The mask guys - in turn - would then need to know exactly what to change on the masks but they have no real visibility into what the schematics look like or what they would need to change - it's a sea of data. Then you would need to modify the masks themselves - somehow. Or, someone could guess that some fab worker could do this, but the fab workers just get the masks and program the machines according to the recipe and there's no ability to dial in the tools to focus on particular transistors. Then there's the idea that someone could hack into Intel to change it - you'd need to know so much inside info to do that... I work on these projects and I frequently have to ask my co-workers for basic information like "hey, what's the path to the main RTL repository?". I can't even imagine trying to reverse-engineer something like mask data externally - it's confusing for the people who work here.

I find the whole premise of this "hack" to be remotely possible - you could do it - but pretty impractical... and then on top of that, say that you do change the randomness of the random number generator, to the best of my knowledge (and my knowledge is pretty good in this space) no one is relying solely on the random number - without any perturbations at all - as one source of "randomness". As Linus Torvalds wrote in this petition, "Long answer: we use rdrand as _one_ of many inputs into the random pool, and we use it as a way to _improve_ that random pool." meaning that you've reduced the randomness of one small portion of a chain which is of limited value in the larger picture.


For the curious, this is the paper in PDF form:
http://people.umass.edu/gbecker/BeckerChes13.pdf
Read it yourself and see what you think. If nothing else it's interesting from a thought experiment point of view.

* As always, I'm not a company spokesperson for Intel and my comments are my own. *

 

[Idontcare]

I will have to disagree a little bit, here, Phil. Although, as for the incredibly unlikely part, yeah, pretty much. I'm not sure it was a waste of tax dollars, though.

This paper is significant for the same reasons that NIST recently had to withdraw Dual EC recommendation due to suspected NSA tampering (see official publication here) which only recently got revealed as part of the Snowden leaks - even though as far back as 2006, security researchers already smelled something was wrong. It is probably important that I preface this with why Dual EC came about in the first place - it was developed by NIST specifically to address a long-standing weakness in the FIPS standard. This FIPS weakness is a very limited number of PRG (or PRNG, or just RNG, whatever your preference in naming it) algorithms, and most had known design weaknesses. They had to go, so we needed new ones. NIST made a new one. Actually, four. 3 symmetric ones, and, strangely, a non-symmetric one: Dual Elliptic Curve. Almost right off the bat, academic cryptographers smelled stink from Dual EC, and we all smelled "NSA tampering" on it, because not only was it super slow, it also didn't come with a security proof (haha, now that's a joke. NIST doesn't actually hand out security proofs, they release standards and let academia deal with coming up with the proof). No proof of such NSA conspiracy, so no luck - maybe it's just NIST being rookies. It happens - standards bodies of all sorts do often come up with mish-mashed, shoddy protocols - see for example the mess that was SSL 1.0 / TSL and even the current iterations.

I don't think I can go on with what exactly was wrong with Dual EC without going into too much detail that none of the CPU crowd here will appreciate anyway. It's probably more a thing of the Security subforum we have, but even there I don't actually see chit-chat regarding academic crypto.

Anyway, going back to the IBV RNG Trojan paper, the paper itself is not significant because it has happened already (the authors clearly stated that they have not observed any tampering in real life), and also not because it can retroactively apply to all your existing IVB systems and servers (because it clearly can't, and the authors were clear about that). The paper is significant only because it allows us security researchers to view another possible vector, which then allows us to come up with oversight and/or new techniques to mitigate or stop attacks from this new vector.

It sounds impossible now, yes, how could anyone (even the NSA?) force chipmakers (Intel, AMD, ARM or its licensees) to cripple their baked-in hardware security module? (To readers: Don't feel too bad the paper "targeted" Intel. Intel has the only useful chip with a hardware RNG module installed, so it's not like the authors had too much choice in the matter). But 7 years ago, way back in 2006, that was also the claim: it was impossible that the NSA could force NIST to weaken cryptograhic standards, so all the stink academic cryptographers had was just that - worst case, incredibly unlikely hacker scenarios more at home in "Enemy of the State" than real life. 7 years forward to the current time, we have the Snowden leaks and the 'evidence' from it suggests that we were pretty much right 7 years ago - NIST still denies it now, but at the same time they've officially dropped Dual EC recommendation after those leaks happened that pointed to some NIST standards being weakened by the NSA on purpose.

That's the only thing this paper is really saying: it is feasible to do so, and in such a way as to be undetectable in routine tests. So if someone (like the NSA) wanted to, they could use the techniques in this paper to weaken the crypto in the CPU's before they are shipped to distributors and retailers, much in the same way that they seemed to have weakend some NIST protocols. If they (NSA) can twist the arm of NIST to weaken crypto standards, or threaten CEO's of search companies with "Treason" for not complying to their orders, then maybe it isn't so far-fetched that in the interest of national security, they would twist the arm of chipmakers in order to bundle security hardware in the chip that they (NSA) can easily exploit.

The world was not this crazy before; 3 months ago, I personally would have laughed out loud at the absurdity of the scenario here - tampering with masks? Hahaha!

Then the NSA leaks happened. I don't care about the homeland spying thing, since I'm not an American and effectively not my problem (that's all yours, my American friends). But when your NSA gets its hands on tampering with international standards, especially standards that are supposed to keep us safe, secure, and private, then that specific portion also affects my work, even though non-American.

All true, but actually I was coming at this subject from an entirely different perspective that incorporates all of the above.

At every point in your compute environment you are implicitly assuming and trusting the hardware and software providers to be (1) not compromised by external influences, and/or (2) not compromised by internal influences.

The fact that some people show you can go to great lengths to accomplish #1 above is literally nothing new. If you, as an external entity, are willing to go to great lengths to compromise the security integrity at the hardware or software level then it can be done in innumerable ways.

Whether the NSA does it without Intel's knowledge, or Intel does it for their own secret reasons, regardless we are still required to trust someone (whom we have never met and never will) to design and sell us a product for which we assume the security aspects of the product are not intrinsically compromised by design from time zero.

These guys are pointing out they found a molehill on a pre-existing mountain. Why not talk about the mountain if that really is the concern?

And so the world putting this kind of money into finding yet one more way in which #1 above can be done, while we ignorantly assume #2 is not happening, is quite a waste of money versus say spending the same money on reducing malaria in tropical countries or shoring up land that is prone to landslides in the rainy season, etc.

 

[bononos]

The CIA/NSA owns and operates semi conductor labs including lithographic machines to fab and experiment on chips. I'm sure part of the reason so much money is poured into this is to make sure some of their critical components can be trusted and possibly to sabotage rivals.

The CIA is probably on friendly terms with big corps like Intel given their talents for industrial spying. Maybe they could work something out to jointly produce hacked chips from CIA labs and slap on an Intel sticker and the target would be non the wiser.

 

[dmens]

The paper states scan is omitted from the digital RNG circuitry because it can be used for an attack. I guess stealing the tap key is pretty easy.

That said I don't see why a scan chain involving the RNG can't be disabled with a fuse after validation.

 

[fyb3r]

You would be surprised by the amount of hardware specific viruses roaming around in the wild.

There is even rumor of the BIOS virus making its come back again, which is why Microsoft has changed over to UEFI in windows 8 for added security. Supposedly , cant remember where I read that at but would be nice to fact check it ^_^

 

[cytg111]

To be clear here, this is all proof-of-concept/what-if work. It's an exercise in seeing how the IVB PRNG could be modified to reduce the randomness. Retail chips are in no way flawed/compromised in this manner.

It's even more involved than that. The experiment was done entirely in simulation, with the idea of getting it into mass production, which requires access to the litho masks themselves. It's not actually practical.

- Somewhere the OS is accessing this hardware device, If I was really paranoid and felt like I had something to hide, I would problary investigate/research/reverse where the kernel does this, patch it up and supply my own rutine.. While my own rutine will be much weaker in academia it should no be so in practise.. I'd like to see "them" throw $$$'ers after one single paranoid SOB's idea of a weak software RNG.