11 ms·
A2: Analog Malicious Hardware [pdf]
- ebbv 10y agoThis is really cool. It proves something that anyone with a reasonable amount of knowledge about hardware and software should understand intuitively; that the ultimate trust for any computing platform is put in the hands of not the hardware designers, but the actual hardware manufacturer. That doesn't mean Apple, that means TSMC or some other foundry. It's great that is proven, though, and not just intuited. This looks like some stellar work by the team.
- sevensor 10y agoI agree that this is a really interesting exploit, but it requires a lot of expensive part-specific work to get it right, as well as the assumption that the foundry does their own masks. Of course, our attacker could work for the mask shop instead, but then he has to do it exactly right the first time, which makes it even trickier. This is all to say that, when we see this attack in the wild, somebody with very deep pockets will have been responsible.
- ebbv 10y agoIf you have a bad nation state actor wanting these exploits in place I don't think it's beyond reason that they would go to any steps. Imagine they could get a backdoor into every smartphone on the market by getting TSMC to manufacture chips with exploits in them. You really think there's any feasible but difficult steps that would stop them from doing this?
- impdmnt2Prgrss 10y agoIf a graduate student and a postdoc can do it...
- Cozumel 10y agoGood for Ken!! Who? lol
- mikecsh 10y agoThis link (pdf) provides the missing context: https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...
- lossolo 10y agoYou use things he worked on everyday, one of them is UTF-8. He also designed and implemented UNIX. He was creator of B language, thanks to which we have C language. He also worked on Golang and Plan9.
- SixSigma 10y agoAnd even wider, almost everything in the modern world was invented at Bell Labs.
- rubiquity 10y agoOr Xerox PARC.
- SixSigma 10y agoNot even close to Bell-Labs.
- SixSigma 10y agoSorry downvoter but you really have no idea how much more Bell-Labs has done. The Simplex algorithm, the transistor, C and C++, the R programming language, the ccd, the mobile phone... Just some from the top of my head
- deleted 10y ago[deleted]
- rubiquity 10y agoNo need to be dismissive. This isn't a peeing contest. OOP, Ethernet, the mouse, GUIs, and tablets were some of the things invented at Xerox PARC.
- Cyph0n 10y agoThanks for this, just added it to my Zotero backlog. I don't see what this has to do with Ken Thompson though. Did he believe that undetectable hardware backdoors would be possible in the future, or what exactly? I applied for a PhD at UMich this year hoping to work at MICL[1] under Prof. Dennis Sylvester, who co-authored this paper, but I was sadly rejected[2]. MICL is one of the best places in the world to do IC design, and Prof. Sylvester is absolutely amazing. [1]: http://www.eecs.umich.edu/micl/ http://www.eecs.umich.edu/micl/ [2]: I got a funded offer at GA Tech, so it's all good :D
- deleted 10y ago[deleted]
- v64 10y agoKen Thompson gave a lecture called "Reflections on Trusting Trust" [1] in 1984 that outlines a similar attack. [1] https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...
- IshKebab 10y agoIt's not a similar attack. This doesn't modify future chip designs to include itself, which is what Ken's attack did with code.
- nickpsecurity 10y agoIt really isn't. People just love that Thompson paper so much they always bring it up. Whereas I predicted this exact problem repeatedly with people dismissing it. Especially for microcontrollers where there's not much else to modify. And here we have the attack vector proven on a microcontroller. :)
- EdwardCoffin 10y agoHis talk used the attack he implemented as an example of a broader family of attacks. In his wrapping-up section (morals) he lists other ways one could embed backdoors into systems, and he noted that the further down you go the harder it is to detect. From Ken Thompson's conclusion: The moral is obvious. You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code. In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect. A well-installed microcode bug will be almost impossible to detect.
- Jach 10y agoExcept... http://www.dwheeler.com/trusting-trust/ http://www.dwheeler.com/trusting-trust/ I think 'nickpsecurity has previously made some interesting remarks on the issue at lower levels...
- aabaker99 10y agoCan you explain this a bit more? I've only read both the abstracts but if I understand right your link deals with compiler-level attacks but the OP deals with hardware-level attacks ("fabrication-time attacker").
- Jach 10y agoIt was basically a comment on the submission title -- Ken Thompson's famous attack has a counter that's been known about for a while. For the submission itself it's not as related as other commenters note they don't provide a way for the exploit to propagate like KT's attack. I'll have to read the full paper later but I wonder if it references https://www.usenix.org/legacy/event/leet08/tech/full_papers/king/king_html/ https://www.usenix.org/legacy/event/leet08/tech/full_papers/...
- nickpsecurity 10y agoIn my main comment, I showed my flow already prevented this as it relied on validated, open, standard cells plus analog reviewed by multiple, suspicious parties. Plus called the exact attack. Due to memory loss, I forgot that Thompson didn't actually invent the Thompson attack: Schell and Karger did during MULTICS evaluation. It's in 2 papers on bottom. So, you can add that to counterpoints to Thompson Attack legend. ;) https://news.ycombinator.com/item?id=11771243 https://news.ycombinator.com/item?id=11771243 Also, I produced a set of links to drop on high-assurance, subversion in general, and my verified compiler technique. I still need to do a Pastebin or something on latter as right now it's embedded in conversation with jeffreyrogers. https://news.ycombinator.com/item?id=10478742 https://news.ycombinator.com/item?id=10478742 https://news.ycombinator.com/item?id=10182282 https://news.ycombinator.com/item?id=10182282 EDIT: While he was ripping off MULTICS, Thompson should've also tried to do prefixed strings, protected stacks, and safer-by-default languages like it had. Might have prevented many attacks on the UNIXen back in the day. Today. Ten years from now. ;)
- qwertyuiop924 10y agoKen proved himself right 32 years ago, this is just another variation.
- nickpsecurity 10y agoThompson didn't invent or prove anything. He based his work off MULTICS Security Evaluation where Karger et al invented the compiler attack and submitted it in the report. See p 17: https://www.acsac.org/2002/papers/classic-multics-orig.pdf https://www.acsac.org/2002/papers/classic-multics-orig.pdf They invented many other attacks and risk areas you see today despite INFOSEC not existing back then. This was one 2 or 3 pentests that started the hacking part of our field.
- qwertyuiop924 10y agoI never said invented, but he did execute it successfully on a scale that may be larger than he admits.
- aabaker99 10y agoFor those who are also wondering, this is a preprint. [1] Kaiyuan Yang, Matthew Hicks, Qing Dong, Todd Austin, and Dennis Sylvester, “A2: Analog Malicious Hardware”, Proceedings of the IEEE Symposium on Security and Privacy (Oakland), to appear May 2016. [1] http://www.impedimenttoprogress.com/publications/ http://www.impedimenttoprogress.com/publications/
- Keyframe 10y agoThose tens of billions of dollars investments baffle me. I'm relatively well-versed in technologies involved as well as their r&d efforts, I understand construction parameters for fabs.. but I still can't understand how can setting up a production process cost such an extraordinary amount of cash. Also makes me think are chips (any smaller transistor scale, for arbitrary amount of small) out of reach for DIY fabrications and smaller startups? edit: I did stumble upon few youtubers doing their own chips with vacuum plasma chambers and DIY lithography and whatnots. It strikes me odd that there aren't more of 'hack' attempts at DIY chips. FPGAs and software is all fine and dandy, but this really seems like a fun and great challenge.
- brandonism 10y agoMy old university had a fairly large cleanroom and start ups would rent space/tools. Most of the equipment was very old, so limited to 100mm or 150mm wafers and sub micron feature would be difficult.
- tonyarkles 10y agoI'm not an IC designer, but from what I understand MOSIS (https://www.mosis.com/what-is-mosis https://www.mosis.com/what-is-mosis) is reasonably priced, for some definition of "reasonable". You don't get to use the latest technologies/feature sizes, but you do get to do small volume prototype runs for somewhere in the neighbourhood of $10,000. Looking around a bit to verify the pricing landed me at: http://www.cmc.ca/en/WhatWeOffer/Make/FabPricing.aspx http://www.cmc.ca/en/WhatWeOffer/Make/FabPricing.aspx. Those prices are likely subsidized from somewhere, but they bring things into the "totally approachable" realm. Here in Canada, if you were going to do an IC fabrication startup, it'd probably make a lot of sense to go through NSERC anyway; they have a lot of programs where you can get a significant portion of your employment and R&D costs covered. Edit: Looks like TSMC will also do things like this directly, but without specifying prices: http://www.tsmc.com/english/dedicatedFoundry/services/cyberShuttle.htm http://www.tsmc.com/english/dedicatedFoundry/services/cyberS...
- vvanders 10y agoYeah, they were talking about this on the Amp Hour a few episodes ago. There's some universities that actually fab a physical chip as part of their coursework using MOSIS. If I remember correctly there was an edu discount. Very cool stuff.
- deleted 10y ago[deleted]
- polarix 10y agoThis isn't quite the same thing -- to be completely analogous, we'd need the fabricator to also recognize that it was fabricating another fabricator, and then change THAT generated fabricator to have the same intervention but only in the case that we care about compromising.
- tamana 10y agoAfter reading the other front page article on a possible new Physics force... Ancient people thought everyday objects had powerful spirits in them or controlling them, subject to whims. Modern science showed almost everything is emergent complexity of very simple rules. Now, technologists are replacing the gods of old, creating powerful nigh invisible "spirits" that live inside everyday object: radios and batteries and computer chips with microscopic logic, the tiniest pebbles or shreds of fabric could be watching you and talking to you, controlled by an automated or remote maliciously force.
- moyix 10y agoThis is a neat paper. One of the tricky parts of making a malicious circuit is the fact that you want your behavior to only be triggered on some unlikely condition. In other words you want: if (counter == 0x686e686e) { do evil } else counter++; But that requires a lot of hardware. What the authors realized is that essentially a simple capacitor can be used as a counter! Each time you reach the condition it adds a bit of charge to the capacitor, until at the appropriate moment it discharges and changes the state of the chip in some way. This is a really clever bit of design, getting something general-purpose and malicious out of a single capacitor!
- impdmnt2Prgrss 10y agoThe paper uses two capacitors that share charge to get the same effect as your code. In effect Cunit (the smaller capacitor) is the increment (i.e., counter++), while Cmain (the larger capacitor) acts as the count-holding variable (i.e., counter). Another circuit (Schmitt Trigger) acts as the comparator.
- moyix 10y agoThanks for the clarification! I'm definitely not a hardware expert and was going off of what I remembered from the talk on Monday.
- schultetwin1 10y agoCould one defense be to design the chip to not have any empty space? In other words, fill in any empty area with test circuitry such that you couldn't tell which areas were actually used and which weren't.
- impdmnt2Prgrss 10y agoIt would be very complex to fill the entire chip with cells---whose functionality mattered, otherwise we the attacker could replace them without the defender noticing---and get them wired in to the rest of the chip. There is a tradeoff between area utilization and routability of the design: it gets exponentially more difficult to route a design as its area utilization increases. This is why most commercial chips have 20% to 30% of free space in the layout. Even worse, in many commercial chips, there are spare cells to allow for cheap low-level patching. The attacker can just swap out one of these cells with their own and have an attack that only modifies a single cell.
- nickpsecurity 10y agoCalled it! It was No 7 on a low-ranked comment [1], the third option in link at bottom of another [2] for standard cells (knew they'd get messed with), and mentioned repeatedly on Schneier's blog. Guy I learned risk from said he actively countered analog poisoning of 3rd party I.P. his company licensed. He said he was constantly finding it, mostly for I.P. obfuscation but sometimes more nefarious. Here's one of his observations on subverting crypto processors with digital or analog additions: "Controlling bits like the Carry flag is essential to the security of all crypto algorithms (techniques like DPA and "timing attacks" try to discover this information by observing the operation of the CPU) if you have a hardware way to transfer just this ONE bit, than most crypto available todays is useless. " He kept pointing out, probably from experience, that you could just modify a bit here, an MMU there, or add RF circuit to bypass plenty of protections. Nobody would even notice analog additions because "their digital tools can't see it." It would take careful reverse engineering. Old risk already deployed into production re-invented in a neat, new paper with new technique. Honestly, I originally got the subversion idea from the MULTICS Security Evaluation [3] [4]. Schell and Karger, not Thompson, should get credit for first attack like this as they introduced software that kept poking at a memory location until the MMU experienced an intermittent failure. They got in since software people assumed HW always worked. They also invented basis of "Thompson Attack" (see note below). So, I predicted HW trojans sitting on MMU, IOMMU, PCI, TRNG's, and some other things using non-standard circuits that nonetheless preserve timing, etc. So, a few years ahead on this one. Note: Karger and Schell also invented in same project the idea of subverting a PL/I compiler to insert malicious code into stuff compiled with it, including the OS. Thompson read that and expanded on it with Trusting Trust. Now, Karger and Schell attack is called the "Thompson Attack." Nah, the founders of INFOSEC thought of that one first, too. Take that Thompson fanboys! :P [1] https://news.ycombinator.com/item?id=10906999 https://news.ycombinator.com/item?id=10906999 [2] https://news.ycombinator.com/item?id=10468624 https://news.ycombinator.com/item?id=10468624 [3] https://www.acsac.org/2002/papers/classic-multics-orig.pdf https://www.acsac.org/2002/papers/classic-multics-orig.pdf [4] https://www.acsac.org/2002/papers/classic-multics.pdf https://www.acsac.org/2002/papers/classic-multics.pdf
- kragen 10y agoAFAIK Ken invented the procedure of quining the compiler backdoor to remove it from the compiler source code.
- mrb 10y ago"Analog malicious hardware" made me think of https://en.wikipedia.org/wiki/The_Thing_(listening_device) https://en.wikipedia.org/wiki/The_Thing_(listening_device) that snooped on americans for seven years...
- ChuckMcM 10y agoI find that fascinating! I have a faint recollection that one of bugs on the 80186 (the high integration 8086 that Intel built) was due to cross coupled noise from the metal layer to one of the register bits and the fix was to reroute one of the signals in polysilicon instead. I would never have considered that sort of effect as being exploitable as a back door.
- Animats 10y agoThis has some similarity to the rowhammer vulnerability. There, if you access some DRAM chips repeatedly in a specific way, some digital elements no longer behave in the idealized way that's expected, and there's cross-coupling between things that aren't supposed to be connected. This allows changing RAM to which you don't have access. That was accidental, rather than being designed in. This new attack is deliberate, rather than accidental, and very explicit, being wired to to the protected-mode bit. It points the way to even more subtle attacks, perhaps something that misbehaves slightly as power management is bringing some part of the CPU up or down. Maybe slightly more capacitance somewhere, so that right after a core comes out of power save, for the first few cycles some part of the protection hardware doesn't work right.
- impdmnt2Prgrss 10y agoYou made some extremely good insights... ;)
- nickpsecurity 10y ago"Maybe slightly more capacitance somewhere, so that right after a core comes out of power save, for the first few cycles some part of the protection hardware doesn't work right." That already happens in embedded systems (esp MCU's) in a different way. You're thinking on the right track. All I can say.
- mrob 10y agoTime to start building discrete transistor CPUs? This discrete 6502 project was posted here recently: https://news.ycombinator.com/item?id=11703596 https://news.ycombinator.com/item?id=11703596 It's far too slow for most uses, but that's mostly because NMOS logic doesn't handle the high capacitance well. NMOS logic uses MOSFETs as constantly enabled pull-up resistors, so they can't be very strong pull-ups or power consumption would be too high. I expect a CMOS design would be able to run much faster, especially with high voltage and the smallest transistors available. Individual transistors can be sampled and destructively tested, and the order they are placed can be randomized to make it harder to subvert the circuit by replacing them with microcontrollers. That leaves RAM, which is far too bulky to build from discrete transistors. But you could encrypt the ram in hardware, and mirror it across multiple chips each encrypted with different keys, and check they all read back the same once decrypted. The same could be done with mass storage devices. EDIT -- on second thoughts this will not defend against replay attacks within the storage device. I'm not sure if reliable detection of a malicious storage device is even possible without having some known good storage.
- nickpsecurity 10y agoHardware guru that taught me warned of another risk: you can't uninvent an advance tech once it's invented. The point being such techniques assume you can inspect what's going on because you're using components you know do only X. Yet, as chips get nanoscale, you can actually embed entire CPU's and RF systems in between larger components on others that are invisible to visual inspection and might not show up in black box testing. You can try to act like those nodes and their risks don't exist but subversives can still use them against you. The simple method here might be swapping more discrete chips or components out for others that are those components plus entire SOC's. Then, once they know your configuration, they hit you. Or they tell each to leak on a different frequency or whatever all at once with them figuring it out later. All kinds of crazy stuff is possible. So, just make sure you buy older stuff under different names with cash at unusual locations. Have proxies do it for you with legit excuses. Then, use multiple systems with voter logic. Tends to work out better than alternatives. Usability issues for sure, though. :)