A security-aware design scheme for better hardware Trojan detection sensitivity

Abstract

Due to the trend of outsourcing designs to foundries overseas, there has been an increasing threat of malicious modifications to the original integrated circuits (ICs), also known as hardware Trojans. Numerous countermeasures have been proposed. However, very little effort has been made to design-time strategies that help to make test-time or run-time detection of Trojans easier. In this paper, we characterize each cell's sensitivity to malicious modifications and develop an algorithm to select a subset of standard cells for a given circuit such that Trojans are easily detected using [1] when the circuit is synthesized on it. Experiments on 8 publicly available benchmarks show that using our method, we could detect on average 16.87% more Trojans with very small power/area overhead and no timing violations. I. INTRODUCTIONDue to the trend of outsourcing designs to foundries overseas, there has been an increasing concern in malicious inclusions in Integrated Circuit (IC) design also known as Hardware Trojans (HTs). HTs can change the IC's functionality, leak secret information, disable or destroy the entire chip and are thus very dangerous [6]. Numerous countermeasures have been proposed and most of them happen at test-time. These approaches compare the functionality or side-channel behavior (path delay, power, etc.) of the IC under test with that of a golden IC (Trojan-free IC). Some reverse-engineering (RE) based Trojan detection schemes also happen at test-time. They apply RE to the IC under test and recover the layout or gatelevel netlist, which is then compared with that of a golden IC. Run-time approaches have also been investigated. These approaches monitor the IC for unexpected changes in functionality or side-channel behavior at run-time. If such changes are detected, the run-time logic will bypass the malicious logic to prevent Trojans from doing any damage.Other than well-studied test-time and run-time approaches, very few design-time strategies that help in either preventing the insertion of Trojans or easier detection of Trojans are proposed [10]. We should notice that Trojan detection is not a easy job and a cooperation between design-time and testtime/run-time approaches is always preferred.In this paper, we propose an innovative design-time strategy that allows easier test-time detection of Trojans using RE based method such as [1]. Our technique relies on choosing a subset of standard cells that are more sensitive to Trojan insertion from a given technology library. By synthesizing the design using the subset, we can still utilize the existing library as well as the design tools. This enables early adoption of security techniques into the EDA tool flow. We choose [1] as our test-time approach because it can be used to verify that a chip is golden which is the underlying assumption of many other test-time approaches. Furthermore, since it uses RE, it is arguably among the strongest approaches to detect Trojans.We summarize the contributions of this paper as follows: 1) We characterize each standard ...

A Touch of Evil: High-Assurance Cryptographic Hardware from Untrusted Components

“…The most common ones attempt to either detect malicious circuitry, or prevent insertions. In particular, detection techniques aim to determine whether any HTs exist in a given circuit and feature a wide range of methods such as side-channel analysis [3,79,95,97], logic testing [26], and trust verification [8,68,90,102]. On the other hand, prevention techniques aim to either impede the introduction of HTs, or make HT easier to detect, such approaches are Split manufacturing [28,69,94] which tries to minimize the circuit/design exposure to the adversary, logic obfuscation [25] and runtime monitoring [47,88] Moreover, there is also a smaller body of work which attempts to tackle the even harder problem of inferring additional information about the HT such as its triggers, payload, and exact location [95,97].…”

“…Understandably, design houses have much better control over the IC fabrication and the supply chain, and this allows them to take full advantage of our architecture. In particular, they can combine existing detection [8,26,68] and prevention techniques [25,28,69,94] with our proposed design, to reduce the likelihood of compromises for individual components. On the other hand, COTS vendors have less control as they have limited visibility in the fabrication process and the supply chain.…”