A Survey on FPGA Cybersecurity Design Strategies

When attempting to define the attack surface of a device, a diagram identifying the layout of critical sub-components is useful. Figures 3(a) and 3(b) show such diagrams for the Zynq-7000 and the Stratix 10 SoC FPGA devices, respectively. These layout diagrams note the various interactions and interconnect between individual sub-components.

Figure 3 highlights the function of the sub-components of each device as either a memory device or controller, playing a significant role in the boot process, part of the debug infrastructure, a bus, I/O, or bus controller, as containing important configuration registers, or as related to the security of the SoC FPGA.

The first distinctive difference between the two showcased SoC FPGA devices is their booting sequence. The Zynq-7000’s initial boot sequence is wholly managed within the hard processing system (HPS), whereas the Stratix 10 features a dedicated microcontroller unit within the secure device manager (SDM) to serve this purpose. A second distinctive difference is the pathways that lead up to each FPGA’s configuration memory. In the case of the Zynq-7000, the configuration memory may be reached either by the application processing unit going through the device controller or directly via the JTAG interface. These paths lead through the FPGA configuration module, a state machine that manages FPGA configurations. Turning our attention to the Stratix 10, we find that all external interactions with the configuration memory are managed directly via the SDM.

Both the Zynq-7000 and the Stratix 10 feature ARM cores within their HPS. These cores have standard ARM infrastructure, including on-chip memory, access to NVM, ethernet interfaces, synchronous dynamic random access memory (SDRAM), and their debug access port. Furthermore, both the SoC FPGA devices incorporate the ARM TrustZone technology [7, 62]. The ARM TrustZone technology allows resources within the FPGA fabric to be divided into two worlds: secure and non-secure. This feature is important for isolating safety-critical components and functions.

Next, data flow diagrams can help outline the life cycle of assets. Figure 4 shows a data flow diagram from the development stage of SoC FPGA assets to the execution of an OS.

In drawing the data flow diagram, we assumed three basic security features were in place. First, we assumed assets were encrypted after development. The Intel Stratix 10 and the AMD-Xilinx Zynq-7000 use the advanced encryption standard (AES)-256 for this purpose. The Stratix 10 uses AES counter mode, whereas the Zynq-7000 uses the AES cypher block chaining mode. In both cases, we can store the secret keys for both devices within eFuses or battery-backed random access memory (BBRAM) [86, 129]. Second, we assumed authentication was in place for all assets before execution. Both the Intel Stratix 10 and the AMD-Xilinx Zynq-7000 allow for authentication. The Stratix-10 authenticates with an elliptic curve digital signature algorithm (ECDSA) via a secure hash algorithm (SHA)-256 or SHA-384 hash of the ECDSA public key stored within either eFuses or BBRAM [55]. The Zynq-7000, however, allows for Rivest, Shamir, and Adleman RSA authentication via a SHA-256 hash of the RSA-2048 public key and a subsequent secondary authentication via keyed-hash message authentication code (HMAC) [128]. HMAC is a message authentication code using a cryptographic hash function and a secret key. This secret HMAC key is stored within the encrypted boot files. The SHA-256 hash of the public key used for RSA authentication is stored within HPS eFuses. The final basic security feature involves debugging port disabling. The Stratix 10 and the Zynq-7000 allow developers to permanently disable the Joint Test Action Group (JTAG) interface used for programming and debugging via eFuse.

The following paragraphs will highlight each stage identified in Figure 4:

The attack surface of common SoC FPGA assets has now been identified for its asset’s life cycle from development to integration. The next logical step would be to define the attack surface during in-system execution. However, a valuable aspect of SoC FPGA devices is their ability to be adapted to many interfaces and protocols based on their application. For example, within the HPS domain, the Zynq-7000 and the Stratix 10 feature dozens of HPS memory controllers, system modules, and interface peripherals ready to be implemented within any design. Furthermore, developers can implement countless interfaces within the FPGA domain, ranging from a customized ethernet interface to a simple universal asynchronous receiver transmitter controller. Understanding this, a data flow diagram for in-system execution will be design dependent and include all active interfaces within a said design.

With AMD-Xilinx being one of the pioneers in the FPGA domain, we find that early research works aimed at reverse engineering bitstreams began here. In the early days, these were mainly focused on understanding the FPGA’s internal structure to implement partial reconfiguration [40, 50, 82, 148, 173]. One of the first publications to analyze a bitstream from a cybersecurity perspective was presented by Ziener et al. [179], who sought to find a way of identifying unlicensed proprietary cores within an FPGA from its bitstream. This work looked at the Virtex-II platform, whose user guide [6], much like previous AMD-Xilinx platforms, revealed a fair level of valuable details into the Virtex-II’s logic cell structure and bitstream. This work successfully identified which packets within the bitstream represented lookup table content and used this content to identify specific unlicensed cores with high certainty.

Following these early attempts, Note and Rannaud [121] introduced the first publication to present a coherent algorithm to reverse engineer the bitstream back into its netlist. They made use of the now replaced AMD-Xilinx tool, ncd2xdl, which would translate the netlist circuit description file into a clear-text representation of the netlist, an AMD-Xilinx design language (XDL) file. The XDL file provided detailed information on the FPGA’s internal state to identify configurable logic blocks and programmable interconnect points. With knowledge of the configurable logic blocks and programmable interconnect points present in a particular design from the XDL file and by the recurring structure of the FPGA, Note and Rannaud could relate an active site within the XDL file to its corresponding site within the bitstream. Using this established relationship, they created a program that automated the process of associating a particular portion of a bitstream to its corresponding XDL format. The next step performed by Note and Rannaud remains the basis of even the most recent bitstream reverse engineering tools: the creation of a database that holds a collection of associations between the location of bits within the bitstream and its corresponding netlist information. Using this database, one could step backward and retrieve critical portions of a plaintext bitstream in its XDL format. Although Note and Rannaud’s work proved to be a significant advancement for the reverse engineering of the AMD-Xilinx bitstream, a considerable amount of information was still missing. With the intent of tackling this deficiency, Benz et al. [20] looked at AMD-Xilinx’s netlist circit description report file (XDLRC). AMD-Xilinx uses the XDLRC file to describe the structure and resources of its various FPGA platforms. This improvement allowed Benz et al. to fully retrieve the FPGA architecture from the bitstream.

At the time of writing, a collaborative project by the name of F4PGA is attempting to create a universal open-source computer-aided design platform for FPGA development [116]. The project currently targets FPGA devices from two manufacturers: Lattice Semiconductor and AMD-Xilinx. However, the project aims at creating a platform to develop a much wider variety of FPGA architectures. Within F4PGA, at its lowest level, the logic hardware is described in a generic FPGA assembly (FASM) format devised for the project. F4PGA then has sub-projects to handle the transition from FASM to bitstreams from various FPGA manufacturers. These sub-projects gather the results from multiple individual bitstream generation runs to create device-specific databases. For AMD-Xilinx devices, this F4PGA sub-project goes by the name Project X-Ray [152]. Project X-Ray has successfully mapped out Artix-7 devices and is working on the remainder of AMD-Xilinx 7-series FPGAs. These same databases created for F4PGA bitstream generation can also convert a bitstream into the FASM format. From the FASM format, one can derive which features are enabled by the target bitstream [153].

Bitstreams for devices from Lattice Semiconductor and Microsemi have also been reverse engineered recently. For Lattice Semiconductor, project Trellis [130] and project IceStorm [30] have successfully reverse engineered the bitstreams of the ECP5 and iCE40 devices, respectively. In the case of Microsemi, its ProASIC3, IGLOO2, and FUSION devices were successfully reverse engineered in 2021 by Kim et al. [71].

Recently, Chen and Liu [27] showed how to recover function blocks from bitstreams using deep learning. They achieved this through a deep learning based object detection algorithm by first transforming the bitstreams of FPGA designs into images suitable for deep learning processing.

Turning our attention to practical examples of SCAs on FPGA devices, we find that one of the first such attack on an FPGA was attempted by Moradi et al. [109] in 2011. In this attack, they broke the AMD-Xilinx Virtex–II DES encryption by analyzing its power supply through differential power analysis techniques. Moradi et al. also performed similar attacks on AES encryption using CPA [110, 111] in 2012 and in 2013. In their 2013 attack, Moradi et al. targeted the Altera (Intel) Stratix II FPGA via its power supply. Using a digital oscilloscope and a custom programmer based on an ATmega256, they successfully retrieved the full AES-128 key in less than 3 hours.

As for other SCA mediums, Moradi and Schneider [112] also successfully mounted EM-based SCAs on AMD-Xilinx FPGA devices. Using a process similar to their previous CPA attack but replacing power readings with EM readings, they broke the AES-256 bitstream encryption of the 5, 6, and 7 series AMD-Xilinx FPGA devices. Comparing their attacks using EM and power side channels, they found that the positional accuracy due to the EM probe drove up the required number of traces. This trend was more significant as technology shrunk from 65 nm with the 5 series to 28 nm with the 7 series. Nevertheless, the non-intrusive approach to EM-based SCA remained a distinct advantage since it only requires one to place the EM probe close to the TOE. A related work by Iyer and Yilmaz [63] in 2019 proposes an adaptive acquisition protocol to help identify the optimal EM capture configuration. The protocol, tested on the AMD-Xilinx Artix-7 FPGA, was found to reduce the required acquisition time by a factor of close to 35.

Finally, recent SCA methods have turned to AI for significant improvements in the number of measurements required. This approach was presented by Ramezanpour et al. [134] in 2020, where they successfully extracted the key from an AES algorithm implemented within the fabric of an Artix-7 FPGA with less than 3,700 measurements. Their approach used unsupervised learning to extract the information required for the leakage model, thus allowing the attack to occur without any prior knowledge of the device. In another approach, Wang and Dubrova [164] demonstrate how deep learning using a single neural network classifier can recover the key from an AES algorithm implemented within an Artix-7. Their results showed they could recover the secret key with less than 430 measurements.

Although all previously stated attacks require physical access to the TOE, the emerging trend of integrating FPGA devices within cloud computing instances is raising new opportunities for attackers. Particularly, placing multiple tenants on a single device to share reconfigurable resources raises concerns over the leakage of sensitive information between isolated portions of the reconfigurable fabric through their power distribution network. With these applications in mind, recent works have shown that SCA techniques can be applied remotely [48, 133, 140, 177]. For instance, Gravellier et al. [48] made use of an AMD-Xilinx Zynq-7000 to show that they could infer the encryption key of both an AES instance running on a CPU and from a hardware implementation of the algorithm based in the fabric. Such capabilities could easily result in loss of confidentiality for unsuspecting cloud users.

Turning to other applications of SCAs, we find Wei et al. [166], who performed a power SCA to recover the pixel value of a CNN’s input image. Their attack on the AMD-Xilinx Spartan-6 FPGA successfully recovered an image being processed in a classification task. In addition, Yu et al. [170] performed an EM-based SCA to retrieve the weight values of a binarized neural network. Using the AMD-Xilinx Zynq-7000 SoC FPGA, they showed that they could accurately recover the underlying model characteristics and develop a substitute model from these values.

Yu et al. [171] in 2020 demonstrated how SCAs could further be used to classify the sequence of 1’s and 0’s from an FPGA’s physically unclonable function (PUF). Using an AMD-Xilinx Artix-7 FPGA as their target, they combined voltage-based SCA with deep learning to show that they could overcome PUF-based key provisioning and remote attestation measures.

Another application of SCAs comes with true random number generators (TRNGs). The aim of SCAs applied to TRNGs is usually to determine the frequency of TRNGs implemented with ring oscillators (ROs). Knowledge of this frequency can then be used to mount other attacks, such as FI attacks on the TRNG’s output. One such approach using an EM-based SCA was presented by Bayon et al. [16] in 2013. Their attack revealed they could deduce the RO TRNG’s frequency with high accuracy. Building on the work of Bayon et al., Yu et al. [172] in 2021 combined voltage-based SCA, deep learning, and a bitstream modification attack to extract the TRNG’s output. Demonstrated on an AMD-Xilinx Artix-7 FPGA device, their attack resulted in a near-perfect accuracy.

Among the works conducted on FI, some researchers have sought to characterize the behavior of a given target due to FIs. Such characterizations were conducted for electromagnetic fault injections (EMFIs) by Zussa et al. [180] in 2014, again for EMFIs by Paquette et al. [126] in 2021, for voltage FI by O’Flynn [122] in 2016, and for laser FI by Selmke et al. [143] again in 2016.

Other researchers have sought to execute specific attacks on FPGA devices. Most of these attacks demonstrated in the literature have sought to show the vulnerability of AES implementations on cryptographic modules within the FPGA [2, 22, 24, 33, 98, 124, 132, 143, 168, 181, 182]. For instance, in 2016, Selmke et al. [143] performed a laser FI on an AES core implemented within the AMD-Xilinx Spartan-6 FPGA device. Although the implementation featured a redundancy circuit, they could inject the same fault twice with a two-laser setup and thus induce exploitable faults into the circuit.

In 2016, Timmers and Spruyt [161] demonstrated an attack highly relevant to the discussion on SoC FPGA. Although this attack focuses explicitly on an ARM CPU, it also introduces the SoC FPGA attack vector. Their attack demonstrated that they could use a voltage fault attack to skip instructions processed by the ARM CPU on the Zynq-7000. Such capabilities raise important concerns for bitstream security. Suppose an attacker can gain control of the CPUs by skipping the authentication check. Access to the FPCA configuration module might be possible via the device controller module even though security features such as encryption and debug port disabling are in place.

Researchers have also shown that they can launch FI attacks from hardware Trojans inserted within the fabric or from neighboring circuits in multi-tenant cloud computing platforms. This example was presented by Gnad et al. [47] in 2017, where they showed that an RO could be used as a form of voltage-based FI mechanism. They found that the spontaneous current draws exerted by frequently activating the ROs would affect the device’s normal operation. In their experiments, Gnad et al. validated the effects of such voltage-based FIs on the AMD-Xilinx Virtex 7, Kintext 7, and Zynq 7020 FPGA devices. In all three FPGA devices, the FI-induced errors ranged from complete system resets to minor malfunctions. Expanding on the works of Gnad et al., Krautter et al. [78] in 2018 formalized the hardware Trojan voltage-based FI attack as the FPGAhammer. Using FPGAhammer, they carried out a DFA on an AES implementation within the Intel Cyclone V SoC FPGA. Their attempt showed they could successfully inject timing faults via the RO-induced voltage drops. Their results showed that using approximately 35% to 45% of FPGA LUTs, they could recover 90% of the secret AES key.

Another remote FI technique was introduced by Alam et al. [4] in 2019. In their attacks, Alam et al. showed that dual-port RAMs in FPGA devices would allow for concurrent writes, which can result in memory collisions when opposing values are written to the same address simultaneously. These collisions cause transient shorts that can be exploited to increase the temperature of the FPGA. These temperature increases can induce timing violations and thus bit-flips in the FPGA device’s configuration memory.

In 2015, Tajik et al. [156] demonstrated laser FIs on PUFs. In their experiment, the laser FIs were used to bypass specific countermeasures placed on PUFs to secure them against machine learning based attacks. In a second attack, they also showed how they could stop the ROs in a RO PUF, thus reducing the entropy of the numbers generated.

Other researchers, such as Bayon et al. [17] in 2012 and Martin et al. [95] in 2015, have evaluated the impact of FIs on TRNGs implemented within FPGA devices. One of the latest such attacks was demonstrated by Madau et al. [90] in 2018. Using EMFI, they demonstrated how an EM pulse could affect the output of a TRNG implemented within an AMD-Xilinx Spartan-6 FPGA.

FI attacks are also possible on neural networks implemented within FPGA devices [83, 88, 178]. The most recent of these attacks, by Luo et al. [88] in 2021, used an AMD-Xilinx Zynq-7000 SoC FPGA to demonstrate how power glitching triggered through a specialized oscillating circuit was able to inject faults into a DNN on a neighboring portion of the fabric.

Electrical probing attacks are typically invasive, requiring attackers to physically decompose their target layer by layer to reverse engineer the electrical pathways within the chip [158]. This reverse engineering step will generally require the use of an optical microscope or a more expensive scanning electron microscope [145]. Once the target pathways are identified, we can use tools such as a focused ion beam system or a laser cutter to etch a hole and deposit the conducting material required for electrical probing.

Although FPGA and SoC FPGA devices are not immune to electrical probing attacks, examples of electrical probing attacks on FPGA are not prevalent in the literature. To provide a practical example, however, we consider an attack demonstrated by Skorobogatov [146] in 2017. As his TOE, Skorobogatov targeted an 8-bit smartcard CPU core built with a 0.35- \(\mu\) m complementary metal-oxide-semiconductor process with three metal layers. Using a similar approach to what is described earlier, he extracted the entire memory space of the device successfully.

Optical probing can be somewhat less invasive than electrical probing. In optical probing, one can also take advantage of the backside of the chip to access critical signals hidden deep within the chip. This approach is efficient on flip-chip packages, where the backside is readily accessible. In most cases, however, some chip decapsulation is still necessary to ensure the light can penetrate the target area.

As an example of optical probing on FPGA devices, we find Tajik et al. [157], who in 2017 successfully mounted an entirely non-invasive attack on the AMD-Xilinx Kintex-7 FPGA. This particular chip is available as a flip-chip package and thus provides direct access to the silicon substrate from its backside. Building on the previous work of Lorhke et al. [84] in 2016, without any modification to the device under test, by using a light source with a wavelength invisible to silicone, they could see through the Kintex’s die. They were able to find and precisely map each bit of the bitstream as they exited the decryption engine. Using an internal clock of 33 MHz, they estimated a total acquisition time of 43 minutes for the whole bitstream. Furthermore, they estimated that the lab work required to complete the attack ranges from a few hours to a few days. As a further example of an optical probing attack, in 2018, using the same techniques as Tajik et al., Lohrke et al. [85] showed how optical probing could extract the full 256-bit AES key directly from the Zynq Ultrascale’s BBRAM.

One of the latest optical probing attempts on FPGA was demonstrated by Krachenfels et al. [76] in 2019. They showed that it is possible to perform an attack similar to those presented by Tajik et al. and Lohrke et al. with a lower-cost laser FI setup. However, here, they noted a longer acquisition time.

Although the optical probing attack demonstrated by Tajik et al. exposes the vulnerability of flip-chip packages, we should note that most probing attacks will require some decapsulation effort in addition to the lengthy reverse engineering process. Furthermore, although Skorobogatov could quickly identify the data bus lines on the top metal layer, most secure chips will likely keep critical pathways deep within the sub-layers.

Looking at the literature, we find several works demonstrating potential hardware Trojan implementations. Among these implementations, we find one proposed by Chakraborty et al. [25] in 2013, where ROs are inserted into a design to reduce the device’s lifetime; Ahmed et al. [3] in 2021 presented a Trojan that leaks out a target’s AES key as it is being processed within an FPGA; and Ye et al. [169] in 2018 introduced a Trojan that can control the image classification process of a CNN implemented within an FPGA.

Other works, including Swierczynski et al. in 2015 [151] and in 2018 [150], and Ngo et al. [117] and Moraitis and Dubrova [113] in 2020, have investigated how adversaries could directly manipulate the bitstreams of cryptographic implementations in an effort to weaken them and thus make key recovery possible. Their results for differing cryptographic algorithms show that direct bitstream manipulation can weaken cryptographic implementations without any reverse engineering requirement.

Some researchers have examined how Trojans could impact the ARM TrustZone technology found within many SoC FPGA devices [18, 49]. For instance, Benhani et al. [19] used the AMD-Xilinx Zynq-7000 SoC FPGA device to show that malicious modifications to the FPGA design could jeopardize isolation and segmentation put in place via TrustZone.

Several points along the bitstream development chain have been identified as vulnerable to Trojan insertion techniques in the literature. Among the proposed approaches, we find Zhang et al. [176], who suggested in 2019 that one could insert Trojans through a malicious FPGA design suite. Another approach proposed by Ahmed et al. [3] in 2021 introduced a Trojan during the place-and-route step of bitstream generation. In their respective techniques, they could bypass all design check rules, thus ensuring that their Trojan remained undetected until their activation in the FPGA fabric.

We find an example of a covert channel demonstrated on an FPGA device by Iakymchuk et al. [57] in 2011. They showed how two electrically isolated circuits on a single FPGA could communicate via a thermal-based covert channel. They established their covert channel with the use of specially designed ROs. They used a set of 20 ROs within the transmitter circuit to generate heat. A counter connected to a single RO within the receiver would detect any changes in the RO’s frequency induced by variations in the die’s temperature. Iakymchuk et al. showed how they could use this setup to transfer the secret key from an AES implementation to an unsecured portion of the FPGA at a rate of 0.5 bits per second. At this transmission rate, an error rate of 5% to 13% was observed. Other similar thermal-based covert channels have also been presented by Masti et al. [96] in 2015, by Bartolini et al. [15] in 2016, and by Tian and Szefer [159] in 2019.

In 2018, Nguyen [118] published a thesis where he introduced a voltage-based covert channel. This covert channel showed many similarities to the previously introduced thermal covert channels; however, whereas previous covert channels hid information in timing variations, he hid information in the voltage’s amplitude. In 2019, improving on the work of Nguyen, Gnad et al. [46] presented a second voltage-based covert channel that introduced modulation into the system. They showed that by using less than 3% or 5% of the surface area of the AMD-Xilinx Kintex-7, they could transfer up to 8 Mbits per second via this covert channel while maintaining an error rate of 0.003%.

We also presented several vulnerabilities of the Zynq-7000 and Stratix 10 in Section 4.2 [103, 104, 105, 107, 108]. From two of these vulnerabilities, CVE-2021-27208 [105] and CVE-2021-44850 [107], a severe exploit is possible on the Zynq-7000. Using these specific vulnerabilities, Schretlen [137], demonstrates specific exploits that can result in arbitrary code execution on the CPU.

Another logical attack was demonstrated on an AMD-Xilinx 7-series FPGA by Ender [42] in 2020. Ender introduced several weaknesses of AMD-Xilinx 7-series FPGA, which, when put together, can allow for a previously encrypted bitstream to be read out 32 bits at a time in its plaintext form.

A more elaborate scheme by Jacob et al. [64] in 2017 showed that a hardware Trojan inserted into the bitstream of a Zynq-7000 FPGA could perform data modifications within the system’s external SDRAM. In their proof of concept attack, Jacob et al. decoyed a Trojan within a hardware module that resembled a cryptographic accelerator. They used this hardware Trojan to exploit a vulnerability in the secure boot process of the AMD-Xilinx Zynq-7000 that necessarily forced the device to execute a malicious kernel. After loading the U-Boot into SDRAM, they demonstrated that they could instruct the device to load a non-encrypted malicious kernel by modifying a few lines of this U-Boot’s image. Furthermore, the device required no partition authentication before executing this malicious kernel.

When it comes to securing bitstreams against reverse engineering, the first line of defense should be bitstream encryption. As such, efforts to improve cryptographic implementations within FPGA devices should be the main priority; however, in cases where bitstream encryption is not practical or where the device of interest has known vulnerabilities that affect its cryptographic implementation, one should seek techniques for bitstream obfuscations.

Hoque et al. [54] proposed one such bitstream obfuscation method in 2019. Their method uses unused LUTs to obfuscate critical and non-critical areas of the FPGA design to render their functions and structural properties indiscernible. Furthermore, Hoque et al. also implement redundancies to prevent attackers from attempting to uncover the system’s functionalities via targeted, rule-based, and random tampering.

The logical way to secure devices against SCAs is to reduce side-channel leakage. This reduction will generally take on two different forms: hiding and masking.

Hiding seeks to normalize channel information that attackers could use to recover secret information. For instance, in the case of timing attacks where execution time or other temporal references are used to extract secret information, controls will usually seek to remove the dependence on time by making all operations equally long [115]. When it comes to voltage-based SCA, Le Masle et al. [81] propose a countermeasure that monitors power consumption to keep the latter constant.

However, masking seeks to obscure intermediate values by injecting randomness via TRNGs to remove the dependence of side-channel leakage on the secret information we wish to protect [29, 38]. Although this method has been mainly applied to protect secret keys in cryptographic implementations, a recent work by Dubey et al. [38] in 2020 demonstrates how one can use masking to protect weight distribution in neural networks.

A uniquely FPGA-related countermeasure to SCA involves using partial reconfiguration to randomize lookup tables within the FPGA fabric. This approach was presented by Sasdrich et al. [139] in 2015, where they updated a new random S-Box configuration for every encryption sequence. Furthermore, noting the impact of placement and routing on side-channel leakage, other preventive countermeasures pay special attention to the placement of critical modules and the length of wires being routed [87, 89, 141].

Last, we also find other researchers who have focused on the development of tools and frameworks to evaluate side-channel emissions [41, 45, 67, 69, 70, 123].

Moving on to FI attacks, the most common approach to secure against these attacks involves passive solutions such as redundancies and active solutions such as glitch detectors.

Redundancy is a clear way to prevent faults and can be implemented in several ways. First, a popular approach employs triple modular redundancy designs. These solutions have been studied extensively and implemented in most recent FPGA devices to secure sensitive pathways such as debug access circuits [8]. Another approach involves redundant algorithms, especially in cryptographic implementations [35, 93]. Similar to what was described for SCA, we also find applications for partial reconfiguration as countermeasures for FI attacks. This approach was presented by Mentens et al. [99] in 2008, where the location of the cryptographic engine is randomized to hinder FI attacks. Regarding SoC FPGA, software redundancies should also be implemented for critical security functions such as authentication [161]. Bypassing a single check is hard, but bypassing two checks is much less likely.

Active controls seek to detect the effects of FIs within the FPGA. Such solutions were proposed by He et al. in 2016 [51, 52], and in 2017 [53]. He et al. proposed high-frequency RO watchdogs to detect laser FIs within the FPGA fabric. Similarly, Shen et al. [144] in 2019 used a delay sensing circuit within the FPGA for detection. Upon detection, they tried several response mechanisms that sought to delay the rising edge of the system’s clock. In this manner, they would mitigate the transient’s effect on the system. Other approaches that specifically attempt to identify and locate malicious tenants in multi-tenant application were proposed by Provelengios et al. [131] in 2019 and Mirzargar et al. [101] in 2020.

Where physical access is possible, an attacker with sufficient means will, in most cases, be able to extract information directly from a device via electrical or optical probing attacks. The best we can do is make it as hard as possible for an attacker to extract valuable information; a few ways of doing this exist.

Tajik et al. [155] propose a countermeasures to their optical probing attack. The countermeasure proposed is a PUF-based security monitor. PUFs rely on the physical characteristics of a given device to generate a unique signature or fingerprint. Tajik et al. propose using an RO PUF whose defining physical characteristics are known. Their experiments showed that attempts at optically probing the internal circuit would impact characteristics of the PUF in a way that could be successfully detected with high probability.

Securing a device against hardware Trojans is mostly about knowing and understanding what composes your design. The best and only foolproof way of securing against hardware Trojans is to control the entire development chain. From this controlled development chain, one can then put authentication and integrity controls in place using secret keys, watermarks, or PUFs to ensure no changes are made to the design. However, this quickly becomes impractical as complexity increases, and there is a need to implement higher levels of abstraction through third-party building blocks. Hence, requirements for Trojan detection become apparent.

Most Trojan detection techniques found in the literature have focused on validating the authenticity of a given design based on defining characteristics. For instance, the work of Söll et al. [154] in 2014 used EM emissions to detect discrepancies between a legitimate design and its FPGA implementation. Similarly, more recent works, such as that of Danesh et al. [32] in 2021, have taken an approach akin to what is used in software security by stepping back into a design through the bitstream reverse engineering. After decomposing their designs, they can use various techniques to identify hidden malicious circuits. Another work of interest by Chithra et al. [28] in 2020 used machine learning to detect Trojans. They showed that they could detect Trojans based on temperature and voltage values obtained from different standard benchmarks of the AES encryption algorithm.

Furthermore, Krachenfels et al. [76] in 2021 proposed using laser-assisted optical probing to awaken dormant Trojans within an FPGA fabric. This technique could help uncover Trojans that have successfully bypassed the EDA’s design check rules.

Other security measures against Trojans include isolation and segmentation to limit the impact of malicious hardware within the FPGA fabric. Taking the attack by Jacob et al. described in Section 5.7.3 as an example, if the HPS had configured ARM’s TrustZone prior to programming the FPGA, then this attack would not have been possible. However, as described in Section 5.5, TrustZone is not infallible. As such, some researchers have begun looking at new techniques for trusted execution environments better adapted to FPGA devices [12, 136, 167]. For instance, Ren et al. [136] proposed a scheme that uses remote attestation to validate hardware accelerators programmed within FPGA devices. They showed how their scheme could validate accelerators deployed on remote cloud infrastructures.