19 Hardware Vulnerabilities
IoT hardware vulnerabilities, debug interface exposure, secure boot, external flash, side-channel leakage, hardware Trojan, side-channel analysis, tamper detection, supply chain assurance
19.1 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. It is a defensive inventory: which physical features could reveal secrets or change code if they were left enabled in the shipped build?
Start simple. Pick one deployed device, name the places a person can touch, then record the control and evidence for each one: debug locked or disabled, boot path verified, external memory protected, tamper assumptions stated, side-channel risk bounded, and supply-chain provenance checked. That turns “hardware security” from a vague property into a set of claims another reviewer can retest.
19.2 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. 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. Once physical access is on the table, a different set of weaknesses opens up that network controls cannot close.
The guiding question for this whole chapter is defensive and simple: what could a person with physical access learn or change, and does the device have controls that limit it? We are not looking for ways to break a device. We are looking for the evidence that says it resists being broken.
That evidence should be tied to the deployment setting. 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.
If you only need the intuition, this layer is enough: a hardware review starts with the physical access assumption, then checks whether debug ports, the boot path, stored secrets, and the supply chain are controlled for the place the device will actually live.
Think of two laptops holding the same secret file. One sits in a locked safe; the other is left open on a cafe table. The file is identical, but the risk is not, because the second machine can be touched. 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.
19.2.1 The Main Surfaces, in One Minute
Interfaces and boot
Debug and programming headers (JTAG, SWD, UART) and the boot path decide what code runs and what memory is reachable.
Storage and secrets
External flash and key storage decide whether firmware and credentials can be read or altered off the main processor.
Physics and supply chain
Side-channel leakage, fault injection, tamper paths, hardware Trojan risk, and component provenance decide whether physics or sourcing can bypass a control.
19.2.2 Beginner Examples
- A development debug header left active on a shipped board is a hardware exposure even if the firewall is perfect, because the threat is local, not remote.
- A device that stores its private key in ordinary readable flash can lose that key to anyone who can read the chip.
- “It has a strong enclosure” slows casual access but is not, by itself, the security model. The board inside still needs review.
19.2.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.
19.3 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. The workflow below stays defensive: it asks what to verify, never how to misuse a device.
19.3.1 The Review Sequence
- Define the physical access assumption. Who can reach the device, for how long, and with what tools, in its real deployment?
- Inventory the surface. List ports, test points, removable storage, radios, sensors, and any security components such as a secure element.
- Check production configuration evidence. Confirm debug lock, boot verification, storage protection, and key provisioning were applied at manufacture, not just supported in theory.
- Compare against approved releases. Match firmware and configuration to the signed, approved record using hashes or signatures.
- Review protected operations. Decide whether sensitive cryptography needs side-channel resistance and whether security checks need fault resilience.
- Inspect supply-chain evidence. Look for component authenticity checks, bill-of-material control, trusted design inputs, manufacturing acceptance tests, and hardware Trojan review evidence.
- Record residual risk. State what is still exposed and which controls are required before deployment.
19.3.2 Surface, Defensive Question, and Evidence
19.3.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.
19.3.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.
19.4 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.
19.4.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.
19.4.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.
Power analysis names three useful review categories. Simple Power Analysis (SPA) asks whether a single trace visibly reveals operations such as encryption rounds. Differential Power Analysis (DPA) compares many traces to look for statistically meaningful differences. Correlation Power Analysis (CPA) compares measured traces with a leakage model to test key hypotheses. In a course review, the point is not to reproduce an attack. The point is to decide whether the device handles cryptographic work in a part and implementation that were designed for side-channel resistance, and whether the evidence includes physical, algorithmic, and protocol-level countermeasures rather than a single “encrypted” label.
19.4.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.
19.4.4 Physical Extraction and Tamper
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.
19.4.5 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. 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. A payload might change logic, alter memory content, leak information, degrade performance, or deny service.
For an IoT reviewer, hardware Trojan risk is a supply-chain and assurance question. The evidence should show which IP blocks, CAD tools, foundry or assembly steps, and receiving tests are trusted for the device class. Detection approaches can be destructive, such as reverse-engineering a sample, or non-destructive, such as logic testing and side-channel comparison. Design-for-security approaches try to prevent insertion or make detection easier, for example by controlling design sources, reducing unused layout space, adding monitors, and preserving a trusted baseline. Runtime monitoring then checks whether deployed devices behave outside the expected power, timing, or functional envelope. High-volume commodity sensors may need only supplier and acceptance evidence; a safety-critical or payment device may need much stronger IC-level assurance.
19.4.6 Supply-Chain Assurance
The trust chain begins before the device powers on. 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.
19.4.7 Common Pitfalls
- Treating the enclosure as the boundary. A case slows casual access but does not verify boot, storage, or tamper response.
- Leaving development access in production. Manufacturing and service interfaces need a recorded production policy.
- Storing secrets where ordinary firmware can read them. A single firmware compromise then exposes long-lived keys.
- Accepting supply-chain trust without evidence. Reputation is not provenance, hashes, or acceptance tests.
- Assuming software controls cover physics. Side-channel and fault risk are addressed in implementation and hardware, not by a firewall.
- Treating hardware Trojan risk as a slogan. The review needs a named trigger/payload concern, trusted design-source evidence, and a detection or monitoring plan scaled to the device.
19.4.8 Under-the-Hood Knowledge Check
At this depth, hardware security is about defending decisions and secrets against an attacker who can touch the device: control the interfaces, anchor the boot, protect the keys, harden the physics, and verify the supply chain, then record the residual risk that remains for the real deployment.
19.5 Summary
- Hardware vulnerability review begins with the physical access assumption, because physical access opens weaknesses that network controls cannot close.
- The main surfaces are debug and programming interfaces, boot trust, external storage, key storage, side-channel leakage, fault injection, tamper paths, and the supply chain.
- The work is defensive and evidence-led: confirm that production controls were applied, recorded, and tested, not merely supported.
- Mechanisms have matching controls: lock or authenticate debug, anchor and verify boot, protect keys in a secure element, harden sensitive operations, and verify component provenance.
- Hardware Trojan review separates trigger, payload, insertion path, detection evidence, design-for-security controls, and runtime monitoring.
- Critical security decisions should be redundant and fail-closed so a single fault cannot flip them.
- Hardware claims must be specific and backed by records, never assumed from brand, price, or enclosure appearance.
Hardware vulnerability review must cover debug ports, the boot chain, secure storage, side channels, fault resilience, tamper exposure, hardware Trojan assurance, and supply-chain provenance, each tied to recorded production evidence and a stated residual risk.
19.6 See Also
Follow the hardware root of trust into a staged, verified boot chain.
See how update paths deliver the firmware that boot trust later verifies, and how they can weaken it.
Place hardware exposure inside the wider asset, boundary, and evidence model.