Where Device Keys Actually Live Decides Whether They're Secrets at All.

A device's keys are either secrets or they are decoration, and which one they are is decided almost entirely by where they physically live. You can run the strongest cipher, verify every signature, and follow every protocol correctly — and none of it matters if the private key sits somewhere an attacker holding the device can simply read out. Cryptography assumes the key is secret. On an embedded device that assumption is not a given; it is a property of the storage, and it is the property most often overestimated.

The useful way to think about key storage on constrained hardware is as a hierarchy of bad-to-good options, each answering one question a little better than the last. Most designs believe they sit higher on that hierarchy than they actually do, because the storage looks opaque from the firmware's point of view while being wide open to someone holding the board. The work of a key-storage review is to find the real tier, not the assumed one.

The real question: can the key leave?

Strip away the vocabulary — key storage, secure storage, key management — and a single question decides everything: can the private key be extracted from the device by someone who physically has it? Everything else is detail. If the answer is yes, the key is compromised the moment one unit falls into hostile hands; whether that takes a soldering iron, a debug probe, or a well-timed glitch is a question of cost, not of possibility. If the answer is no — if the key can be used but never read — then capturing a device costs the attacker that one device and nothing more.

This reframing matters because it cuts through the marketing around the topic. "Encrypted storage" sounds like an answer, but it only moves the question to where the decryption key lives. The honest technique is to keep asking "and where is that key?" until you reach something that genuinely cannot leave the hardware — or until you run out of turtles and discover the whole stack rests on a value sitting in plain flash.

External flash: a key you can desolder

The cheapest and most common arrangement stores the key in external non-volatile memory — a separate flash chip on the board, beside the main processor. From the firmware's vantage point this feels like storage. Physically it is a labelled part with documented pins and a published datasheet. An attacker desolders it, or clips a reader onto it in place, dumps the contents, and walks away with whatever was inside. A key stored in cleartext in external flash is, as the summary goes, a public key with extra steps. No exotic equipment is required: a hot-air station and a commodity reader.

Desoldering is not even the floor. The bus between the main chip and that external flash is itself probeable, and any secret that crosses it in the clear can be captured with an inexpensive logic analyzer while the device runs normally. External cleartext storage sits at the bottom of the hierarchy, and a surprising number of shipped products live there while believing the enclosure or the obscurity of the layout protects them. Neither does.

On-die storage and the readout problem

A real step up is to store the key inside the main chip — on-die one-time-programmable memory or internal flash — so that there is no external part to desolder and no off-chip bus carrying the secret in the open. This closes the two easiest attacks at once, and for many products it is the right and sufficient tier. But it moves the problem rather than ending it, because now the attacker tries to read the key out through the chip: via the debug port, via a readout or bootloader command that will dump memory, via any path the silicon offers to see its own contents.

This is why on-die storage is only ever as good as the readout protection wrapped around it — debug disabled by a fuse rather than by firmware, flash readout genuinely locked, the bootloader prevented from dumping. On-die storage with the debug port still open is barely better than external. And the on-die memory that ordinary microcontrollers offer is typically still readable by the CPU itself, which means any code-execution bug, or a single glitch past the lock check, can lift the key from inside. Better, clearly — but not solved, and not to be confused with a key that physically cannot be reached.

Secure elements and use-without-extract

The top tier changes the model entirely. A dedicated security chip — a secure element, or an equivalent hardened subsystem — performs cryptographic operations internally and exposes only their results. You ask it to sign or to decrypt; it does so inside its own boundary and hands back the output. The private key is generated within the element and never leaves it. There is no command that reads it out, because the interface was designed so that no such command exists.

This is the use-without-extract design, and it is a different relationship with the key than every tier below. The key is no longer a value the rest of the system holds and must protect; it is a capability the secure element exercises on request. Compromising the main firmware no longer yields the key, because the firmware never possessed it — it only ever had the right to ask. These parts are also built to resist physical extraction directly, with shielding, sensors, and hardened memory. They are not magic, but they move the cost of extraction from an afternoon at a bench to a funded laboratory attack, and for most products that shift is exactly the difference that matters.

Ask of every key in your design one question — can someone who holds the device read it out? Everything your cryptography promises rests on the answer, and the answer is set by where the key lives, not by how strong the algorithm is.

Key wrapping and the chain of custody

A common middle design wraps the working keys: encrypt them under a master key, store the wrapped blobs in cheap external flash, and unwrap them at runtime. This is genuinely useful, because it lets one well-protected key protect many others, and it keeps the bulk of your key material off the expensive storage. But wrapping does not remove the extraction question; it relocates it to the wrapping key. The security of every wrapped key is now precisely the security of wherever that master key is stored.

If the master sits in the same external flash as the blobs it protects, you have encrypted nothing that matters — the attacker who dumps the flash gets both. If the master lives in a secure element, the entire wrapped set inherits that strength. This is the turtles-all-the-way-down property, and the only stable bottom is a key that physically cannot leave the hardware. Wrapping is best understood as an amplifier rather than a solution: it makes good root storage protect many keys, and it makes bad root storage an elaborate way to lose all of them in a single read.

Tamper detection and response

The highest-assurance devices add an active dimension: detect physical intrusion and destroy the secrets before they can be read. A conductive mesh over the package, sensors watching voltage, temperature, and light, and — on a trip — immediate zeroization of the keys. The decisive word in that sentence is response. Detection without a fast and reliable erase is merely a log entry the attacker is happy to ignore while they continue working.

For this tier to mean anything, the device has to be able to render its own secrets unrecoverable faster than an attacker can extract them, which puts real demands on the erase path: it must be simple, independently powered for long enough to finish, and actually tested, rather than a best-effort routine a careful attacker can arrange to interrupt. Most products do not need this tier — it is for keys whose compromise would be catastrophic — but knowing it exists sets the ceiling of what is possible, and makes the honest placement of your own keys on the hierarchy easier to see.

Choosing honestly is the whole discipline. It means naming the tier your keys actually occupy and matching it to what their compromise would cost — not reaching for a secure element on every product, but never calling external cleartext "secure storage" simply because the firmware cannot see the difference. When 6QURE reviews key storage, the exercise is deliberately blunt: we pick a key, ask where it physically resides, and then ask what a person holding the board can do to get it — desolder a part, probe a bus, open a debug port, glitch a check. Under that question the real tier becomes obvious, and so does the distance between the security the product claims and the security its storage actually delivers.