TPAD: Hardware Trojan Prevention and Detection for Trusted Integrated Circuits Tony F
Total Page:16
File Type:pdf, Size:1020Kb
TCAD-2015-0006 1 TPAD: Hardware Trojan Prevention and Detection for Trusted Integrated Circuits Tony F. Wu, Student Member, Karthik Ganesan, Student Member, Yunqing Alexander Hu, Student Member, H.-S. Philip Wong, Fellow, Simon Wong, Fellow, Subhasish Mitra, Fellow Abstract— There are increasing concerns about possible we stop a hardware Trojan from being inserted. Part of the malicious modifications of integrated circuits (ICs) used in challenge in detecting or preventing hardware Trojans arises critical applications. Such attacks are often referred to as from the fact that the methods for inserting Trojan attacks are hardware Trojans. While many techniques focus on hardware numerous (e.g., [2][5] for a comprehensive list). Trojan detection during IC testing, it is still possible for attacks out to go undetected. Using a combination of new design techniques a) c) Vdd Vdd and new memory technologies, we present a new approach that + in detects a wide variety of hardware Trojans during IC testing and out Vdd/2 b) D Q also during system operation in the field. Our approach can also in prevent a wide variety of attacks during synthesis, clk 0 Vdd/2 Vdd place-and-route, and fabrication of ICs. It can be applied to any Fig. 1. Examples of hardware Trojans. a) Modification of functional behavior digital system, and can be tuned for both traditional and through logic changes; b) Electrical changes such as changing timing split-manufacturing methods. We demonstrate its applicability characteristics; c) Reliability changes such as accelerating aging with NBTI. for both ASICs and FPGAs. Using fabricated test chips with Trojan emulation capabilities and also using simulations, we Trojan insertion methods include (but are not limited to): demonstrate: 1. The area and power costs of our approach can • Modification of RTL or layout by malicious CAD tools range between 7.4-165% and 0.07-60%, respectively, depending without the designer’s knowledge [6]. on the design and the attacks targeted; 2. The speed impact can be minimal (close to 0%); 3. Our approach can detect 99.998% of • IC modification anytime between tapeout and fabrication, Trojans (emulated using test chips) that do not require detailed since it is possible to reverse engineer (complete or partial) knowledge of the design being attacked; 4. Our approach can netlists from layouts [7][8]. Such modifications may be prevent 99.98% of specific attacks (simulated) that utilize applied to all or a sample of fabricated ICs. IC modification detailed knowledge of the design being attacked (e.g., through can span a wide range from circuit modification to reverse-engineering). 5. Our approach never produces any false modification of the doping profile of a few transistors [9]. positives, i.e., it does not report attacks when the IC operates correctly. • Malicious reprogramming of systems implemented in reconfigurable platforms (such as FPGAs) with incorrect Index Terms — Hardware Security, Hardware Trojan, 3D functionality before startup or during field operation [10]. Integration, Resistive RAM, Concurrent Error Detection, • Leakage of information, e.g., through fluctuations in IC Randomized Codes, Split-manufacturing, Reliable Computing. power consumption [11]. I. INTRODUCTION Existing techniques for hardware Trojan detection exhibit HERE is growing concern about the trustworthiness of one or more of the following limitations (in-depth discussion T integrated circuits (ICs). If an untrusted party fabricates an in Section VII): IC, there is potential for an adversary to insert a malicious 1. Some techniques rely on IC testing for Trojan detection, hardware Trojan [1], an unauthorized modification of the IC which alone limits the scope of Trojans. For example, resulting in incorrect functionality and/or sensitive data being Trojans activated by a “time-bomb” [2][12] or accelerated exposed [2]. These include (but are not limited to) [3]: circuit aging [4] may not be detected. a) Modification of functional behavior through logic changes: 2. Nondestructive visual inspections can be circumvented by For example, extra logic gates may be inserted to force an carefully hiding Trojans [9]. For example, an adversary can incorrect logic value on a wire at some (arbitrary) point in change the doping profile of transistors. Without IC time (Fig. 1a) [2]. delayering, detection becomes increasingly difficult due to b) Electrical modification: For example, extra capacitive limited imaging depth, especially for 3D ICs [53]. loading may be placed on a circuit path to alter timing 3. Destructive IC testing is effective only when the percentage characteristics of the IC (Fig. 1b) [2]. of ICs attacked is high (e.g., many chips on a wafer must be c) Reliability degradation: For example, aging of transistors attacked), as shown in Section VII.A. (e.g., Negative Bias Temperature Instability (NBTI)) may 4. IC fingerprinting, such as circuit path delays, leakage be accelerated, degrading reliability (Fig. 1c) [4]. power, heat or switching activity, relies on statistical models A hardware Trojan is detected when we report malicious to distinguish between malicious activities vs. variability modifications to an IC. A hardware Trojan is prevented when during manufacturing or normal operation. This makes Manuscript received January 9, 2015; revised May 8, 2015; accepted July 20, sufficiently small Trojans undetectable [13]. Moreover, such 2015. Work supported by IARPA Trusted Integrated Chips (TIC) Program. techniques are prone to reporting false positives [90]. All authors are with Dept. of Electrical Engineering, Stanford University, 5. Error-detecting codes [16] can be compromised if the code Stanford, CA 94305 USA (e-mail: [email protected]). S. Mitra is also with Dept. of Computer Science, Stanford University. construction is known. TCAD-2015-0006 2 This paper presents a Trojan Prevention and Detection description of TPAD, experimental results from test chips, as (TPAD) architecture for digital systems. TPAD enables well as various implementation trade-offs with respect to area, test-time and runtime detection of Trojans inserted during power, and delay. The TPAD architecture is introduced in fabrication. TPAD prevents insertion of Trojans during Section II and Section III. Section IV presents an fabrication based on sophisticated reverse-engineering of the implementation of the TPAD architecture that can be used for design being fabricated. TPAD also prevents Trojan insertion any arbitrary digital system. For general processor designs, during logic synthesis and layout design. such as OpenRISC [39], the key results of TPAD are: In this paper, we assume that logic synthesis tools, physical 1. Area overheads range from 114% to 165% with 34% to design tools, as well as IC fabrication are untrusted, meaning 61% power overheads. CAD tools and/or foundries can insert Trojans (Fig. 2a). 2. Near 0% speed impact can be achieved (through additional However, we do require the RTL or system specification as pipelining in the TPAD architecture). well as system assembly to be trusted, meaning that an 3. The corresponding detection rate for uninformed attacks adversary cannot insert a Trojan during these stages. (attacks that do not require detailed knowledge of the a) design before inserting a Trojan) ranges from 87.5%-99.6%. Pre-tapeout b) System Inputs System Outputs RTL Trusted Data 4. TPAD prevents sophisticated attacks requiring some Synthesis Chip 1 Chip 2 Chip n Trojans can detailed knowledge of the implemented design (launched by P&R be inserted System Fabrication Trojans can CAD tools or foundries) with a rate ranging from 96.2% to Combinational activate Assembly Primary Logic Primary 99.98% (Section III). Post-Manufacture Test Inputs k bits Outputs Flip-flops In Section IV.C, we also demonstrate TPAD for fabricated Field Operation Post-tapeout Vulnerable to Trojans FPGA test chips. Section V presents TPAD implementations Fig. 2. a) Assumptions on when Trojans can be inserted or activated. b) Assumptions on vulnerable system and chip components. for specialized (accelerator) designs, such as a Lempel-Ziv (LZ77) data compressor test chip [45] and a Fast Fourier The following are some of the important TPAD features: Transform (FFT) engine [41]. For such accelerators, the key 1. TPAD detects hardware Trojans that produce incorrect results are: Boolean logic value(s) that propagate to sequential elements 1. TPAD area overheads can be 7.4%. (flip-flops, latches), on-chip memories, or I/O pins. 2. TPAD detects 99.998% of uninformed attacks. 2. TPAD has a 0% false positive rate, i.e., it does not report We further show that for LZ77 data compression, Trojan detection when the IC operates correctly. performance metrics such as compression ratio (CR) can be 3. TPAD can be used for Trojan detection concurrently during traded off for area overhead with no impact on Trojan post-manufacture IC testing and also during field operation detection and prevention. (concurrently during system operation or through periodic In Section VI, we discuss how to TPAD can be used to testing). As a result, Trojans triggered by rare events such as prevent logic synthesis and physical design tools from time bomb attacks can be detected. If used in conjunction inserting Trojans. Section VII compares and contrasts existing with system-level recovery techniques (such as those used Trojan detection and prevention approaches vs. TPAD. for fault-tolerant computing), it may be possible to recover Section VIII concludes the paper. from many attacks (Appendix B). Since TPAD significantly Appendix A presents a detailed discussion of various attack improves the observability of signals inside an IC, test-time types. Appendix B discusses possible approaches to recover Trojan detection is expected to be significantly enhanced from Trojans. compared to traditional functional testing. II. SYSTEM ARCHITECTURE OVERVIEW 4. The hardware overhead associated with TPAD is flexible, TPAD is derived from the concept of Concurrent Error and can be adjusted based on targeted attack models and Detection (CED) [19] for fault-tolerant computing. The implemented functionality. “classical” CED approach is illustrated in Fig 3a: given a 5.