Eine Geräte-Identität ist nur so stark wie der schwächste Schritt ihres Lebenszyklus. Wenn Credentials korrekt erzeugt, aber mit demselben Testschlüssel über eine Produktionsserie injiziert werden, ist das kryptografische Design irrelevant: Ein extrahiertes Gerät entriegelt die Flotte. Das Backend kann ein echtes Gerät nicht von einem Klon unterscheiden, weil das Credential, das Eindeutigkeit beweisen soll, geteilt ist.
Das Problem sieht selten nach einem gebrochenen Algorithmus aus. Es sieht aus wie ein Fertigungstool, das Development-Keys weiterverwendet, ein Provisioning-Prozess ohne geräte-individuelle Injektion oder ein Secure Element, das einen Key speichert, der auf einem Build-Server erzeugt wurde. Jedes davon ist im Design-Dokument unsichtbar, und wird erst sichtbar, wenn jemand das echte Produkt angreift.
Die operative Hälfte des Lebenszyklus wird noch häufiger vernachlässigt. Wenn ein Credential im Feld kompromittiert wird: Lässt es sich rotieren, ohne Geräte physisch zurückzurufen? Erreicht Revocation tatsächlich Geräte, die offline oder hinter eingeschränkten Netzen betrieben werden? Eine Produktlinie, deren Identität nicht ersetzbar ist, ist eine Produktlinie, in der ein einziger Leak dauerhaft ist.
Die Identity-Eigenschaft hängt von mehreren technischen Annahmen ab.
- Schlüsselgenerierung Wo entsteht das Key-Paar: im Secure Hardware des Geräts oder extern, um in der Produktion kopiert zu werden?
- Eindeutigkeit je Gerät Bekommt jede Einheit ihr eigenes Credential, oder teilen Chargen Secrets?
- Speicher-Schutz Lebt der Private Key in Secure Element oder TPM, oder als Plaintext im Flash, den physischer Zugriff lesen kann?
- Provisioning-Trennung Sind Werks-Testschlüssel vollständig von Produktionseinheiten ausgeschlossen, oder überlappen Test- und Produktions-Credentials?
- Klon-Widerstand Lässt sich ein extrahiertes Credential auf ein anderes Gerät übertragen, und erkennt das Backend die Anmeldung von Duplikaten?
- Backend-Revocation Wenn ein Credential leakt: Kann das Backend es widerrufen, und honorieren eingeschränkte oder offline Geräte diesen Widerruf tatsächlich?
- Rotation im Feld Lassen sich Identitäten ohne physischen Recall ersetzen, oder ist ein geleakter Key für die Flotte dauerhaft?
Das Zertifikat ist gültig, und über 40.000 Einheiten geteilt.
Jedes Gerät authentisiert sich erfolgreich. Das Backend akzeptiert jede Einheit, weil das Credential echt und korrekt signiert ist. Das Vertrauensmodell bricht lautlos: Das Credential beweist die Mitgliedschaft in der Produktlinie, nicht die Identität eines Geräts.
Wenn eine Einheit physisch kompromittiert und ihr Credential extrahiert wird, wird der Angreifer von jedem anderen Gerät ununterscheidbar. Revocation würde die gesamte Flotte deaktivieren, weshalb sie in der Praxis nie ausgelöst wird.
Die Identity-Kette am implementierten Produkt verifizieren.
Wir mappen den echten Provisioning-Pfad, von der Schlüsselgenerierung über das Fertigungstool bis zur ausgelieferten Einheit, und testen jeden Übergang auf Eindeutigkeit, Schutz und Trennbarkeit. Am Gerät prüfen wir, ob Private Material extrahierbar oder missbrauchbar ist. Gegen das Backend testen wir, ob geklonte oder replays Credential erkannt werden, und ob Revocation unter realistischen Bedingungen funktioniert.
- Neue Geräte-Identitäts- oder PKI-Architektur
- Fertigungs-Provisioning definiert oder geändert
- Secure Element oder TPM im Produkt eingeführt
- Flotten-Wachstum macht geräte-individuelle Credentials operativ kritisch
- Ein Credential-Leak oder geklontes Gerät wird vermutet
- Backend soll einzelne Geräte unterscheiden, kann es aber aktuell nicht
- Compliance oder Kunden-Assurance verlangt Nachweis eindeutiger Geräte-Identität