The relationship between complexity and security seen in software also holds for Integrated Circuits (ICs). Since the inception of the IC, transistor sizes have continued to shrink. For example, compare the 10 feature size of the original Intel 4004 processor (intel_processor_history) to the 10 feature size of Intel’s recently announced Ice Lake processor family (ice_lake_by_june)
. Smaller transistors enable IC designers to create increasingly complex circuits with higher performance and lower power-usage. However, continuing this trend pushes the laws of physics and comes at a substantial cost: by 2020, the cost to build a leading-edge fabrication facility is estimated to be $15–20B(cost_of_fab_2020).
Such costs are prohibitive for not only most semiconductor companies, but also nation states. Thus, most hardware design houses are fabless, i.e., while they are able to fully design and lay out an IC, they must outsource its fabrication. Outsourcing combined with the black-box nature of a fabricated IC requires fabless semiconductor companies to trust that their physical designs will not be altered maliciously by the foundry, also known as a fabrication-time attack. Previous work demonstrates several ways a fabrication-time attacker can insert a hardware Trojan into an otherwise trusted IC (becker2013stealthy; kumar2014parametric; a2). A2 (a2) demonstrates the most stealthy and controllable IC fabrication-time attack to date, whereby a hardware Trojan with a complex, yet stealthy, analog trigger circuit is inserted into the finalized layout of a processor. Even though the inserted Trojan is small, the attacker can trigger it and escalate to a persistent software-level attack (i.e., a hardware foothold (king08)) using only user-mode code.
Early work focuses on post-fabrication detection of hardware Trojans in ICs (tehranipoor2010survey). Broadly, there are two classes of detection: 1) side-channel analysis and 2) Trojan-activation via functional testing. Side-channel (power, timing, etc.) analysis (agrawal2007trojan; jin2008hardware; potkonjak2009hardware; narasimhan2011tesr) assumes that the Trojan’s trigger is complex (i.e., many logic gates); thus, noticeably changes the physical characteristics of the chip. For example, inserting the large amount of extra logic required by a complex trigger into a design alters the power signature of the device. Alternatively, Trojan-activation via functional testing assumes that the Trojan’s trigger is simple (i.e., few logic gates (becker2013stealthy; kumar2014parametric)
); thus, easily activated by test vectors. Unfortunately, layering detection classes isnot sufficient as recent work shows that it is possible to create an attack that is both small and stealthy (a2).
To address the gaps left by post-fabrication Trojan detection schemes, recent work focuses on pre-fabrication, IC layout-level, Trojan prevention (ba2016hardware; ba2015hardware; cocchi2014circuit; xiao2013bisa). IC layout-level defenses work by:
increasing placement & routing resource utilization
increasing congestion around security-critical design components
The lack of resources deprives the attacker of the required transistors needed to implement their Trojan trigger/attack circuits, and the increased congestion around security-critical wires acts as a barrier for the attacker attempting to integrate their Trojan into the victim design. Ideally, defenders utilize just enough resources and create enough congestion such that the attacker cannot implement and insert their attack, while keeping the design routable. Short of that, the added barriers require the attacker to expend more resources (e.g., time) to insert their attack into an IC layout.111Time is the most critical resource for the attacker as IC fabrication is bounded in terms of turnaround time.
Two IC layout-level defensive approaches exist: 1) undirected and 2) directed. Undirected approaches aim to (probabilistically) increase resource utilization and congestion across the entire layout by altering existing place-and-route parameters (e.g., core density (xiao2013bisa)) that will likely result in increased resource utilization and congestion. More recently, a line of directed approaches have emerged (ba2015hardware; ba2016hardware) that systematically increase utilization of specific-regions of the device layer, i.e., nearby security-critical components. Given that it is infeasible to occupy the entire device layer in a tamper-evident manner (ba2016hardware) both classes of approaches may leave IC layouts vulnerable to attack by an untrusted foundry.
To identify gaps in existing defenses and guide future IC layout-level defenses, we design and implement an extensible measurement framework that quantifies defensive coverage with respect to specific foundry-level attacks. Our framework, IC Attack Surface (ICAS), quantifies defensive coverage in three dimensions that capture the essence and difficulty of inserting a hardware Trojan at an untrusted foundry:
Trojan logic placement: finding unused space to place additional circuit components
Victim/Trojan integration: attaching hardware Trojan payload to security-critical logic
Intra-Trojan routing: connecting the trigger and payload portions of the hardware Trojan
A successful attack requires all three steps.
Using ICAS, we analyze over 60 different IC layouts across three fully-functional ASIC designs: an AES accelerator, a DSP accelerator, and an OR1200 processor. For each layout, ICAS reports the coverage against four attacks (a2; hicks10; king08; trusthub) that span the digital and analog domain as well a range of attack outcomes. ICAS’s analysis reveals that all existing IC layout-level defenses are incomplete, leaving 1000’s of opportunities for an attacker at an untrusted foundry to insert a hardware Trojan. An additional finding is that even though most existing countermeasures do increase the complexity of inserting a hardware Trojan, some countermeasures are ineffective. Lastly, ICAS’s analysis suggests that focusing on exhausting resources on the device layer (i.e., transistors) is an incomplete defense; future defenses should also aim to increase congestion around security-critical wires.
This paper makes the following contributions:
We propose an extensible methodology that quantifies the difficulty of inserting hardware Trojans into an existing IC layout by an untrusted foundry.
We design, implement, and open-source (anon) our extensible framework, ICAS, that computes various layout-specific security metrics. The ICAS framework provides an interface to programmatically query the physical layout of an IC (encoded in the GDSII format) to compute various security metrics with respect to attacks-of-interest.
We use ICAS to quantify the effectiveness and expose the defensive gaps of previously-proposed untrusted foundry defenses by analyzing over 60 IC layouts of three real-world hardware cores.
We identify future directions for defenses that work in a layered fashion with existing defenses.
2.1. IC Design Process
Figure 1 shows the typical IC design process (rostami2013hardware), which consists of three main phases: 1) front-end design, 2) back-end design, and 3) fabrication. The front-end design phase can be further split into two design abstraction levels, behavioral and structural, while a single design abstraction level, physical (i.e., consists of both analog and digital properties), encompasses the back-end. The front-end design process begins by first describing the functionality of the circuit at the behavioral level, also known as the Register Transfer Level (RTL), using a hardware description language (HDL), like VHDL or Verilog. Next, the behavioral level description of the circuit is transformed into a structural level description during RTL synthesis. RTL synthesis is similar to software compilation: the RTL design is optimized and reduced to a set of logically connected digital logic gates, called a gate-level netlist (netlists are commonly described using an HDL language). The gate-level netlist is then passed to the back-end design phase to be transformed into something able to be implemented into a physical chip (i.e., an IC layout) through a process known as Placement and Routing (PaR).
IC layouts consist of multiple layers. The bottom layers are device layers, while the top layers are metal layers. Device layers are used for constructing circuit components (e.g., transistors), and the metal layers are used for routing (e.g., vias and wiring). The first stage of PaR is creating a floorplan. Figure 2
illustrates an IC floorplan. To create a floorplan, the dimensions of the overall chip are specified and the core area is defined. Typically a ring of I/O pads is then placed around the chip core, while a placement grid is drawn over the core. Each tile in the placement grid is known as aplacement site. Circuit components (e.g., standard cells) are then placed on the placement grid, occupying one or more placement sites, depending on the size of the component. Lastly, all components are routed together, using one or more routing layers. The output from the back-end design is a Graphics Database System II (GDSII) file that is a geometric description of the placed-and-routed circuit layout. The GDSII file is then sent to a fabrication facility where it is manufactured. The final step is testing and packaging.
2.2. Hardware Trojans
2.2.1. Trojan Components
A hardware Trojan is a malicious modification to a circuit designed to modify its behavior during operation (beaumont2011hardware). Hardware Trojans have two main components: 1) trigger and 2) payload (chakraborty2009hardware; jin2008hardware; wolff2008towards)
. Prior work classifies hardware Trojans based on the functionalities of their trigger and payload mechanisms(chakraborty2009hardware; jin2008hardware; wolff2008towards). In this paper, we adopt and simplify an existing hardware Trojan taxonomy (chakraborty2009hardware); shown in Figure 3.
The trigger mechanism of a hardware Trojan is what initiates the delivery of the Trojan’s payload. Triggers can be built by adding, removing, or altering existing hardware in an IC. They can be digital (king08) or analog (a2). The ideal trigger is small: requiring few or no additional circuit components, stealthy: requiring dozens of rare events to activate, and controllable: readily attacker deployable, but not so by defenders or through regular use. There have been several triggers demonstrated before that span the trade-space of large (requiring many additional gates) and stealthy (lin2009trojan) to the opposite: small (requiring no additional gates) and easy to trigger (shiyanovskii2010process; becker2013stealthy). The most advanced Trojans are small, stealthy, and controllable (a2).
The payload mechanism receives a signal from the trigger and alters the functionality of the IC. Analog (shiyanovskii2010process; becker2013stealthy) and digital (a2) payloads exist, with a variety of effects. These effects can leak information (lin2009trojan), alter the internal state of the IC (a2), or cause a system to be unusable (denial-of-service) (shiyanovskii2010process). Regardless of effect, the payload mechanism must route a wire to, or in the vicinity of, some target “security-critical” (specs15) wire in the IC design.
2.2.2. Trojan Implementations
There are three ways a malicious foundry can ”insert” a hardware Trojan into an otherwise trusted IC layout: additive, substitution, and subtractive. Additive Trojans involve inserting additional circuit components and/or wiring into an existing design. Substitution Trojans require removing logic with low observability to make room for additional Trojan circuit components and/or wiring in an existing circuit design. Lastly, subtractive Trojans require removing circuit components and/or wiring to alter the behavior of a existing circuit design. The focus of this paper is assessing defensive coverage with respect to additive Trojans. Substitution and subtractive Trojans, while intriguing, remain largely unexplored by the community. We do not know of any demonstrably stealthy and controllable substitution or subtractive Trojans and when researchers do create such an attack, there exists orthogonal mitigation strategies (wang2008detecting).222Dopant-level Trojans are the closest substitution Trojan designs demonstrated in the literature (becker2013stealthy; kumar2014parametric). Though their non-existent footprints make them difficult to detect via side channels, their simplistic designs and limited controllability make them detectable during post-fabrication testing (sugawara2014reversing).
Inserting an additive Trojan at an untrusted foundry requires modifying two fundamental characteristics of an IC’s physical layout—placement and routing—regardless of how a an attacker implements the Trojan’s trigger and payload. We define Trojan placement to be the act of placing additional hardware components into an IC layout for the purpose of crafting a Trojan trigger and payload, Victim/Trojan integration to be wiring the Trojan’s payload to, or in the vicinity, of a security-critical net in the victim IC layout, and intra-Trojan routing to be the act of wiring the hardware Trojan together. The most challenging aspect of inserting a hardware Trojan at fabrication-time is finding empty space on the IC’s device layer to insert the trigger and payload components (Trojan placement), AND routing the payload to a security-critical net (Victim/Trojan integration). ICAS quantifies each of these fundamental tasks, in turn identifying weak points in the IC layout that an attacker might exploit.
3. Threat Model
We adopt a threat model for untrusted foundry attacks that assumes all steps in the IC design process can be trusted, except for all of the processes—no matter if they are outsourced—performed by a foundry (colloquially, fabrication). Figure 1 depicts our threat model. This entails that the RTL is designed, synthesized, and laid-out by trusted parties. Post fabrication testing is also performed by a trusted party. We adopt this threat model since the astronomical costs to fabricate ICs force most semiconductor companies to outsource fabrication. To this point, in 2005, the U.S. government identified the untrusted foundry threat as the most significant weakness of the microelectronics supply chain (force2005high).
We restrict our threat model to fabrication-time attacks involving additive Trojans, i.e., hardware Trojans that require inserting additional circuitry to a physical IC design. Previous work on substitution/subtractive hardware Trojans shows that such Trojan insertion methods are addressable by measuring the controllability and observability of logic at the behavioral and/or structural level of the IC design, for which several methods have already been proposed (salmani2017cotd; zhang2015veritrust; ccakir2015hardware; salmani2013analyzing; waksman2013fanci; hicks10; goldstein1980scoap). Orthogonally, this work fills the void of quantifying the susceptibility of an IC design to additive hardware Trojan insertion at the physical level of the IC design process by an untrusted foundry.
Focusing on additive hardware Trojans, an adversary can only insert additional components/wires. They cannot increase the size of the chip to make additional room for the implants because this is readily caught by defenders. As a result, an attacker has two choices: find open space in the design large enough to accommodate the additional circuitry, or create open space in the design by moving circuitry around. The latter is extremely challenging due to its recursive nature, it runs the risk of violating fragile timing constraints and manufacturing design rules, and it increases fabrication turnaround time (which is usually set to three months); any of which could expose the Trojan. Therefore, our focus is identifying open spaces suitable for hardware Trojan implementation.
4. Untrusted Foundry Defenses
To protect IC layouts against insertion of a hardware Trojan by attackers at an untrusted foundry, two classes of defenses exist: undirected and directed. Undirected defenses leverage existing tuning knobs available during the IC layout process, but do not differentiate between security-critical and general-purpose wires and logic. Thus, undirected approaches provide probabilistic protection. On the other hand, directed defenses require augmenting existing PaR tool flows to harden the resulting IC layout, focusing on deploying defenses systematically around security-critical wires and logic. Thus directed approaches provide targeted protection, but increase the complexity of the place-and-route process.
This section provides an overview of the landscape of undirected and directed defenses. The focus is the mechanism each defense uses to increase the complexity faced by a foundry-level attacker. We use the results of the defensive analysis in this section to develop a set of unifying coverage metrics in the next section. Finally, in the evaluation, we evaluate commercial IC layouts using the defense-inspired metrics to quantify each defense’s coverage.
The lowest cost approach for protecting an IC layout from a foundry-level attacker is to take advantage of existing physical layout parameters (e.g., core density, clock frequency, and max transition time) offered by commercial CAD tools (xiao2013bisa; innovus). The goal is to increase congestion across the component layer and the routing layer. Ideally, this also results in increased congestion around security-critical logic and wires. Practically, increases in congestion around security-critical logic and wires is probabilistic.
Increased congestion is a symptom of increased resource utilization; hence, there are fewer resources available to the attacker. The most obvious resource that an attacker cares about are placement sites on the component layer. Increasing the density, decreases unused placement sites. Without sufficient placement sites, the attacker cannot implement their Trojan logic. A less obvious resource is attachment points on security-critical wires that serve as victim/Trojan integration points.. Increasing routing layer congestion (via density and/or timing constraints) increases the blockage around security-critical wires, meaning there are less integration points.
To address the shortcoming of undirected approaches, recent defenses advocate focusing on security-critical logic and wires. Specifically, the approaches aim to prevent the attacker from being able to implement their hardware Trojan by occupying unused placement sites (i.e., transistors) (ba2015hardware; ba2016hardware). The challenge is that the filler cells used by these defenses must be tamper-evident, i.e., a defender must be able to detect if an attacker removed filler cells to implement their Trojan. Previous work shows that filling the entire component layer with tamper-evident filler cells (e.g. (xiao2013bisa)) is infeasible due to routing congestion (ba2015hardware). To make routing feasible, the most recent placement-centric defense focuses on filling the unused placement sites nearest security-critical logic first (ba2015hardware; ba2016hardware).
Such placement-centric defenses increase the complexity faced by the attacker in two ways. First, it is harder for the attacker to find contiguous unused placement sites to implement their Trojan’s logic. Second, an indirect complication is increased intra-Trojan routing complexity. The more distributed the attacker’s placement sites, the more long (i.e., uses upper routing layers) routes the attacker must create. Additionally, since the unused placement sites are far away from security critical logic, the attacker must make a longer, more complex, route to connect their hardware Trojan to the victim security-critical wire.
5. Unified Attack Metrics
Drawing from existing untrusted foundry defenses, we create a extensible set of IC layout attack metrics. We unify the objectives of existing defenses by decomposing the act of inserting a hardware Trojan into ICs at an untrusted foundry into three fundamental tasks and corresponding metrics:
Trojan logic placement: Trigger Space
Victim/Trojan integration: Net Blockage
Intra-Trojan routing: Route Distance
These tasks and accompanying metrics are the foundation for our methodology of assessing defensive coverage of an IC layout against an untrusted foundry. We implement our methodology as ICAS.
5.1. Challenges of Trojan Placement
The first phase of mounting a fabrication-time attack is Trojan placement. This requires locating unused placement sites on the placement grid to insert additional circuit components. While prior work (xiao2013bisa; ba2015hardware; ba2016hardware) employs the notion of limiting the quantity of unused placement sites as a defense against fabrication-time attacks, how can we characterize unused placement sites to gain insight into the feasibility of a fabrication-time attack on a given IC layout?
Only 60–70% of the placement cites are occupied in a typical IC layout to allow space for routing (a2). To facilitate Trojan routing, an attacker prefers open placement sites form contiguous (adjacent) regions. This allows the attacker to drop-in a pre-designed Trojan, or if one had not been pre-designed, it minimizes the intra-Trojan routing complexity by confining the intra-Trojan routing to the lowest routing layers, i.e., reducing the jumping and jogging of nets. Such adjacency is classified in image processing as “4-connected”. Therefore, a key factor that determines the difficulty of mounting fabrication-time attacks is the difficulty of inserting additional circuit components into a finalized IC design. We rank this difficulty in increasing order as follows.
Trivial: the Trojan components fit within a single contiguous group of 4-connected placement sites.
Difficult: the Trojan components must be split across multiple contiguous groups of 4-connected placement sites. The more groups of placement site groups, the more difficult intra-Trojan routing becomes.
Not Possible: the total area required by the hardware Trojan exceeds that of available placement sites.
Figure 4 illustrates these difficulty levels. The susceptibility of an IC design to fabrication-time attack can therefore be partially quantified by the size and number of contiguous open sites on the placement grid. This is the basis for ICAS’ Trigger Space metric.
5.2. Challenges of Victim/Trojan Integration
Routing the Trojan payload to the targeted security-critical net requires the attacker to locate the nets of interest in the IC layout. We assume the worst case: the attacker has knowledge of all security-critical nets in the design, particularly, the nets they are trying to extract information from or influence. An example of such a net in the OR1200 processor (or1200) is the net that holds the privilege bit. The attacker can acquire this knowledge either through a design-phase co-conspirator or through advanced reverse-engineering techniques (a2). No matter how the attacker gains this information, we assume they have it with zero additional effort.
We extend this threat to include nets that influence security-critical nets. To increase stealth, an attacker could also trace backwards from the targeted security-critical net, through logic gates, to identify nets that influence the value of the targeted security-critical net. This is called the fan-in of the targeted net. By connecting in this way, the attacker sacrifices controllability for stealth as their circuit modification is now physically separated from the security-critical net. To gain back controllability, attackers must create a more complex (hence larger) trigger circuit—decreasing the Trigger Space score, as well as increasing the likelihood of visual and/or side-channel detection. This tradeoff limits how many levels back the attacker can integrate their payload.
No matter if the attacker is attacking the targeted security-critical wire directly or indirectly, the attacker must attach to some victim wire or route directly adjacent to it. Since an IC layout is three-dimensional, it is possible for the attacker to attach to any open point on the victim wire, either on the same layer (i.e., North, South, East, West) or by coming in from an adjacent layer (i.e., above or below). In the worst case, there are no other nets blocking the attacker from attaching to the targeted security-critical net or its -level-deep influencers. In the best case, all attachment points are blocked by other nets. To quantify the number of points along, above, and below a targeted security-critical wire—and its -deep fan-in—we implement the Net Blockage metric. Figure 5 shows the open (unblocked) integration points for the privilege net on the OR1200 processor.
5.3. Challenges of Intra-Trojan Routing
The final phase of a fabrication-time attack is Intra-Trojan routing. Intra-Trojan routing requires connecting the components that comprise the trigger and payload portions of the hardware Trojan together—including connecting to the integration point with the victim—to form a complete hardware Trojan. In the worst case, the attacker is able to find a single contiguous region to place the trigger and payload components that is nearby the victim security-critical net. Thus, routing the trigger and payload components will be trivial and the wire used to inject the payload will be short. In the best case, the attacker will have to implement their attack using many 4-connected placement regions (i.e., low Trigger Space score) and the only integration point on the targeted security-critical net (i.e., high Net Blockage score) is as far away from the open placement regions. Hence, we focus on quantifying the difficulty of routing the payload output to open attachment points on targeted security-critical nets (and its -deep fan-in). To this end, we identify two challenges of intra-Trojan routing:
Comply with design and fabrication rules
Meet Trojan and payload-delivery timing requirements
Complying with Design Rules. For each process technology, there are many rules associated with how wires and components must be laid out in a design. Some of these rules are defined in the Library Exchange Format (LEF) (lef_def_format) and contained in files that are loaded by modern Computer Aided Design (CAD) tools throughout the IC design process. There are two types of design rules: 1) those regarding the construction of circuit components (i.e., standard cells), and 2) those regarding routing. We classify these as component design rules and routing design rules, respectively. As technology nodes shrink, both sets rules are becoming increasingly complex (dr_complexity_rising).
It is vital for an attacker to comply with these design rules as violating them risks exposure. If an attacker inserts additional logic gates (standard cells) by making copies of existing components in a design, they can avoid violating component design rules involved with Trojan placement. However, to connect a wire from the Trojan payload to security-critical target net(s), they must perform custom Trojan routing. Therefore, complying with routing design rules is a concern. Routing design rules include specifications for the minimum distance between two nets on a specific routing layer, the minimum width of nets on a given layer, etc. Complying with these rules becomes easier for an attacker if the security-critical target net(s) are not blocked by other wires or components. The higher the Net Blockage score, the more difficult it is to make a connection, the more complex—and error prone—the route.
Meeting Timing Requirements. Every wire in an IC has a resistance and a capacitance, making it behave like an RC circuit, i.e., there is a time delay associated with driving the wire (logic ) or (logic ). The longer the wire, the more time delay there is (elmore1948transient). If the target net(s) has timing constraints (e.g., setup and hold times) that dictate when the payload signal must arrive at the target net for the attack to be successful, the Trojan routing must meet these constraints. Furthermore, the farther the target net is from the payload circuit, the more obstacles that must be routed around, increasing the routing distance even further. This is the basis for ICAS’ Route Distance metric. A natural limit for Route Distance is dictated by the clock frequency of the victim circuit, as most attacks must operate synchronously with their victim.
6. An Extensible Coverage Assessment Framework
The ICAS framework is comprised of two tools, Nemo and GDSII-Score, as shown in Figure 6. Nemo identifies security-critical wires based on designer annotations and circuit dataflow, while GDSII-Score assess the defensive coverage of a given IC layout against a set of attacks. ICAS takes as input four sets of files: 1) gate-level netlist (generated after all physical layout optimizations), 2) process technology files, 3) physical layout files, and 4) set of attacks. The process technology files include a Library Exchange Format (LEF) file and layer map file (lef_def_format; layer_map_format). The physical layout files include a Design Exchange Format (DEF) file and the GDSII file of an IC layout (gdsii_format; lef_def_format). The attack files are are a list of properties for each attack to assess coverage against: number of transistors, security-critical wire(s) to attach to, and timing constraints. All ICAS input files except the attack files are either generated-by or inputs-to the back-end IC design phase, and hence are readily available to back-end designers.
Though ICAS is extensible, our implementation includes three security metrics that capture the challenges faced by a foundry-level attacker looking to insert a hardware Trojan: amount and size of open-placement regions (Trigger Space), quantity of viable attachment points to targeted security-critical (and influencer) nets (Net Blockage), and the proximity of open placement regions to targeted security-critical net(s) (Route Distance). Together with the attack requirements, these metrics quantify the complexity an attacker faces for each step of inserting specific hardware Trojans into the given IC layout. We describe the implementation of both ICAS components below.
Nemo is the first analysis tool in the ICAS framework. It takes as input a Verilog netlist and automatically identifies the fan-in to root security-critical nets, which is output in the form of a Graphviz dot file (ellson2004graphviz). This is necessary since the inter-connected nature of signals within a circuit design means an adversary could influence the state of security-critical nets by controlling a net that is a part of its fan-in. Like prior work (jin2010dftt; linscott2018swan), Nemo assumes that HDL designers have appended a unique signal prefix to various signals considered “security-critical” in their designs at the RTL level. We make this assumption since determining what signals are “security critical” is easier with the semantics provided at the behavioral (RTL) level. For annotation, we leverage existing security-critical signal identification techniques (jin2010dftt; ba2015hardware; specs15; zhang2017identifying). Unfortunately, existing tools do not extend past the RTL design phase. Thus, Nemo’s task is to bridge the semantic gap and uncover duplicated or renamed security-critical signals in the post-PaR netlist. Fortunately, while synthesis and layout tools do modify a netlist by duplicating and removing signals and components (as part of optimization and meeting performance requirements), they do not completely rename existing signals. This makes it possible for Nemo to identify root security-critical signals (flagged at the behavioral level) by name at the physical level. To avoid removal of security-critical signals, we modify synthesis and layout scripts to essentially lock them in place. Nemo works backwards from root security-critical signals to identify the fan-in to these signals. The search depth is a configurable parameter of Nemo.
Nemo is implemented as a back-end target module to the open-source Icarus Verilog (IVL) (icarus) Verilog compiler and simulation tool written in C++. The IVL front-end exposes an API to allow third-parties to develop custom back-end target modules. Nemo is a custom target module (also written in C++) designed to be loaded by IVL. Since gate-level netlists are often described with the same HDL that was synthesized to generate the netlist (e.g., Verilog), we utilize the IVL front-end to interpret the Verilog representation of the netlist and our custom back-end target module, Nemo, to analyze the netlist. We open-source Nemo (anon) and release instructions on how to compile and integrate Nemo with IVL.
GDSII-Score is the second analysis tool in the ICAS framework. GDSII-Score is an extensible Python framework for computing security metrics of a physical IC layout. It takes as input the following: Nemo output, GDSII file, DEF file, technology files (LEF and layer-map files), and attacks description file. First, GDSII-Score loads all input files and locates the security-critical nets within the physical layout. Next, it computes security metrics characterizing the susceptibility of an IC design to each of the input attacks. Specifically, the three security metrics that we implement are: Trigger Space: the difficulty of implementing the hardware Trojan, Net Blockage: the difficulty of Trojan/victim integration, and Route Distance: the difficulty of meeting Trojan timing constraints. We open source the GDSII-Score framework and our security metric implementations (anon).
6.2.1. Metric 1: Trigger Space.
The Trigger Space metric quantifies the challenges of Trojan placement (§ 5.1). It computes a histogram of open 4-connected regions of all sizes on an IC’s placement grid. The more large 4-connected open placement regions available, the easier it is for an attacker to locate a space to insert additional Trojan circuit components at fabrication time. A placement site is considered to be “open” if the site is empty, or if it is occupied by a filler cell. Filler cells, or capacitor cells, are inserted into empty spaces during the last phase of layout to aid fabrication. Since they are inactive, an attacker can create empty placement sites by removing them, without altering the functionality or timing characteristics of the victim IC.
To compute the trigger space histogram, GDSII-Score first constructs a bitmap representing the placement grid. Placement sites occupied by standard cells (e.g., NAND gate transistors) are colored while those that are open are not. Information about the size of the placement grid and the occupancy of each site in the grid is available in the Design Exchange Format (DEF) file produced by commercial PaR tools. GDSII-Score then employs a breadth-first search algorithm to enumerate the maximum size of all 4-connected open placement regions.
6.2.2. Metric 2: Net Blockage.
The Net Blockage metric quantifies the challenges of integrating the hardware Trojan’s payload into the victim circuit (§ 5.2). It computes the percent blockage around security-critical nets and their influencers. The more congested the area surrounding security-critical nets, the more difficult it is to attach the Trojan circuitry to these nets. There are two types of net blockage that are calculated for each security-critical net: same-layer and adjacent-layer.
Same-layer blockage is computed by traversing points around the perimeter (North, South, East, West) at a granularity of , at a specific distance, , around the security-critical net and determining which points lie within other circuit components, as detailed in Figure 7a. To determine if a specific point along the perimeter lies within the bounds of another circuit component, we utilize the point-in-polygon ray-casting algorithm (hughes2014computer). The extension distance, , around the security-critical path element and the granularity of the perimeter traversal, , are configurable in our implementation. However, we default to an extension distance of one wire-pitch and a granularity of 1 database units, respectively, as defined in the process technology’s LEF file. The IC designs used in our evaluation are built using a 45 process technology, for which 1 database units is equivalent to 0.5 . Additionally, an open region is considered “blocked” if it is not wide enough for a minimal width wire to be routed through while maintaining the minimal amount of wire spacing required on that metal layer, as defined in the LEF file. The percentage of the perimeter length that is blocked by other circuit components is considered the same-layer blockage percentage.
Adjacent-layer blockage is computed by analyzing the area directly above and below a security-critical net, and computing the total area of overlap between other components, as detailed in Figure 7b. To calculate this overlap area we utilize the Weiler-Atherton polygon clipping algorithm (weiler_atherton). Additionally, any un-blocked regions above or below the security-critical net are considered “blocked” if they are not large enough to accommodate the smallest possible via geometry allowed on the respective via layer, as defined in the LEF file. The percentage of the total top and bottom area that is blocked by nearby circuit components is the adjacent-layer blockage percentage.
The same-layer and adjacent-layer blockage percentages are combined via a weighted average to form a comprehensive overall net blockage percentage where is based on same-layer blockage (north, south, east, and west) and is based on adjacent-layer blockage (top and bottom). We weight the same-layer blockage by , or , because 4 out of 6 total sides of a wire (north, south, east, west, top, and bottom) are on the same layer. Likewise, we weight the adjacent-layer blockage by , or .
Lastly, a total same-layer, adjacent-layer, and overall net blockage metric is computed for the entire IC design. For an IC design with security-critical nets, the same-layer (), adjacent-layer (), and overall () net blockage metrics are computed according to equations 1, 2, and 3, respectively.
6.2.3. Metric 3: Route Distance.
The Route Distance metric combines the Net blockage and Trigger Space metrics to quantify the difficulty of of meeting Trojan and attack timing constraints (§ 5.3). It computes a conservative estimate, i.e., Manhattan distance, for the minimal routing distance between open trigger placement sites and the
least blocked integration sites on the targeted security critical nets. It cross-references each Manhattan distance with the distribution of net lengths within the entire IC design. Net length can impact whether or not the Trojan circuit will meet timing constraints and function properly. Understanding where in the distribution of net lengths the Trojan routing falls provides insights into the ability of the Trojan circuit to meet its timing requirements and is an opportunity for outlier-based defenses. In summary, the more Manhattan distances that fall within one standard deviation of the mean net length, the easier it is to carry out an attack.
We implement the Route Distance metric as follows. First, the Net Blockage and Trigger Space metrics are computed. Next, the the distribution of all net-lengths within the IC layout are computed. Then, two-dimensional Manhattan distances between all unblocked nets ( overall net blockage) and trigger spaces are calculated. The Manhattan distance calculated is the minimum distance between a given trigger space and security-critical net, i.e., the minimum distance between any placement site within the given trigger space and any unblocked location on the targeted security-critical net. Lastly, each Manhattan distance is reported in terms of standard deviations away from the mean net-length in the given IC layout.
We use ICAS to quantify the defensive coverage of existing defensive layout techniques—revealing that gaps persist. First, we analyze the effectiveness of undirected defenses (xiao2013bisa). Specifically, we measure the impact of varying both physical and electrical back-end design parameters of the same IC layout on its susceptibility to attack. Second, we analyze the effectiveness of directed defenses (ba2015hardware; ba2016hardware). Specifically, we measure the coverage of existing, placement-oriented, defensive layout schemes in preventing the insertion of an attack by the foundry. Beyond revealing gaps, our results reveal that there is an opportunity for a improving both directed and undirected defenses that systematically eliminates Trojan/victim integration points. Lastly, our evaluation also demonstrates that ICAS is design-agnostic, works with commercial tools, and scales to complex IC layouts.
|A2 Analog (a2)||2||20||✗|
|A2 Digital (a2)||91||1444||✓|
|Privilege Escalation (king08; hicks10)||25||342||✓|
|Key Leak (trusthub)||187||2553||✓|
7.1. Experimental Setup
We utilize three IC designs for our evaluations: OR1200 processor SoC, AES accelerator, and DSP accelerator. The OR1200 processor SoC is an open-source design (or1200) used in previous fabrication-time attack studies (a2). The AES and DSP accelerator designs are open-sourced under the Common Evaluation Platform (CEP) benchmark suite (cep)
. The OR1200 processor SoC consists of a 5-stage pipelined OR1200 CPU that implements the 32-bit OR1K instruction set and Wishbone bus interface. The AES accelerator supports 128-bit key sizes. The DSP accelerator implements a Fast Fourier Transform (FFT) algorithm.
All designs target a 45 Silicon-On-Insulator (SOI) process technology. We synthesize and place-and-route all designs with Cadence Genus (version 16.23) and Innovus (version 17.1), respectively. In our first evaluation (§ 7.2) the design constraints (clock frequency, max transition time, core density) used for both synthesis and layout are varied as noted. However, in our second evaluation (§ 7.3) the same design constraints (100 clock frequency, 100 max transition time, 60% core density) were used for both synthesis and layout to form a common baseline. All ICs are synthesized and placed-and-routed on a server with 2.5 Intel Xeon E5-2640 CPU and 64 of memory running Red Hat Enterprise Linux (version 6.9).
7.1.1. Security-critical Signals
The first tool in the ICAS flow is Nemo. Nemo tracks security-critical signals from the HDL level to the IC layout level. The first step is flagging root security-critical signals at the RTL level, for each IC design. For the OR1200 processor SoC, the supervisor bit signal is flagged. We select this signal because one can alter the state of this bit to escalate the privilege mode of the processor (a2). For the AES accelerator, we flag all 128 key bits as security-critical. The signal within the DSP accelerator was flagged as security-critical. The signal of the DSP accelerator indicates to external hardware when an FFT computation is ready at the output registers. Tampering with the signal allows the attacker to hide specific outputs of the DSP accelerator. Lastly, Nemo marks, for each design’s IC layout, all root security-critical nets and their 2-deep fan-in as security-critical nets.
7.1.2. Hardware Trojans
Table 1 lists the hardware Trojan designs that we use in our quantification of defensive coverage. The first two Trojan designs (analog and digital variants of A2) are attacks on the OR1200 processor and DSP accelerator ICs. With respect to the OR1200, the A2 attacks act as a hardware foothold (king08) for a software-level privilege escalation attack. With respect to the DSP accelerator, the A2 attacks suppress the next_out signal (§ 7.1). The Privilege Escalation Trojan targets solely the OR1200 and the Key Leak solely the AES accelerator.
7.1.3. Build Environment
Both ICAS tools (Nemo and GDSII-Score) were run on the same server as the synthesis and place-and-route CAD tools. Nemo and Icarus Verilog were compiled from source using GCC (version 4.4.7). For increased performance, GDSII-Score was executed using the PyPy Python interpreter with JIT compiler (version 4.0.1) (pypy).
7.2. Undirected Defense Coverage
As detailed in § 4.1, a defensive strategy for protecting an IC layout from foundry-level attackers is to exploit physical layout parameters (e.g., core density, clock frequency, and max transition time) offered by commercial CAD tools to increase congestion—hopefully around security-critical wires. The tradeoff is that while this is a low cost defense in that CAD tools already expose such knobs, the entire design is impacted and there is no guarantee that security-critical wires will be protected. We use ICAS and its three security metrics to quantify the effectiveness of such undirected approaches (xiao2013bisa).
To uncover the impact of each parameter, we start by generating 60 different physical layouts of the OR1200 processor design by varying:
Target Core Density (%): 50, 70, 90
Clock Frequency (): 100, 200, 500, 1000
Max Transition Time (): 100, 150, 200, 250, 300
Target core density is a measure of how congested the placement grid is. Typically, designers select die dimensions that achieve 60–70% placement density to allow space for routing (a2). Target clock frequency is the desired speed at which the circuitry should perform. Typically, designers select the clock frequency based on performance goals. Max transition time is the longest time required for the driving pin of a net to change logical values. Typically, designers choose a value for max transition time based upon power consumption and combinational logic delay constraints.
For each of the 60 layout variations we compute ICAS metrics. Figures 8, 9, and 10 provide a visual representation for each metric. Overlaid on Figure 10 are the number of unique attack (color-coded) implementations for each Trojan (Tab. 1) at six parameter configurations. Across the 60 IC layouts, the time it took ICAS to complete its analyses ranged from 38 seconds to 18 minutes. On average, this translates to less than 10% of the combined synthesize and place-and-route run-times. These run-time results demonstrate the deployability of ICAS as a back-end design analysis tool. Overall, our evaluation indicates that while some of these layout parameters do increase attacker complexity, none are sufficient on their own. Next we break down the results metric-by-metric.
7.2.1. Trigger Space Analysis.
Figure 8 shows the distributions of open trigger spaces across 15 unique OR1200 layouts. We vary target core density and max transition time parameters across layouts, while we fix the target clock frequency at 1 GHz. A trigger space is defined as a contiguous region of open placement sites on the device layer placement grid and is measured by number of contiguous “4-connected” placement sites. Each box represents the middle 50%, or interquartile range (IQR), of open trigger space sizes for a given IC layout. The dots represent individual data points within and outside the IQR. Our empirical results affirm prior notions (xiao2013bisa; ba2015hardware; ba2016hardware) that increasing the target core density of an IC layout results in fewer large open spaces to insert hardware Trojans. Additionally our results indicate that at lower densities, decreasing the max transition time constraint decreases the median trigger space size. Similar trends occur at lower clock frequencies. While results show that modulating target core density is effective, observe that even in the best case, large trigger spaces remain.
7.2.2. Net Blockage Analysis.
Figure 9 shows the Net Blockage metric (Eq. 3) computed across 20 unique OR1200 layouts. We fix the target density at 50% across all layouts, while the target clock frequency and max transition time are varied (as listed above). The results show that at lower clock frequencies a smaller max transition time parameter corresponds to increased Net Blockage. This corresponds to less open Trojan/victim integration points available to the attacker. However, as clock speed increases, the correlation between max transition time and overall Net Blockage deteriorates. Intuitively, smaller max transition times should lead to smaller average net-lengths within the design, as transition time is a function of the capacitive load on the net’s driving pin (elmore1948transient). Shorter net-lengths result in more routing congestion as components cannot be spread-out across the die. However, capacitive load (on a driving pin) is inversely proportional to frequency, thus at higher clock frequencies the max-transition time constraint is more easily satisfied, and altering it has less effect on the Net Blockage. Given these results, the effectiveness of modulating transition time is context dependent and—even in the best case—open integration points remain.
7.2.3. Route Distance Analysis.
Figure 10 shows the Route Distances across 6 various OR1200 layouts in the form of heatmaps that capture the trade space between layout parameters. Core density and max transition times were varied across the layouts (indicated in the labels), while clock frequency was held constant at 100 . Each heatmap describes several (column-wise) histograms of Route Distances in terms of standard deviations from the mean net length observed in that particular IC layout (y-axis). The Route Distances reported are those between any unblocked security-critical nets, and trigger spaces large enough to hold an attack of a given size range (x-axis). That is, the color intensities within in a given heatmap column indicate the percentage of (security-critical-net, trigger-space) pairs in that column that are within a range of distance apart. Additionally, overlaid on each heatmap are rectangles indicating the region of the heatmap where a given attack (Tab. 1) can be implemented, and the number of possible attack configurations, (security-critical-net, trigger-space) pairs, that can be exploited.
If timing is critical to the operation of an attacker’s desired Trojan, (critical-net, trigger-space) pairs with routing distances significantly greater than the average net length in the IC layout are less likely to be viable candidates for constructing hardware Trojans. IC layouts with few desirable (critical-net, trigger-space) pairs are much more time-consuming to attack. Namely, the IC layouts with heatmaps that indicate a higher percentages of far-apart (critical-net, trigger-space) pairs, where the trigger spaces are small, are most secure. From Figure 10, we conclude that at high density, max transition time has little affect on IC layout security; while at lower densities, lower max transition time designs are more secure. Similar trends exist across other layout parameters, as shown in Figures 12–14 in Appendix A.
7.2.4. Cost of Varying Layout Parameters.
The results indicate that increasing core density is effective, but incomplete, and increasing clock frequency and decreasing max transition time is marginally effective and incomplete. While tuning these parameters is low cost to the designer, there is a cost to the design in terms of complexity and power requirements. We elucidate by discussing how varying each design parameter (density, clock frequency, and max transition time) impacts non-security characteristics of a circuit design.
While increasing core density to 90% makes placing-and-routing a Trojan more difficult, it also makes placing-and-routing the rest of the design more challenging. Specifically, it can become nearly impossible to meet timing closure for the entire design if there is not enough space within the core area to re-size cells and/or add additional buffer cells. Depending on performance and security requirements, a layout engineer may choose to relax timing constraints in order to achieve a higher core density. Alternatively, a layout engineer may attempt to surround security-critical nets with areas of high densities, while maintaining a lower overall core density, as previously suggested (ba2015hardware; ba2016hardware).
Decreasing the maximum transition time and increasing the clock speed of an entire circuit design makes it more difficult to place-and-route a functional Trojan that meets timing constraints, but also directly impacts the performance characteristics of the circuit. Additionally it is important to note that max transition time is related to the clock frequency, so varying one without the other changes performance tolerances. While increasing the performance of the design might increase security, it comes at the cost of increasing power consumption. Depending on the power-consumption requirements of the design, it may be possible for a designer to over-constrain these parameters for added security.
7.3. Directed Defense Coverage
As an alternative to probabilistically adding impediments to the attacker inserting a hardware Trojan, recent works proposes a directed approach. As detailed in § 4.2, placement-centric directed defenses (ba2015hardware; ba2016hardware) attempt to prevent the attacker from implementing their Trojan by occupying all open placement sites with tamper-evident filler cells. The limitation with such defenses is that it is infeasible to fill all open placement sites with tamper-evident logic (ba2015hardware). Thus, the defenses focus their filling near security-critical logic, leaving gaps near the periphery of the IC layout. Whether these open placement sites near the periphery are sufficient to implement an attack is an open question.
The goal of this evaluation is to determine not only if it is still possible for a foundry-level attacker to insert a hardware Trojan, given placement-centric defenses, but to quantify the number of viable implementations available to the attacker—to act as a surrogate for attacker complexity. For the evaluation, We use our three IC designs (OR1200 processor SoC, AES accelerator, and DSP accelerator). For each design, we create two IC layouts: (1) unprotected and (2) protected. For the protected IC layout, we use the latest placement-centric defense (ba2016hardware); using the identified security-critical wires (§ 7.1) to direct the defense. We layout all IC designs using the these parameters: target clock frequency of 100 , max transition time of 100 , and a target core density of 60%.
We then use ICAS to asses the defensive coverage of each of the six IC layouts. This analysis has two goals: (1) determine whether the IC is vulnerable to attack and (2) understand the impact of applying the defense. We answer both questions in an attack-centric manner using the hardware Trojans in Table 1 to asses defensive coverage against. For each attack/IC layout combination we plot the number of (security-critical-net, trigger-space) pairs that could be used in implementing each Trojan. A (security-critical-net, trigger-space) pair is considered a viable candidate for implementing a Trojan if:
the trigger space size is at least as large as the minimum number of placement sites required to implement the desired hardware Trojan design
the security-critical net is less than 100% blocked
if the hardware Trojan is “Timing-Critical”, i.e., it must function at the design’s core operating frequency, then the distance between the trigger space and open integration point on the security-critical net must be standard deviations from average net length; otherwise, any distance is allowed.333Three standard deviations from the average net length is the threshold for Trojan to integration point routing with violating timing constraints, because it accounts for 99.7% of the designs’ wires—outliers tend to be power wires. For an exact calculation it is possible to extract parasitics for a target for a Trojan’s route to determine if it violates timing constraints.
Figure 11 shows the defensive coverage for each IC design. Overlaid on each heatmap are rectangles (and numbers) indicating unique possible attack implementations. These results show that existing placement-centric defenses are effective at reducing an IC’s fabrication-time attack surface, compared to no defense—but gaps persist. Given that filling placement sites with tamper-evident logic is already maximized, these results point to systematically adding congestion around security-critical wires as a means to close all remaining defensive gaps; i.e., a directed version with similar effect to existing undirected defenses.
ICAS is the first tool to provide insights into the security of physical IC layouts. ICAS is extensible across many dimensions including CAD tools, process technologies, security metrics, and fabrication-time attacks and defenses. To demonstrate ICAS’ capabilities we implemented three security metrics (net blockage, trigger space, and routing distance) using it. The focus of this paper is using these metrics to quantitify the coverage of existing untrusted foundry defenses; which shows that IC designs are still vulnerable to attack. We envision uses for ICAS beyond this, as an integral part of the IC design using commercial tools.
ICAS-Driven Defensive Layout: ICAS provides an added notion of security to the IC layout process (place-and-route) to enable researchers to explore countermeasures against fabrication-time attacks. To the best of our knowledge, the targeted defensive IC layout techniques that exist (xiao2013bisa; ba2015hardware; ba2016hardware) are placement-centric, i.e., filling unused space on the device layer with functional logic cells. While ICAS is capable of evaluating placement-centric defensive layout techniques, its security-insights also asses routing-centric defensive layout techniques. For example, layout engineers can leverage ICAS to create high degrees of routing congestivity in close proximity to security-critical nets. ICAS’ security metrics enable IC layout designers to optimize the security of both the placement and routing of their designs.
Extensibility of CAD Tools: Almost all steps of the IC design process utilize CAD tools. ICAS integrates into a commercial IC design process after placement-and-routing (Figure 1). While ICAS is validated with IC layouts generated by Cadence tools, integrating ICAS with other vendors’ CAD tools requires no additional effort due to the common process technology (LEF) and GDSII specifications used by ICAS.
Extensibility of Process Technologies: We test ICAS using IC layouts built with a 45 SOI process technology; however, ICAS is agnostic of process technology. The LEF and layer map files (§ 6) are the only ICAS input files that are process technology dependent. A LEF file describes the geometries and characteristics of each standard cell in the cell library, and the layer map file describes the layer name-to-number mappings, respectively, for a given process technology. ICAS adapts to different process technologies provided that all input files adhere to their specifications (lef_def_format; layer_map_format).
Extensibility of Security Metrics: GDSII-Score is the ICAS tool that computes security metrics from an IC layout. It loads several files describing the IC layout to instantiate a single Python class (called “Layout”) that contains query-able data structures containing a polygon representation of all components in the layout. Additionally, GDSII-Score contains several subroutines that compute spatial relationships between polygon objects and points within the layout. From these data structures and the provided subroutines, it is trivial to integrate additional novel metrics into GDSII-Score. To facilitate additional metrics, we open source GDSII-Score (anon), and our three example metrics that demonstrate how to query the main “Layout” data structure.
9. Related Work
Fabrication-time attacks and defenses have been extensively researched. Attacks have ranged in both size and triggering-complexity (lin2009trojan; becker2013stealthy; shiyanovskii2010process; kumar2014parametric; a2). Defenses against these attacks include: side-channel analysis (agrawal2007trojan; jin2008hardware; balasch2015electromagnetic; narasimhan2011tesr), imaging (zhou2015detecting; adato2016rapid), on-chip sensors (li2008speed; forte2013temperature), and preventive measures (xiao2013bisa; cocchi2014circuit; ba2015hardware; ba2016hardware). The most pertinent attacks and defenses are highlighted below.
Untrusted-foundry Attacks: The first foundry-level attack was conceived by Lin et al. (lin2009trojan). This hardware Trojan was comprised of approximately 100 additional logic gates and designed to covertly leak the keys of an AES cryptographic accelerator using spread spectrum communication to modulate information over a power side channel. While the authors only demonstrated this attack on an FPGA, they are the first to mention the possibility of this type of Trojan circuit being implanted at an untrusted foundry.
The A2 attack (a2) is the most recent fabrication-time attack. A2’s analog triggering mechanism is stealthy, controllable, and small. It prevents the Trojan from being exposed during post-fabrication testing, or unintentionally through common usage. The attack requires only two additional standard cells and evades every known detection mechanism to date. ICAS quantifies the defensive coverage to these and other fabrication-time attacks.
Untrusted-foundry Defenses: Most untrusted foundry defenses rely on post-fabrication detection schemes (agrawal2007trojan; jin2008hardware; balasch2015electromagnetic; narasimhan2011tesr; zhou2015detecting; adato2016rapid; li2008speed; forte2013temperature). ICAS aims to guide innovation in preventive defenses against fabrication-time attacks, for which few mechanisms currently exist (cocchi2014circuit; xiao2013bisa; ba2015hardware; ba2016hardware). We highlight some of these preventive measures and how ICAS could measure their effectiveness.
While preventive security-by-design was first explored at the behavioral (RTL) level by of Jin et al. (jin2010dftt), Xiao et al. were the first to demonstrate security-by-design at the layout-level with their BISA (Built-In Self-Authentication) scheme (xiao2013bisa). The undirected BISA approach attempts to eliminate all unused space on the device layer placement grid, and create routing congestion, by filling the device layer with interconnected tamper-resistant fill cells. Alternatively, recognizing the impracticality of filling 100% of the empty placement sites in complex circuit designs, Ba et al. take a directed approach to filling empty placement cites (ba2015hardware; ba2016hardware). Specifically, they only fill empty placement sites in close proximity to security-critical nets.
ICAS is an extensible framework that we use to expose and quantify gaps in existing defenses to the threat posed by an untrusted foundry. ICAS has two high-level components: Nemo, a tool that bridges the semantic gap across IC design processes by tracking security-critical signals across all stages of hardware development and GDSII-Score, a tool that quantifies the difficulty a foundry-level attacker faces in attacking security-critical logic. Experiments with over 60 IC layouts across three open-source hardware cores and four foundry-level hardware Trojans reveal that all current defenses leave the IC design vulnerable to attack—and some are totally ineffective. These results show the value of a tool like ICAS that can help designers identify and address defensive gaps.
From a high level, ICAS is momentus in that it makes security a first-class concern during IC layout (in addition to power, area, and performance): ICAS allows IC designers to measure the security implications of tool settings and design decisions. ICAS fits well with existing IC design tools and flows, allowing them to consider security. ICAS is a critical measurement tool that enables the systematic development of future physical-level defenses against the threat of an untrusted foundry.
We thank Ted Lyszczarz, Brian Tyrrell, and other members of the MIT Lincoln Laboratory community for their thoughtful feedback that enhanced the quality of our work.
DISTRIBUTION STATEMENT A. Approved for public release. Distribution is unlimited. This material is based upon work supported by the Under Secretary of Defense for Research and Engineering under Air Force Contract No. FA8702-15-D-0001. Any opinions, findings, conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the Under Secretary of Defense for Research and Engineering.
This material is based upon work supported by the National Science Foundation Graduate Research Fellowship Program under Grant No. DGE 1256260. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.