[HN Gopher] X-ray tech that reveals chip designs
___________________________________________________________________
X-ray tech that reveals chip designs
Author : sohkamyung
Score : 55 points
Date : 2022-04-30 23:04 UTC (1 days ago)
(HTM) web link (spectrum.ieee.org)
(TXT) w3m dump (spectrum.ieee.org)
| deegles wrote:
| Could this be used to extract private keys from smartcards or
| secure enclaves? It seems this would be accurate enough to see if
| a fuse is blown on a chip.
| paulkrush wrote:
| "We began our examination by cutting out a 10-micrometer-wide
| cylinder from the G3260." "A high-resolution (19-nm) scan..." I
| am dumbfounded by their resolution. I would love to take 3D x-ray
| scans at 10-micrometer resolution!
| LeonTheremin wrote:
| Silicon Trojans must perish.
| genmud wrote:
| One of the issues with this type of thing is that each fab has
| slightly different ways of taking the HDL and converting to their
| process. These come in the form of a PDK and each fab and process
| will have their own development kits.
|
| The threat they are trying to deal with is a fab modifying the
| silicon and introducing additional logic during production. The
| issue that I see is the most likely place that behavior would be
| inserted is inside the PDK, so even if you can compare what it
| should output vs what's produced, it would match.
|
| The other issue is even if you compare something that generates
| the exact same transistors... if you produce at Fab A and Fab B,
| the silicon is going to be different.
| CodeArtisan wrote:
| Here an example of a hardware "trojan" for Intel Ivy Bridge; The
| hardware RNG is broken only by modifying its circuitry doping.
|
| https://sharps.org/wp-content/uploads/BECKER-CHES.pdf
|
| https://en.wikipedia.org/wiki/Doping_(semiconductor)
|
| _In this paper we introduced a new type of sub-transistor level
| hardware Trojan that only requires modification of the dopant
| masks. No additional transistors or gates are added and no other
| layout mask needs to be modified. Since only changes to the
| metal, polysilicion or active area can be reliably detected with
| optical inspection, our dopant Trojans are immune to optical
| inspection, one of the most important Trojan detection mechanism.
| Also, without the ability to use optical inspection to
| distinguish Trojan-free from Trojan designs, it is very difficult
| to find a chip that can serve as a golden chip, which is needed
| by most post-manufacturing Trojan detection mechanisms. To
| demonstrate the feasibility of these Trojans in a real world
| scenario and to show that they can also defeat functional
| testing, we presented two case studies. The first case study
| targeted a design based on Intel's secure RNG design. The Trojan
| enabled the owner of the Trojan to break any key generated by
| this RNG. Nevertheless, the Trojan passes the functional testing
| procedure recommended by Intel for its RNG design as well as the
| NIST random number test suite. This shows that the dopant Trojan
| can be used to compromise the security of a meaningful real-world
| target while avoiding detection by functional testing as well as
| Trojan detection mechanisms._
| teddyh wrote:
| Called it: https://news.ycombinator.com/item?id=13952016#13952697
| elihu wrote:
| I wonder what hobbyists and historians may find in future decades
| in our old chips. Clever techniques that were invented much
| earlier that anyone suspected. Weird Easter eggs. Security flaws
| and backdoors. Features that were implemented but never enabled.
| Whole designs that were stolen from one company and used by a
| competitor.
| judge2020 wrote:
| Would this potentially enable pulling secrets (eg. HSM/disk
| encryption keys) from chips? My understanding is that the
| integrated security processor on something like an AMD or Apple
| chip is permanent and stored directly on-chip, with the only
| thing preventing extraction of its secrets being the complexity
| in the traces that govern performing the cryptographic
| operations. I know Amd and Apple have their top talent involved
| in designing the chips are are probably ahead of the curve on
| attacks like this, but at a certain point we might have to
| grapple with a certain world power being able to pull secrets
| from consumer and enterprise electronics.
| hansvm wrote:
| With physical access to a chip the only barrier to accessing
| that information is analysis time (and the absurd amount of
| equipment required to analyze things that small), at least
| assuming no significant quantum weirdness is mandatory to the
| chip's operation (i.e., that classical physics with perhaps
| some simple quantum approximations suffice to roughly describe
| the system). If the chip is capable of performing cryptographic
| operations using certain keys, at a minimum you can produce a
| nand-level algorithm capable of performing those same
| cryptographic operations with those same keys. If the
| cryptographic operations in question are known to be of some
| common pattern (elliptic curves or what have you) then it's
| also trivial to, in the presence of that nand-level algorithm,
| deconstruct the secrets.
|
| That said, this tech doesn't look to be sufficient on its own.
| You probably need to analyze the contents of a chip, not just
| its structure. The linked article just describes an improvement
| in learning some kinds of physical structure.
| tgflynn wrote:
| > With physical access to a chip the only barrier to
| accessing that information is analysis time
|
| > That said, this tech doesn't look to be sufficient on its
| own. You probably need to analyze the contents of a chip, not
| just its structure.
|
| Those two statements appear to be contradictory. Could you
| clarify what you mean by them and in particular what you mean
| by the "contents" of a chip ?
|
| I know that low voltage SEM used to be capable of seeing
| voltage differences in chips but I have no idea if that's
| still feasible with the scale of today's technology
| (resolution tends to be worse at lower beam voltages) and the
| physical basis for flash memory.
| Kirby64 wrote:
| HSM or disk encryption keys (e.g., the encryption keys in Apple
| silicon) should be stored in a space that is intended to be
| impervious from analysis techniques (SEM, X-ray, etc) and any
| deprocessing technique (acid removal, FIB, etc) will destroy
| the contents. It's built differently from traditional
| techniques. I suspect this fancy X-ray would not work either.
| gjvnq wrote:
| Atomic scientists: what if I dissasamble it one atom at a
| time? :)
| RantyDave wrote:
| AFAIK these secrets are written to the chip during manufacture
| in much the same way as you might write to flash. They are not
| described by the physical structure of the chip at all.
|
| Whether or not you can use X-ray or other probing techniques to
| find the current state of a cell of flash memory is a different
| question.
| zerohp wrote:
| Efuses are more common and they change the physical structure
| when written, much like blowing a fuse in your car.
|
| Laser blown fuses are also common.
| go_prodev wrote:
| A blown fuse should be detectable with this method.
| px43 wrote:
| > No trade secret or hardware trojan can hide from ptychographic
| X-ray laminography
|
| That is, of course, assuming you fully trust the software running
| on the x-ray scanners :-)
|
| Really exciting to see these tools come into existence though.
| Just the fact that they exist can be an excellent deterrent
| against any sort of malicious hardware tampering at scale.
| Hopefully the tech eventually gets democratized enough that civil
| rights groups can do random audits on consumer devices at regular
| intervals.
| car_analogy wrote:
| > trade secret
|
| It's not a trade secret once you give it away to millions of
| customers. Though I'm sure that, as we speak, they're lobbying
| to make it illegal to use information you'd get from all but
| the most surface-level, unaided inspection of a product. It'll
| probably come in one of those "free trade" agreements.
___________________________________________________________________
(page generated 2022-05-02 23:01 UTC)