Security: Threats & Defense · Study deck

Hardware Security: Trojans and Assurance

The device resists common physical probes, tests that try to learn from or alter its hardware.

Shield Shelly is your guide for this deck.

hardware-securityiot-securitydebug-interfaces

Shield Shelly, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

Explain: 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.
Explain: 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.
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.
Explain: A test is incomplete if it satisfies only one side.

The counter reaches terminal count once, and the protected signal inverts for exactly one cycle.

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.

The review model that matters is not the exploit -- it is naming what activates the Trojan and what its payload does.

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.

Hardware-Trojan assurance combines detection tests, secure design choices and runtime monitoring. A worked supply-current comparison illustrates why an anomaly needs a matched golden reference before it can support a claim.

Major section

Hardware Trojans and IC Provenance (continued)

A functional test that tries 01, 10, and the expected asserted case 11 reports success while missing the only changed row.

A payload might change logic, alter memory content, leak information, degrade performance, or deny service. Figure: The review model that matters is not the makes that separation visible before the assurance controls are compared.
The four-row table therefore contains one disagreement out of four.
A test is incomplete if it satisfies only one side.

Two added gates change only the untested 00 row, allowing ordinary vectors to miss the Trojan.

Major section

Hardware Trojans and IC Provenance (continued)

The assurance record should name which insertion point and observation gap each mechanism covers rather than counting four controls as four independent guarantees.

A suite covering 01, 10, and 11 reports three matches while missing 00.
Rare-node analysis and mutation-sensitive vectors must force that quiet state.
Layout filling reduces insertion opportunity during physical design.

Four methods, five shared criteria, and four different things that stay unproven.

Major section

Hardware Trojans and IC Provenance (continued)

For an IoT reviewer, hardware Trojan risk is a supply-chain and assurance question.

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.
That distinction must appear in the hardware review because it changes both consequence and test duration.
The evidence can be physically detailed, but the inspected sample is consumed.

Supply-chain assurance has to cover every stage, not just the one you can see.

Major section

Hardware Trojans and IC Provenance (continued)

The added NOR asserts only when $A=0$ and $B=0$ , and its output enters the added XOR; for the other three input pairs the trigger stays low and the protected value passes unchanged.

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.
Starting from zero and comparing the current count before increment, the first terminal state arrives after $2^k-1$ clock edges.
For $k=32$ at $100\ \mathrm{MHz}$ , the delay is about $42.95\ \mathrm{s}$ of uninterrupted enabled clocks.

Major section

Hardware Trojans and IC Provenance (continued)

Naming four mechanisms is not the same as knowing which window each one closes.

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 trigger-payload model does not say where the change entered or where it can still be found.

Each control proves something specific and leaves something specific unproven.

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.
High-volume commodity sensors may need only supplier and acceptance evidence; a safety-critical or payment device may need much stronger IC-level assurance.
Reading the pairs together, rather than the mechanism names alone, is exactly what stops an assurance record from presenting four controls as four guarantees.

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 functional test that tries 01, 10, and the expected asserted case 11 reports success while missing the only changed row.
The assurance record should name which insertion point and observation gap each mechanism covers rather than counting four controls as four independent guarantees.
For an IoT reviewer, hardware Trojan risk is a supply-chain and assurance question.

Retrieval practice

Recall check 1 of 2

Shield Shelly says: answer from memory, then check your reasoning.

Q1A chip behaves normally until a rare input pattern makes it leak data. Which part is the trigger and which is the payload?

AThe chip label triggers the behavior; its serial number is the leak.

BThe data leak triggers the chip; the rare pattern is the payload.

CThe rare input pattern triggers leakage; leaked data is the payload.

DThe input pattern and leak are unrelated network error reports.

Show answer

Answer: C The trigger activates hidden behavior, while the payload causes harm.

Retrieval practice

Recall check 2 of 2

Shield Shelly says: answer from memory, then check your reasoning.

Q2A 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?

AMake the comparison faster because shorter test cycles establish the same fault response evidence.

BRepeat verification and fail closed on disagreement.

CLog the result after boot without rechecking the decision.

DMove the verification key to writable flash for easier updates.

Show answer

Answer: B Redundant checks and fail-closed behavior mean a single glitch is not enough to flip the decision to accept.

Print reference

Answers

Answer key.

C · The trigger activates hidden behavior, while the payload causes harm.
B · Redundant checks and fail-closed behavior mean a single glitch is not enough to flip the decision to accept.