Trojans in Early Design Steps—An Emerging Threat Ilia Polian∗, Georg T. Beckery, and Francesco Regazzoniz ∗Universitat¨ Passau, Germany yHorst Gortz¨ Institute for IT Security, Ruhr-Universitat¨ Bochum, Germany zALARI, University of Lugano, Switzerland Abstract—Hardware Trojans inserted by malicious foundries II. BACKGROUND during integrated circuit manufacturing have received substantial attention in recent years. In this paper, we focus on a different The term “hardware Trojans” historically referred to threats type of hardware Trojan threats: attacks in the early steps of associated with outsourcing of advanced semiconductor man- design process. We show that third-party intellectual property ufacturing into potentially untrustworthy countries [1]. The cores and CAD tools constitute realistic attack surfaces and that foundry would receive circuit layout information (in GDS II even system specification can be targeted by adversaries. We or a similar format) and, possibly, further design data, in order discuss the devastating damage potential of such attacks, the to produce masks and manufacture the circuit. The alleged applicable countermeasures against them and their deficiencies. threat consists in an intentional—and malicious—modification I. INTRODUCTION of the circuit by the foundry before manufacturing, such that the fabricated chip has critical deviations from its layout as Historically, IT security concentrated on attack scenarios provided by its author. targeting software and communication networks, but more recently, the system hardware moved into the focus of attack- However, the modern understanding of hardware Trojans ers. Hardware-related threats are relevant even for extremely includes all malicious modifications of a circuit during its cre- software-dominated systems, which still contain some amount ation: by an untrusted foundry (as discussed above), but also by of hardware on which the software runs; compromising this rogue in-house designers, by third-party intellectual-property hardware makes the entire system vulnerable. Even worse, (3PIP) cores, and by CAD tools. Some early publications refer many software-centric security solutions rely on a hardware- to the threats in early design steps (before manufacturing), by based root of trust which stores secret keys and provides names like “malicious insertions” or “rogue silicon” [2] but essential security functions; successful attacks on such root- recent publications use the name “hardware Trojans” to include of-trust blocks renders the entire security concept ineffective. both pre-manufacturing and foundry-level scenarios [3]. With the emergence of paradigms like cyberphysical systems, Fig. 1 shows the standard integrated circuit design flow internet of things, or Industrie 4.0 that unify the physical world, and indicates sources of possible Trojan threats. Moreover, the IT systems and global connectivity, hardware blocks are at risk lower part of Fig. 1 shows both: standard quality-assurance to become the Achille’s heel of entire infrastructures. techniques which have the potential to identify Trojans, and, This paper considers one emerging attack scenario: Hard- in blue, approaches specifically designed to counter Trojans. ware Trojans. These are malicious modification of system Table I provides a more detailed overview of different types hardware with the purpose to gain control over its functionality of hardware Trojans. In the following, we discuss the current and, e.g., be able to deactivate the affected block at the understanding of both foundry-level Trojans and Trojans in attacker’s will (“kill switch”), or establish a side-channel to early design steps, whereas subsequent sections will treat access confidential data processed by the device (“backdoor”). under-investigated classes of hardware Trojans in more detail. The term “hardware Trojans” was traditionally associated with threats stemming from external, untrusted foundries. However, A. Foundry-level hardware Trojan threats this paper is specifically concerned with Trojans that are intro- duced into the system during early design steps by a rogue in- Suppose that a sensitive industrial or military system has a house designer, by an external provider of intellectual property restriction of its geographical location, i.e., it can be operated blocks integrated into the design, or even by a computer-aided at its legitimate buyer’s site but cannot be moved to a different desing (CAD) tools. An under-investigated attack surface is the system specification which is created in a lengthy and complex TABLE I. ATTACK SURFACES FOR DIFFERENT TYPES OF TROJANS process. If an attacker succeeds in planting a Trojan during the specification phase, such a Trojan is extremely hard to detect, Trojans in circuit specification because any trusted reference is completely lacking. Trojans in early design steps Third-party IP core CAD tools The remainder of this paper is organized as follows. In Trojans in 3PIP core’s Trojans inserted by the next section, background information on hardware Trojans RTL description high-level synthesis tool is given. Two underestimated classes of threats: Trojans that Trojans in 3PIP core’s Trojans inserted by directly affect the circuit specification and Trojans in CAD gate-level netlist logic synthesis tool tools, are discussed in Sections III and IV, respectively. Known Trojans in 3PIP core’s Trojans inserted by countermeasures and detection methods are reviewed in Sec- GDS2 layout physical design tool tion V, and their applicability and efficacy to Trojans in early design steps is evaluated. Section VI concludes the paper. Foundry-level Trojans Third-Party IP Cores Trojans in IP Cores Synthesizable Synthesized GDS2 Standard Cell Trojans in CAD Tools HDL Netlist Data Library Threats Foundry-level Trojans Design Flow Trojan Specifi- High-level RTL Logic Gate-level Physical Layout Manu- Integrated Operation cation Synthesis Description Synthesis netlist Design (GDS2) facturing Circuit (in field) Conventional Quality Assurance: Pre-silicon Post-silicon Formal Verification Layout-vs Schematic Manufacturing On-line Test monitoring Simulation Design Rule Check Post-silicon Self- Timing Analysis Validation checking Pre-silicon Trojan Countermeasures Post-silicon Trojan Countermeasures Trust Susceptible Functional Split Manu- Ring Concurent Error Verification Signal Scoring Test facturing Oscillators Detection / TPAD Correlation Optical Side-channel Security Built-in Self- Obfuscation Analysis Inspection Analysis Monitors authentication Countermeasures Fig. 1. Overview of circuit design flow, Trojan threats and countermeasures site or given to a third party. To implement this functionality, will likely lead to discovery of the manipulation. The outcome one of this system’s circuits includes a module that checks GPS will be enormous legal claims against both the foundry and coordinates and disables the system when they don’t match the individual(s) responsible and a complete collapse of the specification. The foundry-level attacker could find this module foundry’s reputation. In contrast to other hardware security by reverse-engineering and deactivate the protection by dis- threats which can be performed by individual, anonymous connecting its output—a minimal modification which does not attackers (like extracting secret data from smart cards by side- require extensive redesign. A further easy manipulation would channel analysis), foundries are relatively few in number and be to determine cryptographic blocks that drive an encrypted inseparably attached to their equipment that cannot be quickly bus and to disconnect them, such that the bus receives the relocated. As a consequence, all Trojan manipulations are data in cleartext. Then, an attacker who has physical access extremely risky for the foundry, because it would be pretty easy to the chip can read out the protected data from the now- to hold accountable. While it would be wrong to rule out their unencrypted bus. If the malicious foundry is concerned about possibility by this argument, not a single fully documented case legitimate users noticing the absence of encryption, it could was reported by now (the manipulation in [4] turned out to be replace original crypto modules by self-designed blocks which an undocumented test-access feature rather than an attack). modify the data in a way that is easily reversed by an attacker. B. Early-design-step hardware Trojan threats The key question in this context is why a foundry would want to introduce malicious modifications into circuits of One of the first hardware Trojan demonstrations was a their customers. The foundry does not have a direct benefit manipulation of the fuel rod position control block in a nuclear from deactivation of GPS-powered location checker module. reactor [5]. The Trojan affected the hardware module which In theory, a potential illegitimate buyer of the equipment in forwards the temperature readings, thus making the reactor question (e.g., one residing in a country to which export unstable despite redundancy and failsafe mechanisms. King et restrictions are in place) could bribe the foundry to deactivate al. [6] developed techniques to disable memory protection in the protection. In practice, it is extremely unlikely that the a microprocessor and introduce a “shadow mode” where full- buyer even knows which foundry will fabricate the circuits for privilege instructions could run invisible to software. Based on the equipment of interest, and the sheer number of factors that these mecanisms,