Device security often ends at a very concrete question: where should the key live?
The answer cannot simply be “use a secure element” or “put it in eFuse”. Different keys have different uses, lifetimes, attack surfaces, and costs. They may need different storage locations.
Start by splitting the question:
what is the key used for
-> must it be exportable
-> does it need updates
-> what is the blast radius if it leaks
-> can the attacker physically access the device
-> how is it generated or provisioned
-> how is it rotated, repaired, and retired in the field
Device key storage is not about hiding a string. It defines whether key material can be read, copied, replaced, misused, and recovered throughout the device lifecycle.
Classify Keys by Use First
A device may contain many kinds of keys:
- device identity private key
- TLS client certificate private key
- PSK
- Secure Boot verification public key or public-key hash
- OTA decryption key
- local data encryption key
- log authentication key
- PUF helper data
- session keys
These should not be mixed together.
Long-term identity keys and boot trust anchors usually need the strongest protection. Session keys are short-lived and usually live only in RAM. Public keys do not need secrecy, but they need tamper protection. Encryption keys may need both read protection and rotation.
The first step is not choosing hardware. It is labeling every key by purpose and lifecycle.
Plain Flash Is Cheap and Easy to Misuse
Putting keys in ordinary flash files, partitions, or NVS is simple.
It can be reasonable for:
- low-risk configuration
- temporary credentials that can rotate
- key material wrapped by an upper-level key
- public certificates and other non-secret material
The risks are clear:
- firmware bugs may read it
- debug ports may export it
- offline flash extraction may read it
- logs and backups may leak it
- factory reset and OTA may delete it accidentally
- permission isolation is weak
If sensitive keys must be stored in flash, at least consider debug lockout, read protection, partition permissions, file permissions, key wrapping, rollback protection, factory wipe behavior, and log auditing.
Plain flash can be storage media. It is usually not enough as the only protection for the highest-value long-term private keys.
OTP/eFuse Fits Immutable Root Material
OTP and eFuse are write-once or one-way programmable.
They fit:
- Secure Boot public-key hash
- rollback counters
- device unique ID
- root key derivation material
- debug lock bits
- secure boot configuration
Their value is tamper resistance. Ordinary firmware cannot freely change them, and attackers cannot easily roll them back.
But OTP/eFuse is not for everything:
- mistakes are hard to recover
- capacity is small
- frequent updates do not fit
- large certificates or complex structures do not fit
- field replacement policy becomes harder
A common pattern is to put immutable trust anchors in eFuse, while updateable certificates, policy, and version information live in managed secure storage or protected partitions.
Secure Element Is About Non-Exportable Keys
The core value of a secure element is not just having storage. It is that keys can be non-exportable.
The device asks the chip to perform operations:
sign(challenge)
derive_key(context)
decrypt(wrapped_key)
verify(policy)
The private key stays inside the chip. The main MCU receives only the signature, derived result, or cryptographic operation result.
This fits:
- device identity private keys
- mTLS client private keys
- high-value provisioned keys
- anti-cloning device identity
- payment, lock, automotive, industrial, and other high-risk devices
Costs include:
- BOM cost
- I2C/SPI communication and driver complexity
- provisioning flow binding
- chip inventory and supply chain
- performance limits
- certificate and key slot management
A secure element also does not solve everything. A compromised main MCU may still call the chip to sign data, so access control, rate limiting, usage restrictions, firmware integrity, and server-side anomaly detection still matter.
TEE/TrustZone Provides Isolation but Depends on the Platform
TEE, TrustZone, or secure world can isolate key operations from normal applications.
It fits when:
- key operations should stay inside the SoC
- adding a separate secure element is not desirable
- trusted OS, secure storage, and hardware isolation are available
- keys need protection after application compromise
Common pattern:
normal world app
-> secure monitor call
-> trusted app uses key
-> returns result
TEE security depends on the chip, boot chain, trusted OS, drivers, and secure storage implementation. The label alone does not make it secure.
Check:
- whether secure world is protected by Secure Boot
- whether keys are bound to a hardware unique key
- whether normal world can read secure storage directly
- whether trusted apps have permission boundaries
- whether debug and development modes are disabled
- whether rollback can restore old secure storage
PUF Does Not Directly “Store a Key”
PUF uses manufacturing variation to produce a device-specific characteristic. It is often used to derive a device-unique key.
But PUF is usually not a stable raw random string emitted on every boot. Engineering needs:
- enrollment
- helper data
- error correction
- key reconstruction
- limits on what helper data reveals
- temperature, voltage, and aging evaluation
Typical model:
PUF response + helper data
-> fuzzy extractor / error correction
-> stable device key
The value of PUF is reducing plaintext key storage by reconstructing the key from hardware characteristics when needed.
But helper data, implementation, and usage path still need protection. PUF does not replace Secure Boot, certificates, key rotation, or server-side identity management.
Exportability Is the Key Boundary
Ask one question during selection: may this key leave the protection boundary?
exportable key: software can read bytes and pass them to algorithms
non-exportable key: software can only request sign, decrypt, derive, or similar operations
Non-exportable is usually safer because an attacker who controls part of the software may still not be able to copy the key.
But it has costs:
- backup and migration are harder
- repair and replacement workflows are more complex
- algorithm support is limited by the chip
- debugging is harder
- performance may be limited
- key slots and permissions must be designed
High-value identity private keys should generally be non-exportable. Rotatable, low-value, short-lived keys can be more flexible.
Provisioning and Field Workflow Decide Real Security
Key storage has to land in manufacturing and field operations.
Answer:
- whether keys are generated on device or externally
- whether external generation uses HSM
- whether injection transport is encrypted and authenticated
- whether workstations store keys
- how failed devices are handled
- whether repair keeps the original identity
- whether retired devices destroy keys
- whether field rotation is supported
- how resale or tenant migration resets identity
Many leaks happen outside algorithms: CSV files, logs, workstation temp directories, backup packages, debug firmware, and repair processes.
Key storage design must include those paths in the threat model.
A Practical Layering
Use this as an initial rule of thumb:
session keys:
RAM, destroyed when the connection ends
public keys / certificates:
flash is acceptable, but protect against tampering and version confusion
Secure Boot public-key hash / rollback counter:
OTP/eFuse/RPMB/protected secure storage
device identity private key:
prefer secure element / TEE / non-exportable key slot
local data encryption key:
derive from a hardware root key or wrap under it, avoid long-term plaintext in flash
PUF-derived root key:
protect helper data and reconstruction path, evaluate stability and environment
Low-cost devices may not all use a secure element. But avoid the worst pattern: all devices share one key, stored in plaintext flash, readable over debug, and printed in logs.
Debugging Order
When evaluating device key storage, inspect:
is every key's purpose and lifecycle clear
-> is long-term identity unique per device
-> are high-value private keys exportable
-> does plain flash contain high-value plaintext keys
-> does eFuse/OTP store only immutable root material
-> do Secure Element / TEE policies restrict usage and access
-> are PUF helper data and reconstruction path protected
-> can debug ports, logs, dumps, or backups leak keys
-> do provisioning and repair keep key copies
-> are rotation, disablement, and retirement defined
Where a device key should live depends on purpose, cost, threat model, and lifecycle. The goal is not to hide the key in a mysterious place. The goal is to make the key usable when needed and unavailable when it should not be copied, exported, rolled back, or misused.