Building an Attack Tree for Embedded Hardware
An attack tree is a simple, powerful way to reason about how an attacker reaches a goal. Put the goal at the root, break it into the alternative ways to achieve it, then break those down until you reach concrete steps. For embedded hardware it turns a vague worry into a map you can prioritize and defend.
Why It Beats a Flat Worry List
Security discussions drift without structure, jumping between a clever attack someone read about and a worry someone has, with no way to tell which matters. An attack tree imposes order: it starts from what the attacker wants and works backward through how they could get it. Hardware offers many paths at once, the debug port, the firmware, the buses, the radios, the cloud link, and a tree lays them side by side so you compare them honestly. It is the difference between defending against the last attack you heard about and defending against the cheapest path into your actual device.
Goal, Paths, Steps
A tree has one goal at its root, say extract the firmware encryption key. Below it sit the high-level approaches, and below those the concrete steps each requires. Children combine in one of two ways: an OR node, where any child achieves the parent, and an AND node, where all children are required together.
Read top to bottom, every distinct route to the goal is visible at a glance, which is exactly what later lets you find the cheapest complete path and the single defenses that cut off the most branches.
Build It from the Goal Down
Build the tree in three passes, working downward:
- Name the goal the attacker actually wants, not a technique. Run unsigned firmware and extract the signing key are different goals with different trees.
- Decompose into paths as OR branches, the genuinely different routes, including the unglamorous ones like a key leaked in a public repo or harvested at the factory.
- Break paths into concrete steps until each leaf is specific enough to estimate and to map to a defense: clip onto the SPI flash and dump it, glitch the readout-protection check, sniff the I2C line to the secure element.
Attackers take the easiest path, and the easiest path is frequently not the technically impressive one, so a tree that omits the boring routes will mislead your priorities. The discipline at every level is completeness without overlap.
Annotate the Leaves, Then Read the Cheapest Path
A tree becomes a prioritization tool once you annotate each leaf with cost or skill, the gear required, and whether it is even feasible given the design. Those annotations propagate up: an OR branch needs only its cheapest child, an AND branch costs the sum of its children.
| Path to run unsigned firmware | Cost | Gear | Feasible here? |
|---|---|---|---|
| Skip secure boot via glitch | Medium | Glitch rig | Yes |
| Find a signing key in flash | Low | Clip and programmer | No, key in secure element |
| Exploit an update-path bug | Medium | None | Unknown |
| Replace flash with own image | Low | Programmer | Yes, nothing verifies it |
The answer jumps out. Replacing the flash with your own image is low cost, common gear, and feasible because nothing verifies it, so that is the path an attacker takes, not the glitch attack that gets all the attention. The tree just told you where to spend.
Defenses with Leverage
With the cheap paths identified, look for defenses that cut off the most branches at once. Moving the key into a secure element prunes every read-it-from-storage and read-it-from-RAM branch; enabling verified boot prunes the entire replace-the-flash subtree. This is where trees beat a flat list of findings, because they show which fixes have leverage. A control that prunes a whole subtree outranks one that closes a single obscure leaf, even though both address one finding on paper, and the tree makes that leverage visible.
Keep It Honest, Keep It Living
A leaf marked not feasible because of a design choice is a defense you can point to, but only if it is true. Marking dump flash and find the key infeasible is valid only if the key never touches flash or RAM in the clear, which makes building the tree pair naturally with testing: each assumption becomes a hypothesis to verify on real hardware, and where testing contradicts the tree, a path you thought was closed is open.
It is also never a one-time artifact. As the design changes, a new interface, a moved key, an added radio, the tree changes with it and catches paths a change quietly opened. Kept current, it becomes a shared reference: engineers see how their component fits the attacker’s paths, and leadership sees where the real risk concentrates.
From Tree to Test Plan
The output is a prioritized list of defenses tied to the paths they close, feeding straight into the security requirements and the test plan. Each cheap path becomes a must-fix requirement; each closed path becomes a test to confirm it stays closed on real hardware. That hand-off is what keeps an attack tree from being a whiteboard exercise that fades.
Where This Fits
Building attack trees and using them to prioritize defenses is core threat-modeling work, and it is most valuable early, before the design is locked. If you want help mapping how your product could be attacked and where to spend your defensive effort, that is the kind of work we do at Berkner Tech.
