Device Identity: Warum Shared Credentials die Flotte gefährden

Fragt man ein Product-Team, wie sich seine Geräte am Backend authentifizieren, lautet die ehrliche Antwort oft ein Schulterzucken: „Da ist ein Key in der Firmware". Fragt man, was passiert, wenn ein Gerät auf einem Labortisch landet, endet das Schulterzucken. Diese Frage, was kostet die Extraktion eines Geräts?, ist das gesamte Argument für Per-Device-Identity. Ein Shared Credential kann jede Identität gefährden, die auf diesem Geheimnis beruht. Ein einzigartiger Per-Device-Key betrifft zunächst eine Identität. Ob der Schaden dort bleibt, entscheiden Autorisierung und Sperrung, nicht die Einzigartigkeit allein.

Diese Note handelt von der Distanz zwischen diesen beiden Antworten in echten Produkten: warum Shared Credentials viel länger überleben, als sie dürften, was Per-Device-Identity wirklich bringt, und was sie operativ kostet.

Warum Shared Credentials im Maßstab scheitern

Shared Credentials beginnen vernünftig. Ein Pre-Shared Key im Firmware-Image, ein Client-Zertifikat in jeder Einheit, ein API-Token für die ganze Produktlinie, eine Sache zum Provisionieren, eine zum Rotieren, eine zum Debuggen. Schon bei 10 Geräten betrifft ein Leak jede Verwendung des geteilten Geheimnisses. Mit der Flotte wachsen sowohl der mögliche Schaden als auch der Aufwand, das Credential zu ersetzen.

Wird ein geteiltes Geheimnis aus einem Gerät extrahiert, kann ein Angreifer es dort einsetzen, wo dieses Credential akzeptiert wird. Der Aufwand hängt von Hardware und Schutzkonfiguration ab (siehe Firmware Extraction). Authentifizierung allein anhand dieses Geheimnisses kann die beteiligten Geräte nicht unterscheiden. Eine Sperrung ist möglich, unterbricht aber die davon abhängigen Funktionen aller Geräte, die das Credential noch nutzen. Daraus kann ein flottenweiter Authentifizierungsvorfall werden, nicht automatisch Code-Ausführung auf jedem Gerät.

Was Per-Device-Identity bringt

Per-Device-Identity heißt: Jede Einheit hält ein Credential, das nirgendwo sonst existiert, ein Key-Paar, on-chip generiert oder in der Fertigung injiziert, mit einem Zertifikat, das dieses Gerät benennt, nicht die Produktlinie. Konkret kauft man sich:

• Eine abgrenzbare Identität. Die Extraktion eines einzigartigen Device-Keys kompromittiert diese Identität, nicht automatisch die anderen. Der Schaden bleibt nur dann im vorgesehenen Umfang, wenn auch die Rechte auf dieses Gerät begrenzt sind.
• Zurechenbarkeit. Backend-Logs können das authentifizierte Credential von Gerät #4711 benennen, nicht nur „irgendein Gerät". Nach einer Key-Extraktion unterscheiden diese Logs allein allerdings nicht zwischen der echten Einheit und einem Imitator.
• Differenzierte Reaktion. Ein Gerät quarantänen, ein gezieltes Update ausrollen, eine Seriennummer verweigern, statt zwischen „Vorfall ignorieren" und „Flotten-Credential rotieren" zu wählen.
• Revocation, die etwas bedeutet. Individuelle Credentials erlauben gezielte Sperrung, sofern alle relevanten Prüfer sie durchsetzen. Die Sperrung eines Shared Credentials unterbricht auch dessen legitime Nutzer.

Identität ist keine Berechtigung

Zertifikatsbasierte Authentifizierung muss den Besitz des zugehörigen privaten Keys prüfen; das Vorlegen des öffentlichen Zertifikats allein genügt nicht. Autorisierung ist eine separate Entscheidung. Das Backend muss die authentifizierte Identität an erlaubte Geräte-Ressourcen, Mandantengrenzen und Operationen binden. Gerät A darf nicht durch Angabe einer anderen ID, Wahl eines anderen MQTT-Topics oder Aufruf einer Service-Funktion auf Gerät B zugreifen. Diese Grenzen müssen mit zwei unabhängig provisionierten Identitäten getestet werden. Einzigartige Keys ohne diese Prüfungen können weiterhin flottenweiten Schaden ermöglichen.

Provisioning ist das eigentliche Problem

Teams unterschätzen nicht die Kryptografie, sondern die Fabrik. Irgendwo in der Produktion muss jedes Gerät ein einzigartiges Credential erhalten, und der Prozess muss drei Dinge garantieren: Der Key entsteht bzw. wird injiziert, ohne dass jemand außerhalb des Geräts ihn sieht; das Zertifikat wird auf die korrekte Seriennummer ausgestellt; der Provisioning-Schritt lässt sich nicht überspringen oder wiederholen. In der Praxis finden wir Provisioning-Stationen mit Debug-Logs injizierter Keys, HSMs als teure Zufallsgeneratoren und „eindeutige" Credentials, deterministisch aus der Seriennummer abgeleitet, ein Schema, das einen Etikettendrucker in ein Key-Orakel verwandelt.

Das sauberste Muster: das Key-Paar auf dem Gerät erzeugen (in Secure Element oder TEE), nur den Public Key exportieren, ihn gegen das Attestations-Zertifikat des Geräts signieren und daraus das Identity-Zertifikat ausstellen. Der Private Key existiert nie außerhalb des Chips, nicht in einer Datenbank, nicht in einem Log, nicht im Temp-Ordner eines Fabrik-PCs.

Revocation ohne Neu-Provisioning

Per-Device-Identity zahlt sich nur aus, wenn das Sperren eines Geräts operativ langweilig ist. Das heißt: Das Backend hat einen Sperrpfad, der keine anderen Geräte anfasst; die relevanten Dienste setzen den Sperrzustand durch; und das Konzept definiert den Umgang mit bestehenden Sessions und abgeleiteten Tokens. Jemand muss den Prozess vor dem ersten Vorfall proben, das Verweigern einer neuen TLS-Verbindung beendet nicht zwangsläufig eine bestehende Session. Eine Revocation-Architektur, die nie geübt wurde, ist eine Hypothese, kein Control.

Migration weg vom Shared PSK

Für Produkte im Feld mit geteiltem Credential ist die Migration eine eigene Design-Übung. Die übliche Form: Neue Firmware vertraut während eines Übergangsfensters sowohl dem Legacy-Shared-Credential als auch Per-Device-Zertifikaten; Geräte beziehen ihre Identität über einen gegenseitig authentifizierten Kanal; das Shared Credential wird danach herabgestuft, dann entfernt. Das Übergangsfenster ist selbst ein Risikofenster, es verlängert das Leben des geteilten Geheimnisses,, also verdient es eine Frist, Telemetrie zur Adaption und eine Story für Geräte, die nie updaten. Das ist eines der Gespräche, in denen Frühsein dramatisch billiger ist: dieselbe Migration nach einem Vorfall plant einen Angreifer mit ein.

Wo der Key liegt, ist so wichtig wie das Schema

Ein lesbarer privater Device-Key kann die Imitation dieses Geräts ermöglichen. Er bleibt ein Per-Device-Key: Einzigartige Credentials und korrekt begrenzte Rechte können den Schaden weiterhin eingrenzen. Der Speicherschutz. Secure Element, TPM, TEE oder verschlüsselter Speicher, entscheidet separat über den Extraktionsaufwand und ersetzt keine Backend-Autorisierung. Diese Frage behandeln wir vertieft in Secure Element vs. Secure Storage und in der Field Note darüber, was wir hinter dem Satz „der Key liegt im Secure Element" prüfen.

Die Kurzform: Identity ist eine Architektur, kein Credential. Einzigartigkeit der Credentials, Provisioning, Autorisierung, Sperrung und Key-Schutz müssen zusammenwirken. Ein Produkt-Security-Review muss die Übergänge zwischen ihnen prüfen.