TOPIC / SECURE STORAGE & KEY PROTECTION

A key in flash is a key an attacker can read. A key in hardware still needs the right rules.

Secure storage is not a component choice. It is the question of where key material is generated, how it travels into the device, where it lives, and which operations it authorizes, extraction is only half of the threat.

Key material Extraction Misuse
Diagnostic question Where does key material actually live, what can an attacker do with physical access, and can keys be misused even where they cannot be extracted?
KEY MATERIAL PATH EXTRACTION vs MISUSE
↓
↓
↓
↓

Private keys, certificates, API tokens and device secrets have to live somewhere. When that somewhere is internal or external flash in plaintext, physical access turns into full credential compromise: the key leaves the device with the attacker. Encrypted blobs in flash only shift the problem if the wrapping key lives somewhere equally readable.

Secure elements and TPMs solve the extraction half: keys are generated inside, never leave, and operations run in hardware. But they introduce the other half of the problem. A key that cannot be extracted can still be used by anyone who controls the interface to it. If the host that talks to the secure element is compromised, the attacker signs, authenticates and decrypts with legitimate hardware, no extraction required.

The right architecture depends on the threat model: what the key authorizes, who can reach the interface, what happens on a compromised host, and whether the product's lifecycle, provisioning, replacement, revocation, is compatible with hardware-bound keys.

WHAT TO VERIFY

Key protection depends on several technical assumptions.

  • Key origin Is the key pair generated inside secure hardware, or externally and injected, and what does that mean for copying and provisioning security?
  • Storage location Where does private material actually reside on production units: secure element, TPM, TrustZone-protected region, encrypted flash, or plaintext flash?
  • Wrap-key dependency For encrypted flash storage: where does the wrapping key live, and can it be recovered from the same device?
  • Interface control Who can request operations from the secure hardware, and how is the requesting context authenticated?
  • Misuse resistance If the host is compromised, can the attacker sign, authenticate or decrypt at will, or do policies, limits and attestation bound what the key does?
  • Lifecycle fit Can keys be provisioned per device, replaced in the field, and revoked, within the constraints of hardware binding?
EXAMPLE FAILURE

The secure element signed it, the compromised host asked it to.

The private key never leaves the chip; extraction attempts fail. A protocol-level weakness lets an attacker compromise the host application. The host holds a legitimate session with the secure element and requests signature after signature.

The key was never stolen. It was used, by the attacker, through the device, with hardware that worked exactly as designed.

HOW WE APPROACH IT

Test extraction and misuse as separate attack paths.

We map where key material lives on production hardware, attempt extraction with physical access, and then test the misuse path: what a compromised host or protocol peer can make the key do. The result reflects the real protection level of the product, not the component datasheet.

LOCATE KEY MATERIAL → ATTEMPT EXTRACTION → TEST INTERFACE CONTROL → TEST MISUSE PATHS → ASSESS LIFECYCLE
TECHNICAL EVIDENCE
The useful outcome is a supported answer: where key material actually lives, what physical access yields, what a compromised host can authorize, and which architectural changes close the gap that matters for this product.
WHEN TO LOOK AT THIS
  • Selecting secure element, TPM or TrustZone architecture
  • Keys currently stored in flash, encrypted or not
  • A product compromise raises the question of what an attacker could extract
  • Backend or protocol requires evidence that keys are hardware-protected
  • Field key rotation or replacement is planned
  • Compliance requirements demand hardware-backed key protection