1 / 25

A Sensor-Assisted Self-Authentication for Hardware Trojan Detection

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.

dacian
Download Presentation

A Sensor-Assisted Self-Authentication for Hardware Trojan Detection

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 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

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

  7. Design of the Detection Sensor • Steps • logic design via netlist analysis • sequence matching • feature discovery • physical design of sensors • layout integration • delay measurement

  8. 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

  9. 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

  10. [Agarwal et al, ASPDAC’03] Variation-Aware Delay Modeling c a b a

  11. 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

  12. 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

  13. 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]

  14. 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

  15. 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

  16. 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

  17. 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

  18. 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

  19. 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

  20. 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

  21. 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

  22. Trojan Inserted in Design MR: fraction of the paths which are matched with at least one sensor DR: detection ratio

  23. Trojan Insertion in Detection Sensor MR: fraction of the paths which are matched with at least one sensor DR: detection ratio

  24. Trojan Detection Rate in s13207 detection rate % Trojan delay/delay of longest path

  25. 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

More Related