Matthew Hicks

Timothy Trippel, Kang G. Shin, Alex Chernyakhovsky et al.

Hardware flaws are permanent and potent: hardware cannot be patched once fabricated, and any flaws may undermine any software executing on top. Consequently, verification time dominates implementation time. The gold standard in hardware Design Verification (DV) is concentrated at two extremes: random dynamic verification and formal verification. Both struggle to root out the subtle flaws in complex hardware that often manifest as security vulnerabilities. The root problem with random verification is its undirected nature, making it inefficient, while formal verification is constrained by the state-space explosion problem, making it infeasible against complex designs. What is needed is a solution that is directed, yet under-constrained. Instead of making incremental improvements to existing DV approaches, we leverage the observation that existing software fuzzers already provide such a solution, and adapt them for hardware DV. Specifically, we translate RTL hardware to a software model and fuzz that model. The central challenge we address is how best to mitigate the differences between the hardware execution model and software execution model. This includes: 1) how to represent test cases, 2) what is the hardware equivalent of a crash, 3) what is an appropriate coverage metric, and 4) how to create a general-purpose fuzzing harness for hardware. To evaluate our approach, we fuzz four IP blocks from Google's OpenTitan SoC. Our experiments reveal a two orders-of-magnitude reduction in run time to achieve Finite State Machine (FSM) coverage over traditional dynamic verification schemes. Moreover, with our design-agnostic harness, we achieve over 88% HDL line coverage in three out of four of our designs -- even without any initial seeds.

Harrison Williams, Alexander Lind, Kishankumar Parikh et al.

In order to service an ever-growing base of legacy electronics, both government and industry customers must turn to third-party brokers for components in short supply or discontinued by the original manufacturer. Sourcing equipment from a third party creates an opportunity for unscrupulous gray market suppliers to insert counterfeit devices: failed, knock-off, or otherwise inferior to the original product. This increases the supplier's profits at the expense of reduced performance/reliability of the customer's system. The most challenging class of counterfeit devices to detect is recycled counterfeits: recovered genuine devices which are re-sold as new. Such devices are difficult to detect because they typically pass performance and parametric tests but fail prematurely due to age-related wear. To address the challenge of detecting recycled devices pre-deployment, we develop Silicon Dating: a low-overhead classifier for detecting recycled integrated circuits using Static Random-Access Memory (SRAM) power-on states. Silicon Dating targets devices with no known-new record or purpose-built anti-recycling hardware. We observe that over time, software running on a device imprints its unique data patterns into SRAM through analog-domain changes; we measure the level and direction of this change through SRAM power-on state statistics. In contrast to highly symmetric power-on states produced by variation during SRAM fabrication, we show that embedded software data is generally highly asymmetric and that the degree of power-on state asymmetry imprinted by software reveals device use. Using empirical results from embedded benchmarks running on several microcontrollers, we show that Silicon Dating identifies recycled devices with 84.1% accuracy with no software-specific knowledge and with 92.0% accuracy by incorporating software knowledge---without prior device enrollment or modification.

Timothy Trippel, Kang G. Shin, Kevin B. Bush et al.

Since the inception of the Integrated Circuit (IC), the size of the transistors used to construct them has continually shrunk. While this advancement significantly improves computing capability, fabrication costs have skyrocketed. As a result, most IC designers must now outsource fabrication. Outsourcing, however, presents a security threat: comprehensive post-fabrication inspection is infeasible given the size of modern ICs, so it is nearly impossible to know if the foundry has altered the original design during fabrication (i.e., inserted a hardware Trojan). Defending against a foundry-side adversary is challenging because---even with as few as two gates---hardware Trojans can completely undermine software security. Researchers have attempted to both detect and prevent foundry-side attacks, but all existing defenses are ineffective against Trojans with footprints of a few gates or less. We present Targeted Tamper-Evident Routing (T-TER), a preventive layout-level defense against untrusted foundries, capable of thwarting the insertion of even the stealthiest hardware Trojans. T-TER is directed and routing-centric: it prevents foundry-side attackers from routing Trojan wires to, or directly adjacent to, security-critical wires by shielding them with guard wires. Unlike shield wires commonly deployed for cross-talk reduction, T-TER guard wires pose an additional technical challenge: they must be tamper-evident in both the digital (deletion attacks) and analog (move and jog attacks) domains. We address this challenge by developing a class of designed-in guard wires, that are added to the design specifically to protect security-critical wires. T-TER's guard wires incur minimal overhead, scale with design complexity, and provide tamper-evidence against attacks.

Timothy Trippel, Kang G. Shin, Kevin B. Bush et al.

The transistors used to construct Integrated Circuits (ICs) continue to shrink. While this shrinkage improves performance and density, it also reduces trust: the price to build leading-edge fabrication facilities has skyrocketed, forcing even nation states to outsource the fabrication of high-performance ICs. Outsourcing fabrication presents a security threat because the black-box nature of a fabricated IC makes comprehensive inspection infeasible. Since prior work shows the feasibility of fabrication-time attackers' evasion of existing post-fabrication defenses, IC designers must be able to protect their physical designs before handing them off to an untrusted foundry. To this end, recent work suggests methods to harden IC layouts against attack. Unfortunately, no tool exists to assess the effectiveness of the proposed defenses---meaning gaps may exist. This paper presents an extensible IC layout security analysis tool called IC Attack Surface (ICAS) that quantifies defensive coverage. For researchers, ICAS identifies gaps for future defenses to target, and enables the quantitative comparison of existing and future defenses. For practitioners, ICAS enables the exploration of the impact of design decisions on an IC's resilience to fabrication-time attack. ICAS takes a set of metrics that encode the challenge of inserting a hardware Trojan into an IC layout, a set of attacks that the defender cares about, and a completed IC layout and reports the number of ways an attacker can add each attack to the design. While the ideal score is zero, practically, our experience is that lower scores correlate with increased attacker effort.

Stefan Nagy, Matthew Hicks

Of coverage-guided fuzzing's three main components: (1) testcase generation, (2) code coverage tracing, and (3) crash triage, code coverage tracing is a dominant source of overhead. Coverage-guided fuzzers trace every testcase's code coverage through either static or dynamic binary instrumentation, or more recently, using hardware support. Unfortunately, tracing all testcases incurs significant performance penalties---even when the overwhelming majority of testcases and their coverage information are discarded because they do not increase code coverage. To eliminate needless tracing by coverage-guided fuzzers, we introduce the notion of coverage-guided tracing. Coverage-guided tracing leverages two observations: (1) only a fraction of generated testcases increase coverage, and thus require tracing; and (2) coverage-increasing testcases become less frequent over time. Coverage-guided tracing works by encoding the current frontier of code coverage in the target binary so that it self-reports when a testcase produces new coverage---without tracing. This acts as a filter for tracing; restricting the expense of tracing to only coverage-increasing testcases. Thus, coverage-guided tracing chooses to tradeoff increased coverage-increasing-testcase handling time for the ability to execute testcases initially at native speed. To show the potential of coverage-guided tracing, we create an implementation based on the static binary instrumentor Dyninst called UnTracer. We evaluate UnTracer using eight real-world binaries commonly used by the fuzzing community. Experiments show that after only an hour of fuzzing, UnTracer's average overhead is below 1%, and after 24-hours of fuzzing, UnTracer approaches 0% overhead, while tracing every testcase with popular white- and black-box-binary tracers AFL-Clang, AFL-QEMU, and AFL-Dyninst incurs overheads of 36%, 612%, and 518%, respectively.