pith. sign in

arxiv: 2607.01526 · v1 · pith:Q6CCDSHKnew · submitted 2026-07-01 · 💻 cs.CR · cs.AR

LIB-TRAP: Standard Cell Library Hardware Trojan Risk Assessment and Prevention

Harish Kumar Dharavath , Md Muhtasim Alam Chowdhury , Rozhin Yasaei , Soheil Salehi This is my paper

Pith reviewed 2026-07-03 19:47 UTC · model grok-4.3

classification 💻 cs.CR cs.AR
keywords hardware trojanstandard cell libraryhardware securityIC fabricationfabless semiconductorAES encryptionthreat model
0
0 comments X

The pith

Tampered standard cell libraries let foundries insert hardware Trojans that designers cannot detect during synthesis.

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

The paper establishes that standard cell libraries can be modified to include deactivated hardware Trojan cells. When a design house uses the tampered library for synthesis, the netlist looks normal, but a malicious foundry can swap in activated Trojan cells during fabrication. This was shown by turning Saed32nm and Sky130nm libraries into malicious versions and applying them to AES-128, Ethernet controller, and WISHBONE DMA circuits in two technology nodes. A sympathetic reader would care because existing Trojan defenses focus on netlists or layouts, leaving this library-level vector unaddressed in the fabless manufacturing flow.

Core claim

Standard cell libraries can be tampered such that they provide deactivated hardware Trojan cells during synthesis and implementation; the foundry then replaces them with activated counterparts during fabrication, masking the presence of arbitrary hardware Trojans from IC designers. This threat model was demonstrated by converting Saed32nm and Sky130nm libraries into malicious ones and applying them to benchmark circuits including an AES-128 core, an Ethernet controller, and a WISHBONE DMA engine across Synopsys 32nm and SkyWater 130nm technologies.

What carries the argument

The tampered standard cell library containing both standard cells and deactivated hardware Trojan variants, which allows the foundry to perform cell substitution without altering the synthesized netlist.

If this is right

  • Designers using standard cell libraries for synthesis may incorporate undetected hardware Trojans in their final chips.
  • Existing hardware Trojan mitigation strategies that focus on netlist or post-synthesis analysis fail to catch library-level insertions.
  • Binary classification of design features like cell count, area, and power can potentially identify tampered library usage in synthesized designs.
  • Arbitrary hardware Trojans can be masked in common benchmark circuits such as encryption cores and controllers.

Where Pith is reading between the lines

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

  • Verification of standard cell libraries before use could become a necessary step in secure design flows.
  • This attack vector implies that open-source libraries require additional integrity checks to prevent such tampering.
  • Future work might explore automated detection of cell substitutions through layout or timing analysis.

Load-bearing premise

The foundry can replace the library's deactivated HT cells with activated counterparts during fabrication without the substitution being detected by the design house.

What would settle it

Fabricating the same benchmark netlist from both clean and tampered libraries and then comparing post-fabrication power, area, or functional behavior to see if the Trojan activation produces measurable differences.

Figures

Figures reproduced from arXiv: 2607.01526 by Harish Kumar Dharavath, Md Muhtasim Alam Chowdhury, Rozhin Yasaei, Soheil Salehi.

Figure 1
Figure 1. Figure 1: Standard cell library threat model illustrating HT insertion during library development and deployment. [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Modified and malicious HT-Infected cell library regen [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Schematic (left) and layout (right) of a nominal buffer standard cell (a) without an HT payload, (b) with 1 HT payload, [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Average propagation delay (10,000 Monte Carlo it [PITH_FULL_IMAGE:figures/full_fig_p004_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: (a) Static power and (b) Average Propagation Delay (10,000 Monte Carlo iteration, [PITH_FULL_IMAGE:figures/full_fig_p005_5.png] view at source ↗
read the original abstract

Vulnerabilities inherent to the fabless semiconductor manufacturing model have significantly increased the risk of malicious Hardware Trojan (HT) insertion, posing severe threats to hardware security. Several HT mitigation and detection strategies have been developed, and existing works explore the insertion of HTs in the space between standard cells in an integrated circuit. However, there is a lack of research into the vulnerabilities posed by the building blocks of most digital designs on the market today, the standard cells. This work investigates a novel threat model in which standard cells are considered untrusted. Our proposed threat model provides the design house with a tampered standard cell library. The intended netlist is synthesized and implemented using the tampered library. During fabrication, a nefarious foundry replaces the library's deactivated HT cells with activated counterparts. Using open-source and industry-standard Electronic Design Automation (EDA) tools, existing standard cell libraries, Saed32nm and Sky130nm, are converted into malicious libraries capable of masking the presence of arbitrary HTs from IC designers. The malicious library is then applied and characterized in multiple standard benchmark designs. To demonstrate the efficacy and stealthiness of this standard cell-based attack vector, three benchmark circuits, an AES-128 encryption core, an Ethernet controller, and a WISHBONE DMA engine, were synthesized using both clean and Trojan-infected libraries across Synopsys 32nm and SkyWater 130nm technologies. Design-level features, including total cell count, total area, dynamic power consumption, and static power, were extracted from these synthesized circuits to serve as inputs for binary classification

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

2 major / 1 minor

Summary. The paper proposes a threat model in which a tampered standard cell library containing deactivated hardware Trojan (HT) cells is supplied to the design house. The intended netlist is synthesized and implemented with this library; a malicious foundry then substitutes activated HT cells during fabrication. The work converts SAED32nm and Sky130nm libraries into malicious versions using open-source and industry EDA tools, applies them to AES-128, Ethernet controller, and WISHBONE DMA benchmarks, and extracts aggregate design features (cell count, area, dynamic/static power) as inputs for binary classification to assess stealth.

Significance. If the substitution step can be performed without detection, the work identifies a previously under-explored attack surface at the standard-cell level that could affect any design synthesized from a compromised library. The use of real commercial and open PDKs together with standard synthesis flows provides a concrete, reproducible demonstration of the library-conversion step.

major comments (2)
  1. [Threat model / abstract] Threat-model description (abstract and § on threat model): the claim that the attack evades detection rests on the unexamined assumption that a cell-for-cell replacement of deactivated HT cells by activated counterparts can be executed without triggering netlist comparison, timing reports, power analysis, or physical verification; no bounds, simulation, or literature reference is supplied to support feasibility of this step.
  2. [Experiments / abstract] Benchmark experiments (abstract and results section): only aggregate metrics are described; the manuscript supplies no quantitative binary-classification results (accuracy, precision, recall, or ROC), error bars, or cross-validation details, leaving the central claim of stealthiness without empirical support.
minor comments (1)
  1. [Abstract] The abstract ends mid-sentence at 'binary classification'; the full manuscript should ensure the abstract is self-contained.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the detailed and constructive review. We address each major comment below, indicating planned revisions to strengthen the manuscript.

read point-by-point responses

  1. Referee: [Threat model / abstract] Threat-model description (abstract and § on threat model): the claim that the attack evades detection rests on the unexamined assumption that a cell-for-cell replacement of deactivated HT cells by activated counterparts can be executed without triggering netlist comparison, timing reports, power analysis, or physical verification; no bounds, simulation, or literature reference is supplied to support feasibility of this step.

    Authors: We agree that the current manuscript presents the substitution step as part of the threat model without providing simulations, bounds, or references to support its undetectability. The work centers on library conversion and synthesis rather than fabrication-phase verification. In revision we will expand the threat-model section to explicitly enumerate the assumptions about the substitution step, discuss possible detection avenues (e.g., netlist hashing, timing/power sign-off, physical verification), and note that feasibility remains an open question requiring further study. revision: yes

  2. Referee: [Experiments / abstract] Benchmark experiments (abstract and results section): only aggregate metrics are described; the manuscript supplies no quantitative binary-classification results (accuracy, precision, recall, or ROC), error bars, or cross-validation details, leaving the central claim of stealthiness without empirical support.

    Authors: The manuscript extracts the listed aggregate features from the three benchmarks but stops short of reporting the binary-classification results themselves. We acknowledge this leaves the stealthiness assessment without the requested quantitative backing. In the revised version we will add a dedicated subsection presenting binary classification experiments (using standard classifiers on the extracted features), including accuracy, precision, recall, ROC-AUC, error bars, and cross-validation details to provide empirical support for the claim. revision: yes

Circularity Check

0 steps flagged

No circularity; empirical demonstration without derivations or fitted predictions

full rationale

The paper describes a threat model for tampered standard cell libraries and demonstrates it via library conversion, synthesis of AES-128/Ethernet/DMA benchmarks on SAED32nm/Sky130nm, and extraction of aggregate metrics (cell count, area, power) for classification. No equations, parameter fitting, predictions, or self-citations appear as load-bearing steps in any derivation chain. The central claim is a practical feasibility argument resting on the (undemonstrated) physical substitution step, but this is an assumption gap rather than circular reduction of a result to its inputs. The work is self-contained against external benchmarks and does not invoke uniqueness theorems or ansatzes from prior author work.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

The central claim rests on domain assumptions about the fabless flow rather than mathematical axioms or fitted parameters; no free parameters or invented entities are introduced.

axioms (1)
  • domain assumption Standard cell libraries can be modified and substituted by a foundry without detection in the design or fabrication flow.
    Core premise of the threat model that enables the replacement step.

pith-pipeline@v0.9.1-grok · 5830 in / 1189 out tokens · 33208 ms · 2026-07-03T19:47:38.016014+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

25 extracted references · 4 canonical work pages · 1 internal anchor

  1. [1]

    Hardware design and security needs attention: From survey to path forward,

    S. Ghimire, M. A. Chowdhury, B. S. Latibari, M. Mamun, J. W. Carpenter, B. Tan, H. Pearce, P. Satam, and S. Salehi, “Hardware design and security needs attention: From survey to path forward,”arXiv preprint arXiv:2504.08854, 2025

    work page arXiv 2025

  2. [2]

    Optimized and automated secure ic design flow: A defense-in-depth approach,

    K. I. Gubbi, B. S. Latibari, M. A. Chowdhury, A. Jalilzadeh, E. Y . Hamedani, S. Rafatirad, A. Sasan, H. Homayoun, and S. Salehi, “Optimized and automated secure ic design flow: A defense-in-depth approach,”IEEE Transactions on Circuits and Systems I: Regular Papers, 2024

    2024

  3. [3]

    Hardware trojan detection using machine learning: A tutorial,

    K. I. Gubbi, B. Saber Latibari, A. Srikanth, T. Sheaves, S. A. Beheshti- Shirazi, S. M. PD, S. Rafatirad, A. Sasan, H. Homayoun, and S. Salehi, “Hardware trojan detection using machine learning: A tutorial,”ACM Transactions on Embedded Computing Systems, vol. 22, no. 3, pp. 1– 26, 2023

    2023

  4. [4]

    Hardware Trojans: Lessons Learned after One Decade of Research,

    K. Xiao, D. Forte, Y . Jin, R. Karri, S. Bhunia, and M. Tehranipoor, “Hardware Trojans: Lessons Learned after One Decade of Research,” ACM Transactions on Design Automation of Electronic Systems (TO- DAES), vol. 22, no. 1, pp. 1–23, 2016

    2016

  5. [5]

    Novel Techniques for High-Sensitivity Hardware Trojan Detection Using Thermal and Power Maps,

    A. N. Nowroz, K. Hu, F. Koushanfar, and S. Reda, “Novel Techniques for High-Sensitivity Hardware Trojan Detection Using Thermal and Power Maps,”IEEE Transactions on Computer-Aided Design of Inte- grated Circuits and Systems, vol. 33, no. 12, 2014

    2014

  6. [6]

    A clock sweeping technique for detecting hardware trojans impacting circuits delay,

    K. Xiao, X. Zhang, and M. Tehranipoor, “A clock sweeping technique for detecting hardware trojans impacting circuits delay,”IEEE Design Test, vol. 30, no. 2, pp. 26–34, 2013

    2013

  7. [7]

    Lasca: Learning assisted side channel delay analysis for hardware trojan detection,

    A. Vakil, F. Behnia, A. Mirzaeian, H. Homayoun, N. Karimi, and A. Sasan, “Lasca: Learning assisted side channel delay analysis for hardware trojan detection,” in2020 21st International Symposium on Quality Electronic Design (ISQED), 2020, pp. 40–45

    2020

  8. [8]

    Hardware trojan detection using controlled circuit aging,

    V . R. Surabhi, P. Krishnamurthy, H. Amrouch, K. Basu, J. Henkel, R. Karri, and F. Khorrami, “Hardware trojan detection using controlled circuit aging,”IEEE Access, vol. 8, pp. 77 415–77 434, 2020

    2020

  9. [9]

    Mero: A statistical approach for hardware trojan detection,

    R. S. Chakraborty, F. Wolff, S. Paul, C. Papachristou, and S. Bhunia, “Mero: A statistical approach for hardware trojan detection,” inInterna- tional Workshop on Cryptographic Hardware and Embedded Systems. Springer, 2009, pp. 396–410

    2009

  10. [10]

    A survey of hardware trojan taxonomy and detection,

    M. Tehranipoor and F. Koushanfar, “A survey of hardware trojan taxonomy and detection,”IEEE design & test of computers, vol. 27, no. 1, pp. 10–25, 2010

    2010

  11. [11]

    Benchmarking of hardware trojans and maliciously affected circuits,

    B. Shakya, T. He, H. Salmani, D. Forte, S. Bhunia, and M. Tehranipoor, “Benchmarking of hardware trojans and maliciously affected circuits,” Journal of Hardware and Systems Security, vol. 1, no. 1, pp. 85–102, 2017

    2017

  12. [12]

    On design vulnerability analysis and trust benchmarks development,

    H. Salmani, M. Tehranipoor, and R. Karri, “On design vulnerability analysis and trust benchmarks development,” in2013 IEEE 31st inter- national conference on computer design (ICCD). IEEE, 2013, pp. 471–474

    2013

  13. [13]

    Formal security verification of third party intellectual property cores for infor- mation leakage,

    J. Rajendran, A. M. Dhandayuthapany, V . Vedula, and R. Karri, “Formal security verification of third party intellectual property cores for infor- mation leakage,” in2016 29th International conference on VLSI design and 2016 15th international conference on embedded systems (VLSID). IEEE, 2016, pp. 547–552

    2016

  14. [14]

    Detecting malicious modifica- tions of data in third-party intellectual property cores,

    J. Rajendran, V . Vedula, and R. Karri, “Detecting malicious modifica- tions of data in third-party intellectual property cores,” in2015 52nd ACM/EDAC/IEEE Design Automation Conference (DAC). IEEE, 2015, pp. 1–6

    2015

  15. [15]

    Graph similarity and its applications to hardware security,

    M. Fyrbiak, S. Wallat, S. Reinhard, N. Bissantz, and C. Paar, “Graph similarity and its applications to hardware security,”IEEE Transactions on Computers, vol. 69, no. 4, pp. 505–519, 2019

    2019

  16. [16]

    Golden-Free Hardware Trojan Detection with High Sensitivity Under Process Noise,

    T. Hoque, S. Narasimhan, X. Wang, S. Mal-Sarkar, and S. Bhunia, “Golden-Free Hardware Trojan Detection with High Sensitivity Under Process Noise,”Journal of Electronic Testing, vol. 33, no. 1, pp. 107– 124, 2017

    2017

  17. [17]

    Impact of cross- standard cell libraries on machine learning based hardware trojan detection,

    S.-W. Chen, J.-W. Liao, and C.-W. T. J.-H. Hsiao, “Impact of cross- standard cell libraries on machine learning based hardware trojan detection,” 2022

    2022

  18. [18]

    Hard- ware trojan detection using graph neural networks,

    R. Yasaei, L. Chen, S.-Y . Yu, and M. A. A. Faruque, “Hard- ware trojan detection using graph neural networks,”arXiv preprint arXiv:2204.11431, 2022

    work page arXiv 2022

  19. [19]

    Auto- matic hardware trojan insertion using machine learning,

    J. Cruz, P. Gaikwad, A. Nair, P. Chakraborty, and S. Bhunia, “Auto- matic hardware trojan insertion using machine learning,”arXiv preprint arXiv:2204.08580, 2022

    work page arXiv 2022

  20. [20]

    Regds: A reverse engineering framework from gdsii to gate-level netlist,

    R. S. Rajarathnam, Y . Lin, Y . Jin, and D. Z. Pan, “Regds: A reverse engineering framework from gdsii to gate-level netlist,” in2020 IEEE International Symposium on Hardware Oriented Security and Trust (HOST), 2020, pp. 154–163

    2020

  21. [21]

    Logistic regression model opti- mization and case analysis,

    X. Zou, Y . Hu, Z. Tian, and K. Shen, “Logistic regression model opti- mization and case analysis,” in2019 IEEE 7th International Conference on Computer Science and Network Technology (ICCSNT), 2019, pp. 135–139

    2019

  22. [22]

    Machine learning applications based on svm classification a review,

    D. M. Abdullah and A. M. Abdulazeez, “Machine learning applications based on svm classification a review,”Qubahan Academic Journal, vol. 1, no. 2, pp. 81–90, 2021

    2021

  23. [23]

    A comparison of random forest variable selection methods for classification prediction modeling,

    J. L. Speiser, M. E. Miller, J. Tooze, and E. Ip, “A comparison of random forest variable selection methods for classification prediction modeling,”Expert Systems with Applications, vol. 134, pp. 93–101, 2019. [Online]. Available: https://www.sciencedirect.com/science/article/pii/S0957417419303574

    2019

  24. [25]

    An Analysis of Deep Neural Network Models for Practical Applications

    [Online]. Available: http://arxiv.org/abs/1605.07678

    work page internal anchor Pith review Pith/arXiv arXiv

  25. [26]

    Iwls 2005 benchmarks,

    C. Albrecht, “Iwls 2005 benchmarks,” inInternational Workshop for Logic Synthesis (IWLS): http://www. iwls. org, 2005

    2005