[HN Gopher] Can You Insert Hardware Trojan Spyware IP into an IC...
___________________________________________________________________
Can You Insert Hardware Trojan Spyware IP into an IC at the Fab?
Yes
Author : giuliomagnifico
Score : 57 points
Date : 2022-04-14 16:43 UTC (6 hours ago)
(HTM) web link (www.eejournal.com)
(TXT) w3m dump (www.eejournal.com)
| dtx1 wrote:
| 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
| monocasa wrote:
| Because it's much less likely to be found.
|
| 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.
| dtx1 wrote:
| 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
| monocasa wrote:
| 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.
| heavyset_go wrote:
| 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.
| jaywalk wrote:
| I think biasing a HWRNG is in an entirely different league
| than the stuff you mentioned.
| uxp100 wrote:
| 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)
| dtx1 wrote:
| I hadn't considered that the victim might not necessarily
| be the end consumer. Interesting point
| ncmncm wrote:
| 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.
| uxp100 wrote:
| 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.
| ncmncm wrote:
| Yes, deleting things from a layout would be much easier than
| adding them. And, who's checking?
| annoyingnoob wrote:
| > What policies does your company have in place to safeguard
| against these sorts of exploits?
|
| What safe guards are there from a hardware trojan? Solutions like
| zero trust and segmentation only go so far in a scenario like
| this.
| kayson wrote:
| 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.
| ncmncm wrote:
| Sure, Ivan, we trust your judgment here.
| gigel82 wrote:
| 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).
| nonrandomstring wrote:
| 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.
| jacoblambda wrote:
| 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.
| bri3d wrote:
| 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.
| ncmncm wrote:
| Extracting crypto keys is just one high-value example use for
| the technique. It is easy to think of others.
| [deleted]
___________________________________________________________________
(page generated 2022-04-14 23:01 UTC)