Bad actors aren’t just reverse-engineering software; they’re tearing into the silicon itself. From peeling ASICs/SoCs like onions to extracting FPGA bitstreams, the hardware battlefield is heating up. Happily, some brain-bogglingly clever hardware obfuscation techniques can be deployed to flip the script.
As you may recall, I recently penned a column titled From Code Chaos to Cyber Confidence: Inside the World of Firmware Obfuscation. This was based on a chat I had with Dr. Nils Albartus, who is the Embedded Security Specialist and Technical Solutions Director at Emproof.
We started that column by reminding ourselves that the term “obfuscation” is typically taken to mean “deliberately making source code hard to read or understand while keeping it functionally correct.”
As a point of interest, “obfuscation” comes from the Latin ob-, meaning “over,” “against,” or “toward,” and fuscāre, meaning “to darken” (from fuscus, meaning “dark” or “dusky”). So “obfuscate” literally means “to darken over” or “to make dark.” In English, this word has been used since the 1500s to mean “to make something obscure, unclear, or difficult to understand.” This was first used metaphorically (like “darkening understanding”), and later in technical fields (e.g., code obfuscation).
Ironically, “obfuscation” is a word I can never seem to pronounce. Actually, that’s not strictly true: I can pronounce it, but not correctly. However, we digress…
The point of that column was to bring us all up to date on Emproof’s flagship product, Emproof Nyx. This is a binary-level security solution aimed at embedded systems (firmware, microcontrollers, RTOS, etc.). It works after compilation, directly on binaries or libraries, so you don’t need to modify your source code or redesign your hardware.
I’m a hardware design engineer by trade. I keep on hearing about bad actors reverse-engineering silicon chips, so I casually said to Nils, “It’s a pity hardware designers can’t obfuscate their hardware in the same way software developers can obfuscate their software” (where “software” in this context refers to both source code and machine code, as described in the aforementioned column). “But they can,” replied Nils, which is how we come to find ourselves here.
All that follows is based on a follow-up chat I had with Dr. Nils and Prof. Christof Paar, who is Director of the Max Planck Institute for Security and Privacy (Dr. Nils was a former PhD student of Christof). Nils and Christof asked me to point out that the following hardware-related discussions are based on research conducted at the Max Planck Institute and are unrelated to Emproof’s software solutions.
I must admit that I’d initially been thinking about hardware obfuscation applied at the source code level to a design’s Verilog or VHDL. Nils and Christof quickly disillusioned me, pointing out that introducing obfuscation at the RTL level doesn’t make sense, since the RTL will be passed through logic synthesis and place-and-route (P&R), and we really don’t know what the synthesizer and P&R tools will do to it. For example, the synthesizer could optimize away the obfuscation or significantly weaken it.
That was all I had. Bummer!
But wait, there’s more! It turns out that there are obfuscation techniques that can be applied at the netlist (gate and register) and/or transistor levels that will give bad actors a very “bad hair” day indeed (which will be one way we will be able to recognize them as they stagger down the street).
Let’s start by considering how bad actors can perform hardware reverse engineering (HWRE) in the first place. A high-level view of this is presented in the image below. This came from an HWRE lecture our heroes gave at Ruhr University. 
Extracting and analyzing netlists (Source: Dr. Nils and Prof. Christof)
The primary goal of the nefarious nobodies is to obtain the netlist that forms the design. Once they have this netlist in their sweaty hands, they can analyze it to determine the design’s function and how it performs its magic. So, we have two tasks: first, to prevent them from gaining access to the netlist; second, to make it as hard as possible to extract useful information from it if they do.
Let’s start with the process of accessing the netlist. Further, let’s commence with FPGAs, which we might consider to be the simpler—and therefore easier-to-crack—case. Most modern FPGAs are SRAM-based, meaning they lose their configuration when power is removed. As a result, their bitstreams must be stored externally, typically in a separate flash memory device. Unfortunately, this creates ajuicy attack vector for any malcontent with the inclination, opportunity, and a half-decent set of tools.
Although FPGA bitstream formats are proprietary, several community-driven bitstream databases exist (e.g., Project X-Ray and Project Icestorm), thereby enabling conversion from a bitstream to a netlist.
The best defense here is to always use the FPGA vendor’s bitstream encryption tools, which encrypt the bitstream before storing it in external flash, and have the FPGA decrypt it on-the-fly as it’s loaded into the device.
Another interesting FPGA-related technique called LifeLine CrossTalk Obfuscation is implemented at the routing level. The idea here is to exploit the adjacency of long interconnect wires (without an explicit netlist connection) to create crosstalk-based covert channels. That way, even if hackers do get access to the netlist, they won’t see these hidden connections. Now that I come to think about it, this technique might also be applicable to ASICs/SoCs.
Speaking of ASICs/SoCs, to extract the device’s netlist, the attacker starts with
decapsulation, followed by delayering, where the chip is decomposed layer-by-layer, starting with the metallization layers and vias, working down to the polysilicon layer where transistors and other components live. Each layer is imaged, and sophisticated image processing is used to stitch them together into a 3D model from which the netlist can be extracted.
This is, of course, very time-consuming and expensive to do, but it’s well within the capabilities of nation-states like China, North Korea, and Russia, which do it for nefarious purposes, and countries like France, Germany, Israel, and the USA, which do it for the purposes of truth and justice. For example, forensic labs in the USA routinely reverse-engineer foreign chips for supply-chain assurance, Trojan detection, and counter-proliferation purposes.
So, what can someone do with a netlist when they have it? For that, to tools like HAL, which purports to stand for “Hardware Analyzer,” but is actually named after the computer in the movie, 2001: A Space Odyssey.
HAL is a framework for conducting netlist reverse engineering. An analyst can load a netlist into HAL and explore it both visually and through plugins. The first step is to manage the sea of gates (anywhere from thousands to hundreds of millions) that modern devices contain.
The next step is to recover basic blocks, such as high-level registers, adders,
multipliers, and similar components, which helps to introduce an initial structure into the netlist. Once you have these intermediate building blocks, you can use (or develop) more advanced plugins to start recognizing and abstracting higher levels of functionality, such as “This collection of building blocks looks like a cryptographic engine, and this register is probably used to store the key.”
Armed with this knowledge, you can take another copy of the chip (since the first one is no longer with us), decapsulate it to expose the top metallization layer, and run the device while probing it with lasers. You can use these lasers to detect existing 0s and 1s while the chip is operating, or to inject your own 0s and 1s to trigger errors that may uncover security vulnerabilities.
So, what can we do to make life hard for the HWRE scoundrels? I’m glad you asked. One approach is to obfuscate any finite-state machines (FSMs) at the gate level after logic synthesis generates their netlists. You can do things like insert dummy states to “balloon” the state space, re-encode states unpredictably, add unreachable or misleading transitions, and scatter state storage across the design. Understanding how a chip is controlled reveals a lot of information, so obfuscating its FSMs is a good idea. So good, in fact, that Nils, Christof, and their colleagues have written a paper on FSM- Based Hardware Obfuscation.
Another technique leverages the fact that reverse-engineering tools like HAL rely heavily on structure. Registers are often the first thing reconstructed because they reveal key registers used in crypto, state variables, control paths, and dataflow boundaries. This means we wish to prevent a reverse engineer from identifying which flip-flops belong together to form high-level registers. Obfuscation techniques include altering the structure so adjacent flip-flops don’t “look like” they belong to the same register. This can be achieved by using different types of register elements, breaking typical patterns, reordering bits, scattering components, and inserting dummy flops.
And for those chips we really, really want to protect, we can go all the way to “gate camouflaging” (including transistor-level obfuscation). The basic technique here is to use standard cells with the same physical layout but different internal connections. In this case, a cell may look like a NAND, XOR, or AND when viewed from above, but you cannot tell which it is without knowing about any hidden connections in lower layers (you can actually buy buy standard cell libraries with camouflaged gates).
A more recent (and more advanced) method is epitomized by the University of University of Florida’s Covert Gates. These researchers designed gates with dummy inputs—that is, cells that appear to have an additional connection but in reality do not. This technique is particularly interesting because the modified gates are indistinguishable even with scanning electron microscopes at the dopant level, thereby making detection extremely difficult.
I don’t know about you, but my poor old noggin is now reeling with thoughts about this wealth of hardware obfuscation techniques that can be used to knee HWRE proponents in their metaphorical private parts (just the saying of which, of course, reminds me of Penny’s forthright way of dealing with problems as evidenced in this snippet from The Zarnecki Incursion episode of The Big Bang Theory).
But, once again, we digress. How about you? What do you think about all of this?
