pith. sign in

arxiv: 1906.08836 · v1 · pith:MXNN2PGUnew · submitted 2019-06-20 · 💻 cs.CR

An Extensible Framework for Quantifying the Coverage of Defenses Against Untrusted Foundries

Timothy Trippel , Kang G. Shin , Kevin B. Bush , Matthew Hicks This is my paper

Pith reviewed 2026-05-25 19:14 UTC · model grok-4.3

classification 💻 cs.CR
keywords hardware TrojansIC layout securityfabrication attacksdefensive coverageuntrusted foundriesattack surface analysishardware security
0
0 comments X

The pith

ICAS quantifies defensive coverage against fabrication-time hardware attacks by counting the number of ways each attack can be inserted into an IC layout.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

This paper introduces ICAS, an extensible tool that measures how well IC layouts resist attacks from untrusted foundries. It accepts user-provided metrics that encode insertion challenges, a list of attacks the defender cares about, and a completed layout, then outputs the number of ways each attack can be added. A sympathetic reader would care because shrinking transistors and rising fab costs have made outsourcing fabrication routine, creating risks that post-fabrication inspection cannot reliably catch. The tool lets researchers spot gaps for new defenses and compare approaches numerically, while letting practitioners test how design choices affect resilience. Lower counts are described as corresponding to greater attacker effort.

Core claim

The paper claims that ICAS quantifies defensive coverage by reporting the number of ways an attacker can add each attack to the design, with lower scores correlating with increased attacker effort, and that this enables identification of gaps in defenses, quantitative comparison of defenses, and exploration of design decisions' impact on resilience.

What carries the argument

The IC Attack Surface (ICAS) tool, which enumerates attacker insertion opportunities for each considered attack based on supplied metrics and the layout.

If this is right

  • Researchers can identify specific gaps for future defenses to target.
  • Existing and future defenses can be compared quantitatively.
  • Practitioners can explore how design decisions affect resilience to fabrication-time attack.
  • Scores of zero represent ideal coverage, and lower scores indicate increased attacker effort.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The counting method could be paired with layout optimization routines to automatically reduce the reported attack surface.
  • The same structure might extend to quantifying coverage against other supply-chain threats beyond hardware Trojans.
  • Widespread use could shift hardware security assessment from qualitative claims to explicit numerical targets.

Load-bearing premise

The user-provided metrics accurately encode the real-world challenge an attacker faces when attempting to insert a hardware Trojan into the layout.

What would settle it

Finding a concrete Trojan insertion method that succeeds on a low-scoring layout but is not captured by the user metrics would show the counts do not reflect actual attacker effort.

Figures

Figures reproduced from arXiv: 1906.08836 by Kang G. Shin, Kevin B. Bush, Matthew Hicks, Timothy Trippel.

Figure 1
Figure 1. Figure 1: The typical IC design process starts with a textual specification of design requirements and ends with a fabricated and tested chip. Green check￾boxes mark trusted stages and red x-boxes mark the untrusted step (i.e., an untrusted foundry). The fabrication step takes a GDSII file (physical IC lay￾out) as input and produces a wafer of die. While prior work proposes metrics for untrusted front-end design [13… view at source ↗
Figure 2
Figure 2. Figure 2: Typical IC floorplan created during the place-and-route design phase. The floorplan consists of an I/O pad ring surrounding the chip core. Within the core is the placement grid. Circuit components are placed and routed within the placement grid. IC layouts consist of multiple layers. The bottom layers are de￾vice layers, while the top layers are metal layers. Device layers are used for constructing circuit… view at source ↗
Figure 4
Figure 4. Figure 4: Assume an attacker is attempting to insert 6 additional Trojan components that consume a total of 9 placement sites (as shown). If insert￾ing these components on the Trivial placement grid (left), they can be placed adjacent to each other to simplify intra-Trojan routing. If inserting these components on the Difficult placement grid (middle), they must be scattered across the grid, making intra-Trojan rout… view at source ↗
Figure 6
Figure 6. Figure 6: ICAS consists of two tools, Nemo and GDSII-Score, and fits into the existing IC design process ( [PITH_FULL_IMAGE:figures/full_fig_p006_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: A) Same-layer net blockage is computed by traversing the perime￾ter of the security-critical net, with granularity д, and extension distance d, and determining if such points lie inside another component in the lay￾out. B) Adjacent-layer net blockage is computed by projecting the area of the security-critical net to the layers above and below and determining the area of the projections that are occupied by… view at source ↗
Figure 8
Figure 8. Figure 8: Trigger Space distributions for 15 different OR1200 processor IC layouts. Core density and max transition time parameters are varied across the layouts, while target clock frequency is held constant at 1 GH z. The boxes represent the middle 50% (interquartile range or IQR) of open placement regions in a given layout, while the dots represent individual open placement region sizes. and layout to form a comm… view at source ↗
Figure 9
Figure 9. Figure 9: Overall Net Blockage results computed across 20 different OR1200 processor IC layouts. A target density of 50% was used for all layouts, while target clock frequency and max transition time parameters were varied. 7.2.1 Trigger Space Analysis [PITH_FULL_IMAGE:figures/full_fig_p010_9.png] view at source ↗
Figure 11
Figure 11. Figure 11: Routing Distance heatmaps across three IC designs, with and without the placement-centric defense described in [5, 6]. Heatmaps should be interpreted similar to [PITH_FULL_IMAGE:figures/full_fig_p011_11.png] view at source ↗
Figure 12
Figure 12. Figure 12: Route Distance Metric for OR1200 at 50% Density). A target density of 50% was held across each layout, while target clock frequency and max transition time parameters were varied from 100 MHz to 1000 MHz and 100 ps to 300 ps respectively. Each heatmap is intended to be read column-wise, where each column is a histogram. The color intensity within a heatmap column indicates the percentage of (critical-net,… view at source ↗
Figure 13
Figure 13. Figure 13: Route Distance Metric for OR1200 at 70% Density. Same as [PITH_FULL_IMAGE:figures/full_fig_p016_13.png] view at source ↗
Figure 14
Figure 14. Figure 14: Route Distance Metric for OR1200 at 90% Density. Same as [PITH_FULL_IMAGE:figures/full_fig_p017_14.png] view at source ↗
read the original abstract

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.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

1 major / 1 minor

Summary. The paper introduces the IC Attack Surface (ICAS) framework, an extensible tool that takes user-provided metrics encoding the difficulty of inserting hardware Trojans, a set of attacks of interest, and a completed IC layout, then reports the number of ways each attack can be added to the design. The ideal score is zero; the authors state that lower scores correlate with increased attacker effort based on their experience. The tool is positioned to help researchers identify gaps in defenses and enable quantitative comparisons, and to help practitioners explore design decisions' impact on resilience to fabrication-time attacks.

Significance. If the reported counts can be shown to track real attacker effort, ICAS would fill a documented gap by providing the first quantitative method to assess layout-level defensive coverage against untrusted foundries. The metric-agnostic design is a strength that allows reuse across different threat models, and the framework could support reproducible evaluation of future hardening techniques.

major comments (1)
  1. [Section 1] Section 1: The central claim that lower ICAS scores correlate with increased attacker effort is asserted solely from 'our experience' with no quantitative validation, case studies, red-team effort measurements, or ablation experiments demonstrating that the supplied metrics (e.g., area, timing slack) predict actual insertion difficulty. Because the framework is explicitly metric-agnostic, any mismatch between user metrics and real-world cost directly undermines the interpretation of the output counts as a measure of defensive coverage.
minor comments (1)
  1. [Abstract] The abstract and introduction describe intended inputs and outputs but supply no concrete example computation or sample output to illustrate how the reported numbers are derived from layout data and metrics.

Simulated Author's Rebuttal

1 responses · 0 unresolved

Thank you for the opportunity to respond to the referee's comments. We address the major comment point by point below.

read point-by-point responses

  1. Referee: [Section 1] Section 1: The central claim that lower ICAS scores correlate with increased attacker effort is asserted solely from 'our experience' with no quantitative validation, case studies, red-team effort measurements, or ablation experiments demonstrating that the supplied metrics (e.g., area, timing slack) predict actual insertion difficulty. Because the framework is explicitly metric-agnostic, any mismatch between user metrics and real-world cost directly undermines the interpretation of the output counts as a measure of defensive coverage.

    Authors: We acknowledge that the statement in the manuscript regarding the correlation between lower ICAS scores and increased attacker effort is based on our experience and is not supported by quantitative validation, case studies, or experiments within the paper. This observation is not presented as the central claim of the work; the primary contribution is the extensible framework itself. The metric-agnostic design is a deliberate feature to accommodate varying threat models and user-defined metrics. To address the concern, we will revise the manuscript to qualify this statement, clarifying that the framework reports insertion opportunities based on the provided metrics, and that any correlation with attacker effort depends on the validity of those metrics. We will also add a discussion on the importance of metric validation as future work. This change will be made in the revised version. revision: yes

Circularity Check

0 steps flagged

No significant circularity in the derivation chain

full rationale

The ICAS framework defines its output score directly as the enumerated count of insertion opportunities permitted by the user-supplied metrics on the input layout; this is an explicit computational definition rather than a derived quantity that reduces to a fitted parameter, self-citation, or ansatz. The statement that lower scores correlate with attacker effort is presented as an experiential observation without supporting equations, self-citations, or uniqueness theorems. No load-bearing steps match the enumerated circularity patterns, and the tool remains self-contained against its external inputs and benchmarks.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 1 invented entities

The framework depends on externally supplied metrics and attack definitions; no free parameters are fitted inside the tool itself.

axioms (1)
  • domain assumption The count of insertion opportunities produced by the metrics is a valid proxy for attacker effort.
    The paper states that lower scores correlate with increased attacker effort but does not derive or validate this correlation.
invented entities (1)
  • ICAS framework no independent evidence
    purpose: Quantify the coverage of layout defenses against fabrication-time Trojan insertion
    New software tool introduced by the paper; no independent evidence of correctness is supplied.

pith-pipeline@v0.9.0 · 5806 in / 1127 out tokens · 28291 ms · 2026-05-25T19:14:00.058570+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

63 extracted references · 63 canonical work pages · 1 internal anchor

  1. [1]

    Ronen Adato, Aydan Uyar, Mahmoud Zangeneh, Boyou Zhou, Ajay Joshi, Bennett Goldberg, and M Selim Unlu. 2016. Rapid mapping of digital integrated circuit logic gates via multi-spectral backside imaging. arXiv:1605.09306 (2016)

    work page internal anchor Pith review Pith/arXiv arXiv 2016

  2. [2]

    Dakshi Agrawal, Selcuk Baktir, Deniz Karakoyunlu, Pankaj Rohatgi, and Berk Sunar. 2007. Trojan Detection using IC fingerprinting. In IEEE Symposium on Security and Privacy (SP)

    work page 2007

  3. [3]

    Paul Alcorn. [n. d.]. Ice Lake Might Arrive in June, According to Leaked Lenovo Documents. ([n. d.]). https://www-ssl.intel.com/content/www/us/en/design/ products-and-solutions/processors-and-chipsets/ice-lake/overview.html

    work page

  4. [4]

    Anonymous. [n. d.]. Anonymous citation for blind review. ([n. d.])

    work page

  5. [5]

    Papa-Sidy Ba, Sophie Dupuis, Manikandan Palanichamy, Giorgio Di Natale, Bruno Rouzeyre, et al. 2016. Hardware Trust through Layout Filling: a Hardware Trojan Prevention Technique. In IEEE Computer Society Annual Symposium on VLSI (ISVLSI)

    work page 2016

  6. [6]

    Papa-Sidy Ba, Manikandan Palanichamy, Sophie Dupuis, Marie-Lise Flottes, Giorgio Di Natale, and Bruno Rouzeyre. 2015. Hardware Trojan prevention using layout-level design approach. In European Conference on Circuit Theory and Design (ECCTD)

    work page 2015

  7. [7]

    Josep Balasch, Benedikt Gierlichs, and Ingrid Verbauwhede. 2015. Electromag- netic circuit fingerprints for hardware trojan detection. In IEEE International Symposium on Electromagnetic Compatibility (EMC)

    work page 2015

  8. [8]

    Mark Beaumont, Bradley Hopkins, and Tristan Newby. 2011. Hardware trojans- prevention, detection, countermeasures (a literature review) . Technical Report. Defence Science and Technology Organization Edinburgh (Australia)

    work page 2011

  9. [9]

    Georg T Becker, Francesco Regazzoni, Christof Paar, and Wayne P Burleson

    work page

  10. [10]

    In International Workshop on Cryptographic Hardware and Embedded Systems (CHES)

    Stealthy dopant-level hardware trojans. In International Workshop on Cryptographic Hardware and Embedded Systems (CHES)

    work page

  11. [11]

    Cadence Design Systems. [n. d.]. Innovus Implementation System. ([n. d.]). https://www.cadence.com/content/cadence-www/global/en_US/home.html

    work page

  12. [12]

    Burçin Çakir and Sharad Malik. 2015. Hardware Trojan detection for gate- level ICs using signal correlation based clustering. In Proceedings of the Design, Automation & Test in Europe Conference (DATE). EDA Consortium, 471–476

    work page 2015

  13. [13]

    Rajat Subhra Chakraborty, Seetharam Narasimhan, and Swarup Bhunia. 2009. Hardware Trojan: Threats and emerging solutions. In IEEE International High Level Design Validation and Test Workshop (HLDVT) . IEEE

    work page 2009

  14. [14]

    Rajat Subhra Chakraborty, Francis G Wolff, Somnath Paul, Christos A Papachris- tou, and Swarup Bhunia. 2009. MERO: A Statistical Approach for Hardware Trojan Detection.. In International Workshop on Cryptographic Hardware and Embedded Systems (CHES)

    work page 2009

  15. [15]

    Ronald P Cocchi, James P Baukus, Lap Wai Chow, and Bryan J Wang. 2014. Circuit camouflage integration for hardware IP protection. In Proceedings of the 51st Annual Design Automation Conference. ACM, 1–5

    work page 2014

  16. [16]

    Calma Company. 1987. GDSII Stream Format Manual (6.0 ed.)

    work page 1987

  17. [17]

    John Ellson, Emden R Gansner, Eleftherios Koutsofios, Stephen C North, and Gordon Woodhull. 2004. Graphviz and dynagraphâĂŤstatic and dynamic graph drawing tools. Graph drawing software (2004), 127–148

    work page 2004

  18. [18]

    William C Elmore. 1948. The transient response of damped linear networks with particular regard to wideband amplifiers. Journal of Applied Physics 19, 1 (1948)

    work page 1948

  19. [19]

    Task Force. 2005. High performance microchip supply. Annual Report. Defense Technical Information Center (DTIC), USA (2005)

    work page 2005

  20. [20]

    Domenic Forte, Chongxi Bao, and Ankur Srivastava. 2013. Temperature tracking: An innovative run-time approach for hardware Trojan detection. In IEEE/ACM International Conference on Computer-Aided Design (ICCAD)

    work page 2013

  21. [21]

    Lawrence H Goldstein and Evelyn L Thigpen. 1980. SCOAP: Sandia controllabil- ity/observability analysis program. In Proceedings of the ACM Design Automation Conference (DAC)

    work page 1980

  22. [22]

    King, Milo M

    Matthew Hicks, Murph Finnicum, Samuel T. King, Milo M. K. Martin, and Jonathan M. Smith. 2010. Overcoming an Untrusted Computing Base: Detecting and Removing Malicious Hardware Automatically. In Proceedings of the IEEE Symposium on Security and Privacy (SP)

    work page 2010

  23. [23]

    King, and Jonathan M

    Matthew Hicks, Cynthia Sturton, Samuel T. King, and Jonathan M. Smith. 2015. SPECS: A Lightweight Runtime Mechanism for Protecting Software from Security- Critical Processor Bugs. In International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS)

    work page 2015

  24. [24]

    2014.Computer graphics: principles and practice

    John F Hughes and James D Foley. 2014.Computer graphics: principles and practice. Pearson Education

    work page 2014

  25. [25]

    Intel Corporation. [n. d.]. Microprocessor Quick Reference Guide. ([n. d.]). https://www.intel.com/pressroom/kits/quickreffam.htm

    work page

  26. [26]

    Yier Jin, Nathan Kupp, and Yiorgos Makris. 2010. DFTT: Design for Trojan test. In IEEE International Conference on Electronics, Circuits, and Systems (ICECS)

    work page 2010

  27. [27]

    Yier Jin and Yiorgos Makris. 2008. Hardware Trojan detection using path delay fingerprint. In IEEE International Workshop on Hardware-Oriented Security and Trust (HOST)

    work page 2008

  28. [28]

    King, Joseph Tucek, Anthony Cozzie, Chris Grier, Weihang Jiang, and Yuanyuan Zhou

    Samuel T. King, Joseph Tucek, Anthony Cozzie, Chris Grier, Weihang Jiang, and Yuanyuan Zhou. 2008. Designing and Implementing Malicious Hardware. In Proceedings of the Usenix Workshop on Large-Scale Exploits and Emergent Threats (LEET)

    work page 2008

  29. [29]

    Raghavan Kumar, Philipp Jovanovic, Wayne Burleson, and Ilia Polian. 2014. Parametric trojans for fault-injection attacks on cryptographic hardware. In Workshop on Fault Diagnosis and Tolerance in Cryptography (FDTC)

    work page 2014

  30. [30]

    Jie Li and John Lach. 2008. At-speed delay characterization for IC authentication and Trojan horse detection. InIEEE International Workshop on Hardware-Oriented Security and Trust (HOST)

    work page 2008

  31. [31]

    Lang Lin, Markus Kasper, Tim Güneysu, Christof Paar, and Wayne Burleson. 2009. Trojan Side-Channels: Lightweight Hardware Trojans through Side-Channel En- gineering.. In International Workshop on Cryptographic Hardware and Embedded Systems (CHES)

    work page 2009

  32. [32]

    Timothy Linscott, Pete Ehrett, Valeria Bertacco, and Todd Austin. 2018. SWAN: mitigating hardware trojans with design ambiguity. In 2018 IEEE/ACM Interna- tional Conference on Computer-Aided Design (ICCAD) . IEEE, 1–7

    work page 2018

  33. [33]

    MIT Lincoln Laboratory. [n. d.]. Common Evaluation Platform. ([n. d.]). https: //github.com/mit-ll/CEP

    work page

  34. [34]

    Seetharam Narasimhan, Xinmu Wang, Dongdong Du, Rajat Subhra Chakraborty, and Swarup Bhunia. 2011. TeSR: A robust temporal self-referencing approach for hardware Trojan detection. In IEEE International Symposium on Hardware- Oriented Security and Trust (HOST)

    work page 2011

  35. [35]

    OpenCores.org. [n. d.]. OpenRISC OR1200 Processor. ([n. d.]). https://github. com/openrisc/or1200

    work page

  36. [36]

    Miodrag Potkonjak, Ani Nahapetian, Michael Nelson, and Tammara Massey

    work page

  37. [37]

    In Proceedings of ACM/IEEE Design Automation Conference (DAC)

    Hardware Trojan horse detection using gate-level characterization. In Proceedings of ACM/IEEE Design Automation Conference (DAC)

    work page

  38. [38]

    PyPy. [n. d.]. PyPy. ([n. d.]). https://pypy.org/

    work page

  39. [39]

    Masoud Rostami, Farinaz Koushanfar, Jeyavijayan Rajendran, and Ramesh Karri

    work page

  40. [40]

    In Proceedings of the International Conference on Computer-Aided Design (ICCD)

    Hardware Security: Threat Models and Metrics. In Proceedings of the International Conference on Computer-Aided Design (ICCD)

    work page

  41. [41]

    Hassan Salmani. 2017. COTD: Reference-free hardware trojan detection and recovery based on controllability and observability in gate-level netlist. IEEE Transactions on Information Forensics and Security (2017)

    work page 2017

  42. [42]

    Hassan Salmani and Mohammed Tehranipoor. 2013. Analyzing circuit vulnera- bility to hardware Trojan insertion at the behavioral level. In IEEE International Symposium on Defect and Fault Tolerance in VLSI and Nanotechnology Systems (DFT)

    work page 2013

  43. [43]

    Salmani, M

    H. Salmani, M. Tehranipoor, and R. Karri. 2013. On design vulnerability analysis and trust benchmarks development. InIEEE International Conference on Computer Design (ICCD)

    work page 2013

  44. [44]

    Yuriy Shiyanovskii, F Wolff, Aravind Rajendran, C Papachristou, D Weyer, and W Clay. 2010. Process reliability based trojans through NBTI and HCI effects. In NASA/ESA Conference on Adaptive Hardware and Systems (AHS)

    work page 2010

  45. [45]

    Ed Sperling. 2018. Design Rule Complexity Rising. (April 2018). https:// semiengineering.com/design-rule-complexity-rising/. 13 Under Publication Review, June 20, 2019 Timothy Trippel, Kang G. Shin, Kevin B. Bush, and Matthew Hicks

    work page 2018

  46. [46]

    Technology

    S.S. Technology. 2012. Why node shrinks are no longer offsetting equipment costs. (October 2012). http://electroiq.com/blog/2012/10/why-node-shrinks-are- no-longer-offsetting-equipment-costs

    work page 2012

  47. [47]

    Takeshi Sugawara, Daisuke Suzuki, Ryoichi Fujii, Shigeaki Tawa, Ryohei Hori, Mitsuru Shiozaki, and Takeshi Fujino. 2014. Reversing stealthy dopant-level circuits. In International Workshop on Cryptographic Hardware and Embedded Systems (CHES)

    work page 2014

  48. [48]

    Cadence Design Systems. [n. d.]. Layer Map Files. http://www-bsac.eecs.berkeley. edu/~cadence/tools/layermap.html

    work page

  49. [49]

    Cadence Design Systems. 2009. LEF/DEF Language Reference (5.9 ed.). http: //www.ispd.cc/contests/14/web/doc/lefdefref.pdf

    work page 2009

  50. [50]

    Mohammad Tehranipoor and Farinaz Koushanfar. 2010. A survey of hardware trojan taxonomy and detection. IEEE Design & Test of Computers 27, 1 (2010)

    work page 2010

  51. [51]

    Adam Waksman, Matthew Suozzo, and Simha Sethumadhavan. 2013. FANCI: identification of stealthy malicious logic using boolean functional analysis. In Proceedings of the ACM SIGSAC Conference on Computer & Communications Security (CCS)

    work page 2013

  52. [52]

    Xiaoxiao Wang, Mohammad Tehranipoor, and Jim Plusquellic. 2008. Detect- ing malicious inclusions in secure hardware: Challenges and solutions. In IEEE International Workshop on Hardware-Oriented Security and Trust (HOST)

    work page 2008

  53. [53]

    Kevin Weiler and Peter Atherton. 1977. Hidden surface removal using polygon area sorting. In ACM SIGGRAPH Computer Graphics

    work page 1977

  54. [54]

    Stephen Williams. [n. d.]. Icarus Verilog. ([n. d.]). http://iverilog.icarus.com/

    work page

  55. [55]

    Francis Wolff, Chris Papachristou, Swarup Bhunia, and Rajat S Chakraborty

    work page

  56. [56]

    In Proceedings of the ACM Conference on Design, Automation and Test in Europe (DATE)

    Towards Trojan-free trusted ICs: Problem analysis and detection scheme. In Proceedings of the ACM Conference on Design, Automation and Test in Europe (DATE)

    work page

  57. [57]

    Kan Xiao and Mohammed Tehranipoor. 2013. BISA: Built-in self-authentication for preventing hardware Trojan insertion. In IEEE International Symposium on Hardware-Oriented Security and Trust (HOST)

    work page 2013

  58. [58]

    Kaiyuan Yang, Matthew Hicks, Qing Dong, Todd Austin, and Dennis Sylvester

    work page

  59. [59]

    In IEEE Symposium on Security and Privacy (SP)

    A2: Analog malicious hardware. In IEEE Symposium on Security and Privacy (SP)

    work page

  60. [60]

    Jie Zhang, Feng Yuan, Linxiao Wei, Yannan Liu, and Qiang Xu. 2015. VeriTrust: Verification for hardware trust. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems (2015)

    work page 2015

  61. [61]

    Rui Zhang, Natalie Stanley, Christopher Griggs, Andrew Chi, and Cynthia Sturton

    work page

  62. [62]

    In International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS)

    Identifying Security Critical Properties for the Dynamic Verification of a Processor. In International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS)

    work page

  63. [63]

    Boyou Zhou, Ronen Adato, Mahmoud Zangeneh, Tianyu Yang, Aydan Uyar, Bennett Goldberg, Selim Unlu, and Ajay Joshi. 2015. Detecting hardware tro- jans using backside optical imaging of embedded watermarks. In Proceedings of ACM/EDAC/IEEE Design Automation Conference (DAC). 14 An Extensible Framework for Quantifying the Coverage of Defenses Against Untrusted...

    work page 2015