Preventive Techniques for Hardware Trojans

Transcription

1 Masaryk University Faculty of Informatics Preventive Techniques for Hardware Trojans Master Thesis Manoja Kumar Das Hyderabad, December 216

2

3 Masaryk University Faculty of Informatics Preventive Techniques for Hardware Trojans Master Thesis Manoja Kumar Das Hyderabad, December 216

4

5 Replace this page with a copy of the official signed thesis assignment and the copy of the Statement of an Author.

6

7 Declaration Hereby I declare that this thesis is my original authorial work, which I have worked out on my own. All sources, references, and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Manoja Kumar Das Advisor: prof. RNDr. Vaclav Matyas i

8

9 Acknowledgement I thank my supervisor prof. RNDr. Vaclav Matyas, M.Sc., Ph.D., for his kind guidance and valuable feedback on my writing. I would also like to thank prof. Chester Rebeiro of IIT, Madras for providing his valuable time to define the work of this thesis through various sessions of discussion. Last but not least, I thank my family, friends and staff of the Faculty of Informatics for their cooperation during my studies. iii

10 Abstract Hardware Trojan is a malicious modification of hardware during design or fabrication. Hardware Trojans often remain dormant and are activated only under rare circuit conditions. The thesis work will be focused on emerging techniques used after a design phase of an integrated circuit (IC) to protect against the Hardware Trojans. The work will mainly review various techniques applied after the design phase of the IC to prevent activation of Hardware Trojans during use of the IC. These techniques are typically based on static analysis of design, obfuscation of design, and defense in depth strategy. Additionally, the work will explain technique used to prevent insertion of Hardware Trojans during IC fabrication. The thesis will provide a comparative review of various techniques used to prevent activation of different types of Trojans for ICs. The work will also review techniques used prior to fabrication to avoid insertion of Trojans during IC fabrication. iv

11 Keywords Hardware Trojan, hardware security, intellectual-property, integrated circuit, obfuscation, triggers, defense-in-depth, foundry, netlist, combinational logic, sequential logic. v

12

13 Contents 1 Introduction Modern Integrated Circuits Development Life Cycle Hardware Trojan Organization of the Thesis Hardware Trojan Types and Insertion Sources Different Types of Hardware Trojans Classification of Trigger Logic Classification of Payload Logic Hardware Trojan Insertion Sources Hardware Trojan Insertion in Front-end Processes Hardware Trojan Insertion in Back-end Processes 15 3 Preventive Techniques for Design Phase of the IC Assumptions Classification of Preventive Techniques for Design Phase Pre-fabrication Trojan Detection Techniques Runtime Hardware Trojan Disable Techniques Runtime Monitoring Techniques to Detect Trojans 36 4 Preventive Techniques for Fabrication Phase of the IC Design Obfuscation Technique Compact GDS-II Layout Generation Technique Split Fabrication Technique Summary Comparative Review Review of Pre-fabrication Trojan Detection Techniques Review of Runtime Trojan Disable Techniques Review of Runtime Trojan Monitoring Techniques Review of Foundry Side Protection Techniques Defense-in-Depth Approach Conclusions 59 Bibliography 61 vii

14

15 List of Tables 3.1 Truth Table for t Truth Table for I UCI s list of signal pairs Summary of Trust Assumptions for Prefabrication Methods Comparison of features of Pre-fabrication Trojan Detection Techniques Summary of Assumptions for Runtime Trojan Disable Techniques Comparison of features of Runtime Trojan Disable Techniques Summary of Assumptions for Runtime Trojan Monitoring Systems Comparison of features of Runtime Trojan Monitoring Systems Summary of Assumptions for Foundry-side Trojan Prevention Methods Comparison of features of Foundry-side Trojan Prevention Methods. 57 ix

16

17 List of Figures 1.1 Overview of Modern IC development life cycle Simplified Representation of Hardware Trojan Logical Form of Hardware Trojan Classification of Hardware Trojans Based on Trigger Logic General model of a combinational Hardware Trojan Hardware Counter Based Sequential Hardware Trojan Sequence of Events Based Sequential Hardware Trojan Classification of Payload Hardware Trojan Inserted Digital Circuit Data-flow Graph of Example Ckt K-map of circuit shown in Figure K-map of circuit with don t-cares Runtime on-chip Self-monitoring scheme Multicore computing system Design obfuscation based on Modification of State-Transition-Function The BISA Architecture [17] A two IC 3D Integration Technology [18]. 48 xi

18

19 1 Introduction A variety of computing systems are used everywhere such as in consumer, industry, military and government areas. Over the ages, computing hardware is considered as the root-of-trust for the whole computer system. Yet over the past decade, this perception has changed due to the following reasons: 1) the globalization of the integrated circuit (IC) development process, 2) an extensive use of third-party intellectual property (IP) components, 3) the ever-increasing complexity of hardware designs, 4) the growing size of design and verification teams which are distributed across the world, 5) fables IC design houses. Hence, today s ICs are becoming more and more vulnerable to malicious hardware modifications, referred to as Hardware Trojan attacks [1, 2]. Malicious modifications to hardware can occur at IC design house and fabrication house. Traditional post-fabrication IC testing method cannot efficiently detect Hardware Trojans for following reasons, 1) Trojans are mostly stealthy in nature, 2) the spectrum of possible instances of a Trojan is enormous, 3) generally Trojans are activated after a long time after chips are used, 4) an untrustworthy fabrication house can perform malicious modifications in only few ICs, not the complete population. Finally, Hardware Trojans are capable to evade any security measures of a computing system. They can also potentially be used as a foothold for high level software based attacks. Therefore, trusted-ic design has emerged as a new research topic over the past few years. Most of the current research topics in hardware security are focused on techniques to detect the Hardware Trojans or prevent the insertion of Trojans. 1.1 Modern Integrated Circuits Development Life Cycle Modern integrated circuits (ICs) development life cycle involves several processes, and all of these processes must be trustworthy and reliable to ensure trust in ICs. To understand how hardware can be attacked, we have to understand the processes used in its development cycle. Figure 1.1 illustrates the overview of different processes used for a typical IC development life-cycle [3]. In general, the IC life cycle 1

20 1. Introduction can be divided into two phases: design and fabrication. The design phase provides the definition of what the hardware is supposed to do, so it is called the front-end phase. The fabrication phase creates a physical product by using output of design phase, and it is called the back-end phase. Front End Processes Back End Processes Specification Design in HDL Code Design Validation Physical Sysnthesis Fabrication Device Testing Assembly & Deployment Designers, Validation Team Third Party IPs CAD Tools, Std. Cell Library (GDS II / Golden Netlist) Figure 1.1: Overview of Modern IC development life cycle. The front-end phase converts the high level specification into a gate level netlist. 2 I The specification process defines the requirements of the system at higher level and then the architecture of the hardware is designed to meet these requirements. II The design process transforms the architecture of hardware into a precise code using Hardware Description Language (HDL), like Verilog or VHDL. These languages are often Register Transfer Level (RTL) languages. The design is coded into HDL by the in-house design team of the company or code can be bought as intellectual property (IP) from third party vendors. III In design validation process, the design in HDL form undergoes functional simulation using test inputs to verify the correctness of the entire hardware design. This testing process is much more

21 1. Introduction rigorous because hardware bugs are often extremely expensive to fix after fabrication process, that s way the validation team is often much larger than the design team. Formal verification can also be used during validation process to prove the correctness of the design, but it is often not possible for the entire design. Generally design and validation processes are often done in tandem, moving back and forth to uncover bugs. IV In physical synthesis process, the validated functional design is first converted into functional gates and wires, then finally into a golden netlist layout. The design is translated into a golden netlist by using automated computer-aided design (CAD) software tools from commercial companies. The layout form of golden netlist is also called graphic database system (GDS-II) of the design. The Back-end phase converts golden netlist into a hardware system. V In fabrication process, the golden-netlist layout or GDS-II is used by foundry to produce a physical chip. Most of the design houses do not have fabrication facility, so their designs are fabricated in off-shore manufacturing facilities. VI In device testing process, all manufactured chips undergoes the final testing by using automatic test equipment (ATE) to detect any manufacturing faults and random defects occurred during fabrication. This testing is required because yield is never 1% for any manufacturing process. The device testing step is used to test every gate and wire of the chip. VII In assembly process, chips, electronic components (i.e., resistors, capacitors) and mechanical components are mounted on the board. 1.2 Hardware Trojan A Hardware Trojan is any intentional malicious modification of an electronic circuit or design that provides a method for violating the normal or standard operation of the computing system. A Hardware Trojan is a back-door residing at the lowest level of the computing system, and the threat is persistent as long as the tainted 3

22 1. Introduction hardware is in use. It is capable of defeating all security mechanisms of the computing system. Trojans can perform various attacks range from simple targeted attacks to complex software based attacks. A Hardware Trojan can also be used as a foothold for software based attacks, where malicious software is aware of presence of Trojan. Input Good Circuit Malicious Circuit Multiplex Operation Hardware Trojan Figure 1.2: Simplified Representation of Hardware Trojan. Figure 1.2 shows a simplified block diagram of Hardware Trojan in a design [3]. The functionally correct good logic and malicious logic are present together in a design. Both logics outputs are feed into a circuit which behaves functionally as a multiplexer logic. The multiplexer selects output of malicious logic only when the Trojan is activated. The design works as a Hardware Trojan free design whenever the Trojan is not activated, this occurs during design validation process. In the broadest sense, the logical form of a Hardware Trojan can be fundamentally split into two parts: trigger logic and payload logic. Figure 1.3 shows the general logical form of a Hardware Trojan in any design [4]. Generally payload logic is responsible for modifying the internal signals of good circuit by performing some malicious action as intended by the attacker. The trigger logic decides when the payload logic will be activated to change the original behavior of the design. The trigger logic functionality is equivalent to comparator 4

23 1. Introduction Modifying Internal Signals Input Trigger Logic Payload Logic Internal Signals Figure 1.3: Logical Form of Hardware Trojan. logic. The trigger logic is the main component of Hardware Trojan, because it decides whether the Hardware Trojan is active or not at any given point in time, and is also responsible for keeping payload logic inactive and invisible during the design validation process. 1.3 Organization of the Thesis In Chapter 2, the classification of Hardware Trojans based on their trigger or payload mechanisms, and different sources for their insertion are presented. The techniques used to provide protection against Hardware Trojans insertion occurred during the design phase of an IC are discussed in Chapter 3. Chapter 4 presents preventive methods for Hardware Trojans insertion in foundry. In Chapter 5, we provide a comparative review of various preventive techniques used during the design phase and fabrication phase of an IC. Finally, conclusions are drawn in Chapter 6. 5

24 2 Hardware Trojan Types and Insertion Sources 2.1 Different Types of Hardware Trojans According to nature of the design to be attacked, Hardware Trojans can have a large number of possible structures and operating modes. This sub-section describes simple classification of Hardware Trojans based on functionality of trigger logic (activation mechanism) and payload logic (action performed) Classification of Trigger Logic In general, Hardware Trojans are stealthy in nature; this property is achieved by enabling the trigger logic under rare circuit conditions. This kind of Hardware Trojans most often remains dormant and performs the malicious actions only when trigger is enabled. This stealthy nature is used to evade detection during the design-time validation testing and the post-fabrication device testing. Trigger Digital Analog Combinational Rare Value or Single Shot Cheat Code Sequential H/W Counter or Ticking Timebombs Rare Sequences or Sequence Cheat Codes Sensors Hybrid Figure 2.1: Classification of Hardware Trojans Based on Trigger Logic. 6

25 2. Hardware Trojan Types and Insertion Sources Figure 2.1 illustrates the classification of Hardware Trojans based on trigger logic [5]. The trigger mechanism for Hardware Trojans can be classified into two types: digital and analog. Digitally triggered Hardware Trojans uses two common strategies for enabling trigger logic are based on the input data, the passage of time or combination of both. Broadly speaking, digitally triggered Hardware Trojans can again be divided into two types as combinational and sequential. I Combinational trigger mechanism: The trigger circuit enable mechanism is implemented by using the combinational logic and does not contain any memory element such as flip-flop or latch. A Hardware Trojan is activated only when particular set of values are appeared simultaneously at certain internal circuit nodes. These triggering values are sequence of uncommon or rare bits, which don t appears simultaneously at those internal nodes during normal operation of the device. Good Circuit Output G X O X X Y Z X T Payload Trigger Figure 2.2: General model of a combinational Hardware Trojan. For combinational trigger enable mechanism, the attacker has very high degree of control on the Hardware Trojan. But in reality the combinational trigger mechanism may require a reasonably complex state to occur in the device i.e., simultaneously a large set of internal nodes must attain a particular state or value for activation of the Hardware Trojan. The chance of detecting these 7

26 2. Hardware Trojan Types and Insertion Sources 8 trigger values by using random verification method is extremely low. The examples are: a particular word on the data bus is combined with a particular word on the address bus known as single shot cheat code [6] or a set of internal registers attain a specific uncommon state or a specific input pattern that affects address, data & control buses to attain a specific rare state. Figure 2.2 shows a general model of a combinationally triggered Hardware Trojan. When the trigger logic is inactive, i.e., node T will have value 1, the value appears at output node O is same as the value of node G which is output of good circuit. The trigger logic is enabled only when X = 1, Y = 1, Z=1, an extremely rare condition for trigger activation, which makes node T value and results that the value at output node O will be complement of node G. II Sequential trigger mechanism: The sequential trigger circuit is enabled only when a particular sequence of rare events occurs at specific internal circuit nodes with the passage of time, here the triggering mechanism can be implemented by using state machines. An attacker has a massively increased state-space for implementing a sequential trigger mechanism. It is much more difficult to detect these sequences during the design validation testing and device testing of an IC. A hardware counter can be used as simple sequential trigger logic; it is also called as ticking time-bombs. The trigger logic is enabled only when the hardware counter value reaches a particular value after the device has been powered on. For simple timebomb the hardware counter value increments once per clock cycle of the design, therefore it is very easy to implement in the hardware. This triggering mechanism does not depend on any input data, so does not require any software for activation of Hardware Trojan. Here malicious designer is fully aware of number of clock cycles used during the design validation testing and device testing of an IC. So the attacker decided hardware counter value for triggering is such that the timebomb can easily evade detection during these

27 2. Hardware Trojan Types and Insertion Sources testings. For complex nature timebomb, the hardware counter value is not increased by the clock, but increments once per occurrence of some specific events. Good Circuit Output Clock Hardware counter or Enable Specific Event 1 n G X O X X T Payload Trigger Figure 2.3: Hardware Counter Based Sequential Hardware Trojan. Figure 2.3 shows an abstract model of sequential triggering mechanism based on hardware counter for Hardware Trojan. Here the enabling input of a hardware counter can be either clock of the design or occurrence of specific event inside the design. The counter value increments whenever transition occurs at enable input. The trigger logic is enabled only when all bits of counter are 1, which makes node T value and results that the value of output node O will be complement of node G. A sequence of rare events can be used as sequential trigger logic; it is also called as sequence cheat codes [6]. These rare events may not occur over consecutive cycles, but the trigger logic can intelligently monitor internal states to detect the occurrence of these events. This triggering mechanism is very complex from the hardware implementation perspective, and it depends on both data bus and control bus of the design. As the control interface always provides information about events occurring, so it is used by the trigger logic to detect the occurrence of required rare events. 9

28 2. Hardware Trojan Types and Insertion Sources For example, the sequences of events could be mix of read and write operations to a memory unit with multiple words on the data bus combined with multiple words on the address bus. Figure 2.4 shows a general model of sequential triggering mechanism based on sequence of rare events. Good Circuit Output E1 E2 E3 En G X X O X T Input Payload Trigger Figure 2.4: Sequence of Events Based Sequential Hardware Trojan. Hybrid sequential trigger logic uses both hardware counter and sequence of rare events to generate trigger condition for the Hardware Trojan. This kind of Hardware Trojan is much more complex to implement in terms of hardware, because this triggering mechanism needs synchronization between hardware counter and system software used to generate sequence of rare events. III Always-on trigger mechanism: 1 Some Hardware Trojans are "always-on" in nature and are not switched on or off by any particular trigger logic. These Hardware Trojans are often or always perform malicious actions and hence not require specific trigger logic. For example, intentional modification of the fabrication process that can affect certain nodes or paths to have a higher susceptibility to failure. Here the trigger mechanism is to accelerate the wear out of certain paths during operation of device. This type of early failure of device after a certain usage period, typically within a few months to years of operation is known as reliability based Hardware Trojan [7]. These

29 2. Hardware Trojan Types and Insertion Sources time-based early wear-out trigger mechanisms are extremely difficult to detect during post-fabrication testing. Another example is, particular circuit-activity is occurring always inside an IC which could be used for leaking data through a side-channel. The trigger-mechanism can also be analog in nature, where on-chip sensors are used to trigger a malfunction. These sensors could monitor the external environment, such as sensing temperature, voltages, EMI, humidity, and altitude. A Hardware Trojan can be triggered by changes in temperature, for example an inverter-based ring oscillator circuit can be used to produce a lot of switching activity for specific input pattern, this results rise in temperature of the device and subsequently activate a Hardware Trojan [8] Classification of Payload Logic The payload logic is responsible for corrupting normal operation of the device as intended by the attacker. The payload logic can be broadly classified into two categories, based on how payload affects Payload Perform Additional Operations Modify Control Interface of Current Operation Modify Data Interface of Current Operation Figure 2.5: Classification of Payload. the normal operation of the device. The first category of payload does not affect normal operation of the device, but generates new additional operations as intended by the attacker; this is also referred as emitter 11

30 2. Hardware Trojan Types and Insertion Sources backdoor [9]. The aim of this type of payload is to perform the extra work invisibly. On the other hand, the second category of payload will modify the current operation and does not generate any new additional operations. The malicious designer of this type of payload must be aware of the running program, such that the modification of current operation does not crash the system. The second category of payload can be further divided into two parts: payload modifying the data interface of the current operation, this is also referred as data corrupter backdoor and payload modifying the control interface of the current operation, this is also referred as control corrupter backdoor [9]. Figure 2.5 shows the classification of payload logic based on the operation performed when Hardware Trojan is activated. 12 I Payload generates new operations: Here payload circuit performs new additional operations secretly as intended by the attacker without affecting the normal operation of the device. This is mainly used for leakage of secret information and could also involve side-channel attack. For microprocessor based design, one form this attack is to generate new additional instruction fetch from a specific address whenever a particular instruction is executed, and another form of this attack is to generate new additional loads or stores to a specific address whenever a specific instruction is executed. These two methods can be used as foothold for software-based attacks, for example first both methods can be used to store a malicious firmware secretly at on-chip memory, i.e., into the instruction and data caches, and later execute that malicious software within the processor while remaining hidden from the standard software running on the system. For other designs the information is leaked by performing the additional work through serial port interface such as RS-232C port or through thermal emission. This attack can be used to extract the encryption key and password theft. II Payload modifies control interface for current operations: The payload circuit alters control interface of the design to corrupt current operations, such as change access permission of current operations. This is mainly used to escalate the privileges and

31 2. Hardware Trojan Types and Insertion Sources allowing the attacker to bypasses the usual hardware-enforced protections. Here Hardware Trojan can also be used as foothold to assist in software-based attacks, for example the supervisor transition done by Hardware Trojan provides the foothold, that allows unprivileged programs to access privileged instructions and protected resources. For a microprocessor based design, the decoder unit generates control signals for each executed instruction, and here attack is changing the control signal generated for current operations such as converting no-operation instruction into load or store instruction by decoder unit and does not generate any additional operation. III Payload modifies data interface for current operations: The payload circuit modifies data interface of a design to corrupt the current operations. For a microprocessor based design, this attack is to modify the data of memory access operations or change the address of memory access operations or alter the input data of the register file or modify address used to access the register file. This attack can also be used to change the sequence of instructions executed for a program by corrupting specific register value. Here Hardware Trojan can also be used as foothold to assist in software-based attacks For example; change address of current memory access operation method allows access to arbitrary memory locations, so this can be used as foothold for unprivileged malicious software to bypass the memory management unit enforced protections. This attack allows for extracting the encryption key from memory, disabling authentication check by changing content of specific memory location and altering the program flow of system. To summarize, the easiest method to implement is the payload circuit performing additional operations secretly, as this method does not disturb the normal program flow of the system. The main reason is, this method can be easily hidden during normal operation of the system with respect to other methods. 13

32 2. Hardware Trojan Types and Insertion Sources 2.2 Hardware Trojan Insertion Sources By seeing the ICs development life cycle, it can be easily pointed out that hardware security threats can come from any process associated with the design phase and fabrication phase of an IC. This section explains how every process of the ICs development life cycle can possibly be used for the insertion of a Hardware Trojan Hardware Trojan Insertion in Front-end Processes In general, the specification process of a system is considered as trusted, but presence of untrusted personnel at this stage can introduce some specific architecture feature to make provision for insertion of Hardware Trojan for later processes of ICs development life cycle. These features can also be used to perform a software based attack. For microprocessor based design, the vulnerable feature is allocation of unused bits in the encoding format of a specific instruction; this can be used by the malicious personnel to insert Hardware Trojans for particular value of unused bits during HDL-coding process or physical-synthesis process or fabrication process. In the design process, hardware architecture is coded into HDL by in-house design team or code can be bought as an intellectual property (IP) from third party vendors. An attacker at this stage could be any malicious personnel participating in the HDL coding process for the design modules. Here the attacker can be of two types, either insider personnel for in-house HDL coding of the design or outsider for the purchased third party "soft" IP components used in the design. In the case of local attacker, he or she is aware of validation testing process to be used for the design, so the attacker can implement a Hardware Trojan to easily bypass the validation testing process of the design. On the other hand, with an outsider attacker for the third party IP, he or she may not be aware of validation testing process to be used. Additionally, the third party IPs are only supplied with basic functional-validation and interface-verification test suites. Most of the time we do not have a golden reference model for third party IPs to verify them completely. Due to the complexity of modern ICs, generally a black-box verification method is used for the third party IPs and this approach is unlikely to reveal the presence of a Hardware 14

33 2. Hardware Trojan Types and Insertion Sources Trojan. So these third-party IPs and their testing suites may not be trustworthy. In the design validation process, the HDL form of the hardware design is verified to check correctness of the design by using test inputs. Traditionally, the design HDL-coding and design validation are often done in parallel, moving back and forth to verify correctness of design. In the case of local malicious designer for HDL-coding process, there is high chance that, either this attacker can also be a member of design validation team or presence of untrusted personnel in the design validation team.on the other hand, for the third party IP, there is also a possibility that compromised personnel of validation team are incorporation with the malicious outside designer. In both scenarios, the design validation test suites can be made intentionally faulty to ignore the detection of Hardware Trojan at this stage. In the physical synthesis process, first the HDL form of design is synthesized to translate it into functional gates and wires, and then finally convert into a golden netlist layout. At this stage, the automated CAD software tools are used to generate both functional gates and netlist layout. These automated CAD tools being used by design house are purchased from different commercial companies. The CAD tools used for physical synthesis are produced by very few companies across the world. But still these software tools cannot be fully trusted, because these automated tools are capable of inserting the Hardware Trojan into HDL coded design in same manner as the malicious designers can insert Hardware Trojans during HDL coding process. Additionally, these automated CAD tools are capable to analyze functionality of the design, so they can potentially eliminate the preventive circuits from the HDL coded design Hardware Trojan Insertion in Back-end Processes In fabrication process, the physical chip is manufactured by a foundry using the golden netlist-layout of the design. Due to economic reasons, most of the designs are fabricated in off-shore manufacturing facilities across the globe. These foundries are independent third parties; therefore there is a very high possibility that the foundries 15

34 2. Hardware Trojan Types and Insertion Sources can be malicious. In fact, the foundry can easily reverse engineer the golden netlist-layout to extract the functionality of the design. So the foundry can potentially insert Hardware Trojans in same manner as the malicious designers are capable during the HDL coding process and can also be incorporation with the malicious designer. Foundry is the last independent party which works on the design to produce the physical chip, so it can also remove the preventive circuits that have been applied during the design process. Apart from modifying the original design functionality, the foundry can also maliciously modify fabrication process of specific paths of design to accelerate the aging of these paths during operation of device; this attack is used to compromise reliability of chips. Therefore off-shore foundry is considered as powerful attacker. In device testing process, all fabricated chips are tested to detect any manufacturing faults and random defects occurred during fabrication. This post-fabrication testing can also be used to detect the presence of Hardware Trojans in the manufactured chips, which are inserted during the fabrication process. If an untrusted personnel performs this testing, then malicious behaviour of manufactured chips cannot be detected. 16

35 3 Preventive Techniques for Design Phase of the IC For a moderately complex IC, there can be exponentially many different ways to represent Hardware Trojans with different triggering mechanisms and payloads. So it is very difficult to detect these Hardware Trojans and completely remove them from the design before fabrication. However, by incorporating the preventive methods within the design, it is quite possible that Hardware Trojans can be either kept in an inactive state or detected during the in-field use of device. 3.1 Assumptions Following assumptions are necessary for effective implementation of the preventive methods at the design phase. I The company producing the hardware system does not have any malicious intention to damage its own product. II For in-house development, the complete design team is not compromised and only few designers are compromised. III The entire validation or verification team of the organization is not malicious and only a small number of persons are untrusted. IV In general, third party IPs are not provided with complete verification test suites and there is also possibility that an entire third party IP design house is malicious. V A small number of trustworthy engineers will be used to implement the preventive methods correctly to a design. VI These defensive techniques are the last thing to be applied to a design and after this design cannot be accessed by untrusted person. 17

36 3. Preventive Techniques for Design Phase of the IC 3.2 Classification of Preventive Techniques for Design Phase Broadly speaking, the preventive techniques used for protection against Hardware Trojan attacks can be divided into three classes: (a) Pre-fabrication Hardware Trojans detection techniques. (b) Runtime Hardware Trojans disable methods. (c) Runtime Hardware Trojans monitoring methods. The pre-fabrication detection techniques mainly try to detect the presence of Hardware Trojans in the HDL form or gate-level netlist of the design. These techniques are based on generating appropriate verification test vectors for detection of the Hardware Trojans at an IP level. Runtime disable techniques typically attempt to disable the triggering mechanism of the existing Hardware Trojans. As it is very difficult to detect all possible forms of Hardware Trojans, so these techniques are capable of providing protection against specific forms of Hardware Trojan attacks. Runtime monitoring techniques are based on checking the output at block level for the design. This is the last line defence for activated Hardware Trojan, which cannot be detected and disabled by previous two approaches. These techniques often attempt to reduce the effect of an activated Trojan Pre-fabrication Trojan Detection Techniques The pre-fabrication Hardware Trojan detection techniques are based on the detailed functional analysis of the HDL form or gate-level netlist of a design by choosing proper input vectors for each part of the design. 18 I Formal Verification: Theoretically speaking, formal verification is an algorithmicbased approach to prove correctness of a design during design phase. To perform the formal verification, first define formal specification for the design, and then all functions in the specification are defined as properties. The methods used in the formal

37 3. Preventive Techniques for Design Phase of the IC verification are model-checking and property-checking. Formal verification method exhaustively proves the functional properties of a design with an aim to explore to every corner of the design [1]. For small design or modules of a design, formal verification can be used to formally proof the presence or absence of Hardware Trojans in a design. On the other hand for large designs, full formal verification is computationally infeasible, because defining the formal specification itself is extremely hard for such designs. In fact, large designs do not have the golden reference model for verification. So companies usually perform exhaustive functional verification of the large designs to detect Hardware Trojans. II Functional Verification: Functional verification is a simulation-based approach to check correctness of a design during design phase. Exhaustive functional simulation of the design with the help of code coverage and functional coverage can also be used to detect Hardware Trojan. Here all possible states of the design have to be simulated to catch the Hardware Trojan. In general, a simple design can have extremely large number of state space and the traditional functional simulation method only cover a small subset of the total functional space. For large designs, it is an extremely high runtime activity to cover all functional state space using the simulation method to detect Hardware Trojans. So if exhaustive functional simulation method is used, still few state spaces left uncovered. In practice, it is considered that the local attacker is aware of the functional verification techniques used for the design. Therefore for a large design, it is extremely hard, even though it is not impossible, to detect the Hardware Trojans using functional verification techniques. For large designs, both functional verification and formal verification are not suitable for detection of Hardware Trojans. In 19

38 3. Preventive Techniques for Design Phase of the IC the following, we discuss the verification techniques used to detect Hardware Trojans for large designs. These techniques are used to point out the suspicious signal in a design based on the assumption that Hardware Trojans are stealthy in nature. III FANCI: 2 FANCI algorithm performs the static Boolean function analysis of digital design to indicate the existence of Hardware Trojan in the design [11]. FANCI stands for Functional Analysis for Nearlyunused Circuit Identification. FANCI works well for Hardware Trojans that often remains dormant. Here trigger logic is enabled only under rare condition of the trigger inputs, therefore output of the trigger logic rarely affects internal-signals or output of the circuit. The basic working principle of the FANCI algorithm is to identify the sub-circuits of a circuit that weakly influences the output of the circuit and declare these sub-circuits as potentially suspicious. Now security engineers will perform the detailed review of suspicious sub-circuits of the circuit. Without using the traditional functional verification methods, FANCI can find out stealthy Hardware Trojans by identifying rarely affecting input signals of a circuit by using Boolean function analysis. These rarely affecting input signals of the circuit can potentially be used as trigger inputs for Hardware Trojans. FANCI uses a metric called control value to find out the nearly unused circuits of a design.in a design, each intermediate output is a function some of the internal wires which can affect that output. The control value is calculated for each of the internal wires of the design only when they are used as input for an intermediate output signal of the design. The control value for an internal input wire estimates the amount of influence that input has on corresponding internal output signal. FANCI first constructs the truth table for each intermediate output signal with its corresponding internal input wires, and then compute control value for each internal input for that output signal. This vector of control values of internal wires can be used to identify the output wires that look suspicious.

39 3. Preventive Techniques for Design Phase of the IC FANCI next computes heuristic metrics: mean and median on these calculated vectors to decide whether or not any wire is suspicious enough to be signalled for review. Now set a threshold value for both the mean and the median. To determine whether any wire is suspicious or not, FANCI compares each wire s control value against that cut-off threshold value. To decrease the number of false positives, it uses both mean and median. Therefore a wire is signalled as suspicious only if both mean and median are low, i.e., close to zero. Computation of Control Values: (A) Assume an intermediate output signal have m-internal signals as its input (i.e. I 1, I 2,..... I m ), and method for computation of the control value of I1 is given below: (i) Without input I 1, the number of possible values for remaining (m-1) inputs is 2 (m 1). So the truth table of I 1 will have total 2 (m 1) number of rows. (ii) For a fixed value of the inputs (I 2, I 3,.... I m ), now change value of input I 1 from to 1 and check whether or not output changes. (iii) Repeat the step-ii for 2 (m 1) times for all of possible values of (I 2, I 3,... I m ) inputs. (iv) Suppose only for K possible values of the inputs (I 2, I 3,... I m ), the toggle in output occurs for change in input I1 from to 1. Here K < 2 (m 1). (v) The control value of I 1 is : CV(I 1 ) = K / 2 (m 1). (vi) Above steps can be repeated for all inputs to compute their control values. (B) Suppose the intermediate output signal have large number of internal signals as its input, and then computation of control values for these large numbers of inputs becomes exponentially difficult. The main reason for this is: size of the truth table increases exponentially with respect to increase in number of input wires. 21

40 3. Preventive Techniques for Design Phase of the IC (i) For large number of inputs, the size of the truth table is approximated to a constant number (N). (ii) Now randomly select a subset of rows of that constant size (N) from the total number of possible rows of the truth table. (iii) For each value of these selected N possible values of inputs (I 2, I 3,.... I m ), now change value of input I 1 from to 1 and check whether or not output changes. (iv) Suppose only for K possible values from the selected N possible values of the inputs (I 2, I 3,... I m ), there is toggle in output occurs for change in input I1 from to 1. Here K < N. (v) The control value of I 1 is : CV(I 1 ) = K / N. (vi) Above steps can be repeated for all inputs to compute their control values and for each input newly randomly select a subset of rows. (vii) As rows are selected randomly, so the attacker can not know which rows will be selected for analysis. Good Circuit FF5 FF4 I2 I1 G X O X FF3 FF2 FF1 t3 t2 t1 Trigger Logic X T Payload Logic Hardware Trojan Circuit Figure 3.1: Hardware Trojan Inserted Digital Circuit. 22

41 An Example: 3. Preventive Techniques for Design Phase of the IC Figure 3.1 shows a digital circuit infected by a Hardware Trojan. The output node O of the circuit can be considered as an intermediate output of a design. I1, I2 are functional internal input signals of circuit and node G represents original internal output signal of circuit. The output node O will have same value as node G, if Hardware Trojan is inactive. Here t1, t2, t3 are used as trigger inputs and node T is the output of trigger logic. When trigger logic is enabled (i.e. t1 = t2 = t3 = I1 = 1), the output of circuit is corrupted by payload logic which means value of node O is not same as node G. t1 t2 t3 I1 I2 O Table 3.1: Truth Table for t1. I1 t1 t2 t3 I2 O Table 3.2: Truth Table for I1. 23

42 3. Preventive Techniques for Design Phase of the IC The truth table of Boolean functional analysis for trigger input t1 is shown in the Table 3.1. There are only two input patterns for which toggling of t1 results change of the output node O, this is represented in light-gray colour box for Table 3.1. Hence the control value of t1 is: CV(t1) = 2 / 2 4 =.125 The truth table for functional input I1 is shown in Table 3.2. The light-gray colour box are used to highlight toggle in the output node O. The control value of I1 is: CV(I1) = 8 / 2 4 =.5 In similar manner, FANCI computes control values for all other inputs of the circuit and finally obtains a vector of control values for the given circuit. The vector of control values for five inputs [ t1, t2, t3, I1, I2] are: [.125,.125,.125,.5,.5 ] For output node O, the mean and the median values are.275 and.125, respectively. For this circuit both mean and median are close to zero, therefore output node O is suspicious. FANCI would signal t1, t2, t3 as suspicious signals, if the cut-off threshold is set.275. In a design, FANCI performs Boolean functional analysis at module level and does not depend directly on verification techniques. So it can analyse multiple modules of a design simultaneously. Therefore FANCI approach is scaleable and can be applied to very large designs [12]. It is quite possible that the payload logic of a Hardware Trojan can be distributed across multiple modules, but the trigger logic is mostly present only in one circuit of one module. So there is a high probability that FANCI will detect trigger input of stealthy Hardware Trojan. 24

43 3. Preventive Techniques for Design Phase of the IC IV UCI: The BlueChip architecture [13] first demonstrated a hybrid solution based on both hardware and software techniques to identify the Hardware Trojans during the design phase. The BlueChip approach contains a design-time component as well as a runtime component. The design-time component is a hardware technique called as Unused Circuit Identification (UCI), which is used during the design validation or verification stage to detect suspicious circuit by using the functional verification test cases of the design. However, the suspicious circuit can also be a part of a good circuit within the design, that s why BlueChip does not completely remove suspicious circuit from the design. So BlueChip adds an exception generation hardware circuit to the suspicious circuit and this will raise a software exception whenever the suspicious circuit is activated during the running of the device. The runtime component is an additional software module in the exception handler software of the system; this module will provide the necessary support to process these new software exceptions. The additional software module of exception handler software must be capable to emulate the effect of exception generating instruction in software, so that the system runs normally by providing a detour around a suspicious circuit. The system must fulfil the following three requirements to apply the BlueChip techniques. (i) Mechanism to pass the control of the system to software when a hardware exception occurs. (ii) Mechanism to access the hardware state by the software. This is required for recovery of the system when Hardware Trojan is activated (iii) Mechanism to prevent the commit of the modified hardware states. This is required when a software exception is raised. In general, micro-processors having precise exception feature mostly support above three features. Therefore BlueChip approach is mostly suitable for the microprocessor based system. 25

44 3. Preventive Techniques for Design Phase of the IC UCI algorithm uses the functional validation or verification test cases to detect the potentially malicious circuit inserted within the HDL form of design during the design phase of an IC. Generally speaking, the functional verification of a design includes large number of test cases to verify the correctness of the design. During extensive functional verification of the design, UCI identify the parts of the circuit that do not affect the output and consider these parts of the circuit as suspicious.mostly malicious logic do not affect the output during verification, otherwise they would be detected. UCI algorithm performs following two steps to detect malicious logic embedded in the design. (i) First UCI creates a data-flow graph of the circuit. The signalwires and state-elements of the circuit are represented as nodes of the graph and edges are used to represent the dataflow between nodes. Now UCI list the signal pairs derived from this data-flow graph based on the direct and indirect data flow between source node to sink node. (ii) Next UCI performs functional simulation of HDL coded design using verification test cases and find out the signal pairs where intermediate logic does not affect the data flow between source and sink nodes. 26 Identification of unused circuit: Let us consider a signal pair (I,F), where F is dependent on I. Now perform the functional verification using all test cases and check the relation between signals I and F. If it is observed that F = I for all test cases, then the intermediate circuit between F and I is treated as unused circuit. UCI algorithm performs check on all signal pairs of the circuit during the functional verification to identify the signal pairs for which the condition F=I holds for all test cases and report them as suspicious circuitries.

45 3. Preventive Techniques for Design Phase of the IC t2 t1 I2 I1 t3 t2 t1 Figure 3.2: Data-flow Graph of Example Ckt. G T O source sink always same for trigger disabled I1 G No I2 G No I1 T No t1 T No t2 T No t3 T No t1 O No t2 O No t3 O No I1 O No I2 O No T O No G O Yes Table 3.3: UCI s list of signal pairs. An Example: Figure 3.2 shows the data-flow graph of our example circuit as shown in Figure 3.1. The list of all signal pairs for this circuit is shown in Table 3.3. The signal pair (G,O) of this circuit will always satisfy the condition O=G for all verification test cases, if the trigger logic is disabled. Therefore the final report from UCI for this example circuit will be: the signal pair (G,O) will be signalled as suspicious if the trigger logic is not enabled during the functional verification. If all functional verification test-cases of a design can provide the coverage value close to 1% for code coverage and functional 27