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 sits where an attacker can read it, so the question that matters most in an assessment is not which cipher a device uses, it is where it keeps the key. That single choice is the hinge the whole posture swings on:
| Where the key lives | How an attacker gets it | Strength |
|---|---|---|
| Plain flash | Dump the firmware with a clip and programmer, read it out | Worst, one read ends the game |
| Compiled into the binary | Read the data section; obfuscation only slows an analyst | Worst, a speed bump, not a vault |
| OTP fuses | Anchored in hardware, but exposed if firmware reads it into RAM | Better, only if the CPU can never read it |
| Secure element | Key never leaves the chip; only requests and results cross the bus | Strongest common option |
| TPM / secure enclave | Key stays in a protected world the rich firmware cannot read | Strongest, same principle, different form |
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 is the most useful map for thinking about a device’s real, as opposed to claimed, security, and the rest of this walks each rung.
Plain Flash and Compiled-In Constants
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, and 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 and every signature forgeable.
A key baked into code as a constant array is slightly less obvious but no safer, recoverable by anyone who reads the binary. Teams sometimes reach for obfuscation, splitting the key, XORing it with another constant, assembling it at runtime, but the decrypting code is right there in the same binary, so following it reconstructs the key. Obfuscation is a speed bump, never a vault.
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.
Fuses: Better, with a Caveat
One-time-programmable 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, and 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 it. 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, so even sniffing the I2C or SPI line between them 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 transmitted Sniffing 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; with a secure element, the attacker has to keep the device to keep using the key, and they still cannot clone it. Compromising the main firmware no longer compromises the key, and the blast radius shrinks dramatically.
TPM and Secure-Enclave Variants
Secure elements come in several forms beyond the standalone crypto chip: a TPM offers sealed storage and attestation, and 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, 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.
Match 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 is contained to a single low-value unit, 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.
Across embedded assessments, the single most frequent serious finding is a sensitive key stored where the firmware, and therefore an attacker, can read it, as a private key in flash, a hardcoded AES key in the binary, or a fused key the application reads back into RAM. It is damaging precisely because so much rests on it: the encryption, the secure boot, and the update authentication all inherit the weakness of the key’s hiding place, and fixing the cipher does nothing if the key is still readable. The further a key sits from readable memory, the more real the protection, so put the valuable keys as far up the spectrum as the budget allows and be honest about which rung each one actually sits on.
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.
