Where Embedded Devices Hide Their Keys
Every cryptographic protection on a device ultimately rests on a key, and that key has to live somewhere. Where it lives determines whether the protection is real or theater. Here is the spectrum, from the choices I dread finding to the ones I want to see, and how to tell which one a device made.
The Key Is the Whole Game
Encryption, secure boot, authenticated updates, licensed features, all of it reduces to a key and the secrecy of that key. The strongest algorithm in the world protects nothing if the key that drives it is sitting where an attacker can read it. So when I assess a device, the question that matters most is not which cipher it uses, it is where it keeps the key.
That single design choice, key storage, is the hinge the whole security posture swings on. A device can get every other detail right and still fall in minutes because it left its signing key in readable flash. The spectrum from worst to best storage is therefore the most useful map I can give for thinking about a device’s real, as opposed to claimed, security.
Plain Flash, the Worst Case
A key sitting in readable flash is no key at all once an attacker dumps the firmware, which on many devices takes minutes with a clip and a programmer. It is simultaneously the most common finding and the most damaging, because the moment the firmware is readable, every secret in it is too.
The damage multiplies when the same key is shared across every unit. Recover it once, from any device on a bench, and the whole fleet is open: every encrypted image decryptable, every signature forgeable. A per-device key in flash is bad; a global key in flash is a single point of failure for the entire product line.
Finding a Key in a Dump
Keys in flash are not hard to find, which is the problem. High-entropy blocks of the right length, certificate and key markers, and the strings around them give them away in a dump.
# look for PEM markers and key-shaped high-entropy blocks in a firmware dump
strings -n 10 firmware.bin | grep -iE 'BEGIN (RSA|EC|PRIVATE) KEY|aes|hmac'
binwalk -E firmware.bin | grep -i 'high entropy'-----BEGIN EC PRIVATE KEY----- aes_key_default 0x4D120 high entropy region (256 bytes) <- likely an embedded key
A BEGIN EC PRIVATE KEY marker in a firmware image is exactly as bad as it looks: the device’s private key shipped in the clear. The high-entropy region of a key-sized length is the next thing to carve out and test. Either way, the dump just handed over the secret the whole system relied on.
Compiled Into the Binary
Slightly less obvious but no safer, a key baked into code as a constant array is recoverable by anyone who reads the binary. It does not show up as a tidy PEM block, but it sits in the data section as a fixed-length run of bytes that a disassembler resolves the moment you find the function that uses it.
Teams sometimes reach for obfuscation here, splitting the key, XORing it with another constant, assembling it at runtime. That slows an analyst down for minutes, not days. The decrypting code is right there in the same binary, so following it reconstructs the key. Obfuscation is a speed bump, never a vault.
One-Time-Programmable Fuses
Fuses can store a key or its hash in memory that software cannot rewrite, which is a real improvement because the value is anchored in hardware and survives a firmware compromise. A fused key hash, used to verify signatures, is a solid root of trust.
The caveat is what the running firmware can do with the fused value. Some implementations let the application read the key straight back out of the fuse bank, which puts it in RAM and back within reach of a debugger or a memory-disclosure bug. A fuse that stores a key the CPU can read is better than flash, but it is not the same as a key the CPU can never see.
A Dedicated Secure Element
The strongest common option keeps the key inside a separate chip that performs cryptographic operations without ever exporting the key. The firmware asks the secure element to sign or decrypt, the element does the math internally, and the secret never crosses the bus or enters the main CPU’s memory at all.
This is the design I most want to find, because compromising the main firmware no longer compromises the key. An attacker who fully owns the application can ask the element to sign things while the device is in their hands, but they cannot extract the key to forge signatures later or to attack other units. The blast radius shrinks dramatically.
How a Secure Element Changes the Attack
With a secure element, the operation moves into the chip and the bus only ever carries requests and results, never the key. Even sniffing the I2C or SPI line between the CPU and the element yields commands and signatures, not the secret behind them.
# the CPU asks the element to sign; the key never leaves the element
host -> SE: sign(hash, key_slot=0)
SE -> host: signature # the private key in slot 0 is never transmittedSniffing that exchange gets an attacker a signature over one message, not the key that produced it. That is the qualitative difference: with a key in flash, one read ends the game, while with a secure element, the attacker has to keep the device to keep using the key, and they still cannot clone it.
The TPM and Secure-Enclave Variants
Secure elements come in several forms beyond the standalone crypto chip. A TPM offers sealed storage and attestation. Some SoCs include a secure enclave or a TrustZone-based key store that keeps keys in a protected world the normal firmware cannot read. The principle is identical: the key lives behind a boundary the application cannot cross.
Which variant fits depends on the platform and the use case, but they share the property that matters. The key is used through an interface rather than handed out, so a compromise of the rich firmware does not automatically yield the secret. When I see one of these in a design, the key-storage question usually moves from a worry to a checkbox.
Detecting Which Choice a Device Made
You can often tell where the keys live without a full teardown. A crypto chip on the board, a TPM, or an I2C device at a known secure-element address points to hardware storage. The absence of any such part, combined with keys found in the dump, points to software storage and a weaker posture.
An I2C scan that turns up a known secure-element address, or a BOM that lists a crypto authentication chip, is a good sign. Finding the actual keys in a firmware dump is the bad sign, and it usually means the cryptographic part either is not present or is not being used to hold the secrets it should.
Matching Storage to the Stakes
The right choice follows from what one recovered key would cost. If losing it means cloned devices, forged updates, or unlocked paid features across the fleet, a secure element that never exports the key pays for itself many times over. If the impact of a lost key is contained to a single unit and low value, fuses may be enough.
Plain flash and compiled-in constants are never adequate for anything an attacker would actually want, because a firmware dump exposes them in minutes. The engineering judgment is about how far up the spectrum to climb for a given secret, not about whether the bottom rungs are acceptable for valuable keys, because they are not.
The Most Common and Most Damaging Finding
Across embedded assessments, the single most frequent serious finding is a sensitive key stored where the firmware, and therefore an attacker, can read it. It shows up as a private key in flash, a hardcoded AES key in the binary, or a fused key the application happily reads back into RAM.
It is damaging precisely because so much rests on it. The encryption, the secure boot, the update authentication, all of it inherits the weakness of the key’s hiding place. Fixing the cipher or adding a check does nothing if the key is still readable, which is why I treat key storage as the first thing to evaluate, not the last.
Matching Protection to the Threat
The principle is simple to state and easy to neglect under deadline pressure: the further a key sits from readable memory, the more real the protection it provides. A key in flash is readable by anyone with the firmware. A fused key may reach RAM. A key in a secure element never leaves the chip. Each step up the spectrum shrinks what an attacker gains from a compromise.
So the design move is to put the valuable keys as far up that spectrum as the budget allows, and to be honest about which rung each key actually sits on. A device that aims for a secure element, settles for fuses where it must, and never accepts plain flash for anything sensitive has made the one choice that most determines whether its cryptography is real.
Where This Fits
Finding where a device keeps its keys, and how easily they fall, is one of the first things I check in a product security assessment. If you want your key storage assessed and a clear read on what a single extraction would cost you, that is the kind of work we do at Berkner Tech.