Security: Threats & Defense · Study deck

Hardware Security: Surfaces and Side Channels

This first route builds a defensive hardware review and follows leakage, fault, and extraction evidence.

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: Ten similar bursts in a trace can be consistent with the ten rounds of AES-128, for example, but a trace shape alone does not prove which algorithm or key was used.
Explain: A processor doing secret-dependent work also does secret-dependent physics: it draws slightly different power, emits different electromagnetic patterns, or takes different amounts of time depending on the data.
Explain: That repetition is consistent with ten cipher rounds, and the card's own caution is the part a reviewer must keep: shape does not identify the algorithm or the key.

Major section

Overview · Start With the Board in Someone's Hands

A field gateway is taken down for service and placed on a workbench.

The enclosure is open, the board is visible, and a technician can see pads, headers, flash memory, reset pins, and labels.
The first review question is not an exploit recipe.

Major section

Overview: When the Attacker Can Touch the Device · Practitioner: A Defensive Hardware Review Workflow

Most software security quietly assumes the attacker is on the other side of a network.

Hardware security removes that assumption.
That evidence should be tied to the deployment setting.

Physical access exposes interfaces, boot trust, storage, keys, side channels, tamper paths, and component provenance.

Major section

Under the Hood: Why Each Surface Leaks, and What Resists It

The deeper layer explains the mechanism behind each surface, defensively.

Knowing why a control exists tells you what evidence proves it is present and what residual risk remains.
None of this is a recipe; it is the reasoning a reviewer needs.
The single tall bar is not the finding.

This connected JTAG programmer makes the trust boundary tangible: the ribbon cable terminates at a physical board header whose production lock state must be proven, not assumed from the absence of a network service. Photo: Martin Guy, CC BY-SA 3.0

Major section

Under the Hood: Why Each Surface Leaks, and What Resists It (continued)

That physical chain is the point: a tool intended for legitimate programming reaches the target below the network stack.

Interfaces such as JTAG, SWD, and a serial console exist so engineers can program, halt, single-step, and read memory during development.
Those same powers, left enabled in the field, can let someone read firmware and secrets out of the chip or pause a security check.
No single row is sufficient.

Major section

Under the Hood: Why Each Surface Leaks, and What Resists It (continued)

The evidence is a provisioning record proving the lock was applied to shipped units, not just available in the part.

In Figure: This connected JTAG programmer makes the trust boundary, the black AVR programmer is connected by a grey ribbon cable to the board debug header.
A side channel is the observation that those physical signals can correlate with a secret.
Programmable non-volatile memory needs the same evidence discipline.

Major section

Under the Hood: Why Each Surface Leaks, and What Resists It (continued)

A processor doing secret-dependent work also does secret-dependent physics: it draws slightly different power, emits different electromagnetic patterns, or takes different amounts of time depending on the data.

Whether this risk is realistic depends on the device's value and exposure.
Repeated round boundaries, multiplication patterns, conditional branches, or memory transfers may create visibly different regions.
A wrong hypothesis mixes the physical states and tends to cancel.

Major section

Under the Hood: Why Each Surface Leaks, and What Resists It (continued)

Ten similar bursts in a trace can be consistent with the ten rounds of AES-128, for example, but a trace shape alone does not prove which algorithm or key was used.

The defensive question is whether one observation reveals operation order, secret-dependent branches, or exceptional cases.
Differential Power Analysis uses many traces $P_i(t)$ collected while known or chosen inputs vary.
Second, use the hypothesis to place each trace in group 0 or group 1.
If the hypothesis predicts a real data-dependent transition, a peak remains near the instant that intermediate is processed.

Major section

Under the Hood: Why Each Surface Leaks, and What Resists It (continued)

Those two small plots are the entire reason a defender cannot treat trace count as a safety margin.

More traces reduce random uncertainty; they do not “average away” leakage that is correlated with the partition.
SPA and DPA answer different questions from different amounts of data, and that difference is far easier to see than to describe.
Written out as prose, that pipeline is a list of verbs.

What an authorised evaluation produces is a ranking that survives fresh traces, not a key.

Major section

Under the Hood: Why Each Surface Leaks, and What Resists It (continued)

The upper card of Figure: One trace carries structure holds one measurement, P(t), in which ten similar bursts sit between visible boundaries.

That repetition is consistent with ten cipher rounds, and the card's own caution is the part a reviewer must keep: shape does not identify the algorithm or the key.
The lower card trades that single observation for four steps —: Collect n traces: Predict one bit: Average each group: Subtract the means — and then shows the result twice.
That observation connects Physical Extraction and Tamper to the required board-level controls and residual-risk record.

One trace carries structure; many traces carry a single predicted bit.

Major section

Under the Hood: Why Each Surface Leaks, and What Resists It (continued)

Subkey results can combine into a wider secret, which is why a review cannot dismiss a small per-operation leak as harmless.

A sound lab report also tests negative controls, multiple devices, trace-count sensitivity, and confidence margins so noise or alignment artifacts are not mistaken for recovery.
The finding is that the same bar is still tall on a fresh capture, which is why the repetition step is not optional politeness.
Masking can fail if randomness is weak, filtering can leave correlated residue, and rate limits do not protect a device an attacker owns physically.

Major section

Under the Hood: Why Each Surface Leaks, and What Resists It (continued)

The review should combine layers according to value and exposure and retain the measured residual rather than claim that “encryption” itself prevents physical leakage.

The chapter pauses for Figure: This exposed secure-element die shows the physical target so that Physical Extraction and Tamper has inspectable evidence.
The visual's specific claim is that this exposed secure-element die shows the physical target behind the threat model.
The magnified structures make the attack surface physical: isolation raises extraction cost, but it does not erase probing or package-opening risk.

The review flow: physical access assumption first, then inventory, production evidence, protected operations, supply chain, and a residual-risk decision.

Major section

Under the Hood: Why Each Surface Leaks, and What Resists It (continued)

If secrets or firmware sit in external memory, they can be read off-board; more invasive physical attacks target the chip itself.

The bus that carries this traffic is itself part of the surface.
Because these buses are typically unauthenticated and unencrypted by default, physical access to test points or exposed pads can let someone observe or inject on that link even when the memory chip itself is well chosen.
The image therefore returns Debug and Programming Interfaces to its production question—whether that same header is disabled, authenticated, or otherwise proven inaccessible on shipped hardware.

This exposed secure-element die shows the physical target behind the threat model. Hardware isolation raises the cost of extracting keys, but package opening, probing, and the board-level link to the host still belong in the review. Photo: Kawe Mazidjatari, CC BY-SA 4.0

Deck summary

Key takeaways

A field gateway is taken down for service and placed on a workbench.

Most software security quietly assumes the attacker is on the other side of a network.
The deeper layer explains the mechanism behind each surface, defensively.
That physical chain is the point: a tool intended for legitimate programming reaches the target below the network stack.
The evidence is a provisioning record proving the lock was applied to shipped units, not just available in the part.

Retrieval practice

Recall check 1 of 2

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

Q1Why is a hardware vulnerability review different from a typical network security review?

AIt examines enclosure appearance rather than security properties.

BIt assumes memory-safe firmware makes physical components secure.

CIt replaces software review once a physical enclosure is selected.

DIt covers attacks where someone can physically handle the device.

Show answer

Answer: D Physical access changes the threat model.

Retrieval practice

Recall check 2 of 2

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

Q2A production gateway still has a reachable development debug header. What is the most appropriate defensive finding?

AIt is acceptable because the network firewall is configured correctly

BIt is a production exposure until disablement is evidenced.

CIt only matters if a remote attacker can reach the header over the internet

DIt can be ignored because the firmware uses a memory-safe language

Show answer

Answer: B Debug access is fine in development, but a production device needs recorded evidence that the interface is disabled, authenticated, removed, or otherwise controlled before shipment.

Print reference

Answers

Answer key.

D · Physical access changes the threat model.
B · Debug access is fine in development, but a production device needs recorded evidence that the interface is disabled, authenticated, removed, or otherwise controlled before shipment.