X.509-Zertifikate für IoT: Zero-Trust-Geräteauthentifizierung

Symmetrische Schlüssel, die über eine Geräteflotte hinweg geteilt werden, bedeuten, dass ein einziges kompromittiertes Gerät alle Geräte gefährdet. X.509-Zertifikate geben jedem Gerät eine eindeutige kryptografische Identität — kompromittiert man eines, betrifft das nur eines.

Entwurf der Zertifikatshierarchie

Root CA (selbstsigniert, offline, luftgetrennte Hardware)
  └── Manufacturing CA (online HSM, signiert Gerätezertifikate)
       └── Gerätezertifikat (eindeutig pro Seriennummer)
            Schlüssel: ECC P-256 (kleiner und schneller als RSA-2048)

Integration mit Azure IoT Hub DPS

az iot dps enrollment-group create   --dps-name fss-dps   --enrollment-id fss-devices   --certificate-path manufacturing-ca.crt   --iot-hubs fss-production-hub.azure-devices.net

Werks-Provisioning-Prozess

Die Sicherheit Ihrer gesamten Geräteflotte hängt von der Integrität des Werks-Provisioning-Prozesses ab. Der private Schlüssel der Manufacturing CA darf das HSM niemals verlassen. Die Programmierstation, die Gerätezertifikate flasht, muss sich in einem isolierten Netzwerksegment ohne Internetzugang befinden. Jede Zertifikatsausstellung muss mit der Geräteseriennummer, dem Zertifikats-Thumbprint und einem Zeitstempel protokolliert werden — dieses Protokoll ist Ihr Audit-Trail für die Sicherheitslage der gesamten Geräteflotte.

Für die Fertigung großer Stückzahlen (1.000+ Einheiten pro Tag) ist automatisiertes Provisioning, das in die Funktionstest-Station integriert ist, der praktikable Ansatz: Die Testvorrichtung kommuniziert über eine sichere interne API mit dem HSM-Signierdienst, erzeugt einen CSR aus dem ATECC608B-Secure-Element, empfängt das signierte Zertifikat und schreibt es in den NVS des Geräts — alles in unter 5 Sekunden pro Gerät. Das Gerät hält zu keinem Zeitpunkt des Prozesses einen ungeschützten privaten Schlüssel.

Zertifikatswiderruf

X.509-Zertifikate können widerrufen werden, wenn ein Gerät kompromittiert, als gestohlen gemeldet oder außer Betrieb genommen wird. Azure IoT Hub führt eine Geräteregistrierung, in der einzelne Geräte deaktiviert werden können — was eine Verbindung selbst mit einem gültigen Zertifikat verhindert. Für einen Widerruf auf Flottenebene (wenn eine Charge von Geräten aus einem bestimmten Fertigungslauf als kompromittiert vermutet wird) kann die IoT-Hub-Konfiguration Geräte per Tag ansprechen und sie massenhaft deaktivieren.

Zertifikatssperrlisten (CRLs) sind der standardmäßige PKI-Mechanismus zur Verteilung von Widerrufsinformationen, aber sie sind für IoT-Geräte unpraktisch, die über längere Zeiträume offline sein können. Der Ansatz der IoT-Hub-Registrierung — Prüfung bei Verbindung statt CRL-Verteilung — ist für Geräte mit unterbrochener Konnektivität robuster.

Reaktion auf die Kompromittierung einer Intermediate CA

Wenn Ihre Manufacturing CA kompromittiert wird — ein unwahrscheinliches, aber katastrophales Ereignis — brauchen Sie einen Wiederherstellungsplan. Ihre Root CA (luftgetrennt, offline) kann ein neues Intermediate-CA-Zertifikat ausstellen und das kompromittierte widerrufen. Bereits im Feld befindliche Geräte behalten ihre gültigen Gerätezertifikate, die von der (nun widerrufenen) Intermediate CA signiert wurden. Dies erfordert, dass der IoT Hub der neuen Intermediate CA vertraut und einen Widerrufseintrag für die alte führt.

Dieses Szenario unterstreicht die Bedeutung einer dreistufigen Hierarchie gegenüber einer zweistufigen (bei der die Root CA Gerätezertifikate direkt signiert): Die Isolation der Root CA verhindert, dass eine Kompromittierung der Manufacturing CA Geräterückrufe erforderlich macht. Entwerfen Sie Ihre PKI-Hierarchie von Anfang an mit diesem Bedrohungsmodell im Blick.