Validating the Claim - Defeating HaTCh : Building Malicious IP cores

This paper defends the design of hardware Trojan proposed in the paper “Defeating HaTCh: Building Malicious IP Cores” by defining the four critical properties which are required to be satisfied to classify it to belong to class of Deterministic Hardware Trojan. This is to counter the claims of authors of HaTCh in their paper “Comments on Defeating HaTCh”.

💡 Research Summary

The paper revisits the claim made by Bhardwaj and Roy that their hardware Trojan, presented in “Defeating HaTCh: Building Malicious IP Cores,” can evade detection by the HaTCh (Hardware Trojan Catcher) algorithm. HaTCh, as defined by Haider et al., targets deterministic hardware Trojans (HD) characterized by four quantitative parameters: trigger‑signal dimension (d), payload propagation delay (t), implicit‑behavior factor (α), and trigger‑signal locality (l). The authors first restate these definitions, emphasizing that a larger d or l, a longer t, and a higher α increase stealth and make detection harder.

The Trojan under discussion is embedded in an AES encryption IP core. Its purpose is to leak the secret key by using a self‑synchronizing scrambler (a multiplicative scrambler) that transmits key bits over the same output pin used for ciphertext. The transmission is triggered only when no plaintext data is present at the AES input, making the trigger implicit in the normal functional behavior of the AES block. The design employs two identical linear‑feedback shift registers (LFSRs): one in the transmitter, whose output is XORed with the key bit, and one in the receiver that extracts the key by comparing its feedback bit with the incoming data over 128 cycles. A counter and comparator tolerate channel errors by allowing a range of count values (e.g., 3 or 125) instead of exact 0 or 128.

The authors map this Trojan onto the HD parameter space as follows:

1. Trigger‑Signal Dimension (d): Because the trigger condition depends on the entire AES core’s activity, every wire in the core is considered part of the trigger set, yielding an extremely large d value.

2. Payload Propagation Delay (t): To deliver the full 128‑bit key, the Trojan must transmit one bit per 128‑cycle interval, resulting in a minimum of 128 × 128 = 16 384 clock cycles. If plaintext appears intermittently, the effective delay grows even larger.

3. Implicit‑Behavior Factor (α): During trigger periods the output appears as random data, indistinguishable from normal encrypted traffic. Consequently, the Trojan rarely exhibits explicit malicious behavior, leading to a high α and increased stealth.

4. Trigger‑Signal Locality (l): Since the trigger wires are spread across the whole AES block, l is also large, further complicating detection.

Based on these arguments, the paper concludes that the Trojan unequivocally belongs to the HD class (denoted H_d,t,α,l) and therefore falls outside the detection capabilities of HaTCh, which was designed to exhaustively analyze Trojans with bounded d, t, α, and l.

While the logical mapping to the HD parameters is internally consistent, the paper lacks empirical validation. It assumes worst‑case values for d and l without providing a concrete netlist or physical layout that demonstrates such extensive wiring. The delay analysis treats the key‑exfiltration process as a continuous, uninterrupted sequence, ignoring realistic traffic patterns where plaintext may frequently interrupt transmission, thereby reducing the effective t. Moreover, the claim of a high α rests on the premise that random‑looking output will never be flagged, yet side‑channel analyses (e.g., power or electromagnetic profiling) could still reveal the abnormal XOR operations associated with key‑dependent inversion of the scrambler output. HaTCh’s multi‑modal detection strategy—combining statistical testing, formal verification, and side‑channel monitoring—may still capture anomalies even when d, t, α, and l are large.

In summary, the paper provides a theoretical defense that the proposed Trojan satisfies the HD definition and should evade HaTCh. However, the argument relies heavily on optimistic assumptions about trigger implicitness and stealth metrics, and it does not present concrete experimental data to substantiate the claim that HaTCh cannot detect the Trojan in practice. Further work involving detailed hardware simulations, side‑channel measurements, and application of the full HaTCh detection pipeline would be necessary to validate the authors’ conclusions.