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.
After studying this chapter
Learning objectives
You will be able to:
- Explain: IoT devices often live in places where a person can hold, open, probe, swap, or simply steal them: a sensor on a pole, a gateway in a shared cabinet, a consumer gadget on a shelf.
- 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: 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.
Major section
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.
- That turns "hardware security" from a vague property into a set of claims another reviewer can retest.
Major section
Overview: When the Attacker Can Touch the Device
Most software security quietly assumes the attacker is on the other side of a network.
- Hardware security removes that assumption.
- Once physical access is on the table, a different set of weaknesses opens up that network controls cannot close.
- We are not looking for ways to break a device.
Major section
Overview: When the Attacker Can Touch the Device (continued)
IoT devices often live in places where a person can hold, open, probe, swap, or simply steal them: a sensor on a pole, a gateway in a shared cabinet, a consumer gadget on a shelf.
- We are looking for the evidence that says it resists being broken.
- That evidence should be tied to the deployment setting.
- One sits in a locked safe; the other is left open on a cafe table.
Major section
Overview: When the Attacker Can Touch the Device (continued)
A lab prototype, a home device, a field gateway, and a safety-critical controller can expose the same board features but require different production controls, acceptance tests, and retest triggers.
- Hardware vulnerability review is the discipline of asking how much "cafe table" exposure a device has, and how much it was hardened for that reality.
- The chapter can now use Overview: When the Attacker Can Touch the Device as an engineering criterion.
- Debug and programming headers (JTAG, SWD, UART) and the boot path decide what code runs and what memory is reachable.
Major section
Overview: When the Attacker Can Touch the Device (continued)
External flash and key storage decide whether firmware and credentials can be read or altered off the main processor.
- Side-channel leakage, fault injection, tamper paths, hardware Trojan risk, and component provenance decide whether physics or sourcing can bypass a control.
- That order prevents a control name from being treated as proof and connects the visual to the chapter's evidence-led review sequence.
- If you can name the physical access assumption and the main surfaces, you have the core idea.
- The file is identical, but the risk is not, because the second machine can be touched.
Major section
Practitioner: A Defensive Hardware Review Workflow
A hardware review is an evidence exercise, not an exploitation exercise.
- The aim is to identify exposure and confirm that production controls are actually applied, recorded, and tested.
- That support is what the The Review Sequence narrative needs before proceeding.
- Provisioning record showing the lock or fuse was applied.
- Untrusted or downgraded firmware can execute.
Major section
Practitioner: A Defensive Hardware Review Workflow (continued)
Contents can be read or altered off the board.
- A firmware compromise can exfiltrate the keys.
- Provenance, hashes, and receiving acceptance tests.
- Trusted IP/CAD source records, sample tests, side-channel review, and runtime monitors for high-risk parts.
- A hardware Trojan can leak, deny service, or alter outputs below the software layer.
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.
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)
A wrong hypothesis mixes the physical states and tends to cancel.
- The evidence is a provisioning record proving the lock was applied to shipped units, not just available in the part.
- 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.
- Programmable non-volatile memory needs the same evidence discipline.
Major section
Under the Hood: Why Each Surface Leaks, and What Resists It (continued)
A side channel is the observation that those physical signals can correlate with a secret.
- 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.
- The defensive question is whether one observation reveals operation order, secret-dependent branches, or exceptional cases.
- Written out as prose, that pipeline is a list of verbs.
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.
- 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.
- More traces reduce random uncertainty; they do not “average away” leakage that is correlated with the partition.
Major section
Under the Hood: Why Each Surface Leaks, and What Resists It (continued)
SPA and DPA answer different questions from different amounts of data, and that difference is far easier to see than to describe.
- 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.
- Those two small plots are the entire reason a defender cannot treat trace count as a safety margin.
Major section
Under the Hood: Why Each Surface Leaks, and What Resists It (continued)
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.
- 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 visual's specific claim is that this exposed secure-element die shows the physical target behind the threat model.
Major section
Under the Hood: Why Each Surface Leaks, and What Resists It (continued)
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.
- 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.
Major section
Under the Hood: Why Each Surface Leaks, and What Resists It (continued)
The magnified structures make the attack surface physical: isolation raises extraction cost, but it does not erase probing or package-opening risk.
- That observation connects Physical Extraction and Tamper to the required board-level controls and residual-risk record.
- 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.
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.
- IoT devices often live in places where a person can hold, open, probe, swap, or simply steal them: a sensor on a pole, a gateway in a shared cabinet, a consumer gadget on a shelf.
- A lab prototype, a home device, a field gateway, and a safety-critical controller can expose the same board features but require different production controls, acceptance tests, and retest triggers.
- A hardware review is an evidence exercise, not an exploitation exercise.
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?
Show answer
Answer: A 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?
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.
- A · 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.