THEMA / SECURE STORAGE & KEY PROTECTION

Ein Key im Flash ist ein Key, den ein Angreifer lesen kann. Ein Key in Hardware braucht trotzdem die richtigen Regeln.

Secure Storage ist keine Komponenten-Wahl. Es ist die Frage, wo Key-Material erzeugt wird, wie es ins Gerät gelangt, wo es lebt und welche Operationen es autorisiert. Extraktion ist nur die Hälfte der Bedrohung.

Key material Extraction Misuse
Diagnostische Frage Wo lebt Key-Material tatsächlich, was kann ein Angreifer mit physischem Zugriff, und lassen sich Keys missbrauchen, selbst wo sie nicht extrahierbar sind?
KEY MATERIAL PATH EXTRACTION vs MISUSE
↓
↓
↓
↓

Private Keys, Zertifikate, API-Tokens und Geräte-Secrets müssen irgendwo leben. Wenn dieses Irgendwo interner oder externer Flash im Plaintext ist, wird physischer Zugriff zur vollen Credential-Kompromittierung: Der Key verlässt das Gerät mit dem Angreifer. Verschlüsselte Blobs im Flash verschieben das Problem nur, wenn der Wrapping-Key ebenso lesbar woanders lebt.

Secure Elements und TPMs lösen die Extraktions-Hälfte: Keys werden innen erzeugt, verlassen den Chip nie, Operationen laufen in Hardware. Aber sie führen die andere Hälfte des Problems ein. Ein Key, der nicht extrahierbar ist, lässt sich trotzdem von jedem nutzen, der die Schnittstelle zu ihm kontrolliert. Wenn der Host, der mit dem Secure Element spricht, kompromittiert ist, signiert, authentisiert und entschlüsselt der Angreifer mit legitimer Hardware, ohne Extraktion.

Die richtige Architektur hängt vom Bedrohungsmodell ab: Was autorisiert der Key, wer erreicht die Schnittstelle, was passiert bei kompromittiertem Host, und ob der Produkt-Lebenszyklus (Provisioning, Ersatz, Revocation) mit Hardware-Binding kompatibel ist.

WAS ZU VERIFIZIEREN IST

Key-Schutz hängt von mehreren technischen Annahmen ab.

  • Key-Ursprung Wird das Key-Paar in Secure Hardware erzeugt oder extern injiziert, und was bedeutet das für Kopierbarkeit und Provisioning-Sicherheit?
  • Speicher-Ort Wo lebt Private Material auf Produktionseinheiten tatsächlich: Secure Element, TPM, TrustZone-geschützte Region, verschlüsselter Flash, oder Plaintext-Flash?
  • Wrap-Key-Abhängigkeit Bei verschlüsseltem Flash-Speicher: Wo lebt der Wrapping-Key, und lässt er sich vom selben Gerät wiederherstellen?
  • Schnittstellen-Kontrolle Wer kann Operationen von der Secure Hardware anfordern, und wie wird der anfragende Kontext authentisiert?
  • Missbrauch-Widerstand Wenn der Host kompromittiert ist: Kann der Angreifer beliebig signieren, authentisieren, entschlüsseln, oder begrenzen Policies, Limits und Attestation, was der Key tut?
  • Lifecycle-Passung Lassen sich Keys geräte-individuell provisionieren, im Feld ersetzen und widerrufen, innerhalb der Grenzen des Hardware-Bindings?
BEISPIEL-FEHLER

Das Secure Element hat signiert, der kompromittierte Host hat es gebeten.

Der Private Key verlässt den Chip nie; Extraktions-Versuche scheitern. Eine Protokoll-Schwäche lässt einen Angreifer die Host-Applikation kompromittieren. Der Host hält eine legitime Session mit dem Secure Element und fordert Signatur um Signatur an.

Der Key wurde nie gestohlen. Er wurde benutzt, vom Angreifer, durch das Gerät, mit Hardware, die exakt wie designt funktionierte.

WIE WIR RANGEHEN

Extraktion und Missbrauch als getrennte Angriffspfade testen.

Wir mappen, wo Key-Material auf Produktion-Hardware lebt, versuchen Extraktion mit physischem Zugriff, und testen dann den Missbrauchspfad: Was ein kompromittierter Host oder Protokoll-Peer den Key tun lassen kann. Das Ergebnis spiegelt das echte Schutzniveau des Produkts, nicht das Komponenten-Datenblatt.

KEY-MATERIAL LOKALISIEREN → EXTRACTION VERSUCHEN → SCHNITTSTELLE TESTEN → MISSBRAUCHSPFADE TESTEN → LIFECYCLE BEWERTEN
TECHNISCHE EVIDENZ
Das nützliche Ergebnis ist eine belastbare Antwort: Wo Key-Material tatsächlich lebt, was physischer Zugriff liefert, was ein kompromittierter Host autorisieren kann, und welche Architektur-Änderungen die Lücke schließen, die für dieses Produkt zählt.
WANN DAS RELEVANT WIRD
  • Auswahl der Secure-Element-, TPM- oder TrustZone-Architektur
  • Keys aktuell im Flash gespeichert, verschlüsselt oder nicht
  • Eine Produkt-Kompromittierung wirft die Frage, was ein Angreifer extrahieren könnte
  • Backend oder Protokoll verlangt Nachweis hardware-geschützter Keys
  • Field-Key-Rotation oder -Ersatz ist geplant
  • Compliance-Anforderungen verlangen hardware-gestützten Key-Schutz