|
|
Subscribe / Log in / New account

Huang: IRIS (Infra-Red, in situ) Project Updates

Huang: IRIS (Infra-Red, in situ) Project Updates

Posted Mar 12, 2024 14:01 UTC (Tue) by farnz (subscriber, #17727)
In reply to: Huang: IRIS (Infra-Red, in situ) Project Updates by pizza
Parent article: Huang: IRIS (Infra-Red, in situ) Project Updates

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".


to post comments

Huang: IRIS (Infra-Red, in situ) Project Updates

Posted Mar 12, 2024 15:34 UTC (Tue) by paulj (subscriber, #341) [Link]

Great, succinct, summary of the use-case and threat-model. Thanks.

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.

Huang: IRIS (Infra-Red, in situ) Project Updates

Posted Mar 12, 2024 15:37 UTC (Tue) by somlo (subscriber, #92421) [Link] (1 responses)

> Importantly, Huang's hypothesis that drives IRIS forwards is [...] "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".

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...

Huang: IRIS (Infra-Red, in situ) Project Updates

Posted Mar 13, 2024 14:36 UTC (Wed) by pizza (subscriber, #46) [Link]

> 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...

...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.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds