A2: Analog Malicious Hardware [pdf]
impedimenttoprogress.com
impedimenttoprogress.com
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.
That already happens in embedded systems (esp MCU's) in a different way. You're thinking on the right track. All I can say.
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/
[2]: I got a funded offer at GA Tech, so it's all good :D
[1] https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...
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.
Absolutely it should, mods, dang, please fix the title.
Moreover, matthewmacleod (1) shows that Thompson didn't predict exactly this level of subversion and anything specific to this method, so the title is even thus inappropriate.
"And thirdly, the code is more what you'd call "guidelines" than actual rules."
HN actually doesn't even call it rules but Guidelines in the footer.
I like the "A2: Analog Malicious Hardware" work, but I'm quite sure even Thompson wouldn't claim that what's in the work is exactly what he presented in his talk. His talk is more nuanced and has one much more interesting consequence: that unless you decompile the compiler binary with some very clever tools, just the simple modification in one generation of the compiler can make the following compilers carrying Trojan payload without the payload being visible in the source of the given compiler. "A2: Analog Malicious Hardware" doesn't have this "payload propagation through the generations" property.
Very different from what the person who gave the false title here believes. What I claim is that "ltcode" misunderstood the intention of the Thompson's work and therefore the ersatztitle he gave here is very inadequate.
Well, at least he didn't create the title that involves Einstein.
To make this distinction more relevant: this kind of attack would be very useful in the context of EEPROMs or cryptographic chips (like TPMs): you could, for example, induce a cryptographic chip to dump its internal state (private keys), or you could overwrite a flash region that would under normal operation be non-writable.
Submitters: it's against HN's rules to rewrite titles like that. It's only ok to do so if they're misleading or linkbait to begin with (and definitely not to make them more so).
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.
And this is even lower - in the hardware itself.
Really fascinating work.
https://news.ycombinator.com/item?id=11771243
Founders of INFOSEC taught us most of what we needed to know. Mainstream security prefers to ignore it, calling it unnecessary, then reinvent it one technique at a time over several decades. Least the OP paper is doing what high-security recommended which is investigating risks at transistor and analog level. Most data on that is trade secret given it's exploited for competitive advantage and intelligence agencies.
That's not just true for security, that's true for the entire software industry.
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!
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.
Looking around a bit to verify the pricing landed me at: 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/cyberS...
Very cool stuff.
[insert critcism of how I need to be a better public speaker here]
The process for designing and producing chips is extremely waterfall, requiring various specialist skills and software that aren't particularly cheap. It's not impossible for smaller startups - I've actually been a consultant as part of a team for an outsourced mixed-signal chip design, under half a million dollars.
The problem is that now you've made hardware, with all the woes of a hardware startup, with the addition that you don't make any money until people incorporate your product into their product. It requires deep pockets and you're vulnerable to either straight cloning or existing companies pushing out competing products, while it doesn't really have the same unicorn potential upside.
There's plenty of failed processor startups around if you look, but only really one successful one: ARM.
(Acorn's 'exit strategy' in the late 90's was also interesting - they shut down the computer division, focused on DSL chip designs, and got bought by Broadcom a couple of years later for $1xx million...)
Next problem is each iteration into deep, submicron processes uses smaller tooling fighting more physics and noise with ever more sensitive instruments. Figuring out each issue requires lots of expensive tooling and experiments. Those vendors gotta make their money back. So, each tool in semiconductor process can cost millions to tens of millions of dollars. Each are custom built. The fab has to buy dozens to hundreds of these plus recover their investment with profit. They do it in wafers sold mainly.
So, given each market converges on a few players, it's easy to see that only a few players will have the volume to sustain the investments into new tech. On top of it, the nodes seem to double in cost ever so many steps trimming off even more competition. It got down to the lowest nodes that make high-end CPU's and mobile SOC's having only five or six companies fabbing them. Still plenty of work, esp for analog/RF, at higher nodes like 180-350nm. Yet, even an older fab might have to do $10-50mil a month in business just to keep their doors open.
Needless to say, people aren't going to do deep-submicron in their garages any time soon. Most companies with deep pockets gave up on fabs, too. Even IBM is selling theirs IIRC. So, most use a "fabless" model where they design hardware then send files that remaining fabs turn into hardware. There's a few companies that keep their own fabs on mostly obsolete nodes that are still useful to them. Yet, almost everyone else is fabless.
http://alacron.com/clientuploads/PDFs/Applications/FocusedIo...
This describes micromilling semiconductors with focused, ion beams. Now, you said not FIB lithography. I can't be sure this is what you're talking about but it's pretty direct. Regardless, all the schemes work similarly in that you work on one part at a time across a chip or wafer. In this one, you can see the precision work is so time consuming that it can take 8 hours for first, metal layer in a chip with quite a few of them. Another part says days. Whereas, even old uses of masks with steppers were cranking out three wafers per minute. See the difference? That's why the direct technologies, even multiple beams, are usually used for just the photomask (most fabs) or for prototypes (eASIC).
I did find that fab I was telling you about that used tech like this:
http://www.nytimes.com/1988/08/01/business/chip-maker-withou...
It was doing it on nodes that are ancient by today's standards. Yet, you could do quite a bit with them. The lead time was only four weeks for quite a few chips at a reasonable price. Better capabilities can be had at less price today. I keep saying target 0.35 micron initially as it's inexpensive with many fabs available and last cheap one with visual inspection possible. Plus, OSS flows should work on it. Use one beam fab for cheap ones plus one for at least 90nm with 65nm or 45nm high-end.
Far as recent companies, the eASIC process is maskless at 90nm, 45nm, and 28nm for prototyping. THey mainly do structured ASIC's. Here's an example of the prototyping cost:
http://www.easic.com/easic-introduces-45nm-asic-value-shuttl...
You'd think FIB milling (and deposition and implantation) should be able to do considerably better than the 28 nanometers you can do with photolithography these days (after investing a billion dollars in your fab, anyway). The de Broglie wavelength of a heavy ion isn't that big.
The eASIC link you give implies, without saying, that eASIC ASICs aren't "cell-based ASICs", but that's what "structured ASICs" are, and WP at least confirms that the Nextreme ASICs described in that link in particular are cell-based.
It's not totally clear to me that eASIC is in fact using FIBs for their prototypes; is that based on you talking to people at the company?
I agree that the per-unit cost for FIB is enormous. I hadn't thought about the possibility of using many beams at once to reduce that cost.
Re masks. I know. The reason I mention it is they're both essentually drawn by hand a piece at a time. Showing why one is too slow to use for significant volumes should enlighten you on other. Yet, if tiny volumes, might be acceptable but machines cost $$$.
Re eASIC. eASIC uses a multiple, eBeam machine for theirs. They might have more than one. They directly write the stuff onto the naterial. That it's a S-ASIC defined by one, custom layer is why it's so quick and cheap. A full ASIC has many layers so price/time goes way up.
Btw, I'd be interested in an email from the guy to ask him a few questions. Im especially interested if he needs a cleanroom, how he packages them, and what software is like to assess subversion counters at interface level.
I always see articles on the ebeams and FIB showing how they work. Nothing on packaging.
It's great that is proven, though, and not just intuited. This looks like some stellar work by the team.
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.
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.
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.
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. :)
I think 'nickpsecurity has previously made some interesting remarks on the issue at lower levels...
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=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. ;)
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.
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.
"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
[2] https://news.ycombinator.com/item?id=10468624
[3] https://www.acsac.org/2002/papers/classic-multics-orig.pdf
"It was noted above that while object code trap doors are invisible, they are vulnerable to recompilations. The compiler (or assembler) trap door is inserted to permit object code trap doors to survive even a complete recompilation of the entire system. In Multics, most of the ring 0 supervisor is written in PL/I. A penetrator could insert a trap door in the PL/I compiler to note when it is compiling a ring 0 module. Then the compiler would insert an object code trap door in the ring 0 module without listing the code in the listing. Since the PL/I compiler is itself written in PL/I, the trap door can maintain itself, even when the compiler is recompiled."
Given backdrop, hard to say whether they put it in the source or object code of the compiler. It's ambiguous: "since PL/I compiler is written in PL/I." Either it's because they have backdoor in its source code or because the backdoored, object code is the PL/I compiler that will be used to re-compile any PL/I source. Next paragraph indicates they insert the trapdoor in another routine using object code that closely matches that produced from PL/I source. So, I'm assuming... with some uncertainty... that they bugged the object code of PL/I compiler to add trapdoor to it and all executables on compiles. With nothing left in the source.
Then, Thompson paper simply says:
"First we compile the modified source with teh normal C compiler to produce a bugged binary. We install this binary as the official C. We can now remove the bugs from the source of teh compiler and the new binary will reinsert the bugs whenever it is compiled. Of course, the login command will remain bugged with no trace in source anywhere."
Sounds like they're doing the same thing except MULTICS attack uses assembly code directly. They might have coded it in PL/I first, then directly inputed the code. That would make both attacks equal. Who knows. That they each bug the compiler at object level with no source-level evidence seems accurate. In that case, Thompson attack is MULTICS PL/I attack applied to C with clear use of C for subversion artifact.
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
OOP, Ethernet, the mouse, GUIs, and tablets were some of the things invented at Xerox PARC.
That's not something I'd brag about... ;)