Abstract
Field-programmable gate arrays (FPGAs) are integrated circuits (ICs) containing programmable logic components that can be reconfigured by an end-user post manufacturing. Similar to ICs, FPGAs are also susceptible to supply-chain attacks, especially insertion of hardware Trojans. In this book chapter, we explain how attackers can insert Trojans into FPGAs. We present a Trojan taxonomy that is tailored to FPGA supply chain. We then discuss the main classes of Trojans in FPGAs and explain the different ways of inserting these Trojans in detail. Finally, we present the various countermeasures that have been developed to target Trojans that are FPGA specific.
Similar content being viewed by others
1 Introduction
Field-programmable gate arrays (FPGAs) are integrated circuits (ICs) containing programmable logic components that can be reconfigured by an end-user post manufacturing. In the recent years, the usage of FPGAs has drastically increased; the FPGA market share is estimated to reach $9.9 billion by 2020 [36]. FPGAs are used in a wide range of applications such as application-specific integrated circuit (ASIC) prototyping, communication devices, medical instruments, high-performance computing systems, aerospace, and defense systems. The growing demand for power-efficient and high-performance ICs has created a surge in usage of FPGAs in the recent years. FPGAs are also available as cloud services [3], where one can create and run custom hardware designs on a remote FPGA in a server farm. Hence, exploring security issues associated with FPGA designs is critical.
Simultaneously, globalization of IC design flow has reduced design complexity and fabrication cost, but it has introduced several security vulnerabilities [13]. A rogue element anywhere in the IC supply chain can perform the following attacks: reverse engineering (RE), hardware Trojans, counterfeiting (specifically, recycled ICs), and IP piracy [17, 35]. These attacks cost the semiconductor industry billions of dollars annually [30, 37], undermine national security [1, 14], and put critical infrastructure into danger [15]. Though part of the problem is that designers have no control over their design in this distributed supply chain, a more important issue is that current IC design tools do not consider security as a design metric.
This chapter explores insertion of hardware Trojans into genuine designs targeted for FPGAs. Such compromised designs may result in subpar performance, leakage of confidential information, and unauthorized and pernicious operations by an attacker. The use of compromised designs in critical infrastructures such as smart grids, nuclear power plants, medical prosthetic devices, and military equipment can be catastrophic. To explain the different classes of Trojans, this chapter uses Xilinx FPGA design flow. However, the same methodology can be extended to any FPGA and CAD tool vendors. This chapter is organized as follows: We first present the threat model and a taxonomy of FPGA Trojans in Sect. 14.2. Next, we focus on three broad categories of FPGA Trojans: Trojans in FPGA fabric (see Sect. 14.3), Trojans in FPGA tool chain (see Sect. 14.4), and Trojans in FPGA bitstreams (see Sect. 14.5). Section 14.6 discusses the countermeasures that specifically target Trojans in FPGA bitstreams. Finally, Sect. 14.7 concludes the chapter.
2 Threat Models and Taxonomy
2.1 FPGA Design Flow
Figure 14.1 shows the FPGA design flow. An FPGA designer designs the FPGA fabric. Fabless FPGA design houses send the layout of the FPGA fabric to a foundry for manufacturing. Many of these foundries are located typically offshore and are untrusted. Post-fabrication, the FPGAs are tested for defects and faults. FPGAs are sold on the market. The end-user implements the target design on the FPGA. Converting a design described in a modeling language (VHDL or Verilog) into an FPGA-specific programming file involves multiple steps, as explained below:
-
1.
Synthesis involves the conversion of HDL into a logical netlist (similar to logic diagram or circuit).
-
2.
Implementation consists of translate and map processes,Footnote 1 where the logical netlist gets converted and mapped to target device’s physical primitives.
-
3.
Place and route (PAR) takes a mapped native circuit description (NCD) file, places and routes the design, and produces an NCD file to be used by the programmable file generator.
-
4.
In bitfile generation, the routed NCD is used to create a bitfile that can be programmed onto an FPGA.
2.2 Threat Model
In the quest to reduce the development cost of hardware/system, the silicon industry has inadvertently created a complex and extremely vulnerable supply chain shown in Fig. 14.1. An attacker can be present anywhere in the supply chain. The threat model, shown in Fig. 14.1, involves: Overproduction: An untrusted foundry that has access to the FPGA layout mask fabricates more number of FPGAs than requested or authorized by the design company. It can insert these FPGAs into the supply chain without the knowledge of FPGA design company. These FPGAs may not be properly tested and can introduce reliability issues. This results in either loss of revenue or reputation for the design company.
Recycling and remarking: FPGAs can be extracted from electronic waste, used FPGAs can be removed, and their package can be repainted and/or remarked. The die can also be removed from the packaging, repackaged, and remarked. These FPGAs are then reinserted into the supply chain as genuine and new FPGAs. These FPGAs can be highly unreliable, are prone to defects, and typically lead to subpar performance.
Cloning and piracy: It is an unauthorized reproduction of an FPGA by reverse engineering without the legal intellectual property (IP) rights to manufacture the FPGA. These FPGAs can also have malicious modifications.
Apart from these threats, FPGAs are also susceptible to insertion of Trojans, which is described in detail below.
2.3 Taxonomy
Malicious changes can be made at any phase of the FPGA design such as design, fabrication, packaging, and in the supply chain as shown in Fig. 14.1. A taxonomy based on hardware Trojans’ physical, activation, and functional characteristics have already been proposed [19, 34]. We classify Trojans based on the method of creation, activation, and point of entry into the FPGA fabric as shown in Fig. 14.2. The definitions of most of the FPGA Trojans are similar to the IC Trojan taxonomy in [19, 34]. In this chapter, we will focus on the FPGA-specific attributes of the taxonomy. Interested readers can refer to the comprehensive taxonomy presented in [19, 34].
2.4 Point of Entry
Based on the point of entry of Trojans in FPGA, they can be classified as:
-
Prefabrication: It is the phase where the specification of systems such as functionality, size, power, delay, etc., is finalized. Trojan insertion in this step will result in alteration of design or constraints. For example, it could alter the timing of circuit or increase switching frequency of the circuit. A rogue employee can insert a malicious circuit, e.g., a backdoor, to take control of the chip at a later point in time when the FPGAs are deployed in the field. These manifest as FPGA fabric Trojans.
-
Fabrication: Here, a set of masks are designed to fabricate the digital circuit on a silicon wafer. Trojans can be added by a malicious attacker inside an untrusted foundry. These Trojans can be either functional or parametric. These are called as FPGA fabric Trojans.
-
Post-fabrication: In this phase, RTL/HDL designs are used to program an FPGA to achieve desired functionality. Trojans can be either inserted in RTL/HDL designs by a rogue employee or can also enter RTL/HDL designs from IPs from third-party IP providers. These are FPGA design Trojans. Additionally, even the reliability of an FPGA can be reduced by such type of Trojans.
2.5 Creation Method
Based on the creation method, Trojans can be classified into:
-
Functional Trojan: They are created by modifying the FPGA fabric. This includes addition/deletion of gates/transistors, modifying the RTL or layout without affecting the primary functionality of the FPGA fabric. It can enter during prefabrication phase by a rogue employee in the FPGA design company or during fabrication phase by a malicious insider at an untrusted foundry.
-
Parametric Trojan: They are created by modifying physical device parameters, such as thinning of wires, gate channel length variation, dopant level variation [5], transistor size variation, etc. It is always on and primarily created to reduce the reliability and lifespan of an FPGA.
-
Life-span reduction Trojan (LRT): It is the only class of Trojans that are not inserted in the hardware during or before fabrication. It is created by subjecting the FPGA with external factors, such as extreme temperatures, focused ion beams [9], etc. LRT accelerates aging of complete or part of FPGA fabric. It is typically created by a malicious distributor in the FPGA supply chain to reduce the reliability and, hence, reduce the lifespan of FPGAs.
-
Bitstream Trojan: It is inserted by modifying the FPGA bitfile itself. Bitstreams can be reverse engineered to identify the areas of FPGA occupied by the programmed logic, and malicious circuits can be inserted into it. If the malicious circuit does not disturb the original circuit, it is called Type-I bitstream Trojan. Type-II Trojans typically modify the original circuitry with respect to CLBs or other FPGA resources to perform malicious operations.
-
CAD tool Trojan: They are FPGA design Trojans that exploit the CAD tool flow to insert the Trojans at various intermediate netlist formats. These Trojans can be inserted in a synthesized netlist and even in mapped or placed and routed netlists. Due to the lack of resources to understand the intermediate and typically proprietary formats, these Trojans can easily evade detection.
3 Trojans in FPGA Fabric
FPGA fabric Trojans are inserted into the FPGA silicon fabric. They can be inserted either during fabrication by a untrusted foundry or during the design phase of FPGA by a rogue employee in the FPGA design company. Functional fabric Trojans are characterized by addition/deletion of gates by the attacker to carry out malicious activities, whereas parametric fabric Trojans are created by changing device parameters/specification such as thinning of wires and weakening of transistors or flip-flops to reduce the reliability of the FPGA [18, 25]. In this section, we describe three Trojans that can be inserted into the FPGA fabric: Trojans that increase delay, create voltage fluctuations, and reduce lifetime.
3.1 Trojans That Increase Delay
The delay-based fabric Trojan is created by modifying interconnect connecting lookup tables (LUTs) across two configurable logic blocks (CLBs). The delay-based fabric Trojans correspond to change or perturbation in the physical layout of FPGA due to the addition of malicious elements as shown in Fig. 14.3. The assumption is that the silicon fabric of the FGPA is dense and highly utilized. An attacker needs to alter the FPGA silicon in order to add a Trojan. For example, when a Trojan is inserted in a CLB or routing switch matrix (RSM), it will perturb the physical layout of original fabric, thereby increasing the delay.
Example
Figure 14.4 is a screenshot of an FPGA editor tool. The routes colored in red are before and after modification, respectively. This emulates a Trojan inserted in an interconnect that affects the net delay which in turn impacts total delay of the path connecting the two I/O pins of CLBs. Consider this path is configured to be a path of a ring oscillator (RO) programmed using the LUTs in the corresponding CLBs. All the routes, LUTs, and pins remain the same, for both ROs without and with Trojan, except the Trojan-perturbed route. The delays are 0.140 and 0.419 ns, before and after the interconnect modification, respectively. The delay difference caused by the Trojan is 0.279 ns.
3.2 Trojans That Induce Voltage Fluctuations
This set of Trojans is implemented by adding simultaneous switching signals that utilize dense interconnect resources around a CLB. This corresponds to the addition of malicious elements without disturbing the genuine layout of FPGA fabric. This switching signal is connected to unused wires and programmable interconnect points (PIPs) in the tile where the target CLB is configured as shown in Fig. 14.5. This Trojan increases switching activity that will increase dynamic power and therefore impacts the oscillation frequency. In [39], it was observed that voltage drop due to the Trojan switching activity had impacted the RO frequency.
3.3 Life-Span Reduction Trojan (LRT)
Life-span reduction Trojan (LRT) can be induced into an FPGA by artificially creating conditions that accelerate aging of FPGA fabric. Key contributors for an FPGA aging (or any IC) among several physical factors are negative-bias temperature instability (NBTI) and hot carrier injection (HCI) [6]. Both the factors lead to a shift of threshold voltage of the affected transistors, which manifest as increase in switching and path delays. This will subsequently lead to timing violations and wears out an FPGA faster.
NBTI.
Transistor parameters can be evolved over a large range of stress conditions. Bias temperature instabilities are observed when a transistor is stressed at relatively high temperatures. Electrical parameters of transistors such as the threshold voltage (V th ) can be shifted by the creation of interface traps and trapping of holes into the oxide [16]. This in turn reduces the mobility and degrades device parameters, and the transistor yields a lower level of performance. This inherently ages the devices faster. NBTI primarily affects PMOS devices. Supply voltage and temperature exponentially increase the NBTI effect. Thus, NBTI degradation can be induced by subjecting an FPGA to higher operating temperatures and supply voltage.
HCI
primarily affects NMOS; where accelerated electrons in the channel can collide with gate oxide interface, electron-hole pairs are created. V th increases due to free electrons trapped in the gate oxide layer. The degradation associated with HCI attributes to physical breakdown and characteristic distortion of the transistor. Operating conditions and switching frequency are the primary contributors to the rate of HCI degradation [31]. The V th shift has a sublinear dependence on frequency, runtime, and activity factor (ratio of transitions and runtime) [7].
3.3.1 Accelerating FPGA Aging
Because of NBTI and HCI effects, the aging of transistors can be increased significantly by increasing temperature, supply voltage, and switching activity. A malicious distributor can subject an FPGA to extreme temperatures and supply voltage and even program the FPGA to run rogue design with a high switching activity under stressful conditions. To negate the aging effects, manufacturers specify safe operating margins. Running an FPGA outside the safe operating margins would inherently degrade the performance and, hence, reduce the reliability of the chip.
A simple heat gun and an external power supply can be used to operate an FPGA under such extreme conditions. An attacker with access to sophisticated equipment can use focused ion beam irradiation [9, 32] and even create selective-LRT, where only a few specific tiles or CLBs in an FPGA wear out. Using a focused heat gun can also be used to create selective-LRT. However, as the FPGA packaging is designed to spread the heat evenly throughout the FPGA, it is difficult to achieve such precision when compared to focused ion beams.
3.3.2 An Example LRT Trojan
An LRT Trojan is created by subjecting the FPGA to extreme temperature of 180∘C, while the fabric is configured with a design that increases the switching activity inside the FPGA. The setup uses a soldering heat gun placed on the FPGA with a small air gap as shown in Fig. 14.6. FPGA sensors register an internal temperature of 170∘C (50∘C above the manufacturer-specified maximum temperature of 120∘C).
16 ROs are used to measure the performance degradation on Day 3, Day 6, and Day 7. To accurately measure the impact of aging effects due to NBTI and HCI, the heat gun is switched off, and the FPGA is allowed to cool down for 24 h, as studies show that the transistors recover from the aging effects to a certain extent [4]. Figure 14.7 shows the frequencies of the 16 ROs from Day 0 to Day 7. Figure 14.8 shows that the FPGA fabric at the RO locations has degraded by 10% on Day 7.
4 Trojans in FPGA Design
4.1 Trojan Insertion in FPGA Designs
The goal of the attack tool is to decide where to place the Trojan for a given design. The placement of Trojan can be achieved with or without disturbing the original design mapping and routing. The latter requires considerable effort and access to multiple files from the FPGA design cycle.
To insert hardware Trojans in FPGA designs, an attacker may need to have knowledge of internal wires or logic and preferably where the design is physically placed on the FPGA. If the Trojan is conditionally activated based on the input or internal states, the attacker needs to tap into the required wires of the design and connect the Trojan activator circuit. The Trojan payload can be connected to the target elements by disconnecting the wires connecting to these elements and reconnecting with the output of the payload circuit. The original payload and Trojan payload can be connected using multiplexers, with the select line controlled by the activator circuit.
After the logic synthesis process, FPGA CAD tools typically rename and merge (after logic optimization) the internal wires connecting logic elements. An attacker needs to track the name changes in the design, to connect them with the Trojans. This can be achieved by converting the synthesized binary netlist (called NGC by Xilinx) to a readable Electronic Design Interchange Format (EDIF) file and Xilinx Design Language (XDL) file. Figure 14.9a shows the HDL code, and Fig. 14.9b shows the corresponding XDL file obtained from routed netlist (NCD) after PAR, which describes how the HDL is mapped into LUTs. Additional information on the location of configurable logic block (CLB) and LUT is also present in the XDL file. Figure 14.9c shows how the CLB blocks are connected with each other to implement the functionality described in HDL. We can extract the locations and interconnections used by the original design from the NCD or XDL files. Additionally, even the post-PAR timing simulation model can also be used to get the locations used by the design (Fig. 14.10).
4.2 Trojans in HDL
An attacker can insert the Trojan in the HDL design. In the HDL, the attacker can easily track the logic elements or states to be used as an activator and deliver the Trojan payload to the target. Inserting Trojan at this level is significantly easier for an attacker, as the wires and logic elements can be found from the behavioral or structural code.
Example
Consider the C17 circuit of ISCAS 85 benchmark [8]. The RTL representation is shown in Fig. 14.11. The number of internal logic nodes available in RTL for an attacker is four: N1, N11, N16, and N19 (except five primary inputs (PI) and two primary outputs (PO)). A functional Trojan inserted at the internal node N16 is shown in Fig. 14.12. The Trojan component is a MUX activated when N2 is logic “1” and the payload is switching result of node N16 with N11. This Trojan corrupts the functionality when activated. This example demonstrates the design space for an attacker with RTL or HDL circuits.
4.3 Trojans in Post-synthesis Netlist
An attacker can insert the Trojan in the post-synthesized netlist (called as the NCD file). To perform this, the post-synthesized NCD file can be converted to the XDL format. The XDL file contains the CLB configuration, the interconnection between CLB’s, and information on routing inputs and outputs of the FPGA design. The mapped/routed netlist typically would have undergone logic optimization; wires and interconnections will be renamed and, hence, will not have the same wires and components as described in the behavioral/structural code. Logic merging by the CAD tools also makes it difficult to manually tap into internal logic. For instance, consider two equations, A = B + CD and E = F ⊕ CM. A CAD tool can implement these two equations by using just one 6-input LUT by selecting parameters appearing left-hand side as inputs to LUT and outputs E and F can be connected to O5 (output of 5-input LUT) and O6 (output of 6-input LUT), respectively.
To insert Trojans at this level, the attacker needs to have information of renamed signals that can be obtained from synthesized netlist, by converting it to the EDIF. After obtaining the available wires and logic in the design, the attacker can adapt the Trojan activation circuit and payload circuit. The Trojan will be described in XDL language and inserted into the synthesized design by following a similar approach as explained in inserting Trojan at HDL level.
Example
Consider the same C17 circuit targeted for FPGA implementation; the design space for an attacker changes significantly to insert Trojans in post-synthesis netlists. The equivalent C17 circuit after synthesis stage of implementation for Nexys4-DDR FPGA is shown in Fig. 14.13. All the internal nodes of RTL/HDL shown in Fig. 14.11 are unavailable. Xilinx CAD tool implements the C17 using just two LUTs due to optimization. The new post-optimized nodes are N221 and N231. N221 corresponds to merged logic from nodes N10 and N16. N231 corresponds to N11 and N16 in Fig. 14.11. The contents and the connections of the LUT are shown using LUT-perspective graphical representation as shown in Fig. 14.14. As node N16 is not available, the RTL Trojan described in Fig. 14.12 cannot be inserted in the same way after post-synthesis without disrupting the original mapped design. We present two methodologies of inserting this Trojan.
Additional hardware. Here we do not modify the mapped LUTs in the netlist. We create an additional LUT (say MUXLUT) that uses the inputs from IBUF N2 (Fig. 14.14) to get the same activation condition as the Trojan in Fig. 14.12. Another LUT, say Payload-LUT, to generate the payload using N1, N2, N3, and N6 is used. The output is connected to MUXLUT. The connection between N221 LUT and N221_OBUF in Fig. 14.14 is deleted, and N221 is connected to MUXLUT. When N2 is 1, MUXLUT will output the content of Payload-LUT to output else will output the content of N221 (normal output of C17). Without optimization, this requires two additional LUTs. However, only one LUT is required after optimization. The number of nodes involved including activator and payload is five: N1, N2, N3, N6, and N221. Hence, we can pack the logic into a single 6-input LUT.
Reuse existing hardware.
In this case, we modify the content of original LUT itself to achieve the desired functionality. From the original C17 in Fig. 14.11 and Trojan in Fig. 14.12, we can see that both depend on nodes – N1, N2, N3, and N6 – and the LUT in Fig. 14.14 after post-map consists of truth table expressed as a function of normal C17 circuit. We could modify the truth table to achieve the functionality of the Trojan and normal C17 using the same LUT. This way, we introduce the Trojan into the circuit without incurring any extra additional logic and without any changes to the hardware. In this case, the truth table of LUT 221 is given by the expression \((\overline {D3}D4)+(D3((D4\overline {D5})+D6))\) for the Trojan-free circuit. We reprogram the LUT 221 with malicious truth table given by expression ((D6 + D4)(D6 + D5)D3), where D4 is the input of LUT driven by N2 (Trojan trigger). This way C17 will function correctly when the Trojan is not triggered (N2 is 0) and will deliver the Trojan payload when activated (N2 is 1). The required expression is found by converting the logical equivalence of Trojan with normal operation and minimizing it to the conjunctive normal form.
4.4 Case 3: Trojans in the Mapped/PAR Netlist
Inserting Trojans in mapped/PAR netlist follows the same procedure as inserting Trojans in the post-synthesized netlist. After the Trojan insertion, the XDL file is converted back to NCD (the CAD tool may rerun the “place and route” step), and the bitstream file is generated. After the Trojan is inserted at this level, the consequent step is generating the programmable bitstream file. Inserting Trojans in a fully mapped or routed design requires significant effort. The effort can be alleviated by designing scripts to insert Trojans and verify the routing of design. Detecting Trojans at this level is also considerably difficult, and the probability of detection of such Trojans is low.
5 Trojan in Bitstream
FPGAs are configured (or programmed) by loading a binary file, called as configuration bitstream or bitfile on the FPGA’s configuration memory from a PC or over the network. The structure of a Xilinx configuration bitstream file is essential to insert the Trojans. The syntax and semantics of this bitfile are usually proprietary, with very less and basic information publicly available about the bitstream organization, e.g., in [38]. However, useful software tools have been designed in the academic community by utilizing this relatively scarce information, primarily to achieve greater control over the configuration process [23].
5.1 Xilinx Bitstream Structure
The description about the configuration bitstream is proposed in [10, 38] and [23] and focuses on Virtex-II FPGAs. It is described below.
Xilinx Virtex-II FPGA building blocks.
In Virtex-II FPGAs, CLBs are the basic building blocks. They are typically organized in rows and columns and occupy the majority of the FPGA silicon area. A CLB consists of four slices, with each slice containing two flip-flops (FFs), two four-input LUTs used to implement logic functions, and multiplexers to connect and route the logic resources internally. Each CLB is connected to the RSM which provides paths to interconnect multiple CLBs in the FPGA. Block BRAM (BRAM) are used as memories. The input/output logic for each pin on the FPGA device is present in the input/output blocks (IOBs). These resources are represented using dedicated and separate columns in the bitstream.
Xilinx configuration bitstream file organization.
The Xilinx Virtex-II configuration bitstream is stored in a configuration memory and is arranged in frames that are 1 bit wide and stretches from the top edge of the device to the bottom edge, as shown in Fig. 14.15. All operations must act over complete configuration frames as they are the smallest addressable segments of the configuration memory space. Single piece of hardware is not directly mapped by configuration memory frames, but, they configure a vertical slice of many physical resources [38]. The size of the frame depends on the device family such as Virtex-II and specific FPGA device (XC2V40) of interest for which the configuration file is being generated. The relation between the number of configuration bits and frame count is given by:
Apart from the configuration bits in the frames, the bitfile also contains other auxiliary information that includes the header of ASCII-encoded name of the top-level module of the design, cyclic redundancy check (CRC) words, device family, and timestamp. It also consists of a long trailing series of zeros at the end of the files that signify no operation. Each configuration frame has a unique 32-bit address that consists of a block address, a major and minor address, and a byte number. The major address represents a specific column within a block, and the minor address represents a specific frame within a column.
5.2 Trojans That Modify the Bitstream
Modification of the configuration bitstream to add a hardware Trojan can be performed in two ways:
-
Type-I Trojans. Without any resource or area overlap between inserted Trojan circuitry and the original circuitry on the FPGA. In other words, the part of the bitstream that configures the Trojan circuitry on the FPGA is simply inserted into the existing bitstream file at positions where no resources have been utilized originally, and the unoccupied resources of the FPGA are configured with the extra circuit. In this case, the functionality of the original circuit and the Trojan are independent of each other as there is no interconnection between the original design and the hardware Trojan. This kind of Trojans are called Type-I Trojans.
-
Type-II Trojans. There is an overlap between inserted Trojan circuitry and the original circuitry in terms of the resources occupied on the FPGA. The original circuit and the Trojan circuits are interconnected, and this kind of Trojans is called Type-II Trojans. Here, the Trojan can either extract information from the original circuitry or interfere with its functionality.
Type-I Trojans are easier to insert into the bitstream. However, Type-II Trojans are relatively harder to insert as it requires the detailed knowledge of the correlation between routing of the interconnections in the FPGA fabric with the bitstream. Even for a relatively low-end FPGA model like Virtex-II (device XC2V40), insertion of Type-II Trojan is an extremely complex task in the absence of supporting documentation to provide with some basic information. This has been tackled in [24]. However, the approach taken in [24] derives the design description in XDL, modifies this file, and transforms to bitfile. This approach does not directly operate on the bitfile.
5.3 Example Trojans in Literature
In [10], a software-based bitstream Trojan insertion technique using an unencrypted bitstream is demonstrated. The proposed Trojan attack directly modifies the bitfile to insert Trojans into it. The effectiveness of the attack lies in the fact that at present there is no verification mechanism for the correctness of FPGA bitfile, apart from an inbuilt CRC generating and matching mechanism, which can be disabled. This modification would be extremely difficult to detect before deployment. A major strength of this attack is that there will be no trace of Trojan insertion in the generated log files during FPGA CAD tool design processes, as the Trojan is inserted after these steps are completed.
Researchers have exploited the dynamic reconfiguration capability of modern FPGAs to add extra functionality [20]. Furthermore, many modern high-end FPGA families such as Xilinx Virtex family support bitstream encryption. However, there are many other FPGA families with numerous deployed FPGAs such Xilinx Spartan family FPGAs with no bitstream encryption support. Moreover, it was also recently reported that bitstream encryption, which relied on a Triple DES engine inside the FPGA, was broken using side-channel attacks [22].
Additionally, it has been shown in [33] that it is possible to reverse engineer crypto algorithms, identify cryptographic elements in bitstream, and perform modifications that can weaken the FPGA cryptographic implementations. It has also been demonstrated that by employing such modifications to bitstreams, one can easily extract the secret key from cryptographic algorithms [33].
6 Countermeasures Against FPGA Trojans
Hardware Trojan detection techniques in the literature can be classified into two categories: invasive and noninvasive. Invasive techniques require some modification to the original design to aid in fingerprinting the IC and to verify the authenticity after fabrication. A few examples include ring oscillator-based design-for-trust, IC camouflaging, and logic encryption [26, 27].
FPGAs consist of a massive amount of programmable components, and invasive techniques would require additional gates or hardware for each of these programmable components. Thus, invasive techniques are not feasible for FPGAs as this would lead to exponential silicon area overhead. Moreover, physical reverse engineering techniques can be used to test a small number of ICs, but do not guarantee that the remaining ICs are free from malicious modifications (Fig. 14.16).
Noninvasive techniques, on the other hand, do not modify the original design. Instead, a fingerprint of power, timing delay, and/or other side channels of a golden design, in combination with functional testing, are used. Most of the techniques in this category use statistical analysis to distinguish a malicious chip from a genuine one.
There are only a handful of works that detect hardware Trojans in the FPGA fabric [18, 21, 25] and are described below.
6.1 Hardware Trojan Tolerance Using Modular Redundancy [ 21 ]
A triple modular redundancy (TMR)-based technique is used to create a Trojan-tolerant design methodology in [21, 28, 29]. TMR is a renowned fault mitigation methodology used to mask circuit faults wherein three redundant copies of the original system perform a process, and the result is processed by a majority voting system to produce a single output. Any single fault in one of the redundant modules will not lead to an error at the output as the majority voter selects the result from the two faultless modules. TMR, however, leads to 3 × area and power overhead. To reduce the overhead, adapted TMR (ATMR) is proposed where only two modules are used at a time, and the third module is employed only when there is a mismatch in the results of two active modules and shown in Fig. 14.17. An arbiter is used to identify the erroneous module. The experimental results show a 1.5 × reduction in power by using ATMR with negligible performance and hardware overhead when compared to TMR.
The threat model assumes that the Trojans will not be activated simultaneously in the redundant modules. This assumption may not always be true. To overcome this limitation, the Trojan tolerance scheme is extended to improve the protection by using variants of the redundant modules. The key idea here is that instead of implementing all the redundant modules using the same logic circuit, the redundant modules implement variants of each other in terms of logic structures and storage blocks. This way the same nodes are not available across the redundant modules, and hence, if a Trojan activates across both the modules, then it is assumed to have a different effect on both the modules. The primary requirement is that the variants need to differ in both LUT and interconnect structures while keeping the functional behavior and parametric specifications intact.
To address the limitation of the comparator or arbiter being programmed on a compromised area, the use of majority voting system for comparator and arbiter is suggested. However, this approach has considerable hardware overhead.
Moreover, this technique can be used to identify functional Trojans that effect functionality of the original circuit. It might fail when key-leaking Trojans are present, as they typically do not interfere or change the functionality of original designs.
6.2 FPGA TrustFuzion [ 18 , 25 ]
The FPGA TrustFuzion (FTZ) security mechanism is a nondestructive methodology to detect and isolate anomalies such as Trojans in the FPGA fabric. The authors use the term anomalies to indicate the presence of Trojans and reliability problems in FPGA fabric. Anomalies are detected based on the violation to the spatial correlation of intra-die PV in the FPGA fabric. These anomalies are then isolated such that any designs can run reliably even on a Trojan-infected FPGA chip. FTZ is based on the observation that physical characteristics of FPGA fabric’s intra-die process variation (PV) display a huge amount of spatial correlation [2, 11, 12]. Based on the observation in [2, 12, 40], it is assumed that intra-die variations measured from the devices under test should exhibit a strong spatial correlation, with tiles that are closer exhibiting similar characteristics when configured with the same logic and interconnect resources. An anomaly is said to be detected if the spatial correlation is violated by even a single device or set of devices for FPGA under test. Spatial correlation violation is characterized by large deviation in spatial correlation caused by inconsistent variations among neighboring tiles. Ring oscillators are used to measure PV [18, 25, 39]. Anomalies are detected based on the spatial correlation violations. The device locations with anomalies are isolated and excluded from being used in the designs targeting the FPGA device with anomalies. The FPGA is then divided into different zones accounting for the exclusion of locations with anomalies. These FPGA areas are called TrustFuzion zones.
6.3 Bitstream Trojan Countermeasures
Countermeasures against bitstream Trojans involve:
-
1.
Filling up unused resources of the FPGA with dummy logic. Type-I bitstream Trojans inserts malicious circuits in unused FPGA resources. This can be prevented by filling up all the unused resources with dummy logic. This way, the attack space for the adversary is reduced significantly [10]. However, this would increase the power consumption of the FPGA and adversely affect performance.
-
2.
Grounding unused pins of an FPGA design. Type-II bitstream Trojans can leak secret key through covert channels using unused I/O pins of the FPGA. This can be prevented by grounding the unused pins [10]. However, this does not prevent Trojans that leak key through the pins used in the FPGA design or any other side channels.
-
3.
Built-in self-test. Type-II Trojans that weaken crypto-algorithms can be identified by using an integrated self-test that checks the functionality of the algorithm implemented in FPGA for a fixed key and plaintext [33]. However, integrity value has to be stored within the FPGA bitstream itself and can be identified and modified by an attacker.
-
4.
Dedicated hardware to check CRC status. Type-I Trojan described in [10] can disable the CRC in the bitstream. A custom hardware can be placed between the configuration memory and the FPGA to check for disabling CRC and can be used to prevent the loading of bitstream when CRC is disabled [10].
-
5.
Scrambling and descrambling the bitstream file. The bitstream can be scrambled by software, and a dedicated hardware can be used to descramble prior to loading into FPGA [10]. This would add an additional layer of complexity to an attacker and prevent direct modification of the bitstream. However, the scrambling mechanism has to be kept secret, and this acts a low-cost alternative to encrypting bitstreams in FPGA.
7 Conclusion
In the last decade, the use of FPGAs has increased significantly and even has been employed in various applications including mission critical systems. Hence, studying the threat landscape for FPGA security is critical. This chapter identifies the different FPGA Trojans that can be inserted at various phases of FPGA life cycle. Most research on FPGA security emulates Trojan on FPGA while trusting the FPGA fabric. Trojans can be inserted in even FPGA fabric, similar to any other type of ICs/ASICs. FPGA fabric Trojans that can be inserted by an untrusted foundry and a malicious actor in the supply chain in literature are identified, and the taxonomy is introduced. The bitstream files and the designs in HDL format can also be corrupted with Trojans. This chapter also discussed the countermeasures proposed in the literature. Only a couple of technique exists to verify the physical fabric of FPGA for hardware Trojan. Trojans present in physical FPGA fabric could be detected by accounting for spatially correlated intra-die process variations. The intra-die process variation-based approach can identify anomalies contributing to delay or voltage change by locating inconsistent physical characteristics from the ones in close-by regions. Comprehensive work on malicious modification effects can be done by designing and simulating layout without and with anomalies. This would give a better insight into anomaly characteristics and would potentially aid in indicating the precise type of anomaly inserted into the FPGA fabric. However, many of the design details remain proprietary information and are not available to researchers, thus impeding the research.
Notes
- 1.
Translate and map processes are the terms used by Xilinx, an FPGA vendor. These processes may use different names/terms.
References
S. Adee, The hunt for the kill switch (2008), http://spectrum.ieee.org/semiconductors/design/the-hunt-for-the-kill-switch. Last accessed 13 July 2016
A. Agarwal, D. Blaauw, V. Zolotov, Statistical timing analysis for intra-die process variations with spatial correlations, in IEEE International Conference on Computer Design (2003), pp. 900–907
Amazon, Amazon EC2 F1 instances – run custom FPGAs in the AWS cloud, https://aws.amazon.com/ec2/instance-types/f1/. Last accessed 12 May 2017
A. Amouri, M. Tahoori, High-level aging estimation for FPGA-mapped designs, in IEEE International Conference on Field-Programmable Logic and Applications (2012), pp. 284–291
G.T. Becker, F. Regazzoni, C. Paar, W.P. Burleson, Stealthy dopant-level hardware trojans, in International Workshop on Cryptographic Hardware and Embedded Systems (2013), pp. 197–214
K. Bernstein, D.J. Frank, A.E. Gattiker, W. Haensch, B.L. Ji, S.R. Nassif, E.J. Nowak, D.J. Pearson, N.J. Rohrer, High-performance CMOS variability in the 65-nm regime and beyond. IBM J. Res. Dev. 50, 433–449 (2006)
A. Bravaix, C. Guerin, V. Huard, D. Roy, J. Roux, E. Vincent, Hot-carrier acceleration factors for low power management in DC-AC stressed 40 nm NMOS node at high temperature, in IEEE International Reliability Physics Symposium (2009), pp. 531–548
D. Bryan, The ISCAS85 benchmark circuits and netlist format. North Carolina State University, 25 (1985)
A.N. Campbell, K.A. Peterson, D.M. Fleetwood, J.M. Soden, Effects of focused ion beam irradiation on MOS transistors, in IEEE International Reliability Physics Symposium (1997), pp. 72–81
R.S. Chakraborty, I. Saha, A. Palchaudhuri, G.K. Naik, Hardware Trojan insertion by direct modification of FPGA configuration bitstream, in IEEE Design & Test (2013), pp. 45–54
H. Chang, S.S. Sapatnekar, Statistical timing analysis under spatial correlations, in IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems (2005), pp. 1467–1482
B. Cline, K. Chopra, D. Blaauw, Y. Cao, Analysis and modeling of CD variation for statistical static timing, in IEEE International Conference on Computer Design (2006), pp. 60–66
DARPA, Defense Science Board (DSB) study on high performance microchip supply (2005). http://www.acq.osd.mil/dsb/reports/ADA435563.pdf. Last accessed 13 July 2016
Defense Tech, Proof that military chips from China are infected? (2012). http://www.defensetech.org/2012/05/30/smoking-gun-proof-that-military-chips-from-china-are-infected/. Last accessed 13 July 2016
EETimes, Report: Bogus U.S. military parts traced to China (2011). http://www.eetimes.com/document.asp?doc_id=1125076. Last accessed 13 July 2016
V. Huard, M. Denais, C. Parthasarathy, NBTI degradation: from physical mechanisms to modelling. Microelectron. Reliab. 46, 1–23 (2006)
Intelligence Advanced Research Projects Activity, Trusted integrated circuits program. https://www.fbo.gov/utils/view?id=b8be3d2c5d5babbdffc6975c370247a6. Last accessed 13 July 2016
V. Jyothi, M. Thoonoli, R. Stern, R. Karri, FPGA trust zone: incorporating trust and reliability into FPGA designs, in IEEE International Conference on Computer Design (2016), pp. 600–605
R. Karri, J. Rajendran, K. Rosenfeld, M. Tehranipoor, Trustworthy hardware: identifying and classifying hardware trojans. Computer 43, 39–46 (2010)
P. Lysaght, B. Blodget, J. Mason, J. Young, B. Bridgford, Invited paper: enhanced architectures, design methodologies and CAD tools for dynamic reconfiguration of Xilinx FPGAs, in IEEE International Conference on Field Programmable Logic and Applications (2006), pp. 1–6
S. Mal-Sarkar, A. Krishna, A. Ghosh, S. Bhunia, Hardware trojan attacks in FPGA devices: threat analysis and effective counter measures, in ACM Great Lakes Symposium on VLSI Design (2014), pp. 287–292
A. Moradi, A. Barenghi, T. Kasper, C. Paar, On the vulnerability of FPGA bitstream encryption against power analysis attacks: extracting keys from Xilinx Virtex-II FPGAs, in ACM conference on Computer and Communications Security (2011), pp. 111–124
C.J. Morford, Bitmat-bitstream manipulation tool for Xilinx FPGAs. PhD dissertation, Virginia Tech (2005). https://theses.lib.vt.edu/theses/available/etd-12162005-144728/unrestricted/CMorford_Thesis.pdf. Last accessed 22 May 2017
J.-B. Note, É. Rannaud, From the bitstream to the netlist, in International ACM/SIGDA Symposium on Field Programmable Gate Arrays (2008), vol. 8, pp. 264–264
Y. Pino, V. Jyothi, M. French, Intra-die process variation aware anomaly detection in FPGAs, in IEEE International Test Conference (2014), pp. 1–6
J. Rajendran, V. Jyothi, O. Sinanoglu, R. Karri, Design and analysis of ring oscillator based design-for-trust technique, in IEEE VLSI Test Symposium (2011), pp. 105–110
J. Rajendran, Y. Pino, O. Sinanoglu, R. Karri, Logic encryption: a fault analysis perspective, in Design, Automation Test in Europe Conference Exhibition (2012), pp. 953–958
J. Rajendran, H. Zhang, O. Sinanoglu, R. Karri, High-level synthesis for security and trust, in IEEE International On-Line Testing Symposium (2013), pp. 232–233
J. Rajendran, O. Sinanoglu, R. Karri, Building trustworthy systems using untrusted components: a high-level synthesis approach. IEEE Trans. Very Large Scale Integr. Syst. 24(9), 2946–2959 (2016)
SEMI, Innovation is at risk as semiconductor equipment and materials industry loses up to $4 billion annually due to IP infringement (2008). www.semi.org/en/Press/P043775. Last accessed 13 July 2015
Y. Shiyanovskii, F. Wolff, A. Rajendran, C. Papachristou, D. Weyer, W. Clay, Process reliability based Trojans through NBTI and HCI effects, in NASA/ESA Conference on Adaptive Hardware and Systems (2010), pp. 215–222
S.P. Skorobogatov, R.J. Anderson, Optical fault induction attacks, in International Workshop on Cryptographic Hardware and Embedded Systems (2002), pp. 2–12
P. Swierczynski, M. Fyrbiak, P. Koppe, C. Paar, FPGA Trojans through detecting and weakening of cryptographic primitives. IEEE Trans. Comput. Aided Des. Integr. Circuits Syst. 34, 1236–1249 (2015)
M. Tehranipoor, F. Koushanfar, A survey of hardware Trojan taxonomy and detection. IEEE Des. Test Comput. 27, 10–25 (2010)
R. Torrance, D. James, The state-of-the-art in semiconductor reverse engineering, in IEEE/ACM Design Automation Conference (2011), pp. 333–338
Transparency Market Research, FPGA market – Global industry analysis, size, share, growth, trends and forecast, 2014–2020. http://www.transparencymarketresearch.com/field-programmable-gate-array.html. Last accessed 22 May 2017
USPTO, Piracy of intellectual property (2005). http://www.uspto.gov/about-us/news-updates/piracy-intellectual-property. Last accessed 13 July 2016
Xilinx, Virtex-II platform FPGA user guide (v 2.2). www.xilinx.com/support/documentation/user_guides/ug002.pdf. Last accessed 22 May 2017
X. Zhang, M. Tehranipoor, RON: an on-chip ring oscillator network for hardware Trojan detection, in IEEE Design, Automation Test in Europe Conference Exhibition (2011), pp. 1–6
W. Zhang, K. Balakrishnan, X. Li, D.S. Boning, S. Saxena, A. Strojwas, R. Rutenbar, Efficient spatial pattern analysis for variation decomposition via robust sparse regression. IEEE Trans. Comput. Aided Des. Integr. Circuits Syst. 32, 1072–1085 (2013)
Author information
Authors and Affiliations
Corresponding author
Editor information
Editors and Affiliations
Rights and permissions
Copyright information
© 2018 Springer International Publishing AG
About this chapter
Cite this chapter
Jyothi, V., Rajendran, J.(. (2018). Hardware Trojan Attacks in FPGA and Protection Approaches. In: Bhunia, S., Tehranipoor, M. (eds) The Hardware Trojan War. Springer, Cham. https://doi.org/10.1007/978-3-319-68511-3_14
Download citation
DOI: https://doi.org/10.1007/978-3-319-68511-3_14
Published:
Publisher Name: Springer, Cham
Print ISBN: 978-3-319-68510-6
Online ISBN: 978-3-319-68511-3
eBook Packages: EngineeringEngineering (R0)