Security: Threats & Defense · Study deck
Hardware Security: Trojans and Assurance
The device resists common physical probes, but trust also depends on what entered the design before assembly.
Shield Shelly is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: 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.
- Explain: 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.
- Explain: High-volume commodity sensors may need only supplier and acceptance evidence; a safety-critical or payment device may need much stronger IC-level assurance.
Major section
Hardware Trojans and IC Provenance
A hardware Trojan is a malicious change to an integrated circuit or its design flow.
- It may be inserted through an untrusted intellectual-property block, a compromised design tool, or a manufacturing step that changes the physical implementation.
- Separating activation from effect matters because tests that cover ordinary functions may observe neither.
- The decision is consequence-driven.
Major section
Hardware Trojans and IC Provenance (continued)
Trigger coverage asks whether the hidden condition was reached.
- The useful review model separates two parts: the trigger that activates the behavior and the payload that causes the harm.
- A trigger might be a rare digital state, a long sequence, an on-chip sensor condition, or another activation pattern.
- Runtime monitoring carries selected evidence into deployment.
Major section
Hardware Trojans and IC Provenance (continued)
A test is incomplete if it satisfies only one side.
- 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.
- Layout filling reduces insertion opportunity during physical design.
Major section
Hardware Trojans and IC Provenance (continued)
High-volume commodity sensors may need only supplier and acceptance evidence; a safety-critical or payment device may need much stronger IC-level assurance.
- AND · protected is the entire intended function: two inputs, one output, three of four rows sitting at zero.
- The insertion is not hidden by cleverness; it is hidden by test coverage that never visits the rare state.
- For an IoT reviewer, hardware Trojan risk is a supply-chain and assurance question.
Major section
Hardware Trojans and IC Provenance (continued)
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.
- 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.
Major section
Hardware Trojans and IC Provenance (continued)
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.
- A counter trigger resists reasoning from gate names, because its cost is counted in clock edges rather than input values.
- The evidence can be physically detailed, but the inspected sample is consumed.
Major section
Hardware Trojans and IC Provenance (continued)
In Figure: The counter reaches terminal count once, follow the k-bit counter into the terminal count detector and on into the: XOR payload that already carries the protected signal.
- The evidence should show which IP blocks, CAD tools, foundry or assembly steps, and receiving tests are trusted for the device class.
- 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.
- Naming four mechanisms is not the same as knowing which window each one closes.
Major section
Hardware Trojans and IC Provenance (continued)
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.
- 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.
Major section
Hardware Trojans and IC Provenance (continued)
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.
- In Figure: Three countermeasure families, 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.
Major section
Supply-Chain Assurance
Counterfeit parts, substituted components, or firmware that differs from the approved image all defeat downstream controls silently.
- Assurance is documentary: component provenance, a controlled bill of materials, firmware hashes compared to the signed release, and receiving acceptance tests.
- Supplier reputation is context, not evidence.
- Service exceptions must be governed and logged.
- High-value targets may still warrant deeper review.
Deck summary
Key takeaways
A hardware Trojan is a malicious change to an integrated circuit or its design flow.
- Trigger coverage asks whether the hidden condition was reached.
- A test is incomplete if it satisfies only one side.
- High-volume commodity sensors may need only supplier and acceptance evidence; a safety-critical or payment device may need much stronger IC-level assurance.
- 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.
Retrieval practice
Recall check
Shield Shelly says: answer from memory, then check your reasoning.
Q1A device's secure boot reduces to a single comparison that accepts or rejects the firmware signature. Which defensive design best reduces fault-injection risk against that check?
Show answer
Answer: A Redundant checks and fail-closed behavior mean a single glitch is not enough to flip the decision to accept.
Print reference
Answers
Answer key.
- A · Redundant checks and fail-closed behavior mean a single glitch is not enough to flip the decision to accept.