It's unlikely something like this was (or will ever be) successfully pulled off. But there are well known supply chain attacks where firmware of various devices was compromised.
There are also some (unconfirmed) tales of extra, tiny ICs soldered on to existing connections on a PCB at just the right spot to spy on a data bus (those would definitely be more plausible than compromising an IC at the Fab).
It's also possible to add trojan hardware into an IC at the design phase (most likely with the "help" of the owner or otherwise forcing them via lawful or unlawful means by government entities).
I work in IC design. The foundry do not get involved in ecos. Ecos are all done at source, before tapeout to foundry. Inserting logic into an existing design would require intimate knowledge of the design, which the foundry does not have, without very extensive reverse engineering, which a single rouge actor in a foundry is not capable of.
I work in IC design too, and you are correct that this would be nearly impossible for someone at a foundry to pull off. But it would not be hard at all for a mole on the chip design team to do. And based on what I've seen I don't think it would be very hard for a state actor to get moles into most major chip design firms. Indeed, the measures required to protect against this would be scarier to me than the back doors.
It is even possible that chip designers insert back doors into their chips intentionally (no state-sponsored moles required) so they can covertly sell those capabilities to state actors as an additional revenue source. This might not even be illegal.
It probably is illegal, but only if there's damages, because that is usually how civil penalties work. In a way it makes sense: how do you know they did it if you have had no damage done?
The illegality is the damages regardless of how they occurred, but potentially also breach of contract if you think to specify "no backdoors" in your contract.
That's true, but it would be equally true of a backdoor inserted at the foundry by the technique described in TFA. Also, it is possible to insert back doors into hardware in ways that would be very hard to spot even by people familiar with the design. I've seen automated design tools emit some pretty weird shit, and for all I know it might have been a back door. But it passed LEC and DRC so it shipped.
Figuring out the block diagram of a chip is very different from mapping out the physical location of all the busses and gates so that you can splice new circuitry in without damaging the existing functionality.
Reverse engineering for compatibility does not give you an insight to any backdoors there, just as even having the full source code for a system does not trivially reveal all the backdoors or bugs it has.
This is the real reason why every chip team should buy it's members those framed die photos to put on the wall ...... "Hey, I didn't put that there ..."
Very interesting from a theoretical perspective. Luckily most of the devices we use have software on them that we know is compromised (written in memory unsafe languages, closed source, telemetry enabled) already so I doubt we have to worry that much about IC backdoors being inserted after the fact. After all, why dig a tunnel to rob a bank when the backdoor isn't locked
One rumor I've heard for a while is that messing with the doping at the right time can bias HWRNGs in a way that you wouldn't be able to notice even with physical inspection with an electron microscope.
We literally KNOW about the Intel ME and AMD PSP and we KNOW about all the windows telemetry yet most of the worlds IT runs on systems with these backdoors. There's no need to hide it in the first place
I mean, the Russian Elbrus chips boot Windows (and a version of Windows built from source by Russians), all without Intel ME or AMD PSP. But modern Elbrus is fabbed by TSMC.
And security agencies have proved that they take a layered, multipronged approach to SIGINT, even against companies that are directly working with them. Google working with the NSA didn't stop the NSA from also tapping Google's inter-datacenter traffic without telling Google.
Do you have more information about the second version of Windows that was compiled? I never looked at the leaked source code, but was under the impression that it wouldn't compile into a usable system.
And because we KNOW about the Intel ME many security researchers have been looking for backdoors and vulnerabilities in it, several vulnerabilities have been found but no backdoor.
If Intel wants to put a backdoor ME would probably be a bad choice because it's a too obvious and monitored location
This could be more about a rogue actor in a fab leaking Xbox private keys, for example. And Microsoft cares about that a lot, I think mainly because they worry non-legitimate copies of real games could be inserted into the supply chain at some point (though digital download sort of makes this irrelevant)
The end consumer may be the least likely target. More likely, a customer of the end consumer, or OEMs loading what they had hoped was protected code onto a microcontroller.
On a similar note, this attack introduces an artificial power consumption based side channel. It might require more inside information for the attacker, but it seems like an ECO that disables the crypto side channel mitigations that exist could be an interesting approach too. I’m not sure what the advantages and disadvantages would be.
Well, you probably actually are checking with the hardware. Running tests to make sure side channel mitigations worked. But would you recognize this as sabotage, and not just slightly worse performance of some technique that should have helped eliminate particular attacks?
It took me the entire article to figure out they were talking about
the exfiltration of cryptographic keys via power side channels and not
hard coded internet protocol addresses. I do wish people would stop
with this lazy-arsed use of "IP" to stand in for any kind of data they
don't know the proper name for.
IP has a well-understood and specific meaning in the VLSI / chip design industry, it's not a lazy placeholder term and the usual EEJournal reader would be unlikely to confuse it with the Internet Protocol.
FYI in the HDL/ FPA & ASIC design space, IP is short for Intellectual Property and the best analogue from the software space would be a "software library".
IP are often black boxes akin to proprietary software libs.
It's a dumb name but it has been in use for decades now.
This is incredibly far-fetched. At best, a rogue actor within a foundry, who happens to be working on the correct process node, who happens to be on the account of the customer victim, might be able to access the GDS file (the full-chip layout file submitted by the customer) or maybe even the mask files (GDS split into layers and processed by the foundry). Exfiltrating it is an entirely different story. Usually these files only reside in very, very locked-down environments. For this very reason.
Supposing they did get the full layout to an external network, they still likely wouldn't be able to do an ECO because most of the major players will be using custom standard cell libraries, and not the foundru-supplied ones. Even if it were using foundry libraries, the same rogue actor who has access to the chip layout probably wouldn't (and definitely shouldn't) even have access to the foundry's standard cell IP.
At this point it's already a virtual impossibility, but let's keep going. The next step is to actually perform the ECO, which requires a "net list", or a text equivalent of the schematic. Can you get one from the layout? Absolutely. That's how all Layout-vs-Schematic tools work. And the research paper says it's trivial, which it is. But what's not trivial is turning the transistor-level netlist to a gate-level net list. Again - standard cells aren't actually standard, especially bigger and more complex ones. Even harder still is using a netlist to figure out what those logic gates are doing. Trust me, I've tried. Is it doable? Theoretically. But with millions, or potentially even billions of logic gates, it's going to take a very, very long time.
Then you've got static timing analysis and power analysis to worry about. With the layout and a gate level netlist, you have all you need to run the tools. But again, it's going to take an extremely long time. Real designs are built hierarchically, so each team is doing timing/power closure for their own blocks and summarizing those for the parent block. If you have a massively flat structure it will be impossibly slow.
The underlying research paper makes some massive assumptions , which don't have me convinced at all. Their "trojan horse" circuit is legitimate - you create a digitally controlled oscillator tied to some critical data bus like in an AES subsytem, and the changing data modulates the current consumption of the oscillator which can be measured externally. This type of side channel attack is well known.
To me, the Trojan horse implementation is trivial, though. The much harder part is pulling off the ECO.
Doing a "regular" ECO to push a RTL change to the gate-level netlist (bypassing regular synthesis) is already a very difficult process. The hardest part is figuring out how your RTL maps to the optimized gates - and this is with full access to the RTL and netlist. I can't imagine someone being able to manage to pull this off from an unknown netlist and successfully understand, let alone modify, the design.
> The software analogy I like to use is trying to reflect a change in your source code by modifying the binary directly without recompiling.
Not sure about kayson, but I've done essentially that on a couple occasions (usually to some C++ abomination that refuses to compile away from the authors' build server). It's not that difficult.[0]
> Unlike those pirate crackers who sometimes can pull this off, imagine you have no idea what the binary does, and even if you "run" it in simulation (super slowly) everything is gibberish.
Realisticly, you usually do have a pretty good idea what the chip does[1], and may have 'extra'/'lost' stock from the previous revision to compare its behaviour against, especially if you're attacking something popular enough to be worth compromising (= probably more than one batch ordered).
0: Most off-the-top-of-head example from my notes file:
fix caja(glib) wrong(decimal) unit prefixes:
at libglib-2.0.so.0.4105.0:7CFB1
[... more at ...]
change 4 bytes in g_format_size_full
from: 41 F6 C4 02 test r12b 0x02 # if(flags&G_FORMAT_SIZE_IEC_UNITS)
into: 48 83 FB 00 cmp rbx byte(+0x00) # if(size!=0)
1: Presuming 'you' are a intelligence agency, ie the kind of thing that would credibly try such a attack, not a isolated disgruntled fab employee.
Actually "zero trust and segmentation" is the main policy that can enable the insertion of a backdoor in a circuit.
There are many large companies which discourage or forbid the access of the designers to other parts of the project than those that are strictly required to do their jobs.
The result is that very few, if any, have any understanding about how the entire device is supposed to work, besides of passing the cases of the testing plan.
Because of that, even if some backdoor is inserted and everybody sees it, there are good chances that nobody can guess its purpose and recognize that it is something that should not be there.
I was referring to the network, not the people building the hardware. The article asks a question at the end. How does one defend against a hardware trojan? Where that trojan would exist, perhaps dormant and invisible, inside a critical asset.
There are also some (unconfirmed) tales of extra, tiny ICs soldered on to existing connections on a PCB at just the right spot to spy on a data bus (those would definitely be more plausible than compromising an IC at the Fab).
It's also possible to add trojan hardware into an IC at the design phase (most likely with the "help" of the owner or otherwise forcing them via lawful or unlawful means by government entities).