An Overview of FPGA-inspired Obfuscation Techniques

Reverse engineering is extensively demonstrated in the literature, as a method to extract the design and/or technology details of an IC with the help of tools and imaging techniques. It involves a complex process of removing the package of an IC, extracting all the layers, stitching the individual layers, and analyzing the obtained images to recover the netlist of a design [95]. Reverse engineering also provides an opportunity for IP piracy and counterfeiting. Reverse engineering could be exploited with other techniques to extract secret information, i.e., cryptographic keys. Reverse engineering becomes more onerous and time-intensive after fabrication, packaging, or even deployment has occurred, but a skilled adversary can still perform it.

Overproduction occurs when a foundry produces more ICs than necessary or specified. Untrusted foundries may use such practices to sell ICs at lower prices in the grey or black market [59]. This is possible because a foundry typically incurs only a marginal increase in costs when manufacturing additional ICs from the same masks [59], i.e., the design house that owns the IP bears all the design-related NRE costs.

Hardware Trojans are modifications in the form of small and hard-to-detect logic for malicious purposes. Hardware Trojans are utilized to interrupt the service of an IC [49] or to extract secret information [70]. In the context of the layout, the footprint of the Trojan could be very small, which might become invisible to identify and test, especially when there is no reference (golden) design available to cross-verify the functionality. The source of the malicious logic could be a third-party IP, or it could also be mounted during manufacturing. As mentioned earlier, the foundry has complete access to the layout; therefore, it can easily identify potential locations for Trojan insertion [70]. The Trojans/backdoors in third-party IPs may also contain hidden functionalities to expose restricted parts of the design and/or extract some secret information.

As mentioned earlier, the design process usually involves outsourcing third-party IPs (3PIPs). This may result in IP piracy when unlawfully obtained 3PIPs are used in designs. An unauthorized individual inside the foundry has the potential to steal information through reverse engineering or unlawfully sell the IPs without the authorization of the owner.

Counterfeiting refers to the fraudulent creation of ICs that are made to look almost identical to the original ICs. Counterfeit ICs are divided into seven different classes: recycled, remarked, overproduced, out-of-spec/defective, cloned, forged documentation, and tampered (See Figure 3 in [38]). Recycled, remarked, out-of-spec/defective, and forged documentation are post-fabrication issues that appear when the counterfeit ICs deployed in a product are outsourced from non-authorized vendors or duplicate IC sellers. On the contrary, overproducing, cloning, and tampering are fabrication-time issues that could be completely tackled if (and only if) all the stages in Figure 1 were fully executed in a trusted environment.

Recalling again, the design house has to share the layout of the design thus it exposes all the minor details to untrusted foundries. Numerous techniques have been devised to counter these threats effectively. Countermeasure techniques to increase the IC security include Logic Locking [45, 46, 47, 90, 100, 109, 111, 112], Camouflaging [30, 60, 108], Split Manufacturing [69, 74], and reconfigurable-based obfuscation techniques [1, 2, 14, 17, 20, 25, 26, 29, 40, 53, 54, 55, 56, 58, 63, 64, 67, 68, 76, 81, 82, 84, 85, 93, 99, 107]. This process is evolving with time and there is a race to bring a novel technique that is resistant and practical [36]. The aforementioned techniques aim at providing security against threats during IC fabrication. Some techniques also offer degrees of protection for post-fabrication attacks.

Reconfigurable-based techniques typically draw inspiration from field-programmable gate array (FPGA) devices, thus the title of this article. The research line of reconfigurable-based obfuscation is not new, but it has received far less attention than Logic Locking. Regarding the reconfigurable-based obfuscation techniques, one of the most formative works came from Microsoft and Iowa State University authors as described in [17]; the authors appropriately identified that reconfigurable logic could be leveraged as an obfuscation asset. Subsequently, research studies utilized reconfigurable-based obfuscation schemes to protect digital designs. These techniques include a variety of reconfigurable elements, i.e., static random access memory (SRAM)-LUTs [17, 20, 25, 26, 29, 40, 56, 63, 64, 67, 82, 93], NVM-LUTs [14, 53, 54, 55, 58, 99, 107], and other approaches¹ [1, 2, 68, 76, 84].

The Logic Locking concept has existed for over a decade. Initially, Logic Locking techniques received more attention due to their practicality—inserting XOR/XNOR gates in a netlist can be easily scripted. In recent years, a cat-and-mouse game was established between developing and attacking Logic Locking techniques. Thus, Logic Locking has coincided with emerging powerful attacks that have compromised design security [88]. This area of research has progressed rapidly, resulting in dozens of defense techniques and published attack strategies. Logic Locking and reconfigurable-based obfuscation techniques share a common objective of protecting IP against supply-chain attacks.

Recently, reconfigurable-based obfuscation has received more attention due to its high resiliency against attacks. However, this has raised questions about the security versus PPA tradeoffs. As a result, researchers have been proposing solutions where the reconfigurable part is as small as possible [58]. Figure 2 illustrates the conceptual difference between the Logic locking approach, shown on the left, which involves adding key gates to the original design, and the reconfigurable-based obfuscation approach, shown on the right, which leverages reconfigurable logic elements. Logic Locking requires the correct configuration of the secret key, while reconfigurable-based obfuscation techniques rely on loading the correct bitstream. These approaches are somewhat analogous, so attacks from Logic Locking domain can also be applied to reconfigurable solutions.

In Logic Locking, the locking mechanism is embedded in the netlist of the design, so the design is locked behind the secret key. This procedure could subject the design to several attacks, e.g., identifying and removing the lock, tampering with the lock, or identifying the secret key, compromising the secured design. The adversary can access the entire design of the original IP combined with the key gates. On the other hand, a selected portion of the design is hidden in reconfigurable-based obfuscation, meaning that a portion of the design is exposed to the adversary. This technique does not reveal the entire design to the adversary and offers a higher potential for securing ICs against supply-chain attacks.

To implement Logic Locking, the designer makes simple modifications to the netlist and can then utilize the standard CAD design flow. On the other hand, reconfigurable-based obfuscation does not have a CAD tool flow and requires a custom tool to be incorporated into an existing flow, which includes logic synthesis, timing analysis, and optimization of a mixed ASIC and FPGA-like design [67]. The right panel of Figure 2 shows an example of reconfigurable-based obfuscation, such as the eFPGA redaction technique. It employs custom tools that require significant effort to build. Reconfigurable-based obfuscation incurs higher security and overhead costs than Logic Locking, as shown by the arrows pointing to the right in Figure 2. Logic Locking techniques appear to be more mature and more readily available tools.

To ensure efficient usage of reconfigurable elements, it is important to consider the overheads of power, performance, and area (PPA). However, reconfigurable-based obfuscation techniques face various challenges throughout the design, testing, fabrication, and deployment stages. One such challenge is the placement of the SRAM for SRAM-based LUT implementation. Additionally, emerging technologies like spin-transfer torque (STT), spin-orbit torque (SOT), and magnetic-random access memory (MRAM) require specific considerations and capabilities during the fabrication process. These technologies pose operational challenges that can affect PPA overheads. To address these challenges, some designs adopt a TRAnsistor-level Programming (TRAP) fabric, which utilizes a transistor and switch box-based approach for providing obfuscation in the design, as described in [84, 85].

Various reconfigurable-based techniques have the potential to ensure security against almost all hardware security threats. This is evident from the limited number of attacks on reconfigurable-based obfuscation. The attacks on these techniques either explore vulnerabilities or partially break the obfuscated circuit to recover the bitstream of the obfuscated design. Typically, the attacker first identifies the reconfigurable logic inside the obfuscated design for the purpose of the attack [1, 28, 39, 78]. Reconfigurable-based obfuscation attacks can be subject to existing attacks like SAT attacks, brute force attacks, and removal attacks [7, 15, 55, 62, 108].

Overall, this article is the first survey to focus on reconfigurable-based obfuscation techniques that combat security threats. We intend to present a detailed study of obfuscation trends, tradeoffs, and recent attacks. This work provides a comprehensive overview of the reconfigurable-based obfuscation landscape, classifying the techniques based on three important factors: technology used, element type, and IP type. The efficiency of these techniques is evaluated and compared in terms of PPA overheads. We discuss comparing attacks on reconfigurable-based obfuscation and the challenges of evaluating obfuscation on hardware.

The structure of this article is given as follows: Section 2.1 classifies the reconfigurable-based obfuscation techniques and provides in-depth explanations. Section 3 elaborates on the comparison and analysis between numerous reconfigurable-based obfuscation techniques. Then, a comprehensive study of attacks and their evaluation of various obfuscation techniques is given in Section 4. In Section 5, a rich discussion is provided as well as a comparison to Logic Locking. Section 5 also discusses future trends and challenges. Finally, we conclude this article in Section 6.

Over the last few decades, reconfigurable devices such as FPGAs and FPGA-based system on chips (SoCs) have been widely used as stand-alone solutions. Only recently, the ability to reconfigure a design had been considered a form of obfuscation. In Figure 4, we frame the evolution of reconfigurable-based obfuscation era.

As discussed in the previous subsection, the research community has shown a growing interest in implementing obfuscation using reconfigurable logic—we can expect significant progress in this technique due to the apparent robust security guarantees it offers. It is thus important to adopt a unified classification and terminology for the technique. As shown in Figure 8, by carefully analyzing all the proposed techniques, we broadly classify them based on three important factors: (1) Technology used, (2) Element type, and (3) IP type.

Notably, the reconfigurable-based obfuscation techniques using CMOS technology provide an analysis of large designs or benchmarks that highlight an increase in the PPA. However, most of the hybrid technology-based techniques have only been evaluated on small design or ISCAS benchmarks, they exhibit a significant increase in PPA, as seen in references [1, 2, 63, 67]. It is noticeable that some of the overheads are very large. For instance, the authors of [14] used “other” approach and reported a 95.06\(\times\) increase in the area of the C2660 circuit from the ISCAS ’85 benchmark suite using the 32/28 PDK on ASIC. The work in [17] used firm IP to propose LUTs for obfuscation purposes and presented a replacement strategy to secure a netlist. They utilized the Microelectronics Center of North Carolina (MCNC) suite for their experiments but did not specify the technology node. In contrast, a study described in [63] uses an SRAM-LUT structure as configurable logic to replace gates. This involves the incorporation of 2ⁿ-to-1 MUX and 2ⁿ configuration memory cells, which enables the dynamic configuration of the replaced gates. The study evaluated the results using the 45 nm Nangate library, with the LEON2 SPARC processor as a benchmark. Nonetheless, using SRAM for logic obfuscation generally incurs a relatively high area overhead, as shown in Table 1. In [20], the authors employed an eFPGA to redact the design, and they considered the integration of different fabric sizes in PicoSoC using the 45 nm FreePDK library. All three variants present a non-linear percentage increase in PPA with respect to the fabric size. A similar approach is employed in [67], which utilizes a similar technique to other methods but with greater area and power overheads. The authors’ approach was tested on RISC-V and GPS P-code generator, using a 22 nm FinFET commercial library. However, the delay overhead is significant. Considering security vs. area and performance tradeoffs is also important, as discussed in [1]. The authors validated their approach on various designs using 65 nm commercial CMOS technology as a hard IP.

Almost all the techniques aim at redacting the most sensitive part of the design in a modular approach. The flexibility to obfuscate any part of the design, thereby crossing module boundaries, is presented in [1, 2]. The authors almost obfuscated the majority of the gates in the design, approximately 80–90%, which then yields high PPA penalties. Every technique that lies in the category of hybrid technologies could be referred to as a hybrid because it utilizes standard CMOS technology along with one of the STT, MTJ, SOT, or MRAM devices. Table 1 provides an overview of the techniques that belong to these technologies, LUT being used as an element type designed using a hybrid of CMOS and hybrid technologies. A similar strategy could be employed for the combination of both switch box and LUTs as a hybrid technology. To further elaborate, we would like to emphasize a few insights about the hybrid technologies mentioned earlier. In order to realize a STT device, stacked multilayer sandwich structures are typically used. According to Figure 10, there are a number of layers in the structure, including an oxide tunnel barrier, a free magnetic layer, and a pinned magnetic layer. An external magnetic field or a spin-polarized current J_read flowing through the junction can switch the magnetization direction of the free layer from a parallel to an antiparallel state (P to AP). These states, in turn, can represent a logic-1 or a logic-0. However, the most important aspect of the device depicted in 10 is that the MTJ itself does not compete with standard cells for area since it resides between two metal layers.

MTJ integration requires little die area, except for the CMOS circuits and contacts used to connect MTJs to MOS transistors. The MTJs do come with certain operational challenges. Asymmetry in write and read operations results in a difference in operation energy and delay, requiring a higher current for completing write operations. Spin-orbit interaction has recently been explored as an alternative write approach to overcome these bottlenecks, details area available from [22]. The authors in [55] proposed reconfigurable logic and interconnects (RIL)-Blocks that leverage MRAM-based LUTs with MTJ technology and routing-based obfuscation. As illustrated in Figure 11, each cell is accessed via A and B, while the write operation is controlled by \(\overline{WE}\) signals. In each memory cell, the MTJs change complementary to each other during write operations. According to input signals A and B, output nodes O and O direct the appropriate output to the select tree MUX using the RE and RE signals. The RIL-Blocks are built using commercially available STT-MTJ technology to provide the desired obfuscation.

The technique in [99] is the first one to propose hybrid-STT LUTs and its area overhead is pretty small, but the power and delay overheads are around 82%, as shown in Figure 12. The approach given in [107] involves examining the internal gates of each class to identify the gate that can be obfuscated with minimal design overhead and path delay. In this approach, the authors present a cluster of 16, 32, or logic gates which are replaced with 2, 3, and 4-input LUTs. While the area of this technique is comparable to [99], its maximum overhead is nearly equal for groups of 16, 32, and 64. The approach in [58] does not incur any performance overhead and it exhibits almost 90% increase in area. The method given in [25] also validates their technique on small circuits but the area overhead is large even for a very small circuit that executes a sorting algorithm. The PPA overheads in [84, 85] are very small. This approach has the lowest PPA in reconfigurable-based obfuscation with the same remark of validation on small circuits.

Now, we will briefly explore how CMOS technologies can obfuscate circuits. LUT-based obfuscation is the dominant technique used with CMOS technologies. In [55], the authors presented a novel approach to thwart various attacks by utilizing reconfigurable interconnect and logic blocks. The researchers presented their security analysis (SA) without highlighting PPA overheads. The authors in [93] proposed RTL-based partitioning in tandem with eFPGA redaction for better obfuscation. However, the authors in [26, 40, 82] proposed a similar partitioning scheme at the behavioral level, demonstrating an automated partitioning flow for behavioral descriptions for HLS. This technique is associated with high PPA overheads and the explanation of this technique is detailed in Section 2.1. A similar approach was implemented in [67] to obfuscate portions of the RISC-V control path and its overhead is mentioned in Table 1. In [29], the authors presented a LUT-based obfuscation algorithm that optimizes the replacement locations of LUTs and the input signals they receive in order to achieve resiliency against SAT attacks while minimizing overhead. The authors of [64] have proposed a different scheme called LUT-Lock that focuses the effort on a minimal set of primary output pins to increase the obfuscation difficulty. To accomplish this, they decided to focus on fan-in with a few primary outputs for obfuscation and selected gates that are connected to the smallest number of output pins. Additionally, gates that exhibit less control over primary inputs are preferable for obfuscation.

As the research on this type of technique has matured, authors started to consider the tradeoff space between security and PPA. The research in [53] has demonstrated that circuits with a small LUT input size (e.g., 2-input LUT) can be easily de-obfuscated. Their research demonstrates that the input size of LUT is the most influential and straightforward factor in achieving SAT resiliency. Though LUT-based obfuscation provides high-security levels, it results in prohibitive PPA overhead [63]. Recently, another LUT-based research work in [1] presents a security-aware computer-aided design (CAD) flow, which utilizes a combination of MUXs, LUTs, and FFs for obfuscation. It is compatible with the standard cell-based physical synthesis flow. The approach explores a midpoint between pure FPGA and pure ASIC design to generate heavily obfuscated designs that combine static parts with reconfigurable parts, which they then termed a “hybrid ASIC” (hASIC). The results illustrate that better obfuscation could be achieved with slightly high hardware overhead.

Interestingly, the authors in [56] demonstrated a low overhead digital IC design obfuscation flow which is compatible with existing electronic design automation (EDA) tools. They have also fabricated an IC to prove the concept. The proposed method was demonstrated for both non-volatile internal (efuse) and volatile external (SRAM) LUT key configurations to showcase its flexibility. Using the fabricated silicon, the actual design overhead, in terms of area, performance, and power, was measured. The chip was evaluated for various levels of security and showed that the SAT attack could be thwarted in the low obfuscation case with minimal overhead and in the medium obfuscation case with a maximum of 14% overhead, allowing for a significant SAT runtime margin.

Now, we will briefly explore how hybrid technologies can be used to obfuscate circuits. In [54], the authors studied the previously proposed LUT-based obfuscation schemes and proposed a customized STT-LUT-based obfuscation with two different variants: LUT+MUX-based obfuscation, and LUT+LUT-based obfuscation. This combination assists them in elevating security provided by logic obfuscation while concurrently creating SAT-hard instances. But, the work in [58] explored the design space for four crucial design factors that impact the design overhead and security of hybrid STT-LUT-based obfuscation: (1) LUT technology, (2) LUT size, (3) number of LUTs, and (4) replacement strategy. It is concluded in [58] that, among the four studied parameters, the input size of LUT is the most influential and straightforward factor in achieving SAT resiliency. The authors in [57] proposed a multi-layer defense mechanism using a combination of a Symmetrical MRAM-based LUT (SyM-LUT) and STT-MTJ-based LUTas shown in Figure 13. SST structures require a high write current to switch the magnetization direction, SOT structures can achieve the same result with significantly reduced current. This makes them a promising candidate for low-power and high-speed data storage and processing applications. Therefore, the authors in [107] utilized the hybrid SOT-CMOS circuits to realize the reconfigurable logic with a lower write current among LUTs programming operations with smaller hardware overhead as shown in Table 1. To incorporate hybrid technologies into the design flow, additional parameters and processes must be considered. This approach differs from conventional design flows in that it includes additional steps, such as replacing gates and synthesizing the netlist again.

The research community has modified the research aspect of reconfigurable domains by incorporating dynamic morphing to resist SAT attacks. The giant spin hall effect (GSHE) [68] and magneto-electric spin orbit (MESO) [76] concepts enable polymorphism which allows for runtime configuration of Boolean functions. Dynamically changing between states during runtime offers obfuscation, hence neutralizing the threat of an SAT attack. However, randomly morphing from one state to another limits the applicability of the obfuscation to applications like image processing that can tolerate a certain degree of errors [76]. In [25], a variant of an existing architecture called coarse-grained runtime reconfigurable array (CGRRA) is used to selectively map different portions of the design into a reconfigurable block. Different portions of a design, executed at different clock cycles, can therefore be mapped onto the same CGRRA without requiring additional area. The overall hardware overhead of this scheme is mentioned in Table 1. Examples of this architecture include the Stream Transpose Processor from Renesas Electronics [77] and Samsung’s Reconfigurable Processor [50]. Another approach that offers reconfiguration at the transistor level is presented in [84]. The solution exploits “sea-of-transistor” architecture, supporting the implementation of custom cell libraries and facilitating fabric time-sharing. Here, the authors present a partitioning flow for RTL descriptions. As shown in Table 1, the results are promising to note that this solution not only results in an order of magnitude smaller PPA overhead but also increases the complexity of the design [84]. However, this approach presents some drawbacks: it can make testing and simulation more challenging than other solutions, and since the configuration is done at the transistor level, the resulting bitstream size will become extremely large (see Figure 1 of [85]).

Overall, the majority of reconfigurable-based techniques leverage either a reconfigurable element or the eFPGA redaction as depicted in the right panel of Figure 6. The left panel of Figure 6 represents the ASIC that requires obfuscation, while the center panel demonstrates the LUT-based obfuscation approach utilized for obfuscation. The eFPGA-based obfuscation is explained in Section 2.1. In this approach, one of the crucial modules is transformed into reconfigurable logic, and the other modules are converted into standard cells. Additionally, the reconfigurable elements are dispersed throughout the layout, whereas the eFPGA macro is placed in a specific place, resulting in a concentrated reconfigurable logic.

In adversarial modeling, threat models can be classified into oracle-guided and oracle-less. This terminology has been borrowed from the field of Logic Locking [45, 46], and it is equally applicable to attacks on reconfigurable-based obfuscation techniques. An oracle-guided attack involves a reverse-engineered netlist and a functional chip, which is commonly referred to as an oracle. As depicted in Figure 14, oracle-guided attacks typically employ Boolean SAT techniques based on two copies of the locked netlist as part of a miter-like circuit.

Algorithm 1 outlines the SAT attack methodology. A miter-like circuit is created using the locked netlist in the first step of the attack. In order to obtain the IC output \(O_{\text{d}}\), SAT solvers are used to derive a DIP \(I_{\text{d}}\) using the CNF formula of the miter. With the constraint on the diff signal, the miter circuit is formulated as \(L(I,K_{\text{A}}) = L(I,K_{\text{B}})\). In each iteration of the attack, a DIP \(I_{\text{d}}\) is obtained by identifying a satisfying assignment to the miter CNF. The output \(O_{\text{d}}\) of the functional IC is recorded, and the CNF formula is enriched with additional clauses based on the (\(I_{\text{d}}\), \(O_{\text{d}}\)) input-output pair. When UNSAT is returned by the SAT solver, the attack is concluded. The formula \(L(I,K_{\text{A}})\) is solved in the final step of the SAT solver, resulting in the precise key \(K_{\text{C}}\). Repeatedly applying DIPs until the search space has been exhausted allows the attacker to obtain the correct key values.

Oracle-less attacks are techniques that do not require accessing an Oracle or a functional chip. There are many types of oracle-less attacks, most based on structural analysis [6, 7, 24]. Although Oracle-guided attacks, such as the SAT attack, apply to some scenarios, they may not be effective when the search space for the key bits is large.

FPGA-inspired obfuscation techniques, similar to the Logic Locking techniques, aim at protecting IPs against different threats that appear at any phase in the globalized IC supply chain. The attack trend for the reconfigurable-based techniques is illustrated in Figure 7. There is an obvious lack of developed attacks against reconfigurable logic mechanisms—currently, there are a few developed attacks presented in [1, 28, 39, 78]. These will be discussed in the following subsections.

In [28], researchers have demonstrated an oracle-guided attack that replaces the precise logic implemented on eFPGAs with a synthesizable predictive model. This attack leverages machine learning techniques to construct a predictive model that mimics the behavior of the original logic. The adversary is a proficient IC designer with the expertise and tools to understand this layout representation. The threat model of [28] is given below:

The three main steps of a “predictive model attack” are illustrated in Figure 15. In the first phase of the attack, the IC from the market is used to run applications that require the obfuscated hardware accelerator, and inputs and outputs of eFPGA are recorded for generating a predictive model. The latency of the obfuscated design is also recorded to ensure there are no timing issues when replacing the eFPGA portion with a predictive model. This text describes the second phase of the proposed attack, which involves searching for a predictive model that can be mapped in hardware on the eFPGA. The predictive model must fit within the eFPGA fabric, have outputs within the specified error threshold, and operate at the same frequency and latency as the original design. This phase is divided into three steps: model fitting, predictive model refinement, and automated MLP exploration. The output of this phase is a synthesizable C description of the predictive model that operates within the given constraints. The two predictive models considered are linear regression and multi-layer perceptron. The automated MLP explorer optimizes the MLP configuration to fit within the eFPGA and meet the error constraint. The predictive model generated in step 1 is further optimized in step 2 by obtaining the smallest possible model that operates within the specified error threshold.

The third and final step in generating a predictive model for HLS involves finding the smallest possible implementation of the predictive model with a latency equal to that of the exact version extracted in the first phase. This is achieved by setting different synthesis options combinations for the optimized synthesizable predictive model and generating the smallest implementation with latency \(L_{\text{efpga}}\). The authors discuss the use of synthesis directives (pragmas) for synthesizing arrays, loops, and functions and how different combinations of these directives lead to a unique micro-architecture with specific area vs. latency tradeoffs. The output of this stage is the pragma combination that leads to the smallest predictive model implementation (pragmaopt) and the newly optimized predictive model with exact latency as the exact obfuscated circuit (C_Copt). The final phase of the process generates an eFPGA bitstream to configure an eFPGA with the predictive model. The process includes HLS, logic synthesis, technology mapping, place and route, and eFPGA bitstream generation. The target synthesis frequency should be set to the same frequency at which the exact obfuscated circuit works to enable the unlocking of every manufactured IC. Despite the cleverness of the attack, it does bear a major limitation since it only applies to approximate computing. It is, therefore, unlikely that the eFPGA-obfuscated logic would implement any form of hardware-based cryptography since it has to be deterministic.

The next proposed attacks are oracle-less attacks, namely, the “structural analysis attack” and the “composition analysis attack” [1, 2]. Because [1, 2] proposes a hybrid FPGA-ASIC solution, it is assumed that an attacker has access to a reversed engineered netlist where a portion of the logic is in the clear. The security of such a style of reconfigurable-based obfuscation depends on how much information is exposed in this fully exposed portion of the logic. In [1], a follow-up work, authors present the threat model for their attacks as follows:

The authors of [1] proposed two different attacks: “structural analysis attack” and the “composition analysis attack”. It is argued that, by exploiting the static portion of the design, including the frequency of specific LUT masking patterns, an adversary can extract information and reduce the search space for the key that unlocks the design. They found that the combined number of unique masking patterns forms a set of 3,376 elements, which reduces the global search space from \(2^{64}\) to \(3,376=2^{11.72}\). They hypothesize that attackers can exploit the frequency of LUTs appearing in a netlist to mount structural analysis attacks. The authors investigated this by analyzing the behavior of the frequency of masking patterns at different obfuscation levels. The results show that the adversary can somewhat estimate what masking patterns are the outliers. The results show that certain levels of obfuscation can either result in no correlation, a strong correlation to another circuit, or a correlation to itself. The study suggests that obfuscation can be targeted to confuse an adversary and shrink the key search space for obtaining the bitstream.

However, the success of the attack depends on the adversary’s ability to reconstruct LUTs from the static part, the availability of enough datapoints in the database, and the design having static parts to begin with (eFPGAs would not have static parts). Additionally, the frequency of masking patterns can serve as a template for comparing different designs, as the composition of the LUTs within a design would enable a powerful template-based attack.

Another attack proposed in the literature is called “break and unroll attack”. It is capable of recovering the bitstream of eFPGA-based redaction schemes in a relatively short time even with the existence of hard cycles and large size keys [78] and, interestingly, this contrasts the common perception of eFPGA-based redaction schemes being secure against oracle-guided attacks [2, 19, 20, 31, 67]. In their threat model, it is assumed that all ICs are sequential circuits; thus, the attacker can access the always-present scan chain. The attacker has complete access to the obfuscated netlist and can obtain a functional circuit from the market as a black box, which can derive correct outputs for input vectors.

In [78], the “Break and Unroll attack” combines cycle breaking and unrolling to recover the bitstream of state-of-the-art eFPGA-based redaction schemes. The study highlights that the common perception that eFPGA-based redaction is secure against oracle-guided attacks is false and that additional research is required to secure eFPGA-based redaction schemes systematically. The overall flow of the Break and Unroll attack is given in Algorithm 2. The Break and Unroll algorithm consists of two main stages: breaking cycles and unrolling remaining cycles. If the first stage fails to reveal the correct key, the second stage, unrolling, neutralizes the effect of hard cycles. The breaking phase involves breaking all cycles and adding a non-cyclic condition as a new constraint to the obfuscated circuit. The unrolling phase conquers the weakness of the breaking phase by unrolling a single cycle at a time, choosing a single feedback, and adding a copy of every gate to the circuit. After unrolling one cycle, a new version of the obfuscated circuit is created, and set W must be updated each time in the body of the attack algorithm.

Another attack named “FuncTeller” on eFPGA-based obfuscation is proposed to retrieve the hardware IP with only black-box access to a programmed eFPGA. This attack was achieved by leveraging the effect of modern EDA tools on practical hardware circuits, guiding the attack towards the desired outcome [39].

This threat model is consistent with previous works on eFPGA-based obfuscation, attacks on eFPGA [1, 28, 78], and the cybersecurity awareness worldwide competition (CSAW) [75]. The attackers are a collusion of an untrusted foundry/testing facility and an untrusted end-user. The untrusted foundry/testing facility can access a netlist with the unprogrammed eFPGA and can isolate the eFPGA by analyzing the IC netlist or identifying the scan-chain connected to the eFPGA using reverse engineering techniques [94]. It is important to note that the purchased functional chip is ASIC integrated with the configured eFPGA. A detailed explanation of this threat model is presented as follows:

The authors in [39] present an attack that aims at recovering an IP that is implemented on an eFPGA with only I/O access. In practical circuits, logic synthesis optimizes PPA by reducing the number of prime implicants (PIs) and literals in the circuit’s prime implicants table (PIT). This behavior is consistent in hardware designs and has two implications. Firstly, a single PI covers multiple ON-set minterms that share the same literals in the PI representation. The authors utilize this property to predict each PI by expanding from a discovered ON-set minterm (seed). Each value is replaced by a “don’t care” and heuristically verified in this process. Secondly, the Hamming distance between two PIs in a PIT is usually much smaller than the input size. This property reduces the search space when updating the predicted PIT with the new PI.

In order to efficiently search for the next ON-set minterm, FuncTeller limits the search space to be in close proximity to the current PIs. To implement boolean functions, FuncTeller utilizes the implications of circuit cones and employs a mechanism illustrated in Figure 16. This approach ensures optimal utilization of resources and enables efficient implementation of complex circuits. The circuit cone has n inputs (\(A_{\text{1}}, A_{\text{2}}, \ldots , A_{\text{n}}\)) and one output, and the example circuit implements the Boolean function \(f\left(A_1, A_2, \ldots , A_6\right)=A_1 A_2 \overline{A_4}+A_4 \overline{A_6}+\overline{A_1} A_6\), which is non-canonical in its PIT representation. The authors demonstrate this mechanism in Figure 16, and the PIT representation of the aforementioned function is displayed in Figure 16(b).

The recovery of an entire circuit’s functionality is described in Algorithm 3. The algorithm’s objective is to predict the circuit’s complete functionality based on an input oracle and several parameters. The oracle O, which represents the circuit to be predicted, is accompanied by a distance parameter \(d_0\), linear parameter p, convergence parameter \(p_{conv}\), and time limit T. The algorithm aims at constructing the predicted circuit \(C_{pred}\) that represents the entire functionality of the given circuit O. To achieve this, it employs several helper functions.

The main function, predict_circuit, begins by determining the number of outputs in the circuit using the function count_number_of_outputs and stores this value in the variable \(output\_size\). It initializes an empty set \(Cones_{pred}\) to hold the predicted cones. The algorithm iterates over each circuit output, represented by variable w, from 1 up to \(output\_size\). For each output, the function predict_cone is called on line 5 to predict the corresponding cone. A cone represents a part of the circuit associated with a specific output.

Within predict_cone, the algorithm uses the distance parameter \(d_0\), the linear parameter p, the convergence parameter \(p_{conv}\), and the time limit T to perform the prediction. The result, denoted by \(PIT_{pred}\), is a Predicted Information Table representing the cone’s functionality. The PIT is then converted to a netlist representation using the function convert_PIT_to_netlist on line 6. The netlist describes the cone’s structure and behavior, which is stored in the variable \(Cones^\text{w}_{pred}\). The algorithm combines the predicted cones in the set \(Cones_{pred}\) on line 7 to update the overall predicted circuit. To construct the entire predicted circuit \(C_{pred}\), the function merge_cones_to_circuit takes this set as input on line 8. Finally, on line 9, the algorithm outputs the predicted circuit \(C_{pred}\).

Table 2 presents a list of reconfigurable-based obfuscation techniques, categorized according to the technology used in the implementations, as discussed in Section 3. The prohibitive costs of reconfigurable-based obfuscation techniques could make them impractical despite their attack resiliency. As an attempt to decrease the overheads without compromising security, researchers have explored hybrid NVM technologies for implementing reconfigurable logic. In addition, NVM technology can be used as a replacement for a tamper-proof memory if it loses its content upon invasive reverse engineering attempts [53]. Despite being promising technologies, these technologies are still under development and have not been widely adopted. For a detailed discussion, we refer our readers to [79].

As indicated in Table 2, some authors solely employed SA to assess the effectiveness of their defense techniques. If authors effectively attempted to attack their own defences, we marked them as applied attacks (AAs). Here, we make a clear argument that both SA and AA have merits, but SA can be easily misinterpreted to suggest the techniques are more secure than they actually are. For instance, a classical SA discussion is the enumeration of the adversarial search space. But even large search spaces can be broken and this can only be shown through AA.

Furthermore, the resilience of the techniques was evaluated mainly against SAT-based attacks, as listed in the fourth column of Table 2. However, it should be noted that most of the techniques have not been validated against power side-channel attacks (PSCAs), especially in the case of CMOS implementations. The authors of [107] and [85] discussed the resiliency of their techniques against testing-based attacks, circuit partition-based attacks, brute force attacks, SAT-attacks, and side-channel attacks. The column “Others” in the table shows the resilience of a given technique against other AAs. We have observed this trend over and over with Logic Locking mechanisms that were considered secure—some even proven to be secure—falling prey to simple attacks that were simply not initially considered.

One of the major challenges is defining a security metric for reconfigurable-based obfuscation techniques. Currently, there is no specific or common security metric being adopted. To fairly assess the security of reconfigurable-based obfuscation techniques in this study, we adopted a common criterion: number of gates divided by the length of bitstream. Here the term “gates” refers to logic gates in the same way as in logic synthesis, meaning that a gate is a standard cell. For instance, if an author considered that a circuit with 1,000 gates was adequately obfuscated with a bitstream of 128 bits, this circuit would have a metric of 7.81. In most cases, the degree of obfuscation or the hidden portion tends to increase in proportion to the length of the bitstream. Authors of defensive techniques are interested in maximizing the metric, such that a high number of gates can be protected with a small number of configuration/programming bits.

Often, authors report the area of obfuscated design, and from that, we can estimate the number of gates from the area using information about the technology used for implementation. Figure 18 compares the gates count to the bitstream size ratio of benchmark circuits to be obfuscated as a security metric. We calculated the minimum, maximum, and average values of the ratio in most of the techniques⁴ considering all benchmarks and bitstream sizes used originally by the developers for evaluating their techniques. As a rule of thumb, a large ratio is an indication of lower and costly security [64, 68, 85]. However, there are exceptions to this rule [64]. In addition, optimizing a design for desirable PPA overheads and security would complicate the security-bitstream size relation [19]. For some techniques, calculating the ratio was straightforward as the gates count and the size of bitstream were provided by the authors [2, 53, 56]. However, for other techniques, the ratio either could not be calculated due to missing values [17, 64] or estimations were required for calculating it. For example, in [20], we needed to turn the area of a given circuit into the gate equivalent (GE) form to estimate the circuit gate counts.

We noticed two contradictory solutions in the eFPGA context: First, in many techniques, obfuscating nearly 10%, 20%, or 30% of a circuit gates count could suffice to ensure security (i.e., SAT attacks would run out of time) [17, 64, 68, 85]. Second, in [2], a much higher obfuscation rate is required for protecting the bitstream and design intent, e.g., obfuscation rates higher than 86% are recommended. As a result, the first solution would result in a large ratio when compared to the second solution as this is evident in Figure 18. Yet, the objectives of the techniques are different, and so are the underlying threat models.

Regarding reconfigurable-based obfuscation, the main objective is to select a part from the design and map it into reconfigurable logic. This involves dividing the design into reconfigurable and non-reconfigurable parts, which is done at different levels as outlined in Section 2.2.3. For instance, for the first IP, the partitioning is done at either HLS or RTL level. One example of this approach is [26], where the researchers partitioned their design on the HLS level and mapped it towards hardware.

Another example is [84], where the researchers partitioned their design on the RTL level and then mapped it to the hardware [63]. Alternatively, the reconfigurable logic can be treated as a black box, and hard IP can be included in the final implementation design, but the partitioning is still done on soft or firm IP level. Researchers typically split their design on the gate-level for firm IP and map it to the hardware [93].

Balancing security and PPA overheads is crucial and depends on the architecture and the designer’s choices. The impact of changes in the architecture plays a vital role in the selection of reconfigurable parts. The research in [1, 2] has developed a tool that designers can use to analyze the early tradeoff between security and PPA overheads. This tool provides insight into how the reconfigurable part’s size affects security evaluation and how it evolves over time.

Automating the selection of critical parts is challenging. An AI-based obfuscation engine trained on thousands of circuits may help achieve this. However, if the circuit’s architecture is novel or many circuit traces are different, it may pose a significant challenge.

A survey was conducted on the CAD tools developed by researchers who proposed reconfigurable-based obfuscation techniques. The results of the survey revealed that 41% of the techniques employed custom tools to obfuscate the designs. These tools were closed-source and claimed to be compatible with standard CAD flow. This is illustrated in Figure 19. On the other hand, 59% of the techniques relied on standard CAD tools. Surprisingly, only 4% of the researchers made their tools open-source. As for the remaining 55% of the techniques, the authors provided no details regarding the availability of the tools, whether they were open-source or closed-source.

The security of bitstreams is now essential in reconfigurable-based obfuscation. These bitstreams contain the configuration information of an obfuscated IC. It may be vulnerable to attacks by adversaries seeking to exploit the design’s IP or gain unauthorized access to sensitive information. The storage of bitstreams is critical and varies depending on the obfuscation class. Most of the studies reviewed did not discuss the long-term storage of their bitstream [20, 25, 26, 67, 68, 76, 85, 93]. These researchers assumed that the bitstream would be stored similarly to a standard FPGA. However, none of the researchers implemented bitstream encryption to secure it. Instead, they assumed that the bitstream would be stored externally and loaded at power-on or internally using secure, “tamper-proof” memory. Some researchers suggested encrypting the bitstream using a symmetric cipher (such as AES) and eliminating the ability to read-back the bitstream from a programmed device.

None of the research discusses security during the deployment and distribution stages. Instead, they assume that all processes related to the activated IC are conducted in a trusted environment. This means that every step involved in the distribution, from loading the bitstream to activating the IC, is executed in a trusted environment where security measures are in place to prevent unauthorized access, tampering, or interception of the data. Such a trusted environment typically includes controlled access to facilities, encryption of bitstream during transfer, authentication mechanisms, and adherence to strict security protocols.

There is a severe lack of frameworks to validate the security and functionality of obfuscated designs, as correctly highlighted in [56, 69]. Additionally, there is a minor effort toward silicon validation of the techniques as a proof of concept. For example, only techniques presented in [56] and [85] were validated on silicon. Silicon validations of the techniques would provide an impetus to advance reconfigurable-based obfuscation as a promising solution for protecting digital ICs.

The proposed FPGA-inspired obfuscation techniques have been primarily evaluated against SAT-based, logical attacks. Physical attacks, such as side-channel attacks, are barely assessed [55, 57, 107]. On the other hand, there are a few new attacks that are developed to assess the security of the reconfigurable-based obfuscation design [1, 28, 39, 78]. Nonetheless, there is still a need for a more comprehensive SA to evaluate FPGA-inspired obfuscation techniques against specific attacks. Even for well-established attacks, the analyses performed so far still have room for improvement.

During our survey, an effort was made to present the findings of numerous research articles clearly and unbiasedly. Yet, it is as evident as ever that the hardware security community lacks a unified benchmark suite and/or a common set of criteria. Frequently, researchers employ benchmark suites that enjoy popularity within the test community but are irrelevant to security. For instance, the ISCAS’85 suite lacks crypto cores and other real applications that are the cornerstone of the evaluation in this field. Furthermore, we believe that employing circuits that more accurately reflect current IC design practices, where IPs frequently comprise millions of gates and ICs house billions of transistors, would be highly beneficial for the community.

Within the research community, no standard criteria for assessing the security of reconfigurable-based obfuscation techniques is observed. Although it is confirmed that such techniques are resilient to various state-of-the-art attacks, the need for commonly accepted criteria to evaluate their security is an urgent need. While we utilized a ratio of gates to bitstream size, which is a reasonable but simple metric, it is noteworthy that for eFPGA estimations need to be converted into the number of gates. Concerning eFPGA macros available on the market, few companies have products available, including Achronix [3], Menta [66], and Quicklogic [71]. In tandem, there is also a discernible trend in the realm of ASIC design companies, such as AMD [11] and Intel [42], which both have acquired FPGA technology. This strategic move has enabled these entities to benefit from both ASIC and FPGA domains. With the convergence of these two technologies, there exists a possibility of integrating reconfigurable logic as an integral aspect of commercial production for security purposes. Today, the driver behind ASIC-FPGA hybrid solutions are design metrics, not security metrics.

It is also worth discussing the threat models proposed so far. The authors in [1] have established a robust threat model. Defining the capabilities of an attacker remains a complex task, requiring an understanding of their motivations, technical skills, and resource availability. Underestimating the attacker may result in ineffective defense strategies, whereas overestimating them could lead to unnecessary PPA overheads due to convoluted defense strategies. This challenge extends to reconfigurable-based obfuscation techniques and any other obfuscation-promoting approaches.

Another consideration in terms of attack is whether an attacker can leverage a partially recovered netlist. For instance, in a design that employs multiple instances of the same block, recovering one block correctly may enable the attacker to recover all other instances of the same block through a visual inspection of their structure [16]. This line of thinking is also applicable to datapaths and certain cryptographic structures that exhibit regularity. Consequently, a functional analysis of the recovered netlist can be combined with existing attacks to enhance correctly guessed connections.

Figure 19 clarifies that developing a custom tool is almost a mandatory part of the obfuscation process: 45% of the researchers have developed their custom tool, and 41% of them are closed source. This practice is a barrier to the research community, and there must be an initiative to make the tools open-source for academic use. Future research could (and should) explore how these tools, along with reverse engineering and other methods mentioned previously, can be utilized to break the security of reconfigurable-based obfuscation. Logic Locking has become increasingly susceptible to SAT attacks. There have been many attacks and measures against these attacks, so the Logic Locking concept continues to evolve. In spite of the proposal of SAT-hard solutions for Logic Locking, perhaps reconfigurable-based obfuscation techniques will eventually take over due to its inherit security against SAT-attacks. It is predicted that the use of eFPGA-based obfuscation is expected to gradually overtake Logic Locking in the near future. This is because eFPGAs offer a higher level of reliable security compared to traditional Logic Locking techniques. [28, 39, 78]. Researchers in this field will likely benefit from open-source macro generators for eFPGAs since only commercial solutions exist. In the near future, there will probably be many publications based on this area of research.