20 Hardware Security: Surfaces and Side Channels

20.3.1 The Main Surfaces, in One Minute

20.3.2 Beginner Examples

20.3.3 Overview Knowledge Check

If you can name the physical access assumption and the main surfaces, you have the core idea. Continue to Practitioner to run a structured, evidence-led review.

20.4.1 The Review Sequence

The design consequence of The Review Sequence depends on the path, not just the endpoint. Figure 20.2 makes that path explicit as “The review flow: physical access assumption first, then inventory, production evidence, protected operations, supply chain, and a residual-risk decision” is explicit in the diagram.

The labels Inventory, sensitive ops, and accept or fix divide Figure 20.2 into responsibility, decision, and consequence. Their exact meanings support the claim that “The review flow: physical access assumption first, then inventory, production evidence, protected operations, supply chain, and a residual-risk decision” is explicit in the diagram. That support is what the The Review Sequence narrative needs before proceeding.

20.4.2 Surface, Defensive Question, and Evidence

20.4.3 Review Claims as Testable Statements

Hardware claims are easy to overstate, so phrase each as a specific statement with named evidence. “Debug is disabled in production” should point to a provisioning record and an acceptance test. “Keys are protected” should name where keys live and who can read them. If the evidence is missing, record the claim as unverified rather than assuming it from brand, price, or enclosure appearance.

20.4.4 Practitioner Knowledge Check

If you can run the workflow and demand evidence per claim, you can review a board responsibly. Continue to Under the Hood for why these surfaces leak and how the controls actually work.

20.5.1 Debug and Programming Interfaces

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. The defensive answer is to close or gate the door: permanently disable the interface, blow a one-time-programmable fuse, or require authenticated debug so that only an authorized party with a key can re-enable it. The evidence is a provisioning record proving the lock was applied to shipped units, not just available in the part.

A reliable account of Debug and Programming Interfaces must show both responsibility and outcome. Figure 20.3 links those ideas through the claim that 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.

In Figure 20.3, the black AVR programmer is connected by a grey ribbon cable to the board debug header. That physical chain is the point: a tool intended for legitimate programming reaches the target below the network stack. 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.

20.5.2 Side-Channel Leakage

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. A side channel is the observation that those physical signals can correlate with a secret. The defensive focus is never how to measure them; it is whether sensitive operations use implementations designed to leak less, such as constant-time code that avoids data-dependent branches and timing, masking that randomizes intermediate values, or a secure element built to resist physical observation. Whether this risk is realistic depends on the device’s value and exposure.

20.5.2.2 DPA: make a small dependency survive averaging

Differential Power Analysis uses many traces $P_i(t)$ collected while known or chosen inputs vary. For a candidate hypothesis $g$, compute a predicted one-bit property $d_i(g)$ of an internal intermediate, split the traces by that prediction, and subtract the group means:

$$\Delta_g(t)= \frac{1}{n_1}\sum_{i:d_i(g)=1}P_i(t) - \frac{1}{n_0}\sum_{i:d_i(g)=0}P_i(t).$$

Walk the logic rather than memorising the formula. First, time-align the same operation across traces. Second, use the hypothesis to place each trace in group 0 or group 1. Third, average within each group: unrelated noise tends toward the same mean in both groups. Fourth, subtract. If the hypothesis predicts a real data-dependent transition, a peak remains near the instant that intermediate is processed. A wrong hypothesis mixes the physical states and tends to cancel. 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. Before adding a continuous statistic, read the two paired panels of Figure 20.4 side by side.

The upper card of Figure 20.4 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. Under the correct hypothesis g a time-localised peak survives the averaging; under the wrong hypothesis g the two groups cancel into the same flat noise. Those two small plots are the entire reason a defender cannot treat trace count as a safety margin.

20.5.2.3 CPA: rank a leakage model continuously

Correlation Power Analysis replaces the binary partition with a numeric leakage prediction. For each test vector $x_i$ and candidate subkey $g$, a lab evaluator computes an expected intermediate $z_i(g)$ and a simple leakage model such as Hamming weight $L_i(g)=\operatorname{HW}(z_i(g))$. At each time sample $t$, compare the prediction vector with the measured power vector using Pearson correlation:

$$\rho_g(t)= \frac{\operatorname{cov}(L(g),P(t))} {\sigma_{L(g)}\sigma_{P(t)}}.$$

The defensive evaluation pipeline is: capture traces under authorized test vectors; preprocess and align them; generate a predicted leakage vector for every candidate; compute $\rho_g(t)$ across the trace; rank candidates by a preregistered statistic such as $\max_t|\rho_g(t)|$; repeat on fresh traces; and treat a stable, time-localized separation as evidence of leakage. 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.

Written out as prose, that pipeline is a list of verbs. What a reviewer actually receives is a ranking, so it helps to see the shape of a positive result before judging one. Figure 20.5 draws the six steps, the ranking they produce, and the countermeasures the next section unpacks.

In Figure 20.5 the numbered steps run from Capture traces under authorised test vectors to Repeat on fresh traces; require a stable peak, and the bar chart under them shows what a positive result looks like: one candidate standing clearly above the noise band while every other candidate stays inside it. The single tall bar is not the finding. The finding is that the same bar is still tall on a fresh capture, which is why the repetition step is not optional politeness. The lower card then puts the answer where it belongs, from 1 · PHYSICAL decoupling and shielding through to 4 · PROTOCOL AND SYSTEM query limits and key rotation, with each layer naming the evidence it owes rather than the label it carries.

20.5.3 Fault Injection

Many security decisions reduce to a single check, for example “is this signature valid, yes or no.” Fault injection is the family of techniques that push hardware outside its safe envelope, with abnormal voltage, clock, or temperature, to make a check misbehave, such as skipping the branch that would have rejected an image. The defensive design response is to make a single glitch insufficient: verify critical decisions more than once, use robust state machines, default to fail-closed so an unexpected state denies rather than allows, and add environmental sensors where the threat model justifies it.

20.5.4 Physical Extraction and Tamper

The chapter pauses for Figure 20.6 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. 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.

Read the photograph in Figure 20.6 by locating the silicon die, the bond-pad perimeter, and the dense internal interconnect that package plastic normally hides. 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 layered defense is to keep high-value secrets in a secure element or one-time-programmable storage rather than general flash, to encrypt and integrity-check anything stored externally, and to add tamper evidence or tamper response, such as seals, enclosure design, or automatic key erasure, when opening the device should change the trust boundary.

Programmable non-volatile memory needs the same evidence discipline. One-time-programmable cells, lock fuses, and secure key slots are useful only when the provisioning record proves which secrets or boot decisions were written, who could write them, and whether application firmware can ever rewrite them. EEPROM-style key or bootloader storage is more flexible, but that flexibility is a risk: the review should show that manufacturing key injection is authenticated, that application code cannot overwrite protected areas, and that any configuration fuse or write-protect state survives firmware updates and repair workflows.

The bus that carries this traffic is itself part of the surface. Many designs move keys, configuration, or firmware between the main processor and external memory or a secure element over a simple board-level bus such as I2C or SPI. 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 review question is not only whether the memory is protected, but whether the link to that memory is protected: evidence should show bus-level encryption or an authenticated transaction scheme, or a physical control such as shielding, potting, or trace routing that raises the cost of probing the link.