Obfuscation is a promising solution for securing hardware intellectual property (IP) against various attacks, such as reverse engineering, piracy, and tampering. Due to the lack of standard benchmarks, proposed techniques by researchers and practitioners in the community are evaluated by existing benchmark suites such as ISCAS-85, ISCAS-89, and ITC-99. These open source benchmarks, though widely utilized, are not necessarily suitable for the purpose of evaluating hardware obfuscation techniques. In this context, we believe that it is important to establish a set of well-defined benchmarks, on which the effectiveness of new and existing obfuscation techniques and attacks on them can be compared. In this paper, we describe a set of such benchmarks obfuscated with some popular methods that we created to facilitate this need. These benchmarks have been made publicly available on Trust-Hub web portal. Moreover, we provide the first evaluation of several obfuscation approaches based on the metrics and existing attacks using this new suite. Finally, we discuss our observations and guidance for future work in hardware obfuscation and benchmarking. Keywords Hardware obfuscation · Benchmark development · Benchmark testing · Hardware security 1 Introduction final layout to an off-shore foundry for fabrication. This trend has resulted not only in decreased costs and quicker With the rising costs of chip fabrication at advanced technol- turnaround times but also in a plethora of security issues. ogy nodes and ever-increasing design complexity, today’s Most notably, an untrusted off-shore foundry could engage semiconductor industry has shifted to a predominantly fab- in IP piracy, overproduction, malicious modifications (hard- less business model. In this model, a design house typically ware Trojan insertion), and cloning. Further, once the chip enters the supply chain, it is also vulnerable to various sources pre-designed and pre-verified hardware IPs from different sources including third party IP (3PIP) vendors, reverse engineering attacks, which aim at extracting the integrates them into a system-on-chip (SoC), and ships the design or specific secrets from a design. The most prevalent method of protecting IPs today is IP encryption . In this approach, electronic design automa- Sarah Amir tion (EDA) tools provide a platform for encrypting IP. firstname.lastname@example.org System integrator needs to verify the correct functionality of Bicky Shakya the incorporated encrypted IP through functional verifica- email@example.com tion and testing. Most EDA tools facilitate such verification Xiaolin Xu in a secured environment. In a common scenario, EDA tool firstname.lastname@example.org decrypts the IP during synthesis and the resultant netlist is Yier Jin usually unencrypted. Typically, the Design-For-Test (DFT) email@example.com team needs unencrypted design of the system to insert addi- Swarup Bhunia tional test circuitry that would facilitate the post-production firstname.lastname@example.org structural tests to verify the integrity of the IC. Previously, Mark Tehranipoor the existence of decrypted IP in design and fabrication cycle email@example.com was not considered a security threat, based on the con- Domenic Forte tract and trust between parties who were well-known to firstname.lastname@example.org each other. However, as the semiconductor industry became University of Florida, Gainesville, FL 32611, USA a horizontal business model distributed across the globe, J Hardw Syst Secur (2018) 2:142–161 143 this trust becomes questionable. More severely, any rogue The rest of the paper is organized as follows—Section 2 employee in the design or fabrication facility or any adver- articulates the motivation behind our work. Section 3 sary with access to an unencrypted IP may become a discusses the existing work in hardware obfuscation that potential security threat. For example, a malicious insider acts as a foundation for our benchmarking initiative. in the design house may sell the IP to a third party while Section 4 presents details on the benchmark generation claiming it as their own (IP piracy), use the IP in excess process. Section 5 discusses the metrics used to evaluate the of their contracted limit (IP overuse), and intentionally per- benchmarks as well as the associated results of overheads form malicious modification (hardware Trojans insertion) and attack resiliencies. Section 6 provides directions for to make the IP vulnerable to certain attack or become less future research in this field, and Section 7 concludes the reliable in critical usage [12, 14]. Additionally, reverse engi- paper. neering can be performed on the IP to understand design intent and retrieve the higher level of design for malign intention. 2 Motivation In order to protect hardware IP from these threats, the design needs to be unintelligible, even in decrypted form. Hardware obfuscation emerged in 2007–2008 to protect IP from threats in the semiconductor supply chain [2, 11, 34]. Hardware obfuscation provides the option to effectively hide and disable the design, but still facilitate structural Since then, it has been gaining popularity among hardware security researchers, according to Google Scholar. As testing and static/dynamic parameter analysis [29, 34]. This convenience makes obfuscation a desirable method shown in Fig. 1, the number of publications on obfuscation for security and an active field of research. In recent in major conferences and journals was relatively static each year until 2013. Since 2014, there has been an exponential years, a large number of obfuscation techniques and attacks on obfuscation have been proposed. In most cases, increase in obfuscation-related work. Note that while 2017 is not shown in the figure, as of this writing, it already has researchers evaluate their techniques and attacks on circuits generated in an ad hoc fashion. Unfortunately, this makes 22 more publications than 2016. Unfortunately, even after many publication on numerous it difficult to objectively evaluate their merits and compare their effectiveness against various metrics. Lack of well- ways of obfuscation and new attacks, there has been no impartial standardized comparison platform to evaluate the designed benchmarks, which can facilitate objective and accurate evaluation of important properties of obfuscation advancements. Some researchers use ISCAS benchmarks [8, 9], while others are more comfortable with ITC . and manifest the merits and limitations of an approach, has become a major barrier for the research community. To For presenting attack models, researchers are forced to address this limitation, for the first time, we introduce a suite generate their own benchmarks because of the unavailability of any standard ones . As a result, it is infeasible of new obfuscation benchmarks that provides the option to evaluate obfuscation methods and attacks accurately and for designers to know the scalability or applicability of these methods, and relative analysis of the effectiveness establish a baseline for comparison. In this paper, we also present our experimental results on comparative analysis of obfuscation or hardware overhead. Thus, it has become necessary to establish standard benchmarks for obfuscation of popular methods in the field based on resiliency against noteworthy attacks. We also introduce a set of metrics with which the research community can evaluate their methods. to quantify characteristics of the circuit and obfuscation technique applied to it. Our contributions in this paper include: – Generation of obfuscation benchmarks to evaluate existing and emerging obfuscation methods and attacks. This required implementing many of the approaches found in literature. – Introducing new obfuscation metrics such as recon- vergence, differential entropy, verification failure, key structure, and performing analysis of their relation with overheads and attack resiliencies using the benchmarks. – Analyzing how obfuscation metrics can indicate resiliency of an obfuscated circuit and providing future directions and insight on how to improve, optimize, and utilize these benchmarks, metrics, and obfuscation methods. Fig. 1 Trends of publication in hardware obfuscation 144 J Hardw Syst Secur (2018) 2:142–161 3 Background and Preliminaries 3.2 Related Work in IP Protection In order to protect IP from threats throughout the supply In this section, we briefly describe the various threats for IP designers that hardware obfuscation can prevent. Then, we chain, passive methods such as watermarking and digital rights management [3, 23] have been proposed will present the obfuscation methods that were considered to generate our suite of benchmarks. In the last part, we which can be used to authenticate suspect IP or IC or prove ownership during litigation. However, these passive will describe two attacks on obfuscation that we utilize in methods cannot prevent piracy from happening in the first evaluation of attack resiliencies, along with one designated attack defiant obfuscation. place. Active approaches such as metering  have been proposed to authenticate and regulate the unauthorized usage of the IP or IC. In metering, the number of 3.1 Threats keys provided can be limited by the original designer, thus avoiding IC overproduction and IP overuse. An The threats bore by 3PIPs have been analyzed extensively essential part of metering is to have logic obfuscation or in literature. Supply chain vulnerabilities and threats are encryption techniques implemented to lock the design from discussed in detail in [27, 37]. Also, Rostami et. al. unauthorized access. categorized many of these threats in . An overview of Industry has also been looking into the protection of their these attacks is enlisted with examples here and also shown designs using these approaches. Syphermedia was recently in Fig. 2. acquired by Inside Secure for their “root-of-trust” solutions – 3PIP: Any rogue employee in 3PIP design house with in SoCs which is based on camouflaging and for its long access can sell, modify, overuse, or reverse engineer an history of IP protection in Pay TV and printer ink cartridge IP as the design is open and visible in this phase. markets [10, 43]. Mentor Graphics has been developing – SoC and DFT inserter: A malicious entity in SoC or platforms for chip life cycle management which rely heavily DFT insertion phase with access to unencrypted IP can on both secure testing and metering. In order to protect from also sell, modify, or reverse engineer the design. reverse engineering attacks, improvisation of the platform – Untrusted foundry: Any adversary with access to the has been proposed to include functional locking with logic final GDSII file of the IC design might overproduce obfuscation . the design or sell it to a third party. They might reverse engineer the design to retrieve higher level description 3.3 Hardware Obfuscation to exploit vulnerabilities. – Assembly, distributor, and user: An attacker in assem- Obfuscation is a powerful tool to hide the hardware design bly and distribution stage or an end user does not from a potential adversary, even when the IP is in decrypted have access to the original design. However, they form. The underlying protection of obfuscation relies on might reverse engineer the fabricated IC. Although hiding and obscuring the functionality and structure of IC reverse engineering is a slow and expensive pro- the original design. Such a goal is also desirable in cess, it has become more practical today with the software, where the owner of a code might want to make advent of advanced imaging and probing techniques it unintelligible to users. In fact, software obfuscation has such as focused ion beam (FIB) and scanning electron received quite a bit of attention in the past few decades, microscopy (SEM). In order to reverse engineer the and many techniques have been proposed [7, 15]. In design, an attacker needs to perform delayering, high- software obfuscation, there is no notion of “locking”, i.e., resolution imaging or X-raying, and image processing the obfuscation should make the code indiscernible but not to retrieve the netlist from a fabricated IC. If the adver- prevent its usage. Unfortunately, recent theoretical results sary is a foreign government or competitive ill-intended have shown that such a notion of “virtual black-box” organization, acquiring these expensive imaging equip- obfuscation, in which an obfuscated code does not leak ment is possible. This is why sensitive designs, like military anything other than what it would through oracle access, is grade ICs, need to be kept secure from such threats. impossible to achieve . However, hardware obfuscation Fig. 2 Threats on third party IP in supply chain J Hardw Syst Secur (2018) 2:142–161 145 necessitates the prevention of black-box usage, due to which re-synthesis is performed after post-synthesis obfuscation. locking (e.g., key gate-based post-synthesis obfuscation) or Layout obfuscation is based on modifying layout design, design withholding (e.g., split manufacturing) is employed, utilizing features of placement and multi-layer routing. and such impossibility results are (generally) avoided. It is performed on the geometric representation of the Though obfuscation has been widely used to protect circuit and depends on the layout design and available software [5, 7, 15], there are however concerns while spaces. It can be compared with similar concepts as applying it to hardware IPs. For example, obscuring split manufacturing, camouflaging, or Chip Editor. Split may protect hardware IPs from reverse engineering or manufacturing considers splitting the design to fabricate in modification, but might not protect them from piracy. separate untrusted foundry [20, 31]. Camouflaging modifies This is also why hardware obfuscation needs to consider some of the standard cells to make them indistinguishable both functional locking and structural modification of the by physical design inspection to hide the functionality design. The functional locking mechanism makes the design in order to protect from reverse engineering . The unusable and structural modification makes it unintelligible. foundry is considered trusted in this technique. In the Chip Hardware obfuscation can be both key-based and key- Editor method in , obfuscated circuit layout is modified less. In key-less functional locking, obfuscation does not post fabrication with FIB to unlock it. Figure 3 shows depend on external key input. An example of such a the integration of these different obfuscation techniques technique is split manufacturing, where a fraction of the at different abstraction levels throughout the design flow. design is manufactured in separate untrusted foundry and Verification is necessary to be carried out before and after stitched together in a trusted facility [20, 31]. Although obfuscation, to ensure the implementation has been properly split manufacturing is an operational strategy, the goals are done and the original functionality is preserved when similar to obfuscation. Without proper knowledge about the unlocked. correct connections, the design intent stays obscured. In a keyed system, an unlocking key or certain input pattern 3.3.1 Post-synthesis Obfuscation can be used to retrieve the IC’s original functionality [13, 34, 48]. A correct unlocking pattern can make the IC work Combinational logic locking by placing XOR/XNOR key properly, otherwise the IC stays locked and non-functional. gates randomly in the circuit design was proposed by Hardware obfuscation techniques can also be classified Royet. al.in. In their initial approach, one of based on whether they are combinational or sequential in the two inputs of these XOR/XNOR gates comes from nature. In this work, we focus on combinational obfusca- external inputs, through a cryptographic module. Often, the tion. This type of hardware obfuscation is realized by adding cryptographic part is overlooked for simplicity and the key combinational components only to the combinational parts gates are considered directly connected to external inputs, of a hardware design. There have been a good number of for analysis. This extra external input is referred to as a methods proposed based on combinational obfuscation over “key input”. An XOR gate becomes transparent for key the years [30, 34, 44, 48]. input 0 and becomes inverter for 1. For an XNOR gate, Obfuscation techniques can also be classified based the impact is the exact opposite. To hide the identity of the on what representation of the design they are applied locking gates, some XOR gates are replaced with serially to. Obfuscation performed on Register Transfer Level connected XNOR and NOT gates; similar techniques can (RTL) abstraction is pre-synthesis obfuscation. In this also be applied to an XNOR gate. This process hinders locking, the functional details, such as state machine of the the removal of key gates . Since the key gates are circuit, are considered. After, the obfuscation re-synthesis randomly placed without considering any circuit structure, is necessary. On the other hand, post-synthesis obfuscation, it is fast to implement the obfuscation even for larger which is applied to synthesized gate-level netlist designs, circuits. However, such randomly placed gates cannot fully includes techniques such as logic locking where the guarantee resiliency against attacks on obfuscation. The functionality is mostly overlooked and structural parameters random keys can be placed on nets where they are easily such as fanout and number of gates are considered. Often, identifiable (see Section 5.2.2) or can be placed in a critical Fig. 3 Integration of hardware obfuscation in all levels of abstraction through the design flow  146 J Hardw Syst Secur (2018) 2:142–161 information path causing more vulnerability for information design prior to logic synthesis. This could include the leakage . placement of a locking/obfuscation mechanism at: To mitigate the possible vulnerability of placing key – Control and data flow graph (CDFG): The authors of gates randomly, one deterministic approach that considers  propose a locking mechanism in which the RTL the circuit structure is secure logic locking (SLL) . In code is transformed to its control and data flow graph this method, key gates are integrated in the hardware IP in (CDFG) form, which is locked by the superimposition a way that it is hard to observe the impact of each single of an authentication FSM, and then converted back to key gate. To facilitate the key searching and insertion, key RTL form. gate interconnection types are assigned specific weights and – High-level synthesis (HLS) level: For some HLS- placements are made to maximize the summation of these level techniques, the obfuscation is implemented at weights . The selection depends largely on the weight the behavioral code level (e.g., C/C++ during datapath distribution, but the authors of  did not provide a weight and control logic synthesis) and then converted to distribution which would make the obfuscation stronger. RTL code (with subsequent gate-level synthesis) . Another heuristic to place gates based on the structure of In this technique, MUXes, which are driven by a the circuit is integrating the key gates with other gates that locked controller unit, are implemented to add decoy have the largest fanin or fanout cone or both. The logic connections in the datapath of the design. Therefore, cone size is computed by the equation provided in . The only the correct control signals can unlock the design to positions are evaluated and marked with the corresponding an authorized party. weights. Key gates are placed in positions with the largest – Binary decision diagram (BDD): Another technique weight. involves the expression of combinational logic in Because of the confusion it introduces, MUX gates the form of BDDs and embedding of the locking offer better hiding of internal structures than XOR/XNOR mechanism at the BDD level [26, 45]. BDDs are gates [30, 44]. Inserting XOR gates does not change canonical expressions for Boolean logic, represented in the information flow path, as it only adds an additional the form of a directed acyclic graph (DAG) with arcs, input to the path. Using MUX gates instead of XOR nodes, and leaves. A BDD consists of several nodes gates changes the information flow paths for wrong key. arranged in various levels, with each level representing In MUX locking, one of the inputs to the MUX is the a variable (i.e., primary input) of the Boolean function. original signal, while the other input is another internal Arcs can be either dashed as complemented or solid signal from the design that does not form a combinational as un-complemented. Traversing a path through nodes loop . Though MUX gate-based obfuscation has higher and edges to either of the two leaves evaluates the overhead than XOR gates, it has the benefit of resiliency function to either logic-0 or logic-1. In essence, BDDs against removal attack because it is hard to distinguish can be thought of as highly compressed binary trees between the intended net in the design and the dummy implementing the entire truth table of the Boolean net, which the MUX switches between. Also, if the depth function. An example of a BDD is shown in Fig. 4, of both inputs of the MUX is kept similar, it is very where the Boolean expression Y = A ⊕ B is hard to figure out the correct key by analyzing timing implemented. BDDs can be converted directly to overheads. 3.3.2 Pre-synthesis Obfuscation Obfuscation techniques focus on locking or obfuscating the design after logic synthesis and technology mapping. This is similar to DFT techniques, such as insertion of scan chains and compression logic after synthesis. Therefore, most of these obfuscation techniques are agnostic to the underlying function or specification being implemented by the design, and operate using structural metrics such as fanout, observability, or fault impact. On the other hand, pre-synthesis obfuscation techniques aim to obfuscate the 0 1 In complementary CMOS design, a two-input MUX gate requires more transistors than a two-input XOR/XNOR gate. Fig. 4 BDD for a simple XOR function J Hardw Syst Secur (2018) 2:142–161 147 combinational logic circuits, by mapping each BDD single DIP in one iteration. The more wrong keys it can rule node to a MUX. Note that the overall size of the BDD out in each iteration, the less number of iteration it needs to thus determines the circuit size, which can be controlled break the entire obfuscation. Thus, this attack compromises by the order/level in which variables appear in the most existing logic locking techniques in seconds. There diagram. In order to embed a locking mechanism, a new have been a few methods proposed against SAT attack that variable (i.e., key input) can be added to the BDD, along can deter the attack either by increasing the number of iter- with if-then-else (ITE) operations to switch between the ations it needs to rule out all incorrect keys or by increasing correct Boolean function and a wrong one (which could the time required in each iteration [44, 47]. be a different part of the original function, or new logic AntiSAT technique is one such method that can increase altogether). For example, the ITE operation f = k ·f + the number of iteration to the exponential of number of k · g embeds a key k, which causes a locked function, primary inputs used to implement the AntiSAT block . f to evaluate to f (the correct function) when k = 1 It decreases number of key patterns to be detected per input and evaluate to g otherwise (the incorrect function). pattern to one. For best case, when all of n primary inputs are used (as in our forthcoming benchmarks), SAT tool will 3.3.3 Attacks need to iterate 2 times. This is ensured by implementing a particular function Many attacks have been proposed to break combinational g and the exact compliment of that function g (as in obfuscation and retrieve the key [22, 38, 41, 45, 48]. Secure Fig. 5), both provided with all or some primary inputs obfuscation techniques should ideally force the attacker to X ,X , ...,X . These inputs are XOR/XNORed with 1 2 n brute force the key. But in reality, there are other aspects same or different keys K ,K , ...,K and K , ...,K , 1 2 n n+1 2n of the designs that facilitate logical attacks that can retrieve separately. The output of the complimentary function pair correct key with far less effort than brute force [22, 38, 41, are fed to an AND gate and the output of this gate Y 45, 48]. There are two popular attacks against logic locking is XORed with an internal node with high observability that run fast and either completely or partially break the by inserting new XOR gate G. For the right key, the locking scheme. complimentary pair would cause Y to be always zero, and Key sensitizing attack uses auto test pattern generation XOR gate G would be transparent. On the other hand, (ATPG) to sensitize the effect of a key gate to a primary for a wrong key, this is not true and Y can also be one, output . Fault analysis of the key input results in an causing G to act as an inverter. The author of  suggested input pattern that can propagate this fault to a primary output to implement any logic locking technique along with the AntiSAT technique. The logic locking protects the circuit for observation. Then, the input pattern is applied to the locked netlist and an unlocked IC and resultant outputs are from unauthorized access and AntiSAT makes the SAT compared to determine the right key for that gate. This attack infeasible. However, several papers have found that approach can be used to find the correct key assignments for such hybrid approaches can still be attacked [38, 39, 45, 49]. isolated gates (i.e., gates whose fault impact can be observed directly at the primary outputs). In the case of key gates which are not isolated, either the ones placed in each other’s 4 Obfuscation Benchmarks logic cone or whose signals converge in a way that the effect of key gates is not observable separately, the ATPG tries to The obfuscation benchmarks introduced in this work are figure out the patterns that can both excite and propagate generated by obfuscating existing standard benchmarks the effect of each key to primary output by setting other key inputs to certain values. This attack is usually able to retrieve a portion of the keys, after which brute force can be applied on the remaining keys (which cannot be sensitized). Most of the popular obfuscation techniques are vulnerable to this attack. Boolean satisfiability attack (SAT attack) utilizes con- ventional SAT tools to break logic locking . It con- verts the locked netlist to Conjunctive Normal Form (CNF) on which the Boolean satisfiability test is performed. An unlocked IC is used to determine Distinguishing Input- output Patterns (DIPs) that can rule out at least one wrong key in each iteration. With most logic locking obfuscated circuit, the SAT tool can rule out multiple wrong keys with a Fig. 5 AntiSAT method proposed in  148 J Hardw Syst Secur (2018) 2:142–161 are performed by varying the key size between 32 , 64, 128, and 256 bit. For each case, three different logic locking techniques: random logic locking, secure logic locking , and logic cone size-based lock placement, are applied, with Fig. 6 Graphical representation of naming convention of generated and without AntiSAT . benchmarks The purpose of the benchmarks is evaluation of different methods and attacks. For this application, it is often required with various methods. Since the existing ISCAS 85 benchmarks were mainly made for VLSI-related reasons to observe the effect of variation of key length while keeping (e.g., EDA and other tools evaluation), these benchmarks do other parameters same, or to observe the effect of different obfuscation methods, while all other parameters stay same not have any secret to hide from an attacker. To analyze the security of a system, we need benchmarks that contain some and so on. Our benchmark suite provides the option to observe the impact of any one obfuscation parameter on sensitive assets that need to be protected. In the obfuscation benchmarks, the unlocking key is that asset. If an attacker security. Table 1 enlists the generation parameters and numbers of resultant benchmarks. deduces the key, the obfuscation is broken and security is breached. Besides the above mentioned features, we also cate- gorized the obfuscation benchmarks based on structural To generate the obfuscation benchmarks, a set of unlocked benchmarks that are widely accepted among characteristics, such as circuit size in terms of the num- ber of gates in the synthesized netlist (with SAED90nm researchers is chosen. These benchmarks are then obfus- cated with highly cited combinational obfuscation tech- library and with high mapping and area effort), key size, niques, including a SAT attack-resilient method. A tool key gate type, and method of obfuscation. Based on our cat- named as Key Insertion Tool (KIT) is developed to automate egorization, the classification has many subclasses. Obfus- the obfuscation process. cation can be sequential or combinational; combinational obfuscation can be either structural or functional; whether We have established a naming convention for the benchmarks which includes original circuit name, code one or more obfuscation techniques has been applied to generate the benchmark and so on. The classification tax- for obfuscation method, key length, and version of the benchmark. The rule is illustrated in Fig. 6. The codes for onomy is presented in Fig. 7, which includes the existing classification presented in  and future extensions, such as obfuscation methods we have implemented are presented in Table 1 column B. (The markings A, B,and C in Fig. 6 key type-based classification. correspond to the respective columns of Table 1). 4.1 Post-synthesis Obfuscation Benchmark In the initial obfuscation benchmark suite released Generation on Trust-Hub , we have included 228 obfuscated combinational benchmarks. As initial unlocked circuits, ISCAS85  suite has been selected because of its The process for generation of logic locking-based post- synthesis obfuscation benchmark that we implemented in familiarity to most researchers. Choosing ten benchmarks of this suite provide the option of different types and sizes of our work has three phases—preparation phase, selection phase, and insertion phase. circuit (that needs to be obfuscated). Then, the obfuscations Table 1 Obfuscation (A) Source (B) Method (and code) (C) Key length Number of benchmark benchmarks c432 c499 Random (RN) Secure Logic Locking (SLL) 32 c880 Logic Cone Size based (CS) 2 × 6 × 3=36 c1355 AntiSAT+Random (NR) 64 c1908 AntiSAT+Secure Logic Locking (NS) + c2670 AntiSAT+Logic Cone Size based (NC) 128 c3540 BDD-Random* (BR) 8 × 6 × 4 = 192 c5315 BDD-AntiSAT* (BS) 256** c6288 BDD-Entropy* (BE) c7552 Total number of benchmarks 228 c432 and c499 are too small for 256 bit key J Hardw Syst Secur (2018) 2:142–161 149 Fig. 7 Classification of benchmarks in the obfuscation benchmark suite 4.1.1 Preparation Phase library parser to incorporate the multiple libraries. Provided with the synthesized file, the tool can Before we go into details of how the post-synthesis detect the library it is synthesized with and perform obfuscation has been automated, we need to mention some obfuscation in that format. The benchmarks we have of the concerns that comes with circuit modification. We released in our first suite have been obfuscated in solved these concerns in the preparation phase before library independent Verilog netlist format, and then performing the obfuscation. synthesized with SAED90nm library (with high map and area effort). – The source: Though our generation process can operate – Key bit distribution: When obfuscating a circuit with on sequential and larger combinational benchmark multiple modules, each module gets obfuscated with a circuits, we started with the ISCAS85 benchmarks  number of key bits that are proportional to the size of for its familiarity. the module. So, the larger module is obfuscated with – Description language: Our implemented obfuscation more locking gates than the smaller ones. tool is capable of working on standard Verilog netlist – Hierarchy: As we are working with the unsynthesized files. Working with such versatile formats eases many ISCAS benchmarks in Verilog format, the modification limitations like working with memory elements and un- is performed on the lowest level of hierarchy first flattened design and offers great flexibility as the files and then climbing upward, as depicted in Fig. 8.Ifa are synthesizable with commercial tools. flattened netlist is used, then this complexity can be – Technology library: To make our generation process avoided. work with different libraries, we have developed a – Key gate type: The obfuscation can be performed with either XOR/XNOR gates or MUX gates. With XOR/XNOR gates, one input of the locking gate comes from certain selected internal node and the other input comes from an external input, termed as key input.In the case of MUX gates, both inputs of a two-input MUX gate comes from two separate internal nodes, which do not form a combinational loop, and the selection input comes from external key input (Fig. 9). Solely, employing MUX gates results in higher area overhead in smaller circuits, so it is often advised to implement a Fig. 8 Module hierarchy and modification sequence 150 J Hardw Syst Secur (2018) 2:142–161 Fig. 9 Combinational obfuscation with XOR/XNOR and MUX key gates portion of the locks with MUX gates and the rest with cones of a gate. Gates with higher value of this metric XOR/XNOR gates. have larger fanin or fanout cone or both and are chosen to have locking gate in their inputs. 4.1.2 Selection Phase |FI | |FO | i i P = 0.5 ∗ ( + ) (1) In this phase, we select the positions where locking max(|FI |) max(|FO |) i i key gates will be inserted. Firstly, the selection is made randomly or heuristically and then key gates are inserted in The equation is utilized to select the locations for those selected positions. The selection process varies with inserting key gates with Algorithm 2. This method does different proposed methods, but the main idea is similar. not include any randomness in the selection process, The methods we implemented for position selection in so multiple generation attempts with same parameters generating the obfuscation benchmark suite are described result in consistent outputs. below. – Random: The idea of placing locking gates in random positions is similar to the idea of position selection proposed in . As described before, the simplest method of key gates insertion is placing the key gates randomly in the circuit. The algorithm is presented in Algorithm 1. – Secure logic locking (SLL): To implement SLL, we have minimally modified the algorithm provided by the authors of  to work with our insertion tool. In this technique, based on interrelation, the key gates – Logic cone size based (LCSB): The concept behind this are assigned with different key type categories and method is to place keys in the largest logic cones so each category is assigned a specific weight . The they will impact more signals. The position with the authors provided examples of each type, but did not largest logic cone has been calculated by measuring mention the rules that can define the exact process of and comparing a weighted normalized metric for all the gate categorization. Also, this selection is dependent gates in the module under consideration. This metric on the weights that is assigned to each key type, but was defined in  (as presented in Eq. 1) for similar the literature did not present any direction for the purpose. The metric considers both the fanin and fanout weight distribution. Assigning the weights is left to the J Hardw Syst Secur (2018) 2:142–161 151 imagination of the implementer and varying the weight, carefully that do not form a combinational loop. Algorithm selection varies. In our benchmark generation process, 4 contains our implemented key gate insertion process we have assigned weight of convergent key type to (where KI stands for key input). 10, dominant key type to 5, and isolated key type to 0 (key types are described in ). Determination of non-mutable gates and golden pattern requires ATPG tools, and we avoided those for the present version. The implemented algorithm is presented in Algorithm 3. 4.1.4 AntiSAT To protect the combinational obfuscation from SAT attack, multiple methods have been proposed. AntiSAT is a well-known technique among those. We developed a dedicated tool to perform AntiSAT technique on circuits. 4.1.3 Insertion Phase It defines a new module with all primary inputs and key inputs of thrice the number of primary inputs. The new In this phase, the netlist is modified to insert the locking module is called from the original circuit, specifically from key gates in the selected positions. The Verilog file is a selected module. The AntiSAT module implements the firstly analyzed to determine the technology library, input logic presented in Section 3 and generates a single bit output and output, number of modules, number of gates in each that goes in the original circuit to be XORed with a primary module, and hierarchy of modules, and to enlist gates of output (this is an adaption of the “secure integration” each module. If necessary, detailed analysis is performed, mode of AntiSAT, proposed in ). In our AntiSAT-based such as determining the fanin and fanout cones of each gate. benchmarks, we have performed hybrid obfuscation, where Then, the insertion of new gates starts from the module with the circuit is also locked with logic locking techniques. highest hierarchy to the module with lowest hierarchy. The Algorithm 5 provides the technical details about how we insertion process varies slightly for XOR and MUX key implemented the AntiSAT technique. In this algorithm, PI gates, as for the later, two internal nets must be selected stands for primary input and KI stands for key input. 152 J Hardw Syst Secur (2018) 2:142–161 fanin cone or TFI) are firstly extracted and converted to their corresponding BDD representation. Iterative ITE operations (as explained in Section 3.3.2)are then applied to the BDD to embed key inputs. The wrong functions implemented on applying the wrong keys are the same as the original function, except at one randomly chosen min-term, where the output is flipped. – Random: We also performed random functional locking using BDDs. In this technique, applying wrong key values leads to a cube formed by a random permutation of a random number of primary inputs. Similar to SAT-inspired BDD locking, the random locking was performed on a per-output basis. – Entropy driven: We also generated BDD-locked bench- marks where the goal was to increase the overall entropy of the obfuscated circuit. The entropy is a met- ric that reflects the amount of information contained in a vector (see Section 5.3.2). Algorithm 6 shows the steps performed. The main idea is to selectively lock a few outputs (and gates in their TFI) using key inputs and BDD nodes that have a differential entropy greater than a predefined threshold. Here, differential entropy refers to the entropy of the circuit that results from XORing f (BDD representation of an output cone) with b (an internal BDD node that is part of the BDD B of the entire circuit). This differential entropy metric helps us to select sub-functions that are vastly different in terms of Boolean functionality than the original function f . 4.2 Pre-synthesis Obfuscation Benchmark Generation Pre-synthesis obfuscation follows entirely different tools and processes to perform the locking. The circuit represen- tation and the parameters used are fundamentally different than those of post-synthesis obfuscation. The pre-synthesis obfuscation technique we have implemented to generate our benchmarks is described hereunder. 4.2.1 BDD BDD-based pre-synthesis obfuscation has been performed with three variations in the selection techniques: first one is random permutation based, second one is to implement SAT resiliency, and the last one is to maximize the entropy of the circuit. – SAT inspired: Similar to other SAT-resistant logic locking techniques such as anti-SAT and SARLock, the BDD-based SAT-resistant circuits also ensure that only one wrong key value is ruled out per input pattern. This forces SAT-based attacks  to brute force through all possible input patterns to extract the correct keys. To perform the actual locking on a circuit, several output pins of the circuit (and the gates in their transitive J Hardw Syst Secur (2018) 2:142–161 153 5 Evaluation the block itself occupies extra area. For these reasons, AntiSAT benchmarks have higher area overhead, but On all the generated benchmarks, we performed extensive similar for different logic locking methods like previous analysis to calculate the overheads, attack resiliency, and case. metrics. We have selected a few benchmarks to represent – Power overhead has only static components and the whole set (note that for brevity, we cannot include all depends largely on each method. The location of the results in this paper). This selection includes 72 benchmarks key gate has a significant impact on power overhead as generated by varying the circuit while keeping the key- it introduces additional loading on adjacent transistors. length fixed, and varying the key length while keeping If the node where the key gate is inserted has high the circuit fixed, enabling us to observe both the effect of fanin or fanout, the power overhead increases. AntiSAT changing key size and circuit parameters. Also, to avoid the hybrid benchmarks have large additional logic and effect of randomness of the generation processes on attack BDD benchmarks contain huge amount of decoy logic resiliency and metrics, we have taken 10 samples for each for wrong keys. This additional logic draws large of the 72 benchmarks, making our sample space consisting amount of static power. of 720 benchmarks. In these samples, we incorporated – Timing overhead depends on the obfuscation methods three BDD-based obfuscation methods (benchmarks built greatly. For example, SLL and LCSB obfuscation on which are yet to be released) along with the six inserts new key gates in the same path as previous ones methods (on which our already released benchmarks are to increase correlation between them. This results in built). the formation of new critical paths in the design, or worsening of preexisting ones. As a result, the delay 5.1 Overhead overhead associated with SLL is usually higher. Note that BDD overheads are quite high, because BDD In order to calculate overhead, we synthesized obfuscation size depends on the order in which variables (primary benchmarks with GSCLib3.0 library with map effort and inputs) are arranged in the BDD. Since these orders are area effort set as high in Synopsys Design Compiler. Area, obtained via heuristics, circuit to BDD conversion usually power, and timing overheads of the selected benchmarks results in a large number of nodes in the BDD (which are are presented in Fig. 10. From the result, we made a few later mapped to MUXes for BDD to Netlist conversion). observations: Where possible, we also tried to use a BDD-based synthesis – Area overhead for structural logic locking techniques (BDS) tool  to perform further logic optimization on depends more on the key size than on different the MUX network. BDD benchmarks generated with c5315 obfuscation methods. If the key length is same, different and c7552 (32 and 64 bit key) and all entropy-driven BDD locking schemes—SLL, random, and logic cone size benchmarks (except for the ones generated with c1908) have -based locking—result in almost same area overhead. been optimized with BDS tool. We can see in Fig. 10 that For SAT-resilient techniques, there are extra key inputs overheads for these benchmarks are less than the ones that equal to thrice the number of primary inputs . Also, are not optimized. However, for most of the benchmarks, we Fig. 10 Overheads of selected obfuscation benchmarks 154 J Hardw Syst Secur (2018) 2:142–161 noticed that BDD-based locking almost always results in a not experimental. For the BDD benchmarks, the number of much higher power, area, and delay overhead. SAT iterations will depend on the number of outputs locked and the key length allocated to each output. For example, 5.2 Attack Resiliency if we locked 4 outputs, each with a key length of 4, we have in total (2 ) × 4 = 16 total distinguishing input One of the main usage of the obfuscation benchmarks patterns. Therefore, the SAT tool should resolve the circuit is analyzing attack resiliency of different methods and in approximately 16 iterations. Observations from the SAT attack results are quite designs. The existing attacks can be performed to compare the methods in terms of protection offered. Also, new clear. Any method without a SAT-resilient technique is attacks can be performed to show the effectiveness of such vulnerable to SAT attack, where the AntiSAT implemented over existing ones. In our experiment, we have attacked with such circuit is protected from the attack. AntiSAT BDD the obfuscation benchmarks with two well-cited attacks on obfuscation benchmarks performs better against SAT attack logic locking techniques that we discussed in Section 3.3.3. than logic locking based ones, but not as good as AntiSAT benchmarks. 5.2.1 SAT Attack 5.2.2 Key Sensitization Attack SAT attack is a functional attack on logic locking. Combinational obfuscation is vulnerable to the attack Key sensitization attack is based on fault analysis with unless additional SAT-resilient techniques are implemented ATPG tool [25, 48]. The key inputs are set as stuck at . We have applied the SAT attack (with the tool the faults and ATPG is used to generate pattern to propagate authors provided as open source ) on every obfuscation the fault (and thus the switching of key value) to primary benchmark of the suite. SAT attack on all the hybrid outputs. This input pattern can be used to determine the benchmarks (combined with anti-SAT) timed out (where right value of the key, by comparing the result of the locked timeout is set as 3 h). The time taken by the attack along netlist with the result from an unlocked IC. We implemented with the number of iterations for a selection of benchmarks the attack partially, with Synopsis TetraMAX and is presented in Table 2. Note that the number of iterations performed the attack on all obfuscation benchmarks. We presented in AntiSAT methods is the expected number of have implemented the first part of the attack in where iteration (calculated by the equation presented in ) and the attack only finds out isolated key gates. But we extended Table 2 SAT attack time (sec) and iterations (shown in square brackets) needed to break the obfuscation Benchm- Key Random SLL Cone size AntiSAT AntiSAT AntiSAT BDD BDD BDD ark length random SLL cone size random AntiSAT entropy C432 32 0.072 0.056 0.116 4407 Timeout Timeout 0.184 4.896 0.348     [5.9 × 106]* [5.9 × 106]*    C880 32 0.06 0.16 0.136 0.072 0.048 0.12 105.9 147.1 0.136          C1908 32 0.06 0.144 0.136 Timeout Timeout Timeout 5621 7221.8 22.356    [2.1 × 106]* [2.1 × 106]* [2.1 × 106]*    C3540 32 0.216 0.476 0.516 Timeout Timeout Timeout 163.2 284.3 17.508    [3.0 × 109]* [3.0 × 109]* [3.0 × 109]*    C5315 32 0.196 0.52 0.348 Timeout Timeout Timeout 0.184 0.372 0.272    [3.7 × 1033]* [3.7 × 1033]* [3.7 × 1033]*    C7552 32 0.44 0.5 0.156 0.18 0.28 0.34 0.364 13.8 0.392          64 0.652 0.34 0.316 Timeout 0.772 Timeout 0.504 66.75 12.748    [9.6 × 1038]*  [9.6 × 1038]*    128 2.108 0.6 0.932 1.352 4.344 0.612 5.672 Out of 16.716        memory  The timeout is set as 3 h. Also, for AntiSAT benchmarks for which the attack timed out, numbers of iterations are theoretically calculated as the expected value, not experimental J Hardw Syst Secur (2018) 2:142–161 155 the attack by making it iterative. The isolated gate that Hamming distance, entropy,and verification failure metric. gets broken in the first iteration is fixed to the correct key The metrics can be combined in different ways to derive value and attack is performed again. Faults on some key a global quality metric. The composition of such a metric gates that could not be propagated to the outputs in the first will be user specific as the weights of each component will iteration become vulnerable in the next as the controllability vary with design intent and application. We have analyzed of internal nodes changes. The iterative attack runs until these metrics thoroughly and observed the relation of these there are no new key gates. We have presented the result of with other quantifiable aspects of the obfuscated circuit like this attack on selected benchmarks in Fig. 11 as percentage overhead or attack resiliency. In this section, we present of key bits that got deduced correctly. In the best case, we some key findings along with the details of new metrics we could determine 84% of the keys accurately. We validated have proposed. the determined key by equivalence checking with the original netlist with ABC tool . 5.3.1 Veriﬁcation Failure We can see in Fig. 11 that BDD obfuscation benchmarks are the only ones that are immune to this attack. In In order to study the impact of logic obfuscation techniques generating these benchmarks, each output is obfuscated on the corruptibility of designs in more detail than with with predefined number of keys. For these benchmarks, it Hamming distance, we have implemented a verification is impossible to isolate and observe the effect of each gate failure metric. This metric utilizes Synopsys Formality, an separately, making the attack ineffective. Both secure logic industrial-strength equivalence checking tool, to evaluate locking and cone size-based obfuscation place key gates the functional difference between an unlocked and a locked in a way that makes larger network of locks, resulting in netlist. The output ports of both netlists are set as “compare moderate resiliency against key sensitization attack. points” and the following metric is computed. Similar Another observation of the results is that, though the equivalence checking tools such as Cadence Conformal or percentile looks better for AntiSAT-coupled benchmarks, Mentor Questa can also be used for the computation. the number of detected key is similar to the circuit without n(Fail) AntiSAT. Even though the AntiSAT block introduces n(Fail) n(Failing Patterns) · (2) additional key inputs, it only affects one output bit. So, in n(Fail) + n(Pass) n(Total Patterns) i=0 the best case, AntiSAT can hamper a single key detection of the original circuit. The fact that all the keys in AntiSAT The first portion of expression (2) (the ratio between module are nested together and convergent to a single number of output ports failing to the total number of output ports undergoing equivalence checking) tells us output port also makes them impossible to isolate. But the percentile appears better because of the increase in total what proportion of the outputs is being affected by number of keys over which the percentage is calculated. the obfuscation technique. The second portion of the expression (the summation) counts the number of failing 5.3 Metrics patterns produced by Formality for each failed output port. The denominator of 1000 indicates a maximum of 1000 Hardware metrics are set of deterministic parameters that failing points that need to be produced during equivalence can represent aspects of the circuit in numeric value. For checking for each compare point. Thus, with the two obfuscation, we have introduced a few metrics that can portions combined, the metric captures the number of represent features of obfuscation. Some of those metrics outputs affected as well as the extent to which they are refer to the structural features that cause the obfuscated affected by the obfuscation technique. Also, in contrast to circuit to behave in certain way, like reconvergence and differential entropy (discussed in Section 5.3.2) which relies key structure metric. Other metrics quantify the effect of on simulations, the metric uses failing patterns produced obfuscation on the functional behavior of the design, like as counter-examples by Formality. This guarantees higher Fig. 11 Percentage of keys successfully retrieved by key sensitizing attack 156 J Hardw Syst Secur (2018) 2:142–161 coverage, i.e., the failing patterns are more likely to be outputs resulting from the N random vectors for each vect “discovered”, which is clearly not the case for simulation output, and (iii) divide the output-1 count by N . vect unless an inordinate number of input vectors is used. In addition, we have also computed a metric we term as differential entropy. In order to compute this metric, a 5.3.2 Entropy and Diﬀerential Entropy miter circuit is formed by XORing each of the outputs of the unlocked netlists with the corresponding outputs in Entropy, as it specifically relates to Shannon Entropy, the locked netlist. After forming the miter circuit, random patterns are applied to the miter circuit (i.e., random primary measures the amount of information present in a source of data. For a combinational circuit (or equivalently, a input patterns as well as random key inputs), and the entropy Boolean function), entropy relates to the number of distinct of the miter circuit is evaluated using Eq. 5. This metric outputs that can be produced by the function . For a thus captures, on a per-output basis, the proportion of bits single output, Boolean function with a probability of logic-1 that differ between the original and locked netlists, and is denoted by P , the entropy is given by Eq. 3, where the first useful for quantifying “output corruptibility” induced by the term stands for entropy of logic-1 and second term stands locking technique. It has close similarity with Hamming for entropy of logic-0. distance in the miter part, but the logarithmic calculation makes entropy calculation more about the amount of 1 1 H = P · log + (1 − P ) · log (3) i i information contained than the amount of differing bits. P 1 − P i i In our experiment, we have found a close relation For a multiple output function, the exact entropy is between differential entropy and power overhead (as computed by calculating entropy for each possible output presented in Fig. 12). The proportionality found is well vector and summing up the entropies . If probability of expected as entropy corresponds to the amount of switching an output vector O is P , then the entropy H is calculated j j in a circuit and power overhead increases with the with Eq. 4,where M is the total number of possible output switching. vectors, for N output function, usually M ≤ 2 . 5.3.3 Reconvergence H = P · log (4) Reconvergence is a structural metric that represents the j =1 rate of internal signals converging in other nodes. For a Since such a calculation is usually prohibitive in terms particular gate, it is defined as the number of times signals of computation time (due to the large number of possible starting from this gate converges at some other gate, divided output vectors M), a good estimate of entropy for a N output by the number of total gates in fanout of that particular gate. function is given in as: It was proposed as a metric for VLSI benchmark evaluation in . For the purpose of using the concept for evaluating 1 1 H = P · log + (1 − P ) · log (5) i i obfuscation, we have slightly redefined the reconvergence P 1 − P i i i=1 metric. Instead of finding the nodes where signals may converge, we search if the inputs to a certain gate started The entropy expression in Eq. 5 tells us about two aspects of the function: from a same origin, thereby making it a convergent node. For example, in Fig. 13,let G be the gate under test whose – Power: A function with high entropy necessarily has inputs In has fanin A and In has fanin B. The 2 common 1 2 many output values that are possible. This then implies that many transitions between logic-0 and logic-1, or between different output vectors, are also possible. This D.Entropy vs Power Overhead directly increases the dynamic power consumption of the resulting circuit as a result of the switching. – Implications for obfuscation: An obfuscated combi- national circuit with maximum entropy (i.e., 1) most resembles a random function, where all output values are equally likely across all possible input values. The major difficulty in computing entropy comes from accurately computing probability P . In our experiments, 0 0.2 0.4 0.6 0.8 P is estimated by random vector simulation. We have D.Entropy used N = 10, 000 random vectors to (i) perform logic vect simulation on the circuit, (ii) count the number of logic-1 Fig. 12 Plot of differential entropy vs power overhead % Power Overhead J Hardw Syst Secur (2018) 2:142–161 157 Fig. 13 Reconvergence calculation of a gate gates in A and B are G and G .Also, G has fanin C in those logic cones would have less spread ability, causing 1 2 X with 5 gates. So, the reconvergence for G is 2/5. It is a the wrong key to alter only a portion of circuit (and hence, normalized value between 0 to 1. less corruptibility). Plots c and d in Fig. 14 display the relation between A = Fanin (IN ) = [G ,G ,G ] 1 1 2 3 reconvergence and SAT attack resiliency in terms of attack B = Fanin (IN ) = [G ,G ,G ,G ] 2 1 2 5 6 time and number of iterations, respectively. According to the (6) n(A∩B) Reconvergence = plots, high reconvergence relates to low SAT attack iteration X n(A∪B) n G ,G [ ] 2 1 2 and time. This phenomena can be explained as SAT attack = = n G ,G ,G ,G ,G 5 [ ] 1 2 3 5 6 rules out wrong keys by detecting the effect of the wrong key bit in the primary outputs. Gates close to the outputs Reconvergence is calculated for each gate of the circuit. are highly reconvergent than gates close to the inputs (as per We have found that the percentage of gates that are highly our computed metric). When key gates are placed in logic reconvergent has direct relation with attack resiliencies. So cones that converge to a gate close to the outputs, there is we defined circuit reconvergence as the percentage of gates more chance that the key’s effect can be observable through that have reconvergence between 0.9 and 1.0. the primary outputs. This allows the SAT attack to rule out Figure 14 shows the relation between attack resiliency more keys with less iterations. and circuit reconvergence. In Fig. 14a, percentage of keys detected by our implementation of key sensitizing attack is 5.3.4 Key Structure Metric plotted against reconvergence. As lower percentage of keys getting detected refers to more resilient obfuscation, the Key structure metric is a normalized metric that indicated inversely proportional relation indicates that more resilient the structural interconnection between key gates. The circuits have higher reconvergence and vice versa. High connection between key gate pairs is categorized and reconvergence means large portion of the signals converge assigned weights, similar to the assessment in , but at reconvergent gates, and it is obvious that key gates placed with extra categories included. The arithmetic mean of on those converging logic cones would be harder to isolate these weights is termed as the key structure metric. The and detect by key sensitization attack (see Section 5.2.2). categories of key pairs based on the structure of their relative Figure 14b shows the plot of verification failure metrics vs position and the weights we assigned on those to calculate reconvergence. The inverse proportionality is because of key the metric are presented in Fig. 15. In this figure, the fanin distribution and key effect masking. For lower percentage cone is shown in blue and fanout in orange. The weights of gates being highly reconvergent, the circuit is more of corresponding type are included in the caption. A key loosely connected, and the keys inserted are spread across gate is labeled “non-mutable” (with maximum weight) if its the design, each perturbing more signals. Conversely, a value cannot be determined by our implementation of key higher value of the parameter would indicate large number sensitization attack. of gates having high convergence; hence, effect keys placed Fig. 14 Plot of reconvergence vs attack resiliencies and verification failure metric 158 J Hardw Syst Secur (2018) 2:142–161 Fig. 15 Key categories used in calculating key structure metric. a Isolated, weight = 0. b Convergent, weight = 10. c Partly convergent, weight = 1. d Dominant, weight = 5. e Partly dominant, weight = 1 5.4 Comparative Analysis The last five rows of the table present the comparison of metrics that we propose. The assessment has been done by We evaluated existing and proposed metrics for all of the comparing the average metrics of all benchmarks for each selected 720 samples. Averaging over each obfuscation method. Though these metrics vary largely for any specific method provides a deeper insight into the structural method, the ranges of value that the metrics can have differ changes that occur because of the obfuscation. Comparative for methods. The table contains relative variation of metrics representation of these metrics for the methods we have for different obfuscation methods. implemented is visualized in Fig. 16. The well-known metric in evaluation of obfuscation, Hamming distance, is found not distinguishable for different methods, which 6 Future Directions indicates its limitation in relative analysis. On the contrary, proposed metrics (verification failure, differential entropy, While the paper presents a well-chosen set of benchmarks, reconvergence,and key structure) are found to be more several different metrics for quantitative comparison of sensitive to variation of methods. This property makes the quality of obfuscation, and extensive analysis of the these metrics suitable for comparative analysis of different benchmarks using these metrics, there remain many new methods. opportunities for contribution by the peer researchers. Next, We have summarized our findings from the analysis in we describe several possible areas where future research can Table 3. The first three rows shows the comparison of over- be directed. heads between different methods of obfuscation. AntiSAT benchmarks have high overhead because these benchmarks – Metrics: In our analysis, we have seen trends that show how the obfuscation metrics relate to attack resiliencies contain SAT resiliency logic which is quite large compared to the small original circuit. BDD obfuscation benchmarks and other features. But these were drawn from 720 samples (72 different benchmarks, 10 samples each). incur higher area and power overhead because we did not We need to look deeper into the relations with large performed the optimization with BDS tool on most of the number of samples from more benchmarks and inspect benchmarks (see Section 5.1). relations among multiple metrics simultaneously. In The fourth and fifth rows in Table 3 represent the com- parative attack resiliencies of the methods. For SAT attack, our ongoing work, we plan to perform large-scale characterization of the metrics, optimize, find a global all benchmarks without any SAT-resilient technique are vulnerable. AntiSAT benchmarks are completely resilient quality metric from multiple qualitative metrics to against the attack. AntiSAT BDD benchmarks show mod- compare different methods, and utilize the metrics in erate resiliency against SAT attack (see Section 5.2 for strengthening obfuscation. details). For key sensitization attack, only BDD benchmarks – Larger circuits: We have worked with ISCAS85 since are found to be completely resilient. they are the most widely used benchmark in several Fig. 16 Variation of metrics for different methods J Hardw Syst Secur (2018) 2:142–161 159 Table 3 Summary of comparative analysis Random SLL Cone size AntiSAT AntiSAT AntiSAT BDD BDD BDD Random SLL Cone size Random AntiSAT Entropy Area Overhead Low Low Low Medium Medium Medium High High Medium Power Overhead Low Low Low Medium Medium Medium High High Medium Timing Overhead Low Low Medium Low Low Medium Medium Medium Low SAT attack resiliency Low Low Low High High High Low Medium Low Key sens. attack resiliency Low Medium Medium Low Medium Medium High High High Verification failure metric High Medium Low High Medium Low High Low High Entropy Medium Medium Medium Medium Medium Medium Low Medium High Differential entropy High High High High High High Medium Low Medium Reconvergence Medium Medium Medium Low Low Low Medium High Low Key structure metric Low Low Medium Medium Medium Medium High High High Green stands for desirable, red for undesirable, and yellow for in between VLSI fields. In our future work, we plan to construct that we have worked on already. We want to simi- large benchmarks tailored particularly for hardware larly combine other methods and observe the resultant obfuscation. We also plan to work on industrial designs resiliency. and on how we can make obfuscation feasible for those. – New obfuscation techniques: Since hardware obfusca- – BDD benchmarks: The method of modifying BDD tion is an active area of research, many different tech- for obfuscation appears to be strong against attacks niques are being regularly proposed. We are working . But because of implementing the BDD in circuit to incorporate as many of those as we can to generate with network of MUXs, the method suffers from high obfuscation benchmarks and evaluate their resiliency overhead. Future work can focus on optimizing the against existing and new attacks. technique to limit the overhead in acceptable range. – Trust-Hub: We welcome researchers to upload their – Sequential obfuscation: Along with the combinational obfuscation benchmarks on Trust-Hub  with our benchmarks, we are working on benchmarking sequen- suite of benchmarks. It is recommended to include tial obfuscation. A new suite of such benchmarks will supporting documentation and to follow our naming be published in the near future. convention. More benchmarks with different methods – Behavioral obfuscation: Most of the proposed obfusca- will benefit researchers with wider selection and more tion techniques are based on modification of structural features to evaluate methods and attacks. description of a design. Until now, we have worked in netlist representation. We are planning to design an algorithm to perform the obfuscation at the behavioral 7 Conclusion level. This is more challenging because the represen- tation can include many style and patterns in coding. With growing interest in hardware obfuscation, it is Also, the effect of obfuscation after synthesis still needs necessary to have standard obfuscation benchmarks to to be evaluated. evaluate and compare various obfuscation techniques and – Combination of multiple techniques: We have imple- attacks. We have developed the first of such benchmarks. mented each technique individually, as was proposed in The benchmarks are available on trust-hub.org, and we corresponding literatures. In our future work, we plan encourage researchers to use these benchmarks in lieu of to mix-and-match different techniques and evaluate the arbitrarily generated benchmarks. We have also performed detailed analysis of the benchmarks and developed a effect. It is desirable to find the optimum ratio of mix- ing more techniques that would give the best resiliency few obfuscation metrics in process. These metrics have against known and future attacks. By mixing, we refer close relation with attack resiliencies and also, in some to choose a portion of the key size to be implemented cases, overheads. For example, our proposed reconvergence with one technique and another portion with some other metric is found to be proportional to key sensitization technique and so on, and the ratio of the key sizes is attack resiliency and inversely proportional to SAT attack the ratio of mixing. AntiSAT technique is such a system resiliency. These conclusions will lead our future work to 160 J Hardw Syst Secur (2018) 2:142–161 improve the proposed metrics, develop new ones, and utilize International conference on VLSI design, 2010. VLSID’10. IEEE, pp 405–410 the metrics in security assessment. 14. Chakraborty RS, Bhunia S (2011) Security against hardware trojan attacks using key-based design obfuscation. J Electron Test Funding Information This work is supported by Cisco Systems, Inc., 27(6):767–785 NSF under grant CNS 1651701, and AFOSR under award number 15. Collberg C, Thomborson C, Low D (1997) A taxonomy of FA9550-14-1-0351. obfuscating transformations. Tech. rep. Department of Computer Science. The University of Auckland, New Zealand 16. Contreras GK, Nahiyan A, Bhunia S, Forte D, Tehranipoor M Open Access This article is distributed under the terms of the (2017) Security vulnerability analysis of design-for-test exploits Creative Commons Attribution 4.0 International License (http:// for asset protection in SoCs. In: 2017 22nd Asia and South creativecommons.org/licenses/by/4.0/), which permits unrestricted Pacific design automation conference (ASP-DAC). IEEE, pp 617– use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a 17. Corno F, Reorda M, Squillero G (2000) RT-level ITC’99 link to the Creative Commons license, and indicate if changes were benchmarks and first ATPG results. Des Test Comput IEEE made. 17(3):44–53. https://doi.org/10.1109/54.867894 18. Hutton M, Grossman JP, Rose J, Corneil D (1996) Characteri- zation and parameterized random generation of digital circuits. References In: Proceedings of the 33rd annual design automation conference. ACM, pp 94–99 19. IEEE Std 1735-2014 (Incorporates IEEE Std 1735-2014/Cor 1- 1. Forte D, Tehranipoor M (2017) Obfuscation Benchmarks. 2015) (2015) IEEE Recommended Practice for Encryption and Trust-HUB.org, Trust-HUB. http://www.trust-hub.org/OBFbench Management of Electronic Design Intellectual Property (IP), 1– marks.php 90. https://doi.org/10.1109/IEEESTD.2015.7274481 2. Alkabani Y, Koushanfar F (2007) Active hardware metering for 20. Imeson F, Emtenan A, Garg S, Tripunitara MV (2013) Securing intellectual property protection and security. In: USENIX security computer hardware using 3d integrated circuit (IC) technology and symposium, pp 291–306 split manufacturing for obfuscation. In: Proceedings of the 22th 3. Alkabani Y, Koushanfar F, Potkonjak M (2007) Remote activation USENIX security symposium. Washington, pp 495–510 of ICs for piracy prevention and digital right management. In: 21. Kahng AB, Lach J, Mangione-Smith WH, Mantik S, Markov IEEE/ACM International conference on computer-aided design, IL, Potkonjak M, Tucker P, Wang H, Wolfe G (1998) Water- 2007. ICCAD 2007. IEEE, pp 674–677 marking techniques for intellectual property protection. In: De- 4. Amir S, Shakya B, Forte D, Tehranipoor M, Bhunia S (2017) sign Automation conference, 1998. Proceedings. IEEE, pp 776– Comparative analysis of hardware obfuscation for IP protection. In: Proceedings of the on great lakes symposium on VLSI 2017. 22. Kocher P, Jaffe J, Jun B (1999) Differential power analysis. In: ACM, GLSVLSI ’17, pp 363–368 Advances in cryptology—CRYPTO’99. Springer, pp 789–789 5. Barak B, Goldreich O, Impagliazzo R, Rudich S, Sahai A, Vadhan 23. Koushanfar F, Potkonjak M (2007) CAD-based security, cryptog- S, Yang K (2012) On the (im)possibility of obfuscating programs. raphy, and digital rights management. In: Proceedings of the 44th J ACM 59(2):6,1–6,48 annual design automation conference. ACM, pp 268–269 6. Berkeley Logic Synthesis and Verification Group (2004) ABC: a 24. Macii E, Poncino M (1996) Exact computation of the entropy of system for sequential synthesis and verification. http://www.eecs. a logic circuit. In: Sixth Great lakes symposium on VLSI, 1996. berkeley.edu/alanmi/abc/ Proceedings. IEEE, pp 162–167 7. Bhatkar S, DuVarney DC, Sekar R (2003) Address obfuscation: 25. Manual SU (2005) TetraMAX ATPG user guide. Version X- an efficient approach to combat a broad range of memory error 200509, pp 249–264 exploits. In: USENIX Security symposium, vol 12, pp 291–301 8. Brglez F, Fujiwara H (1985) A neutral netlist of 10 combinational 26. Massad ME, Zhang J, Garg S, Tripunitara MV (2017) Logic benchmark circuits and a target translator in fortran. In: locking for secure outsourced chip fabrication: a new attack and Proceedings of IEEE Int’l symposium circuits and systems provably secure defense mechanism. arXiv:170310187 (ISCAS 85). IEEE Press, Piscataway, pp 677–692 27. Mishra P, Tehranipoor M, Bhunia S (2017) Security and trust 9. Brglez F, Bryan D, Kozminski K (1989) Combinational profiles of vulnerabilities in third-party IPs. In: Hardware IP security and sequential benchmark circuits. In: IEEE International symposium trust. Springer, pp 3–14 on circuits and systems, 1989, vol 3, pp 1929–1934. https://doi. 28. Narasimhan S, Chakraborty RS, Chakraborty S (2012) Hardware org/10.1109/ISCAS.1989.100747 ip protection during evaluation using embedded sequential Trojan. 10. Business Wire (2017) Inside secure unveils industry’s first IEEE Des Test Comput 29(3):70–79 root-of-trust solution based on RISC-V processor. https:// 29. Rahman MT, Forte D, Shi Q, Contreras GK, Tehranipoor M www.businesswire.com/news/home/20171114006581/en/ (2014) CSST: an efficient secure split-test for preventing IC Secure-Unveils-Industry piracy. In: IEEE 23rd NATW 2014. Johnson City, pp 43–47 11. Chakraborty RS, Bhunia S (2008) Hardware protection and 30. Rajendran J, Pino Y, Sinanoglu O, Karri R (2012) Logic authentication through netlist level obfuscation. In: Proceedings of encryption: a fault analysis perspective. In: DATE 2012. Dresden, the 2008 IEEE/ACM international conference on computer-aided pp 953–958 design. IEEE Press, pp 674–677 31. Rajendran J, Sinanoglu O, Karri R (2013) Is split manufacturing 12. Chakraborty RS, Bhunia S (2009) Security against hardware secure? In: DATE 13. Grenoble, pp 1259–1264 trojan through a novel application of design obfuscation. In: 32. Rajendran J, Ali A, Sinanoglu O, Karri R (2015) Belling the Proceedings of the 2009 international conference on computer- CAD: toward security-centric electronic system design. IEEE aided design. ACM, pp 113–116 Trans Comput-Aided Des Integr Circ Syst 34(11):1756–1769 13. Chakraborty RS, Bhunia S (2010) RTL hardware IP protection 33. Rostami M, Koushanfar F, Rajendran J, Karri R (2013) Hardware using key-based control and data flow obfuscation. In: 23rd security: threat models and metrics. In: Proceedings of the J Hardw Syst Secur (2018) 2:142–161 161 international conference on computer-aided design. IEEE Press, 41. Subramanyan P, Ray S, Malik S (2015) Evaluating the security of pp 819–823 logic encryption algorithms. In: IEEE Intl. symposium on HOST 34. Roy JA, Koushanfar F, Markov IL (2008) EPIC: ending piracy 2015. Washington, pp 137–143 of integrated circuits. In: Design, Automation and test in Europe, 42. Subramanyan P, Ray S, Malik S (2015) SAT attack tool. https:// DATE 2008. Munich, pp 1069–1074 bitbucket.org/spramod/host15-logic-encryption 35. Roy JA, Koushanfar F, Markov IL (2010) Ending piracy of 43. Syphermedia (2018) Syphermedia. http://www.smi.tv/ integrated circuits. Computer 43(10):30–38 44. Xie Y, Srivastava A (2016) Mitigating sat attack on logic locking. 36. Shakya B, Asadizanjani N, Forte D, Tehranipoor MM (2016) Chip IACR Cryptology ePrint Archive 2016:590 editor: leveraging circuit edit for logic obfuscation and trusted 45. Xu X, Shakya B, Tehranipoor MM, Forte D (2017) Novel bypass fabrication. In: Proceedings of the 35th ICCAD 2016. Austin, p 30 attack and BDD-based tradeoff analysis against all known logic 37. Shakya B, Tehranipoor M, Bhunia S, Forte D (2017) Introduction locking attacks. In: International conference on cryptographic to hardware obfuscation: motivation, methods and evaluation. hardware and embedded systems. Springer, pp 189–210 hardware protection through obfuscation. Springer, chap 1, pp 46. Yang C, Ciesielski M (2002) BDS: a BDD-based logic 3–32 optimization system. IEEE Trans Comput-Aided Des Integr Circ 38. Shamsi K, Li M, Meade T, Zhao Z, Pan DZ, Jin Y (2017) AppSAT: Syst 21(7):866–876 approximately deobfuscating integrated circuits. In: 2017 IEEE 47. Yasin M, Mazumdar B, Rajendran JJV, Sinanoglu O (2016) International symposium on hardware oriented security and trust Sarlock: SAT attack resistant logic locking. In: IEEE Intl. (HOST). IEEE, pp 95–100 symposium on HOST 2016. McLean, pp 236–241 39. Shen Y, Zhou H (2017) Double DIP: re-evaluating security of 48. Yasin M, Rajendran JJV, Sinanoglu O, Karri R (2016) On logic encryption algorithms. In: Proceedings of the on great lakes improving the security of logic locking. IEEE Trans CAD of Integr symposium on VLSI 2017. ACM, pp 179–184 Circ Syst 35(9):1411–1424 40. Skudlarek JP, Katsioulas T, Chen M (2016) A platform 49. Yasin M, Mazumdar B, Sinanoglu O, Rajendran J (2017) Security solution for secure supply-chain and chip life-cycle management. analysis of anti-sat. In: 2017 22nd Asia and South Pacific on Computer 49(8):28–34 design automation conference (ASP-DAC). IEEE, pp 342–347
Journal of Hardware and Systems Security – Springer Journals
Published: Jun 4, 2018
It’s your single place to instantly
discover and read the research
that matters to you.
Enjoy affordable access to
over 18 million articles from more than
15,000 peer-reviewed journals.
All for just $49/month
Query the DeepDyve database, plus search all of PubMed and Google Scholar seamlessly
Save any article or search result from DeepDyve, PubMed, and Google Scholar... all in one place.
Get unlimited, online access to over 18 million full-text articles from more than 15,000 scientific journals.
Read from thousands of the leading scholarly journals from SpringerNature, Elsevier, Wiley-Blackwell, Oxford University Press and more.
All the latest content is available, no embargo periods.
“Hi guys, I cannot tell you how much I love this resource. Incredible. I really believe you've hit the nail on the head with this site in regards to solving the research-purchase issue.”Daniel C.
“Whoa! It’s like Spotify but for academic articles.”@Phil_Robichaud
“I must say, @deepdyve is a fabulous solution to the independent researcher's problem of #access to #information.”@deepthiw
“My last article couldn't be possible without the platform @deepdyve that makes journal papers cheaper.”@JoseServera