250 likes | 490 Views
A Sensor-Assisted Self-Authentication for Hardware Trojan Detection. Min Li*, Azadeh Davoodi *, Mohammad Tehranipoor ** * University of Wisconsin-Madison **University of Connecticut. WISCAD Electronic Design Automation Lab http://wiscad.ece.wisc.edu.
E N D
A Sensor-Assisted Self-Authentication for Hardware Trojan Detection Min Li*, AzadehDavoodi*, Mohammad Tehranipoor** *University of Wisconsin-Madison **University of Connecticut WISCADElectronic Design Automation Lab http://wiscad.ece.wisc.edu
Challenges of Hardware Trojan Detection • Challenges: • lack of observability and controllability after fabrication • complexity • due to existence of billions of nano-scale components • due to high volume of soft and hard integrated IP cores • overhead associated with physical inspection of nanometer feature sizes for reverse engineering • could be intrusive • difficulty to activate a Trojan • increasing fabrication and environmental variations with technology scaling
Fundamental Challenge • Trojan-free or Golden IC (GIC) • required in any (generic) IC authentication process • create a reference fingerprint from the transient behavior of GIC and compare with fingerprint obtained from target IC • existence and identification of GIC cannot be guaranteed • if inserted in GDSII file, or if the foundry alters the mask to insert a Trojan, GIC will not exist • if an IC passes a rigorous test, in theory one cannot conclude that it is a GIC
Contributions • A framework to use custom-designed on-chip detection sensors to alleviate the need on a golden IC by providing a self-authentication • On-chip “detection sensor” • a compact (small area) representation of a design • can be designed by searching for common “features” in a design • shares common sources of uncertainty with the design due to realization on the same chip • e.g., process and environmental variations • Assumptions • Trojan may infect the design paths, the detection sensor, or both • the detection sensor is obfuscated within the design’s layout • i.e., an adversary will not be able to distinguish it
Proposed Framework Design stage Post-silicon self-authentication process Design and integration of custom-generated detection sensors capturing within-die variability On-chip delay fingerprint of detection sensors On-chip delay fingerprint of arbitrary design paths Offline analysis of fingerprint correlation PASS? NO Alert Trojan
Design stage Post-Silicon detection sensor: a compact representative of the design -- Finds most frequent “layout features” which are design-dependent and technology-sensitive measured on-chip delays of design paths and of detection sensors analyze correlation -- Main Idea: Addition of Trojan disturbs the expected delay correlation between the design and the detection sensor detect Trojan
Design of the Detection Sensor • Steps • logic design via netlist analysis • sequence matching • feature discovery • physical design of sensors • layout integration • delay measurement
Design of A Detection Sensor • An optimization framework for finding frequent sequences in a netlist* • modeled using a graph representation of the design’s netlist • break (all or some portions) of the graph into collection of “similar” sequences • similar sequences grouped together and represented by one sensor • given a budget for total area used by the detection sensors, the goal is to maximize coverage of graph with formed sequences *Li and Davoodi, “Custom On-Chip Sensors for Post-Silicon Failing Path Isolation in the Presence of Process Variations”, Technical Report, 2011
Design of the Detection Sensor • Constraints: • sequence constraints • a sequence is made of consecutive edges • similarity constraints • “similar” sequences are mapped to the same sensor • similarity defined based on delay correlation in the presence of uncertainties such as process variations • area constraint • summation of the areas of detection sensors are bounded extended graph after modification original netlist simplified version for illustration
[Agarwal et al, ASPDAC’03] Variation-Aware Delay Modeling c a b a
Design of A Detection Sensor • Benefits of the formulation • flexible definition of similarity between sequences mapped to the same sensor, • for example similar sequences could be: • structually identical (e.g., same sequence of logic gates) • have the same timing distribution • highly correlated in their timing characteristic • in general can define similarity with respect to sensitivity to technology parameters • flexible objective • if edge weights are equal, objective is maximizing netlist coverage • can modify to also ensure spatial coverage from different regions of the chip
Design Post-Silicon detection sensor: a compact representative of the design -- e.g., BIST technology -- First check BIST is healthy (e.g., by verifying delays of embedded ring oscillators) measured on-chip delays of design paths and of detection sensors analyze correlation detect Trojan
On-Chip Path Delay Measurement • Examples • Path-RO [Tehranipoor et al ICCAD08] • requires inserting measurement circuitry at the pre-silicon stage along the desired representative paths • Shrinking clock signal [Abraham et al GLSVLSI 2010]
Design Post-Silicon detection sensor: a compact representative of the design • -- Detection scenarios: • Trojan may be added to the design, the detection sensor, or both • -- The timing correlation between the design and its detection sensors will be different in the presence of a Trojan measured on-chip delays of design paths and of detection sensors analyze correlation detect Trojan
Detection Scenarios • Trojan inserted in the design paths • actual delay range: obtained from direct path delay measurement considering measurement error • predicted delay range: computed using actual sensor delay and predicting the remainder of the path using worst/base-case values Trojan-infected path used for actual delay range path used for predicted delay range sensor sensor matched case-based estimate
Detection Scenarios • Trojan inserted in the design paths • underestimation of path delays that are Trojan infected • detects Trojan if predicted delay range does not overlap with the measured range sensor
Detection Scenarios • Trojan inserted in the detection sensor • actual delay range: obtained from direct path delay measurement considering measurement error correct range • predicted delay range: computed using Trojan-infected sensor delay and predicting the remainder of the path using worst/base-case values path used for actual delay range path used for predicted delay range sensor sensor matched case-based estimate
Detection Scenarios • Trojan inserted in the detection sensor • overestimation of the predicted range of the design paths • correctly detects existence of Trojan if the two ranges don’t overlap • can identify that detection sensor is infected sensor
Detection Scenarios • Trojan inserted simultaneously in the design and detection sensor • actual and predicted ranges both erroneous • depending on how the Trojan impact each one, different cases can happen path used for actual delay range path used for predicted delay range sensor
Detection Scenarios • Trojan inserted simultaneously in the design and detection sensor • can only predict that Trojan exists if the predicted and measured ranges do not overlap, otherwise it doesn’t generate any output sensor
Simulation Setup • Randomly selected a subset of critical design paths from the ISCAS89 suite • For each considered path • inserted a Trojan at a random location on the path • sensor area budget is 15% • repeated many times for varying Trojan delays • 3 to 10% of the delay of the longest path in the circuit (30 different values uniformly selected from the range) • assumed on-chip measurement error of 3% for measuring the delays of the infected paths • variation modeling • assumed process variations in channel length and threshold voltage of transistors according to variation setting for 45nm technology and a 5-level spatial correlation model • considered 10K scenarios of variations
Trojan Inserted in Design MR: fraction of the paths which are matched with at least one sensor DR: detection ratio
Trojan Insertion in Detection Sensor MR: fraction of the paths which are matched with at least one sensor DR: detection ratio
Trojan Detection Rate in s13207 detection rate % Trojan delay/delay of longest path
Conclusions • Benefits of the detection framework • alleviates the need on a GIC • does not output a wrong answer • detection at a finer granularity • faster detection of Trojan • captures both layout-dependency and technology-dependency • Limitations • spatial correlation modeling • path delay measurement accuracy • layout integration