Detecting and Removing Malicious Hardware Automatically

Appears in Proceedings of the 31st IEEE Symposium on Security & Privacy (Oakland), May 2010 Overcoming an Untrusted Computing Base: Detecting and Removing Malicious Hardware Automatically Matthew Hicks, Murph Finnicum, Samuel T. King Milo M. K. Martin, Jonathan M. Smith University of Illinois at Urbana-Champaign University of Pennsylvania Abstract hardware-level vulnerabilities would likely require phys- ically replacing the compromised hardware components. The computer systems security arms race between at- A hardware recall similar to Intel’s Pentium FDIV bug tackers and defenders has largely taken place in the do- (which cost 500 million dollars to recall five million main of software systems, but as hardware complexity chips) has been estimated to cost many billions of dollars and design processes have evolved, novel and potent today [7]. Furthermore, the skill required to replace hard- hardware-based security threats are now possible. This ware and the rise of deeply embedded systems ensure paper presents a hybrid hardware/software approach to that vulnerable systems will remain in active use after the defending against malicious hardware. discovery of the vulnerability. Second, hardware is the We propose BlueChip, a defensive strategy that has lowest layer in the computer system, providing malicious both a design-time component and a runtime component. hardware with control over the software running above. During the design verification phase, BlueChip invokes This low-level control enables sophisticated and stealthy a new technique, unused circuit identification (UCI), attacks aimed at evading software-based defenses. to identify suspicious circuitry—those circuits not used Such an attack might use a special, or unlikely, event to or otherwise activated by any of the design verification trigger deeply buried malicious logic which was inserted tests. BlueChip removes the suspicious circuitry and during design time. For example, attackers might intro- replaces it with exception generation hardware. The ex- duce a sequence of bytes into the hardware that activates ception handler software is responsible for providing for- the malicious logic. This logic might escalate privileges, ward progress by emulating the effect of the exception- turn off access control checks, or execute arbitrary in- generating instruction in software, effectively providing structions, providing a path for the malefactor to take a detour around suspicious hardware. In our experi- control of the machine. The malicious hardware thus ments, BlueChip is able to prevent all hardware attacks provides a foothold for subsequent system-level attacks. we evaluate while incurring a small runtime overhead. In this paper we present the design, implementation, and evaluation of BlueChip, a hybrid design- time/runtime system for detecting and neutralizing ma- 1 Introduction licious circuits. During the design phase, BlueChip flags as suspicious, any unused circuitry (any circuit not acti- Modern hardware design processes closely resemble the vated by any of the many design verification tests) and software design process. Hardware designs consist of deactivates them. However, these seemingly suspicious millions of lines of code and often leverage libraries, circuits might actually be part of a legitimate circuit toolkits, and components from multiple vendors. These within the design, so BlueChip inserts circuitry to raise designs are then “compiled” (synthesized) for fabrica- an exception whenever one of these suspicious circuits tion. As with software, the growing complexity of would have been activated. The exception handler soft- hardware designs creates opportunities for hardware to ware is responsible for emulating hardware instructions become a vehicle for malice. Recent work has demon- to allow the system to continue execution. BlueChip’s strated that small malicious modifications to a hardware- overall goal is to push the complexity of coping with level design can compromise the security of the entire malicious hardware up to a higher, more flexible, and computing system [22]. adaptable layer in the system stack. Malicious hardware has two key properties that make it even more damaging than malicious software. The contributions of this paper are: First, hardware presents a more persistent attack vector. Whereas software vulnerabilities can be fixed via soft- • We present the BlueChip system (Sections 3 and 4), ware update patches or reimaging, fixing well-crafted which automatically removes potentially malicious 1 circuits from a hardware design and uses low-level lectual property) blocks. Many system-on-chip (SoC) software to emulate around removed hardware. designs aggregate subcomponents from existing com- mercial or open-source IP. Although generally trusted, • We propose an algorithm (Section 5), called unused these third-party IP blocks may not be trustworthy. In circuit identification, for automatically identifying this scenario, an attacker can create new IP or modify circuits that avoid affecting outputs during design existing IP blocks to add malicious circuits. The attacker verification. We demonstrate its feasibility (Sec- then distributes or licenses the IP in the hope that some tion 6) for use in addressing the problem of detect- SoC creator will incorporate it and include it in a fabri- ing malicious hardware. cated chip. Although the SoC creator will likely perform significant design verification focused on finding design • We demonstrate (Sections 7, 8, and 9), using fully- bugs, traditional black-box design verification is unlikely tested malicious hardware modifications as test to reveal malicious hardware. cases on a SPARC processor implementation oper- In either scenario, the attacker’s motivation could be ating on an FPGA, that: (1) the system successfully financial or general malice. If the design modification prevents three different malicious hardware modifi- remains undetected by final design validation and ver- cations, and (2) the performance effects (and hence ification, the malicious circuitry will be present in the the overhead) of the system are small. manufactured hardware that is shipped to customers and integrated into computing systems. The attacker has 2 Motivation and attack model achieved this without the resources necessary to actually fabricate a chip or otherwise attacking the manufacturing This paper focuses on the problem of malicious circuits and distribution supply chain. We assume that only one introduced during the hardware design process. Today’s or a few individuals are acting maliciously (i.e., not the complicated hardware designs are increasingly vulner- entire design team) and that these individuals are unable able to the undetected insertion of malicious circuitry to compromise the final end-to-end design verification to create a hardware trojan horse. In other domains, and validation process, which is typically performed by examples of this general type of intentional insertion of a distinct group of engineers. malicious functionality include compromises of software Our approach to detecting insertions of malicious development tools [26], system designers inserting mali- hardware assumes analysis at the level of a hardware cious source code intentionally [8, 20, 21], compromised netlist or hardware description language (HDL) source. servers that host modified source code [11, 12], and In the two scenarios outlined, this assumption is reason- products that come pre-installed with malware [1, 4, 25]. able, as (1) design validation and verification is primarily Such attacks introduce little risk of punishment, because performed at this level and (2) softcore IP blocks are the complexity of modern systems and prevalence of often distributed in HDL or netlist form. unintentional bugs makes it difficult to prove malice or We assume the system software is trustworthy and to correctly attribute the problem to its source [27]. non-malicious (although the malicious hardware may More specifically, our threat model is that a rogue attempt to subvert the overlying software layers). designer covertly adds trojan circuits to a hardware design. We focus on two possible scenarios for such rogue insertion. First, one or more disgruntled employees at a 3 The BlueChip approach hardware design company surreptitiously and intentionally inserts malicious circuits into a design prior to final Our overall BlueChip architecture is shown in Figure 1. design validation with the hope that the changes will In the first phase of operation, BlueChip analyzes the cir- evade detection. The malicious hardware demonstrated cuit’s behavior during design verification to identify can- by King et al. [22] support the plausibility of this sce- didate circuits that might be malicious. Once BlueChip nario, in that only small and localized changes (e.g., to identifies a suspect circuit, BlueChip automatically re- a single hardware source file) are sufficient for creating moves the circuit from the design. Because BlueChip powerful malicious circuits designed for bootstrapping might remove legitimate circuits as part of the transfor- larger system-level attacks. We call such malicious cir- mation, it inserts logic to detect if the removed circuits cuits footholds, and such footholds persist even after would have been activated, and triggers an exception if malicious software has been discovered and removed, the hardware encounters this condition during runtime. giving attackers a permanent vector into a compromised The hardware delivers this exception to the BlueChip

Load more