21 Hardware Security: Trojans and Assurance

21.4.1.1 Worked combinational trigger: one truth-table row changes

Start with an intended two-input AND output

A hidden rare-state detector built from a NOR gate asserts only when both inputs are zero:

If an XOR payload combines that trigger with the protected signal, the modified output is

Evaluate every row rather than relying on the gate names:

The outputs of the AND gate and the NOR gate can never both be 1, so this particular modified function is also $A\ \text{XNOR}\ B$: it asserts at 00 as well as 11. A functional test that tries 01, 10, and the expected asserted case 11 reports success while missing the only changed row. That is why rare-node analysis and mutation-sensitive test vectors matter; ordinary high-coverage application tests may never place all trigger inputs in their rare combination at once.

The algebra above proves that one row moves. It does not show how small the inserted circuit is, or how ordinary the rest of it looks. Trace the intended path and the modified path in Figure 21.2 before moving to the sequential case.

Read the two circuit cards of Figure 21.2 in order. AND · protected is the entire intended function: two inputs, one output, three of four rows sitting at zero. The modified card leaves that gate untouched and adds two more — NOR · trigger, which asserts for the single input pair A = 0 and B = 0, and XOR · payload, which passes the protected value through unchanged for as long as the trigger stays low. The table beneath marks exactly one row CHANGED, and the closing panel spells out the awkward consequence: a suite that exercises 01, 10, and the asserted 11 row sees three matching outputs and reports success. The insertion is not hidden by cleverness; it is hidden by test coverage that never visits the rare state.

21.4.1.2 Sequential trigger and XOR payload timing

Let a synchronous $k$-bit counter hold $Q[n]$ after clock edge $n$:

The payload $Y[n]=X[n]\oplus T[n]$ passes the protected signal unchanged while $T=0$ and inverts it while $T=1$. If the terminal-count signal is not latched, inversion lasts only for the terminal-count cycle; if a hidden latch captures the event, it can persist until a reset condition. That distinction must appear in the hardware review because it changes both consequence and test duration.

Starting from zero and comparing the current count before increment, the first terminal state arrives after $2^k-1$ clock edges. At clock frequency $f_{clk}$,

For $k=32$ at $100\ \mathrm{MHz}$, the delay is about $42.95\ \mathrm{s}$ of uninterrupted enabled clocks. Resetting or clock-gating the block during short production tests can therefore prevent activation even when total test time looks long enough. State-aware verification must vary reset, enable, low-power, and wraparound behavior rather than simply run random vectors.

The trigger and payload tables answer different questions. Trigger coverage asks whether the hidden condition was reached. Payload observation asks whether the resulting digital or analog deviation reached a measured output. A test is incomplete if it satisfies only one side.

A counter trigger resists reasoning from gate names, because its cost is counted in clock edges rather than input values. Follow the block path and then the waveform lanes in Figure 21.3, where the wait itself becomes something you can point at.

In Figure 21.3, follow the k-bit counter into the terminal count detector and on into the XOR payload that already carries the protected signal. In the waveform lanes, T[n] stays at zero through every earlier count, so Y[n] tracks X[n] exactly and nothing in the observable behaviour looks wrong; only the highlighted column at the terminal value shows an inversion, and only for one cycle. The card holding t_trigger converts that column into wall-clock time — roughly 42.95 s of uninterrupted, enabled clocking at $k = 32$ and 100 MHz — which is why resetting or clock-gating the block between vectors keeps a long test suite permanently short of activation. The four payload cards below separate what a payload changes from the evidence that would notice it.

For an IoT reviewer, hardware Trojan risk is a supply-chain and assurance question. The evidence should show which IP blocks, CAD tools, foundry or assembly steps, and receiving tests are trusted for the device class. Detection approaches can be destructive, such as reverse-engineering a sample, or non-destructive, such as logic testing and side-channel comparison. Design-for-security approaches try to prevent insertion or make detection easier, for example by controlling design sources, reducing unused layout space, adding monitors, and preserving a trusted baseline. Runtime monitoring then checks whether deployed devices behave outside the expected power, timing, or functional envelope. High-volume commodity sensors may need only supplier and acceptance evidence; a safety-critical or payment device may need much stronger IC-level assurance.

21.4.1.3 Detection-method decision table

Destructive reverse engineering begins by depackaging a sampled IC. The laboratory exposes the die, removes material one layer at a time—often using chemical-mechanical polishing or another controlled delayering process—images each layer with optical or scanning-electron microscopy, aligns the images, extracts devices and interconnect, and reconstructs a layout or netlist for comparison. The evidence can be physically detailed, but the inspected sample is consumed. It is also a sampling claim: clean reconstruction of one die does not prove every unit or lot is identical.

The decision is consequence-driven. Use pre-silicon checks where the design representation is available, logic tests to exercise functional effects, side-channel comparisons to look for unpropagated physical differences, and destructive analysis for high-assurance sampling or disputed evidence. Record the golden reference’s provenance and statistical spread; “matches golden” is meaningless if the reference device or model could contain the same change.

A table compares each method against its own axis, which makes every row easy to read and the overall shape of the choice easy to miss. Figure 21.4 aligns four methods on the same five criteria so the blind spots line up in a column instead of hiding in prose.

Compare the destroys? and coverage cells of Figure 21.4 first. Reverse engineering is the only method that consumes the part, and it is also the only one whose coverage reads 1 sample — a pairing that explains why it belongs to disputed evidence rather than routine assurance. Then read the trigger? column downward: post-silicon logic testing needs the payload to must fire before it can observe anything, while side-channel comparison can register a dormant change through extra switching alone. That is the complementarity worth remembering, and it is also why the reference cell matters so much for the side-channel row, since a golden distribution containing the same modification proves nothing. Every card closes with a Confidence and a Limit line so a review can state precisely what its chosen method did and did not establish.

21.4.1.4 Design for security across the lifecycle

Walk the stages in order. Logic locking constrains function before manufacture. Layout filling reduces insertion opportunity during physical design. Embedded monitors create observability during test. Runtime monitoring carries selected evidence into deployment. The controls overlap by design: a delay monitor may catch a change that logic vectors miss, while protected field telemetry can reveal a deviation that did not appear under factory voltage and temperature. The assurance record should name which insertion point and observation gap each mechanism covers rather than counting four controls as four independent guarantees.

Naming four mechanisms is not the same as knowing which window each one closes. Read Figure 21.5 down the lifecycle rail and treat the two coloured strips inside every card, not the mechanism name above them, as the claim being made.

In Figure 21.5, the LOGIC DESIGN card shows key-controlled locking that Proves that unauthorised copies fail equivalence checks, yet Cannot prove the key path is itself clean — the control and its own attack surface arrive together. PHYSICAL LAYOUT filling buys density and engineering-change records while saying nothing about cells that were already in the design. TEST SUPPORT monitors surface out-of-envelope telemetry but not a payload dormant inside the bounds they watch. FIELD OPERATION monitoring buys fleet comparison and containment, and still cannot establish absence before the trigger fires. Reading the pairs together, rather than the mechanism names alone, is exactly what stops an assurance record from presenting four controls as four guarantees.

The trigger-payload model does not say where the change entered or where it can still be found. Trace Figure 21.6 from design inputs to deployment to assign assurance and detection evidence to each owner.

Read Figure 21.6 from IP and CAD sources through design, manufacture, test, and deployment. Compromised design inputs or tools can introduce a logical change before fabrication, while an untrusted manufacturing step can alter the physical implementation. Receiving and acceptance testing are later opportunities for logic or side-channel comparison against a trusted baseline, and runtime monitoring can reveal out-of-envelope timing, power, or functional behavior after deployment. The sequence shows why provenance is continuous evidence, not a supplier name recorded at purchase.

No single control covers every stage or rare activation condition. Use Figure 21.7 to compare prevention-oriented design assurance, pre-deployment detection, and monitoring after release without claiming that one family proves absence.

In Figure 21.7, start with detection: destructive reverse-engineering can inspect sampled physical structure, while non-destructive logic and side-channel tests compare behavior without consuming every unit. Move next to design-for-security controls that constrain trusted sources, unused logic, and opportunities for insertion. Runtime monitoring then watches deployed devices for functional, timing, or power deviations that earlier assurance missed. Together the families form layered evidence across the lifecycle, scaled to device value and consequence rather than presented as a guarantee that no Trojan exists.