Field Note: „Der Key liegt im Secure Element”, was wir als Nächstes prüfen
Die häufigste Behauptung in Hardware-Assessments ist in einem engen Sinne wahr und schweigt über alles, was zählt. Die vier folgenden Checks: Debug-Oberflächen, Key-Policy, Provisioning-Historie, und was der Key tatsächlich schützt.
Jede Hardware-Bewertung beginnt mit Behauptungen. Die häufigste in der Produkt-Sicherheit: „Der Key liegt im Secure Element." Der Satz soll die Diskussion beenden. Für uns beginnt damit die Arbeit, denn der Satz ist in genau einem engen Sinne wahr (das Key-Material liegt tatsächlich in dem Chip) und schweigt über alles, was entscheidet, ob es etwas bedeutet. Diese Field Note hält fest, was wir als Nächstes tatsächlich prüfen, in dieser Reihenfolge, und was jeder Schritt in echten Produkten zutage gefördert hat.
Check 1: die Debug-Oberflächen um das SE herum
Das Secure Element verteidigt sein eigenes Die. Es verteidigt nichts über den Prozessor daneben. Erster Stopp: der Haupt-MCU. SWD- und JTAG-Pins, UART-Pads, Bootloader-Shells, Testpunkte, die zufällig sprechen. Erreichen wir Code Execution auf dem Host, brauchen wir den Key nicht; wir brauchen nur den Bus. Ein Sign-Request ist ein Sign-Request, egal wer ihn schickt. Befund: offener Debug-Zugang auf dem Host, SE-Policy komplett offen, der teure Chip machte Passwort-Speicher-Dienst.
Check 2: die Nutzungspolicy des Keys
Secure Elements lassen sich konfigurieren, was ein Key darf: welche Operationen, aus welchem Autorisierungszustand, mit welcher Host-Authentifizierung. Defaults sind permissiv, und Projekte shippen Pilot-Konfiguration in die Produktion. Wir lesen als Nächstes die Policy: Kann der Key beliebige Daten signieren? Verlangt das SE einen Beleg, dass es mit legitimer Firmware redet? Ein Key ohne Policy ist ein Key-Depot ohne Pförtner, physisch sicher, operativ öffentlich.
Check 3: wie der Key hineinkam
Die Provisioning-Historie entscheidet, wer den Key sonst noch hält. Beim CM injiziert mit einem Skript, das auch eine Log-Zeile schrieb? On-chip generiert und per Attestation zertifiziert? Aus einer Seriennummer abgeleitet? Jede Antwort verschiebt die Trust-Grenze. Die schlechteste Variante, die wir fanden: „eindeutige Per-Device-Keys", deterministisch aus der MAC-Adresse abgeleitet, einen Flash-Dump von jeder Geräte-Identität entfernt, Secure Elements inklusive.
Check 4: was der Key tatsächlich schützt
Letzter Check, der den Kreis schließt: die Architektur um das Geheimnis. Ein Device-Identity-Key im SE scheitert trotzdem, wenn das Backend jedem Inhaber des Zertifikats vertraut, wenn Sessions nicht an die Identität binden, wenn privilegierte Kommandos nicht re-authentifizieren. Das SE schützt eine Tatsache („dieses Gerät hält Key #4711"). Ob diese Tatsache etwas bedeutet, entscheiden Protokoll und Backend, und keines von beiden wohnt im Chip.
Wie gut aussieht
Übersteht die Behauptung alle vier Checks, sieht das Ergebnis auf die beste Art langweilig aus: Host-Debug geschlossen und verifiziert, Key-Policy auf die vorgesehenen Operationen beschränkt, Keys on-chip generiert mit attestiertem Provisioning, und ein Protokoll, das die Identität tatsächlich konsumiert. Diese Kombination ist nicht exotisch; sie ist ein paar Wochen diszipliniertes Engineering. Es prüft nur niemand, ob sie passiert ist, deshalb tun wir es.