Pattern-based hardware Trojan characterization for design security assessment

Abstract

Hardware Trojan detection has become a major concern in computer security during the last decade. Many approaches have been proposed to detect hardware Trojans, most of them focussing on the threat model of a malicious manufacturer (while the design phase is trusted). Such Trojans can be detected by post-fabrication methods, which require a golden model to reason about the chip’s maliciousness. Such a golden model can neither be assumed, nor guaranteed. In addition, security analysis always requires manual assessment in a sense to decide whether an alarm is indeed caused by a malicious entity. This requirement is not covered by most of these approaches. To justify the assumption of a golden model, this work assumes the threat model of a malicious designer. In this threat model, a malicious designer adds malicious functionality at any step in the design flow. Due to high flexibility, this work focuses on the hardware description language (HDL) level. At HDL, manual assessment is possible because identified Trojan candidates can be reviewed by analyzing their source code. One contribution of this thesis is show the plausibility of this threat model by elaborating its costs and opportunities and by giving two specific attack examples. At HDL, design reviews assure the quality of a design’s conformance to its specification, which is why a malicious designer will obfuscate malicious inclusions, such that it is not detected during design review, and to escape detection during functional testing. Many approaches that target hardware Trojan detection at design-level assume that there are triggers which cause nearly-unused signals or circuits in a design in order to escape functional testing. So, these approaches attempt to identify unused signals or circuits. However, assuming such a trigger limits the applicability of these methods to Trojans that incorporate such triggers, while Trojans that do not incorporate such triggers remain undetected. Therefore, the central assumption in this thesis is, that together with obfuscating code, malicious functionality will be distinguishable by implementation style. A main question that this thesis addresses is: Is it possible to distinguish malicious HDL code from non-malicious HDL code solely under the assumption that malicious code is somehow differently implemented than the rest of the design? Thus, this work first proposes the pattern graph specification language (PGSL), which is a two-dimensional regularexpression-like graph search methodology to specify and search for subparts of a design. From the literature, we know several functional units which are frequently used in hardware Trojan implementations. Prominent examples are counters to trigger malicious behavior, or linear-feedback shift registers (LFSRs) to modulate covert code-division multiple access (CDMA) channels. With PGSL, we are able to specify patterns for such functional units and to find them in a design. This is called feature localization. The problem is that feature localization yields all potential Trojan candidates (malicious and benign ones). This can lead to a significant number of false positives. It is therefore necessary to further analyze these candidates in order to reduce the number of false positives. Based on the assumption that malicious functionality is implemented differently than the rest of the design, we process potential Trojan candidates such that implementation style difference is made visible. This should support the verification engineer to manually verify the candidates, e.g., by suggesting a verification order. We accomplish visualization by structurally characterizing the register transfer level (RTL) netlist of all Trojan candidates. Experiments on a subset of the TrustHUB benchmarks indicate that structural design characterization can potentially be used to successfully distinguish between malicious and non-malicious functional units. However, for a particular design, effectiveness depends on the design’s architecture, and also on the patterns that are used to specify these functional units.