Secure Element vs. Secure Storage vs. TPM: Wo Device-Keys hingehören
Ein Secure Element schützt ein Geheimnis, Secure Storage Daten im Ruhezustand, ein TPM fügt Attestation-Protokolle hinzu. Was jede Option wirklich bringt, wo jede scheitert, und die zwei Fragen, die das Design entscheiden.
„Unsere Keys liegen im Secure Element." Diesen Satz hören wir in fast jedem ersten Gespräch, meist als Schlussargument des Security-Konzepts. Der Satz ist oft wahr und meist unvollständig: Ein Secure Element ist eine Antwort auf eine Frage, wo lebt Key-Material? Produkte haben mehrere Geheimnisse mit mehreren Bedrohungsmodellen, und das Silizium, das eine Device-Identity schützt, ist nicht das Silizium, das Bulk-Daten im Ruhezustand schützt.
Diese Note kartiert die Optionen: Was ein Secure Element tut, was Secure Storage tut, wohin ein TPM passt, und welche Frage Sie eigentlich beantworten sollten, wenn Sie sich entscheiden.
Was ein Secure Element wirklich tut
Ein Secure Element ist ein eigener Chip, dessen Aufgabe es ist, Key-Material zu halten und damit Krypto-Operationen auszuführen, ohne den Private Key jemals über sein Host-Interface preiszugeben. Die Applikation schickt Daten über I²C oder SPI hinein; Signatur oder MAC kommen zurück. Der Key wird innen erzeugt, lebt innen, stirbt innen. Typische Bausteine: Microchip ATECC608, ST STSAFE, NXP EdgeLock.
Was man kauft: Extraktions-Resistenz. Den Key zu lesen erfordert das Überwinden der Chip-Schutzmechanismen. Fault Injection, invasives Probing, Side Channels, statt eines Flash-Dumps. Was man nicht geschenkt bekommt: korrekte Key-Nutzung. Ein SE ohne Sign-Policy dient jedem, der seinen Bus erreichen kann. Ist der Debug-Port des Haupt-MCUs offen und kann Firmware beliebige Sign-Requests schicken, hat der Key den Chip nie verlassen, und der Angreifer brauchte ihn nie. Genau dieses Fehlermuster behandeln wir in der Field Note „Der Key liegt im Secure Element", was wir als Nächstes prüfen.
Was Secure Storage schützt
Secure Storage ist eine andere Antwort auf eine andere Frage. Sie schützt Daten im Ruhezustand: Konfiguration, Datenbanken, Logs, Inhalte, alles, was bei geöffnetem Gehäuse nicht lesbar sein darf. Die Mechanismen variieren: RPMB-Partitionen auf eMMC/UFS (authentifizierter, replay-geschützter Schreibzugriff), File-Based-Encryption-Schichten, verschlüsselte Custom-Flash-Bereiche.
Der entscheidende Punkt ist immer derselbe: Wo liegt der Key, der den Speicher verschlüsselt? Ist er von einem Wert im lesbaren Flash des MCUs abgeleitet, schützt die Verschlüsselung vor gelegentlichem Kopieren, nicht vor einem Angreifer. Ist er von einem geräteeinzigartigen Key in SE oder TPM umschlossen, haben Sie eine echte Kette. In Reviews hat „verschlüsselter Speicher" seinen Namen erst verdient, wenn wir den Key-Pfad Ende-zu-Ende verfolgt haben.
TPM: das standardisierte Secure Element
Ein TPM ist ein Secure Element mit öffentlicher Spezifikation, und die Spezifikation ist der Wert. PCRs, die die Boot-Kette hashen, Attestation-Keys und Quotes, Data Sealing an Systemzustände, ein herstellerübergreifender Befehlssatz. Auf Linux-Klasse-Produkten ist ein TPM 2.0 oft die pragmatische Wahl: gut unterstützte Stacks, Measured Boot und Remote Attestation ohne eigenes Protokolldesign.
Der wiederkehrende TPM-Fehler ist Präsenz ohne Integration: Der Chip steht auf dem BOM, die Firmware extended nie PCRs, nichts wird dagegen gesealt, keine Attestation wird je vom Backend geprüft. Das ist ein Secure Element in Briefkastenfunktion. Die Stückliste ist keine Architektur.
On-chip generiert vs. injiziert
Über alle drei Optionen hinweg dominiert eine Design-Entscheidung: Wird der geräteeinzigartige Key in der Hardware erzeugt, oder in der Fertigung injiziert? On-chip generiert: Der Private Key existiert nirgendwo sonst, Provisioning ist einfacher, und die Supply-Chain-Frage schrumpft auf das Vertrauen in den Chip. Injiziert: Sie können escrowte Kopien zurückholen, Identitäten im Batch provisionieren, Key-Ersatz unterstützen, aber ab jetzt sind eine Datenbank, ein Fertigungsprozess und jeder mit Zugriff auf beide Teil Ihres Bedrohungsmodells. Die meisten Identity-Architekturen, die wir respektieren, wählen On-chip-Generierung plus Zertifikats-Attestation; die meisten Vorfälle, die wir sehen, führen auf Injektionsprozesse, die im Pilotlauf bequem waren und für die Produktion nie gehärtet wurden.
Kosten, Pins und Board-Realität
Die nicht-technischen Randbedingungen entscheiden mehr Designs als Datasheets. Ein Secure Element bedeutet: zusätzlicher Chip, BOM-Kosten, Boardfläche und einen zweiten Firmware-Lebenszyklus (auch SE-Applets brauchen Updates). RPMB ist in Ihrer eMMC vielleicht bereits enthalten, die billigste Option, die wirklich verdrahtet ist. Ein TPM ist auf einem Embedded-Linux-Board eine Commodity; auf einem kleinen RTOS-Produkt kann es architektonisch schwerer sein als das Produkt drumherum. Die falsche Antwort ist hier nicht der schwächere Chip, es ist der starke Chip, dessen Integration in der nächsten Cost-down-Revision gestrichen wurde und der jetzt stumm auf dem Board liegt.
Die Entscheidung, komprimiert
Ohne Vendor-Material reduziert sich die Wahl auf zwei Fragen:
- Was muss physischen Zugriff überstehen? Device-Identity und Signing-Keys → Secure Element oder TPM, Keys on-chip generiert. Bulk-Daten im Ruhezustand → Secure Storage, umschlossen von einem geräteeinzigartigen Key aus genau diesem Element.
- Wer muss wem was beweisen? Braucht das Backend Evidenz über den Gerätzustand (Attestation), verdient die TPM-PCR-Maschinerie ihren Preis. Geht es nur um Key-Custody, ist ein diskretes SE das schlankere Design.
Und ein Abschluss-Check, der nichts mit Silizium zu tun hat: Was auch immer Sie gewählt haben, ist es in den Seriengeräten tatsächlich aktiviert, gefust, provisioniert und in Betrieb? Oder nur auf den Dev-Boards, die demonstriert wurden? Die Lücke zwischen diesen beiden Antworten ist der Ort, an dem Assessments ihre Befunde finden.