Warum sichere Provisionierung in die Fertigung gehört
Ein vernetztes Gerät, das ohne Identität ausgeliefert wird, muss im Feld provisioniert werden. Feldprovisionierung bedeutet einen manuellen Schritt (oder eine angreifbare automatische Anmeldung) bei der Installation. Beides verursacht Betriebsaufwand und sicherheitsrelevante Angriffsflächen.
Die Provisionierung auf der Fertigungsseite gibt dem Gerät vor der Auslieferung eine eindeutige kryptografische Identität. Das Gerät startet, authentifiziert sich und meldet sich ohne manuellen Eingriff an.
Secure Elements
Microchip ATECC608 und NXP EdgeLock sind verbreitete Secure Elements für IoT. Beide unterstützen:
- Erzeugung privater ECC-Schlüssel innerhalb des Chips (der Schlüssel verlässt den Chip nie)
- Signieren und Verifizieren von Zertifikaten
- Zählerbasierten Replay-Schutz
- Manipulationssensitives Verhalten
Die Fertigungslinie erzeugt einen Schlüssel im Secure Element, signiert ein Zertifikat gegen die Root-CA, schreibt das Zertifikat auf das Gerät und protokolliert den öffentlichen Schlüssel gegen die Seriennummer.
X.509-Zertifikatsanmeldung
X.509 ist das Standardformat für Zertifikate. Die Anmeldung auf der Fertigungsseite folgt typischerweise diesem Muster:
- Das Secure Element erzeugt ein ECC-Schlüsselpaar (der private Schlüssel ist im Chip eingeschlossen)
- Das Fertigungssystem liest den öffentlichen Schlüssel
- Das Fertigungssystem signiert das Zertifikat über die HSM-gestützte Root-CA
- Das Zertifikat wird auf das Gerät zurückgeschrieben
- Öffentlicher Schlüssel und Zertifikats-Fingerabdruck werden gegen die Seriennummer protokolliert
Der private Schlüssel der Root-CA berührt die Fertigungslinie nie. Er liegt in einem HSM in einer kontrollierten Umgebung.
AWS IoT und Azure DPS
AWS IoT unterstützt Just-in-Time Provisioning (JITP) und Multi-Account Registration. Der Azure Device Provisioning Service (DPS) unterstützt X.509-Attestierung, Trusted Platform Module (TPM)-Attestierung und symmetrische Schlüsselattestierung.
Beide ermöglichen es der Fertigungslinie, Geräte vorab zu registrieren, sodass sie sich bei der ersten Cloud-Verbindung automatisch anmelden. Der Workflow auf der Fertigungsseite:
- Gerät wird mit X.509-Zertifikat provisioniert
- Zertifikats-Fingerabdruck des Geräts wird beim Cloud-DPS registriert
- Gerät startet im Feld, präsentiert das Zertifikat, meldet sich automatisch an
- Die Cloud weist das Gerät der richtigen Gruppe zu und lädt die Konfiguration herunter
Eine kundeneigene PKI folgt demselben Muster, nur mit interner Infrastruktur statt AWS oder Azure.
Funktionierender Workflow auf der Fertigungsseite
- HSM-gestützte Root-CA in einer kontrollierten Umgebung, zugänglich über eine Signatur-API
- Schlüsselerzeugung pro Einheit im Secure Element auf der Linie
- Zertifikatssignierung über API-Aufruf (kein Schlüsselmaterial wird offengelegt)
- Cloud-DPS-Vorabregistrierung als Teil des Provisionierungsschritts
- Anmeldedatensatz pro Einheit in der Fertigungsdatenbank protokolliert
- Optionale Verwaltung von Sperrlisten für ausgemusterte oder verlorene Geräte
Typische Fallstricke
- Privater Schlüssel der Root-CA liegt auf der Fertigungslinie (nicht im HSM)
- Derselbe Schlüssel wird in mehrere Geräte gebrannt ("Testmodus, der ausgeliefert wurde")
- Zertifikats-Fingerabdruck protokolliert, aber nicht beim Cloud-DPS vorab registriert
- Provisionierungsworkflow per Hand auf wenigen Einheiten ausgeführt, nie skaliert
Quellen
- AWS-IoT-Dokumentation zu Just-in-Time Provisioning
- Microsoft-Azure-Dokumentation zum Device Provisioning Service
- Microchip-Dokumentation zum Secure Element ATECC608
- NXP-Dokumentation zum Secure Element EdgeLock