Huang: IRIS (Infra-Red, in situ) Project Updates
The technique works because although silicon looks opaque at visible light, it is transparent starting at near-infrared wavelengths (roughly 1000 nm and longer). Today's commodity optics and CMOS cameras are actually capable of working with lights at this wavelength; thus, IRIS is a low-cost and effective technique for confirming the construction of chips down to block level. For example, IRIS can readily help determine if a chip has the correct amount of RAM, number of CPU cores, peripherals, bond pads, etc. This level of verification would be sufficient to deter most counterfeits or substitutions.
Posted Mar 10, 2024 14:14 UTC (Sun)
by dskoll (subscriber, #1630)
[Link] (23 responses)
This is really cool. I suspect, however, that a determined attacker could still hide some malicious circuitry on the chip. For example, if a chip contains memory, it usually contains spare rows that can be activated by blowing fuses in case some cells are defective; this improves yield. It's not beyond the realm of possibility that a "spare row" could actually be something malicious, though it'd be tough to make it look as regular as an actual spare row.
Back in 1999, I worked for a company that reverse-engineered ICs. I created a system called Integrated Circuit Imaging System (ICIS... in retrospect, an unfortunate name) with a microscope, camera, and precision computer-controlled stage that could image an entire chip and let people reverse-engineer it at the transistor level. That was back when feature sizes were significantly larger than visible light wavelength.
Posted Mar 10, 2024 19:12 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (16 responses)
As I understand it, this is merely a "smell test", which would detect things like selling a 256GB USB as eg a 512GB. Basically, it'll pick up consumer fraud, but going much beyond that won't get you very far.
Cheers,
Posted Mar 10, 2024 22:19 UTC (Sun)
by roc (subscriber, #30627)
[Link] (14 responses)
Posted Mar 10, 2024 23:24 UTC (Sun)
by dskoll (subscriber, #1630)
[Link] (13 responses)
I find the hybrid detection mechanism using a scan chain that the article described unconvincing. As I wrote earlier, an attacker can hide malicious circuitry in "unused" sections of the chip and just not include it in the scan chain.
Posted Mar 11, 2024 21:55 UTC (Mon)
by smoogen (subscriber, #97)
[Link]
Posted Mar 12, 2024 1:26 UTC (Tue)
by himi (subscriber, #340)
[Link] (11 responses)
Way outside my area of expertise so I have no idea about the implications for cost/performance/etc, but if the goal of this is to achieve an independently verifiable trust root then implementing this kind of extra validation support doesn't seem unreasonable.
Posted Mar 12, 2024 3:37 UTC (Tue)
by dskoll (subscriber, #1630)
[Link] (10 responses)
But the scan chain is set up by the chip manufacturer, and it can't be changed after that.
I get that this is useful for detecting blatant fraud like selling a 1GB flash drive that really only holds 512MB, but detecting these kinds of blatant fraud is pretty easy anyway.
Most complicated digital chips are essentially software... they're synthesized from a hardware description language (typically VHDL or Verilog) input. If someone hides a trojan in that input, I don't think anyone can tell by looking at images of the chip.
Posted Mar 12, 2024 3:39 UTC (Tue)
by dskoll (subscriber, #1630)
[Link]
Ah, ok, so the manufacturer puts the unused sections in scan chains and documents them. But the case I mentioned was for spare memory rows that are used if other rows are defective; they get switched by severing some fusible links with a laser. So you can't really include them in the scan chain because they're defective and will defeat the purpose of having spares, which is to increase yield.
Posted Mar 12, 2024 12:44 UTC (Tue)
by pizza (subscriber, #46)
[Link] (8 responses)
No; it's set up by the chip *designer* when they synthesize the RTL/verilog/etc into a sea of gates; this is where scan chains are generated and inserted into the design, and must be done before you can do the necessary timing analysis to find out if your design will actually *work* at the desired clock speeds.
(Granted, the designer has to trust the (usually highly proprietary) tools that synthesize the RTL into gates, but the accuracy of that can be done offline, before anything gets sent to the fab)
The sea of gates is then translated into a physical design through another synthesis pass that adds in the various analog components (eg RAMs, I/O cells, level shifters, amplifiers, and the individual transistors) and spits out a set of GDS files corresponding to the various mask layers in your design. These analog components are usually highly tuned for the specific fabrication process you're using.
You hand those GDS files to the fab, which may further modify them to add in any remainng analog blocks (or pre-synthesized 3rd party digital blocks), They then copy-n-paste your design until they can fill an entire wafer, and that is used to create the production mask set.
To the tl;dr of tihs is that unless you're intentionally plonking a 3rd-party pre-synthesized digital block into your chip design, the chip designer has full control over the scan chains, and they can't be altered after the fact by the fab.
Posted Mar 12, 2024 13:42 UTC (Tue)
by somlo (subscriber, #92421)
[Link] (3 responses)
The fab can choose to alter anything they want, they have full control of the *physical* layer underneath!
Their challenge consists in understanding (reverse engineering) enough of your masks to alter things in a way that is 1. hard to detect by you (i.e., leaves the design in a still apparently working order) and 2. useful (to them). E.g.:
https://web.eecs.umich.edu/~taustin/papers/OAKLAND16-a2at...
Posted Mar 13, 2024 14:19 UTC (Wed)
by pizza (subscriber, #46)
[Link] (2 responses)
Sure, but doing so in a way that preserves the designer-supplied scan chains (and continues to meet timing constraints) is a _far_ more challenging proposition.
...The difficulty is not unlike that of inserting arbitrary code into a binary while maintaining its sha256sum and not inducing any failures in an exhaustive, timing-dependent test suite.
(You can design the chip such that each logical block has its own scan chains, and you have to mux the external test bus to select which module you want to check. The attack vector here is that someone inserts _additional_ logic in unused/wasted silicon. accessed via some OOB mechanism. It wouldn't get caught by the original scan chains due to the additional test mux setting, but its ability to interact with the original logic would be quite limited due to any interaction necessarily affecting signal routing (and thus timing). Realistically, the main thing you'd have to worry about is something that can monitor your external I/O busses, but since those components are usually provided as opaque 3rd-party IP anyway, you're already in a position where you have to trust them...)
Posted Mar 13, 2024 23:01 UTC (Wed)
by himi (subscriber, #340)
[Link] (1 responses)
From what I can tell, it may not be doable on a modern process, but it's /definitely/ doable on an old 130nm process, and it /may/ be doable on a 22nm process that's still in very common use.
Posted Mar 14, 2024 0:55 UTC (Thu)
by pizza (subscriber, #46)
[Link]
It's definitely doable on 65/55nm processes too -- 8-ish years ago, we did some die imaging to aid in planning a series of FIB experiments [1] [2] and you could clearly see the analog components, along with relative transistor/metal density in the sea of gates and how it aligned with the EDA tools' view of the final placed-and-routed design.
(When the team was disbanded I used those die photos to make a really cool poster for everyone)
[1] https://en.wikipedia.org/wiki/Focused_ion_beam
Posted Mar 12, 2024 14:01 UTC (Tue)
by farnz (subscriber, #17727)
[Link] (3 responses)
And to bring this back round to Huang's original concern; he wants to mass-produce an ASIC from an open-source design such that it is practical for purchasers of that ASIC to confirm that the source code that Huang provides matches the ASIC they've bought.
The parts of this problem under Huang's control have known solutions - he can provide all the files he has to show that the design he sent to the fab and the source code match up, and I can verify that those files match up. However, there's currently no good way to show that the fab actually manufactured the design they were sent; they could, at least in theory, change the design to one that functions the same way as the one they received, but has malicious components added either in empty space in the design, or next to the original design when they repeat it across the wafer. IRIS addresses this by providing a way to inspect the chip and confirm that it doesn't have "surprise" blocks not on the original design.
Importantly, Huang's hypothesis that drives IRIS forwards is not "this can detect any modification to any chip". It's "if you design your chip with supply-chain tampering in mind, you can design a chip such that modifications made at the fab either show up under IRIS inspection or show up on the scan chain".
Posted Mar 12, 2024 15:34 UTC (Tue)
by paulj (subscriber, #341)
[Link]
In-situ verifiable, open-source-design chips seems like a significant step forward. Even it means a design has to stick to IR-light resolvable process nodes, and has to accept some inefficiencies from design constraints (fill up unused space; more scan chains to allow small, recognisable blocks to be verifiable; etc.).
Self-made "home" fab seems like the other, perhaps longer-term, prong towards verifiable hardware that exists. LWN has had some articles on someone plugging away at that.
Posted Mar 12, 2024 15:37 UTC (Tue)
by somlo (subscriber, #92421)
[Link] (1 responses)
Trouble with that (as also pointed out by other commenters) is that modifications made at the fab can be too small (see the UMich paper linked above) for IRIS's resolution to pick up. There are also other attacks (see https://pdfs.semanticscholar.org/6407/ebd0a24026e4dad84bc...) where even if one could obtain a die shot with perfect resolution, it would still be impossible to tell that the fab did, in fact, compromise the die (e.g., by replacing selected transistors with identically sized ones, but of the wrong doping polarity).
AFAICT, the value proposition of IRIS is to visually confirm that the number of cores, SRAM blocks, and other *major* sub-components of a die are more or less present and accounted for, and nothing much deeper beyond that...
Posted Mar 13, 2024 14:36 UTC (Wed)
by pizza (subscriber, #46)
[Link]
...And to make sure no other major/noticable chunks were added in the deadspace.
Realistically though, there's not a lot of deadspace in a typical chip -- the main reason for deadspace is if you're constrained by pincount/packaging requirements; you need a minimum amount of die area to support a given number of pins.
Part of your chip design includes a floorplan for major components, so you'll know where all your stuff is supposed to be, and that will closely correspond to what's "visible" on the die. Deadspace stands out quite clearly, so if something is there, it'll be _very_ obvious.
Posted Mar 11, 2024 9:40 UTC (Mon)
by NAR (subscriber, #1313)
[Link]
Posted Mar 10, 2024 23:05 UTC (Sun)
by NYKevin (subscriber, #129325)
[Link] (5 responses)
I'm sure there are *some* cases where you have real answers to those questions, but I have to suspect that, for the vast majority of real use cases, microscopy and reverse engineering are overkill.
Posted Mar 11, 2024 7:20 UTC (Mon)
by fwiesweg (guest, #116364)
[Link] (2 responses)
For now it looks like overkill, but if the technology is sufficiently cheap and simple ("commodified"), it will be possible to integrate it into supply chains without huge additional costs, increasing trustworthiness all over the place. There might be other applications (defect detection maybe) which we're not even thinking of right now. So there's at least a chance it makes the world better.
On top, even if that does not work out, Andrew gets to have a whole lot of fun, so why not give him a chance and see? People have gotten more funding for much worse proposals, this one is genuinely interesting.
Posted Mar 11, 2024 8:39 UTC (Mon)
by kleptog (subscriber, #1183)
[Link] (1 responses)
Sure, it costs a lot of money to fabricate a chip, but not that much. Requiring the resulting chips to look the same to as an existing block design makes it an order of magnitude harder.
Posted Mar 11, 2024 8:45 UTC (Mon)
by spacefrogg (subscriber, #119608)
[Link]
Posted Mar 11, 2024 10:38 UTC (Mon)
by atnot (subscriber, #124910)
[Link]
This isn't anything like the kind of sophisticated malicious supply chain attack people are hypothesizing about here. That would be ridiculously expensive and this really wouldn't do much about it. This is more about countering straightforward types of fraud which are pretty universal in the electronics industry.
There's a lot of hands a chip has to go through from fab, dicing, bonding, packaging, reeling, wholesalers and the final seller. Each of these steps is (sub-)contracted out to the lowest bidder. All of them run on very thin margins and have a huge incentive to "cut" their supply with some fakes. This isn't exactly difficult: Someone comes in after hours and loads the wrong file into the laser engraver and runs it for an hour. You grab a handfull of cheap chips from one of your production lines and toss them into a more expensive one. You bribe someone at a factory into giving you cheap chips with the wrong label and mix them into your distribution. You buy some salvaged/desoldered used chips and give them some new markings.
If they're sly, they'll pick some similar chips, or maybe different grades/bins of the same chip. But often times they don't even bother with that and just use completely unrelated or non-functional chips. If they keep the amount of fakes below, say, 1%, all you'll notice is a slight increase in boards failing QC, which you'll probably blame on something else.
This isn't just an issue with buying sketchy stuff off of aliexpress. The percentage there will be higher, but you're almost guaranteed to get some amount of fakes even from the most reputable sellers.
Posted Mar 12, 2024 2:48 UTC (Tue)
by himi (subscriber, #340)
[Link]
That detailed information would allow those "hobbyist" level hardware hackers to know more about the low-level implementation of those components, learn more about chip design, make cool pictures, have fun, etc . . .
In the hands of a sufficiently motivated and skilled hardware hacker, these scanning techniques *may* allow for independent verification/validation of actual hardware against specs, within certain constraints - limited imaging resolution, limited information about the components, etc. Over time, relatively widespread use of this technique could build up a library of "well known" components, which could then give "hobbyist" level hardware hackers something to compare against the chips they've just received in the mail - a small but not insignificant improvement in supply chain reliability, particularly if it becomes common enough that manufacturing and shipping counterfeit or malicious components becomes noticeably more risky. Though on its own IRIS wouldn't be enough to protect against explicitly malicious components, it would at least raise the bar enough that those malicious components would have to be actively hiding rather than simply relying on obscurity.
And finally, in cases where the design of the chip is open (or where the designer is sufficiently open), it *might* make it possible to use current manufacturers and supply chains to build truly independently verifiable components, which could then be used to build a trust root which was genuinely under the control of the user, rather than any current "trusted platforms" which rely ultimately on trusting a vendor. That would (assuming it works at all, let alone works in a practical end-user verifiable way) require the chips to be designed and shipped with the capacity to self-test such that any "trojan" elements would need to be implemented in a way that would be detectable using IRIS - so that the combination of self-testing against the design and physical inspection via IRIS would independently validate the actual hardware that you're running. Again, assuming it works the way that Huang (and others) are hoping.
But all of that is independent of any particular threat model - it's a toolset that can be *applied to* addressing threat models. The most basic use case (the hobbyist modifying a cheap digital camera and looking at chips illuminated by an IR LED) could be usefully applied to basic supply chain assurance, since it could probably detect counterfeit parts easily and fairly reliably; the most specialised use case might be applicable in the case of a completely untrusted supply chain, one where you could send your design to a fab and get parts back, but couldn't trust anything at all - you'd then need to validate the hardware from the ground up, but that would be /possible/ with this technique available; a wide range of other use cases surely exist in between those extremes.
Huang: IRIS (Infra-Red, in situ) Project Updates
Huang: IRIS (Infra-Red, in situ) Project Updates
Wol
Huang: IRIS (Infra-Red, in situ) Project Updates
Huang: IRIS (Infra-Red, in situ) Project Updates
Huang: IRIS (Infra-Red, in situ) Project Updates
Huang: IRIS (Infra-Red, in situ) Project Updates
Huang: IRIS (Infra-Red, in situ) Project Updates
Huang: IRIS (Infra-Red, in situ) Project Updates
Huang: IRIS (Infra-Red, in situ) Project Updates
Huang: IRIS (Infra-Red, in situ) Project Updates
Huang: IRIS (Infra-Red, in situ) Project Updates
Huang: IRIS (Infra-Red, in situ) Project Updates
Huang: IRIS (Infra-Red, in situ) Project Updates
[2] We were able to experiment with some design changes by modifying existing silicon instead of waiting ~3 months to find out if our theories of the failure were correct.
Huang: IRIS (Infra-Red, in situ) Project Updates
Huang: IRIS (Infra-Red, in situ) Project Updates
Huang: IRIS (Infra-Red, in situ) Project Updates
Huang: IRIS (Infra-Red, in situ) Project Updates
Huang: IRIS (Infra-Red, in situ) Project Updates
Huang: IRIS (Infra-Red, in situ) Project Updates
Huang: IRIS (Infra-Red, in situ) Project Updates
Huang: IRIS (Infra-Red, in situ) Project Updates
Huang: IRIS (Infra-Red, in situ) Project Updates
Huang: IRIS (Infra-Red, in situ) Project Updates
Huang: IRIS (Infra-Red, in situ) Project Updates