-
Notifications
You must be signed in to change notification settings - Fork 6
ASIC hardening
Foundries impose legal and practical limits on the depth of inspection allowed on chip designs. Even designs submitted as fabricated mask patterns can be tampered with during the mask fracture and manufacture process; and due to fragility and contamination concerns, it's not possible to extract the masks from a foundry for third-party audit. And, even if a mask could be inspected for third-party audit, nothing guarantees the inspected mask is the one actually used at fab time. In other words, inspection of mask designs is one huge Time of Check/Time of Use (TOCTOU) problem, with turtles all the way down.
The fundamental problem is that in hardware, it's not possible to "hash the entire binary and check it against a signature", as it is for code. Comprehensive examination of a chip's construction is a destructive process. Furthermore, most modern processes require metal tile fills that fully obscure lower layers of the chip. Besides this, the pitch of metal wires in, for example, a 40nm process is on the order of 150nm, which is several factors smaller than what can be optically imaged. Note that SEM imaging can only image the surface of a chip, it cannot penetrate into the inner layers of a chip (most SEM images are either cross-sections or the chip has been delayered or the insulating dielectric has been etched out). While it is possible to fully understand the construction of a chip, the process is typically destructive and not suitable for confirming that a given chip is actually the chip that you're claimed to have. Therefore, the TOCTOU problem: one can sample chips from a lot and confirm their construction, but this is not the same as checking the exact same chip you plan to use for keeping your secrets.
That being said, during the design process, every reasonable effort should be made to recover the design data that is in line with industry standards for inspection. ASIC designers may typically expect the following items for inspection and validation:
- Chip flooplan with precise boundaries on the size of various IP blocks
- "Amoeba plot" floorplan with precise locations of various standard cells within compiled RTL regions
- Upper-level metal routing, as this should be necessary for timing extraction and verification
Note it is possible (even likely) that even these high-level items are sharable only with the chip designer, and it may be a violation of a fab NDA to share them more broadly/openly.
Finally, if the chip is being taped out with a full reticle (that is, with no other designs sharing the same mask), it may be possible to order "wafer stops", that is, wafers processed to various layers and stopped during processing. These wafer stops can then be diced up and handed to various organizations for inspection to confirm that at least the initial mask pattern conforms to the specified logic design. However, wafer stops are most likely not possible with (multi-project wafers) MPWs, because providing the raw wafers would essentially disclose other customer's designs.
This is not to argue against open hardware as being valuable from a security perspective. However, it's important to set expectations as to what is achievable through hardware design inspection:
- Confirmation of design correctness. Design inspection can check for problems such as address aliasing, as well as inadvertent and malicious back doors. However, in the case of mitigating address aliasing, the RTL must be carefully crafted to defeat optimizing silicon compilers. It is a reasonable space optimization to remove logic that decodes bits of an address space that seem to never be used. As a result, explicit circuitry must be specified for all invalid addresses to avoid optimizations from loosening otherwise strict address decoding logic.
- Disclosure of microarchitectural state for side channel analysis. Spectre-class vulnerabilities rely upon hidden microarchitectural state to create sidechannels for exfiltration of data. Although one option is to simply turn off all time and space optimizations (such as caching and branch prediction), this may lead to unacceptable performance. Unfortunately, it is difficult to prove the efficacy of Spectre mitigations because microarchitectural state in closed source computers is a black box, and security researchers must spend considerable effort reverse engineering the microarchitecture of a CPU in order to validate their mitigations. Open RTL for a microarchitecture creates a unique opportunity for Spectre mitigations, as the exact side channel mechanisms within the microarchitecture can now be analyzed and mitigated.
The best options available for non-destructively confirming a chip's function is thus:
- Gross morphological examination of the metal tile patterns to imply silicon structures.
- Optical fault induction, to create upset events that should map to specific clusters of transistors.
- Monitoring passive optical emissions of transistors to map out the fabricated locations of devices.
All of these require some specialized equipment, but it's conceivable that open-source labs (or hacker spaces even) could acquire the necessary equipment so that a given device can be inspected to the extent that it can be.
The layout of the chip itself should be conducted in a manner that simplifies and aids the examination process. Of course, this is at odds with security; in particular aiding the monitoring of passive optical emissions can assist with the extraction of secret material from the device. Thus it's preferred to rely on techniques that put hard upper bounds on the size of large regions of the chip, and layout/design techniques that cluster key transistors in known areas such that faults may be induced to map their location but without revealing any secrets.
Inspection methods enable placing an upper bound on the complexity of an exploit buried in silicon. For example, an exploit injected through recompiling an RTL netlist may lead to significantly different morphology in the data pathways, which may be detectable, given the size of the exploit, with gross morphological examinations. These upper bounds can be leveraged to harden an RTL design against tampering.
Thus, the basic idea behind RTL hardening is to increase the complexity of a backdoor in the silicon to the point where trivial modifications cannot induce a reliable exploit. Here are examples of trivial modifications that are currently hard to detect:
- Permanently inverting the output of a flip-flop can be accomplished with as little as a single via change
- Permanently selecting a multiplexer path can be accomplished with as little as a single via change
- Adding in a few additional gates can usually be done with only edits on metal layers 1-3, given the standard practice of including spare gates on the silicon layer
- An alternate row of SRAM or ROM may be hard to detect, especially if the memory IP block already contains redundant rows that can be fused out for yield reasons. The detection problem is not helped by the common practice of adding dummy devices on the periphery of dense, regular blocks to equalize e.g. etch and metal polishing factors.
Thus the footprint of an exploit that can map in an alternate row of RAM at an attacker's chosen time is actually quite small given the malleability and redundancy of unhardened RTL.
Ideally, RTL hardening makes it infeasible for just a few gates inside a hard IP block to reliably change the function of that block, and also makes it more difficult for an attacker to simply rewire a few gates to change a key security property of the device.
Some ideas for RTL hardening techniques include:
- Randomizing the address space of hard IP blocks (like RAM, eFuses). The "key" for the randomization is a secret provided by the user at boot-time, via a simple serial interface, and the randomization can be as simple as permutations and XORs of various address and data bits. The complexity of the obfuscation only needs to be great enough such that any de-obfuscation circuitry introduced would force a gross morphological change to the size of the hard IP block, that it may be detectable with an optical microscope.
- Adding parity functions to internal busses and key control flow signals, so that single-wire mods are no longer effective. This also aids in optical fault resistance and detection, which can assist with mapping out which transistors are where without revealing secrets.
- For hardening eFuse blocks against SEM readout, add a large amount (1kbits) of entropy to the efuse block, and hash that with the stored values. The entropy should be randomly selected from the set of stored bits. The theory is that it may be easy to read a few efuses, but trying to read out a thousand bits is error-prone. So, construct the hardware such that a small bit error rate in readout leads to a difficult brute forcing problem (the random selection of which bits are entropy and which bits are data is important to making the readout problem non-trivial).