🤖 machine learning

Explainability Methods for Hardware Trojan Detection: A Systematic Comparison

This paper systematically compares three categories of explainability methods—domain-aware property analysis, model-agnostic case-based reasoning, and model-agnostic feature attribution techniques—on the Trust-Hub benchmark to determine which approach best provides actionable insights for reducing false positives and negatives in gate-level hardware Trojan detection.

Original authors: Paul Whitten, Francis Wolff, Chris Papachristou

Published 2026-07-14

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Paul Whitten, Francis Wolff, Chris Papachristou

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine a billion-transistor microchip as a massive, bustling city built entirely of logic gates. Most of the buildings are honest citizens doing their jobs, but a sneaky saboteur (a "Hardware Trojan") has secretly constructed a tiny, hidden trapdoor in one of the buildings. This trapdoor stays locked until a very specific, rare combination of events happens—like a specific sequence of cars passing a certain intersection at the exact same time—then it opens to steal secrets or crash the city.

The problem? You can't just patch these traps with a software update. Once the chip is made, the trapdoor is baked into the silicon forever. If you miss it, you have to recall the entire product, which costs a fortune. So, engineers need a way to find these traps before the chips are built.

Enter the researchers from Case Western Reserve University. They tried to use Artificial Intelligence (AI) to act as a detective, scanning the blueprints of these cities to spot the suspicious buildings. But here's the catch: the AI is a "black box." It can point to a building and say, "This one is 73% likely to be a trap," but it can't explain why. For a human engineer, a number like "73%" is useless. They need to know what about the building looks suspicious so they can double-check it.

The team asked a big question: Which kind of "explanation" actually helps a human engineer?

They tested three different ways of explaining the AI's detective work:

1. The "Domain Expert" (The Property-Based Method)

This approach is like hiring a detective who speaks the language of the city. Instead of just giving a score, this method looks at 31 specific "city rules." For example, it might say: "This building has a weirdly complex entrance (high fanin) right next to the main exit (primary output). That matches the pattern of a rare-event trap."

The Result: This method is great at speaking the engineer's language. It uses concepts they already know. However, when the researchers tried to use this method to catch the traps, it was a bit clumsy. It found almost all the traps (88.9% recall) but flagged so many innocent buildings as suspects that the precision was only 1.7%. It was like a detective who screams "Thief!" every time someone walks near a door—too many false alarms to be useful on its own.

2. The "Case File" (The k-Nearest Neighbors Method)

This approach is like a detective who says, "I don't need to explain the theory; just look at the evidence." It finds the 5 most similar buildings from its training files and says, "This building looks just like these 4 other buildings we know were traps."

The Result: This was a huge hit. The AI's decision matched the "case files" 96.51% of the time. It gave engineers a concrete, visual reason to trust the alert: "Look, this matches the known bad guys."

3. The "Mathematical Scorecard" (LIME, SHAP, and Gradient)

These are the popular, general-purpose AI explainers used in many fields (like image recognition). They act like a scorecard, assigning a number to every feature. For example, "The distance to the nearest flip-flop contributed +0.05 to the suspicion score."

The Result: The paper found that while these methods are mathematically rigorous, they are not very helpful for hardware engineers. They gave generic scores that lacked the "circuit-level context" needed to actually fix the problem.
- The Agreement Problem: When the researchers compared the scores from these different math methods, they didn't agree very well. The correlation was only about 0.30 (on a scale where 1.0 is perfect agreement). It's like three different weather apps giving you slightly different rain probabilities; they are related, but they aren't telling the same story.
- The Speed Trap: One of these methods (Gradient) was super fast (0.16 milliseconds per gate), while another (SHAP) was slower (1.10 milliseconds). But the paper argues that speed doesn't matter if the explanation is useless. Being fast at giving a generic score doesn't help you find the trapdoor.

The Big Winner: A Better Detective

The researchers also tested a new type of AI classifier called XGBoost (a "gradient-boosted" tree). Think of this as upgrading the detective's magnifying glass.

The Old Way (SVM): The previous standard method was like a detective who found 70% of the traps but flagged 35 innocent buildings for every 1,000 gates checked. That's a lot of wasted time!
The New Way (XGBoost): The new method found 69.44% of the traps (about the same amount) but only flagged 4.74 innocent buildings per 1,000 gates. That is a 7.4-fold reduction in false alarms! It also improved the "precision" (how many flagged buildings were actually guilty) from 11.33% to 48.08%.

What This Means for You

The paper concludes that for hardware security, generic math scores aren't enough. You need explanations that make sense in the real world of circuits.

Case-based reasoning (showing similar past cases) worked incredibly well because it gave engineers a precedent to trust.
Domain-aware analysis (using circuit-specific rules) is great for understanding why, but it needs to be paired with a strong detector like XGBoost to avoid too many false alarms.
Generic feature scores (like LIME and SHAP) are interesting mathematically, but they don't provide the "actionable insights" engineers need to actually fix the chip.

The authors are careful to note that these results are based on the Trust-Hub benchmark, which uses synthetic (man-made) traps in digital circuits. They haven't tested this on real-world, complex analog chips or sequential traps yet, so while the method looks promising, it's still a work in progress for the real world. But for now, they've shown that if you want to find a hardware Trojan, you need a detective that speaks the language of the circuit, not just a calculator that spits out numbers.

Technical Summary: Explainability Methods for Hardware Trojan Detection

Problem Statement
Hardware trojans are malicious circuits embedded during the design or fabrication of integrated circuits (ICs). Unlike software vulnerabilities, they are permanent in silicon and cannot be patched, necessitating early detection during the design phase. While machine learning (ML) models can flag suspicious gates in gate-level netlists, their "black-box" nature often yields statistically based solutions with high false-positive rates. Security engineers require actionable explanations grounded in circuit-design principles to validate alerts and plan remediation. Current explainable AI (XAI) methods, developed for general domains like image classification, often provide generic feature importance scores that lack the specific circuit-level context required by hardware practitioners. This work addresses the gap by empirically comparing domain-aware explainability against model-agnostic techniques for hardware security applications.

Methodology
The study utilizes the Trust-Hub benchmark dataset, comprising 30 digital combinational circuits (RS232 peripherals and ISCAS benchmarks) with labeled gate-level trojan insertions. The dataset exhibits extreme class imbalance (approximately 158 benign gates to 1 trojan gate).

The methodology evaluates five explainability approaches across three categories, all utilizing the same five structural features derived from Hasegawa et al.: Logic Gate Fanins (LGFi), Flip-Flop Input (FFi), Flip-Flop Output (FFo), Primary Input (PI), and Primary Output (PO).

Domain-Aware Property Analysis (Method 1): This approach constructs an ensemble of 31 XGBoost classifiers, each trained on a distinct non-empty subset of the five features. Explanations are generated by identifying which specific property combinations (e.g., high fanin near outputs) voted for a detection. This aligns explanations with hardware security vocabulary.
Model-Agnostic Case-Based Reasoning (Method 2): This method uses a single XGBoost classifier for prediction but explains decisions by retrieving the $k=5$ nearest neighbors from the training set. Explanations rely on precedent, showing engineers specific training examples that match the suspect gate's feature profile.
Model-Agnostic Feature Attribution (Methods 3–5): Three standard post-hoc attribution techniques are applied to the XGBoost classifier:
- LIME: Local Interpretable Model-agnostic Explanations using perturbation.
- SHAP: SHapley Additive exPlanations using game-theoretic values (TreeExplainer).
- Gradient Attribution: First-order sensitivity analysis.

Detection performance is primarily evaluated using XGBoost, with Random Forest used to verify generalization. The Hasegawa SVM baseline is reimplemented under identical experimental conditions (same split, features, and thresholding protocols) for a fair comparison.

Key Contributions

Systematic Comparison: The paper provides the first empirical comparison of domain-aware property analysis, precedent-based reasoning, and generic feature attribution specifically for gate-level hardware trojan detection.
Improved Detection Performance: The work demonstrates that optimized XGBoost and Random Forest classifiers significantly outperform the re-implemented SVM baseline. XGBoost achieves 48.08% precision and 69.44% recall (F1 = 0.568), representing a 4.25-fold precision improvement and a 7.4-fold reduction in false-positive density compared to the SVM baseline (11.33% precision, 35.0 false positives per 1,000 gates).
Explainability Trade-off Analysis:
- Domain-Aware vs. Model-Agnostic: Domain-aware methods offer explanations in familiar circuit terms (e.g., "high fanin complexity near outputs"), whereas model-agnostic methods (LIME, SHAP) yield generic importance scores.
- Correspondence: Case-based reasoning achieves 96.51% correspondence between predictions and training exemplars, providing intuitive justification.
- Attribution Consistency: LIME and SHAP show only moderate per-gate agreement (Spearman $\rho = 0.30$ ), indicating they do not produce identical importance rankings despite both being model-agnostic.
- Efficiency: Gradient-based attribution is found to be 7 times faster than SHAP (0.16 ms vs. 1.10 ms per explanation) while yielding similar feature rankings, though it lacks SHAP's formal consistency guarantees.

Results

Detection: On a held-out test set of 11,392 gates, XGBoost at an optimized threshold (0.940) achieved 48.08% precision and 69.44% recall. Random Forest achieved comparable F1 scores (0.555) with half the false-positive density of XGBoost (2.37 vs. 4.74 FP per 1,000 gates).
Explainability:
- Property-Based (M1): While the initial ensemble weighting (EPARS) yielded low precision (1.7%), re-weighting with MCC at an optimized threshold achieved 78.1% precision at the cost of lower recall (34.7%). This highlights that the "limited" performance of property-based methods in this low-dimensional setting is a function of weighting and operating point, not an inherent ceiling of the approach.
- Case-Based (M2): Achieved high correspondence (96.51%) and provided full netlist provenance for retrieved neighbors, allowing engineers to inspect actual training examples.
- Attribution (M3–M5): LIME and SHAP provided generic feature weights without explicit circuit context. Gradient attribution offered a speed advantage but shared the same limitation of lacking domain-specific interpretation.
Generalization: Leave-one-circuit-out (LOCO) validation showed strong generalization within the RS232 family (F1 = 0.80) but failed across distinct ISCAS benchmark families (F1 = 0.06), indicating that the five scalar structural features are insufficient for cross-architecture generalization without richer local graph representations.

Significance and Claims
The paper claims that for hardware security practitioners, domain-aware property analysis and case-based reasoning offer complementary advantages over generic feature attribution. Property-based methods align with how engineers reason about circuits, while case-based methods provide precedent-based interpretability without requiring domain expertise to interpret the explanation itself.

The authors assert that computational efficiency (e.g., gradient methods) cannot substitute for domain-aware interpretability; generic importance scores (from LIME/SHAP) lack the circuit-level context necessary for validation and remediation planning. The work concludes that while model-agnostic methods are useful for exploratory analysis, domain-aligned or precedent-based approaches are superior for generating actionable insights in hardware security. The findings suggest that in low-dimensional, feature-constrained domains, combining model-agnostic ML with precedent-based explanations may be more effective than relying solely on property ensembles.

1. The "Domain Expert" (The Property-Based Method)

2. The "Case File" (The k-Nearest Neighbors Method)

3. The "Mathematical Scorecard" (LIME, SHAP, and Gradient)

The Big Winner: A Better Detective

What This Means for You

More like this