Researchers demonstrate ‘hardware trojan’ attack on Ivy Bridge

A team of researchers from the US and Europe has demonstrated a "hardware trojan" attack on Intel’s Ivy Bridge processor. This paper (PDF) describes the exploit, which changes the dopant polarity of individual transistors to weaken the chip’s random number generator. The researchers were able to reduce the random number generator’s entropy from 128 to 32 bits, making cryptographic keys much more predictable. They claim the exploit is stealthy enough to pass not only the CPU’s built-in self-test, but also the National Institute of Standards and Technology’s tests for random number generators.

Inserting the trojan involved altering the dopant masks of "only a few" transistors. Ivy Bridge has about 1.4 billion transistors, making the small change difficult to detect. According to the researchers, the "sub-transistor" trojan can’t be exposed by optical reverse engineering because the chip’s circuitry remains the same.

Ars Technica has a good summary of the paper, including some commentary from one of its authors. That researcher points out that hardware trojans haven’t been found in the wild. However, the proof-of-concept attack illustrates that existing chips are vulnerable to hardware exploits that may be impossible to detect.

Comments closed
    • ronch
    • 6 years ago

    But… but…. my antivirus says I am SECURED!!!!!

    /sarcazm

    • Krogoth
    • 6 years ago

    So basically it is a backdoor exploit guise as artificially crippling your products? Like this never happened before, oh wait!

    I think some marketing people at Intel are coming up with a way to sell this a “feature”…….

    • Stickmansam
    • 6 years ago

    The major thing this brings up IMO is the need for better testing methods to detect tampering of that kind. It not likely going to be some random hacker/employee nor likely the company implementing an exploit of this level. This level of exploit would likely be State sponsored and forcing the chip maker (not just Intel, but any chip maker really) to introduce the exploit. The chips would likely only be a limited batch and distributed to certain targeted organizations/persons or states to weaken their security.

    • UnfriendlyFire
    • 6 years ago

    For those who lack reading comprehension:

    How this attack can be applied:

    1. An Intel CPU manufacturing plant’s management or their engineers are approached by some “3rd party members”.

    2. Manufacturing schematics of a few transistors is slightly altered to break the random number generator.

    3. Wait a few months for the altered CPUs to penetrate the market.

    This concept can also be applied to suppliers of mission-critical chips. Especially ones that are manufacturing counterfeit chips.

      • UnfriendlyFire
      • 6 years ago

      I would also like to point out that in some cases, ethically-challenged suppliers sometime crank out counterfeit ones along with the real products.

      • Clint Torres
      • 6 years ago

      “It would be a shame if anything were to happen to your beautiful family…wouldn’t it?”

    • Deanjo
    • 6 years ago

    These types of exploits are not anything new. Back in 2010 groups were demonstrating attacks on many different NIC firmwares allowing them to exploit systems before the bootloader even came into play.

      • Glorious
      • 6 years ago

      Different kind of attack entirely, and anyone in the their right mind has all of those retarded “management” protocols disabled.

    • indeego
    • 6 years ago

    Who knew making programmable firmware would bring this type of attack? WHO KNEW?!

      • chuckula
      • 6 years ago

      If you have firmware that can change the dopant molecules in transistors, then there’s a Nobel prize committee that would like your number…

        • BIF
        • 6 years ago

        You don’t need to change dopey molecules.

        All you need to do is manufacture each core with two sets of molecules and write the firmware so that it selectively uses one set or the other in the core.

        Or just manufacture one core in your 12-core Ivy Bridge E with the shortcut pathway, and then use firmware (or hell, why not a batch command?) to selectively dispatch whatever you want to that core?

          • just brew it!
          • 6 years ago

          The point of the (theoretical) hack outlined in the paper is that you don’t need to add or remove components in the chip design; you’re just subtly altering the behavior of existing ones, in a very difficult-to-detect way (even if the chip die is examined under a microscope), that affects only a single CPU instruction. OTOH, to do what you’re proposing would require additional circuitry and control registers (changes to the physical chip layout), hidden CPU instructions (detectable by disassembling the code that triggers the exploit), etc… i.e. a rather non-trivial design change to the CPU core.

    • WillBach
    • 6 years ago

    I’ve said it in a reply to Neely but it’s worth noting in it’s own thread that the Linux kernel uses the RDRAND instruction provided by Bull Run as only [i<]one[/i<] of [i<]several[/i<] sources of entropy for its rand function. That means that keys generated by the Linux kernel would not be affected by this attack... alone. There's still a lot of benefit from even a known compromised RDRAND instruction (especially if it still has 32-bits of entropy) because it's so fast. It can be useful for various algorithms like quicksort that require fast random numbers for optimal efficiency.

      • Phr3dly
      • 6 years ago

      You are making assertions about rdrand for which you have not provided any evidence.

        • Glorious
        • 6 years ago

        Did you bother to look?

        “Elaborating the use of rdrand, Torvalds stated that the function was being used as just “_one_ of many inputs” to the random pool and that it was used to improve the overall randomness. Torvalds iterated that rdrand did in fact improve the overall quality of random numbers generated through /dev/random. Ending his reply with the statement “you’re ignorant.” The petition is now closed.”

        [url<]http://www.paritynews.com/2013/09/10/2710/change-org-petition-arm-soc-changes-invite-torvalds-fury/[/url<] In the news as of last week...

          • Phr3dly
          • 6 years ago

          You misunderstand. The OP (WillBach) is claiming that rdrand is an NSA backdoor. He has asserted that in several posts.

          “the Linux kernel uses the RDRAND instruction provided by Bull Run”

          /that/ is an assertion for which he has not provided any support.

    • Captain Ned
    • 6 years ago

    Project BULLRUN??

      • WillBach
      • 6 years ago

      Yeah, that’s what they modified. It’s named after a county in Virginia or a creek in Tennessee.

        • indeego
        • 6 years ago

        Or a reservoir in Oregon.

        • Glorious
        • 6 years ago

        BULLRUN is the NSA program

        Bull Mountain is the Intel Random Number Generator (AKA RDRAND).

        Now, maybe one has something to do with the other, but that’s beyond the scope of the paper…

          • NeelyCam
          • 6 years ago

          Interesting that the names of the programs have such similarities.. Coincidence..?

          • WillBach
          • 6 years ago

          Oh wow. The names were so similar I misremembered Bull Mountain as Bull Run.

            • destroy.all.monsters
            • 6 years ago

            No Teddy Roosevelt figurine for you you dirty commie.

    • lilbuddhaman
    • 6 years ago

    Makes one wonder if/when you buy a processor from a lesser/unknown vendor at a heavily discounted price, whether they’ve preemptively made this change.

      • Goty
      • 6 years ago

      The change would need to be implemented at time of manufacture, so it’s not something that a third party can do to any random CPU they get their hands on.

        • Mourmain
        • 6 years ago

        Unless that third party is the NSA, and they have a “collaboration” with the computer vendor. It’s entirely plausible.

      • MarkG509
      • 6 years ago

      There were some interesting threads about de-lidding/re-lidding CPUs a few weeks back to do stuff like change the crappy TIM to something better.

      I’ve worked on ASICs that were dead when they came off the manufacturing line that were sent out for some very expensive/extensive rework involving lasers and redeposition of some metal layers and were quite usable after.

      Never underestimate what *can* be done given adequate motivation.

        • just brew it!
        • 6 years ago

        Yeah, when you’re dealing with chips that cost thousands of dollars this kind of thing can be economically viable. Probably wouldn’t work for this particular hack, unless you can induce a similar failure in the RNG by adding/removing metal interconnects.

        Speaking of expensive chips, a couple of years ago I worked on a project which had a custom board with a rather expensive FPGA on it. For a while we had a copy of [url=http://xkcd.com/730/<]XKCD #730[/url<] posted in the break area, with the title changed to the name of our project (note the "most expensive chip available" at the left side of the diagram).

          • NeelyCam
          • 6 years ago

          [quote<] XKCD #730 [/quote<] Hilarious! Thanks for that!

          • MarkG509
          • 6 years ago

          I’m still laughing as I try to type this. Thanks!

    • chuckula
    • 6 years ago

    “Demonstrate” is a strong word that shouldn’t really be applied here.
    “Postulate” would be more accurate. Additionally, if this attack works, any processor that exists is going to be vulnerable to the same type of attack.

      • just brew it!
      • 6 years ago

      Yeah, as an exploitable attack vector it’s all just theoretical at this point. However, if their claims about the RNG still passing built-in and NIST tests are true, then we need better tests!

        • chuckula
        • 6 years ago

        Better randomness tests are always a good thing and they should be applied to all RNGs (software and hardware).

      • WillBach
      • 6 years ago

      “Demonstrate” definitely applies as they showed the attack working. While “any processor” may be vulnerable to transistor doping and this research reminds us not to rely too heavily on any individual security IP block in general the attack was demonstrated on one such block in particular. That block, Bull Run, is common to all Intel 22-nm devices that I know of (except maybe Xeon Phi) so this is a particularly noteworthy demonstration. That said it’s worth noting that the Linux kernel uses the RDRAND instruction provided by Bull Run as only [i<]one[/i<] of [i<]several[/i<] sources of entropy for its rand function meaning that keys generated by the Linux kernel would not be affected by this attack [i<]alone[/i<]. And 32-bits of entropy is still enough for a quicksort routine 😉

        • just brew it!
        • 6 years ago

        Looks to me like they’ve only done it in simulations of the affected circuit(s). So they’ve only “demonstrated” it if you define “demonstrate” as “write a paper describing an attack which seems to work in simulation, and which you might be able to implement for real if you have the ability to modify the masks used in Intel’s fabs”.

        If that’s your standard of proof I could “demonstrate” all sorts of things for you, none of which I’d be able to actually pull off in real life…

        Edit:

        Or, to put it another way: “News flash! Tinkering with the design of a circuit can make it misbehave!” The only part of it that anyone should find particularly disturbing is that existing tests do not detect this failure mode.

          • Glorious
          • 6 years ago

          Yup.

          The only remotely interesting part of any of this is the claim that it’ll still be compliant with NIST and FIPS.

          Given how these chip-based RNGs work it’s not surprising that by just lightly tweaking a few things you can vastly undermine the entropy. If you are relying on circuits not being well-defined; if you are letting them teeter on the brink of 1 or 0, just the gentlest nudge will completely change the consistency. The slightest whisper can utterly override the background noise that the RNG needs to work properly.

          So, again, the modification is completely ho-hum. As JBI says, the claim that it defeats the tests absolutely isn’t.

        • chuckula
        • 6 years ago

        When you can show me the doped silicon, then we have a demonstration.
        If you can show me *redoped* silicon that started out OK at the factory and was later successfully re-doped to introduce the attack, then I’d be more worried about it.

        Simulations are great, but I could simulate practically anything if you give the simulation lots of knobs to turn to mess with the structure and functionality of a chip.

          • NeelyCam
          • 6 years ago

          [quote<]If you can show me *redoped* silicon that started out OK at the factory and was later successfully re-doped to introduce the attack, then I'd be more worried about it.[/quote<] Yeah, and that would be impossible. This is not a demonstration, and they most certainly haven't demonstrated this attack on Ivy Bridge. To make this happen, you'd have to intercept the mask making process to tweak the mask, and you'd have to have very specific knowledge as to where those transistors are that you'd want to tweak. A mask vendor wouldn't know where to look unless they reverse-engineer the whole database that is coming in as a bunch of rectangles with hierarchical cell names obfuscated (i.e., no RTL). The attack could be done by the source before obfuscation, but if you can't trust the design house not to mess with the database, you can't trust them to design the RNG properly in the first place. In Intel's case, this is even less likely, as the whole process is in-house, from design to mask generation and manufacturing. There is no way some evil third party could tweak Intel's doping masks. It's far more likely that NSA has "encouraged" Intel to tweak the RNG in the design stage. I understand these guys need to justify their research funding by churning out papers, but this one seems kind of silly.

            • bthylafh
            • 6 years ago

            That’s what They want you to think. Wake up sheeple!

        • NeelyCam
        • 6 years ago

        [quote<]That block, Bull Run, is common to all Intel 22-nm devices that I know of (except maybe Xeon Phi) so this is a particularly noteworthy demonstration.[/quote<] They haven't demonstrated this on Intel's 22nm devices. They theorize that they could do if it they managed to get access to the mask generation, but they don't have that access.

          • Glorious
          • 6 years ago

          Yeah, which is why it’s strange they picked Ivy Bridge. Yes, I know it’s got copious amounts of documentation, and that’s what they said. But, still, only Intel fabs it, and when was the last time desktop chip counterfeiting was even a thing?

          The whole things seems kind of silly. It’d be better to pick an ARM design…

        • WillBach
        • 6 years ago

        Whoops – my understanding of the paper was wrong. I think “demonstrate” still applies in the academic sense because they showed it [i<]would[/i<] work.

          • just brew it!
          • 6 years ago

          They’ve demonstrated that it is theoretically possible. I’d still argue that the operative word should be [i<]could[/i<], not [i<]would[/i<]. There's usually a huge difference between an academic exercise and real-world application. As I've already noted (but I'll mention it again), the thing that makes this potentially dangerous is the claim that existing tests used to validate RNGs don't detect the flaw. Whether introduced intentionally ("sleeper" engineer planted by the NSA, organized crime, or lone yet highly skilled and exceedingly determined individual), or by accident (normal manufacturing slop or industrial mishap), we need to be able to detect these types of failures in the RNGs that secure our digital communications!

            • MarkG509
            • 6 years ago

            On new memory sticks, I usually run “memtest86+” for a several hours, sometimes overnight.

            If there were a “RNGtest86+” (that I trusted), I’d be willing/happy to run that for days.

            • Glorious
            • 6 years ago

            Dieharder isn’t perfect, but it’s nice.

            [url<]http://www.phy.duke.edu/~rgb/General/dieharder.php[/url<]

            • just brew it!
            • 6 years ago

            Cool. I may need to run the RNG I wrote years ago through this, just for grins. (Not expecting much, it wasn’t designed to be cryptographically secure; it was part of a DRAM and communications stress test suite, where speed was more important than true statistical randomness.)

Pin It on Pinterest

Share This