E



 

 

 

SDO - Secure Device Onboarding

Oftmals auch ZTO – zero touch onboarding genannt.

Das IIoT (Industrial Internet of Things) stellt neue ernsthafte Sicherheitsherausforderungen dar, die sich mit zunehmendem Umfang und Ausmaß der IIoT-Systeme weiter verschärfen. IIoT-Geräte sind häufig bereits bei der Inbetriebnahme mit veralteter Software ausgestattet, bedürfen also eines Updates. Und sie müssen ihrer Aufgabe gemäß sich mit einem Server (Cloud) verbinden, um Daten auszutauschen. Dazu müssen sich die Geräte eindeutig kennzeichnen lassen und mit einem dedizierten Server verbinden können.

Aus Sicherheitsgründen gilt: die Verbindung zwischen Server und IIoT darf erst aufgebaut werden, wenn sich beide Seiten eindeutig authentifizieren konnten.

Eine Lösung hierfür ist das Secure Device Onboarding, auch Zero-Touch-Onboarding genannt. Hierdurch können IoT-Geräte mit Einstellungen konfiguriert werden, die in einem zentralen Server gespeichert sind. Sobald ein Gerät aktiv wird, verbindet es sich mit diesem Server und es werden seine Konfigurationseinstellungen automatisch installiert, ohne dass ein Techniker eingreifen muss. Dies ermöglicht den Betreibern eine wesentlich schnellere Onboarding-Methode und minimiert gleichzeitig die Angriffsfläche auf die Geräte.

Unabhängig von der verwendeten Methode des ZTO ist, mit Ausnahme des SDO Verfahrens (siehe weiter unten), immer ein Austausch von Informationen zwischen Produktion und Server basierter Anmeldung notwendig.

Eine sichere Verbindung zum (Cloud-) Server verlangt vom IIoT Gerät eine Authentifizierung am Cloud-Backend. Dies kann auf verschiedenen Verfahren aufsetzen.

  • Nur in seltenen Fällen wird eine "einfache" Authentifizierung mittels 128-Bit-Zahlen gemäß universally unique device identifiers (UUID) ausreichen. Auch die Kombination von UUID und einem Schlüsselpaar wird nur selten ausreichend sein. Besser geeignet ist hier eine Hardware-ID, die in die Firmware eingebrannt ist.

  • Meist wird die Verwendung eines HSM, TPM oder fTPM1 die bevorzugte Lösung2 darstellen, wahlweise nur mit Schlüsseln oder in Kombination mit X.509 Zertifikaten. Unter anderem setzen OPC UA sowie viele große Cloud Anbieter (beispielsweise MS Azure3) auf diesen Ansatz. Die Verwendung eines TPM (fTPM) hat zugleich noch den Vorteil, dass man einen Secure/Measured Boot durchführen kann, wodurch nicht nur eine Authentifizierung, sondern auch eine Attestation Abfrage durchführbar ist.

  • Alternativ könnte auch ein Challenge / Response Verfahren zum Einsatz kommen. Anfragen von Clients werden durch den Server mit einer zufälligen Byte-Sequenz, der sogenannten Challenge, und einem Identifier, das ist eine Zufallszahl, beantwortet. Der Client muss die Anforderung korrekt beantworten indem er sie mit einem Passwort, das Server und Client bekannt ist, verbindet und daraus mittels einer Hashfunktion einen Hashwert errechnet, den er an den Server zurückschickt. Dieser errechnet aus den Daten ebenfalls einen Hashwert und vergleicht ihn mit dem vom Client geschickten. Bei Übereinstimmung wird die Anfrage ausgeführt.

All diesen Lösungen ist gemein, dass sie eine eindeutige Zuordnung von Geräten, die rückverfolgbar bis auf den aktuellen Nutzer ist, erlauben. Hier setzt das Secure Device On-Board Verfahren an, das ursprünglich von Intel unter dem Namen EPID (Enhanced Privacy ID) entwickelt wurde. Seit Februar 2020 ist diese Lösung eine Open Source Lösung, die von der Linux Foundation4 gehosted wird. Das Onboarding muss hier über einen dedizierten Rendezvous Server laufen, dessen Code ebenfalls von Intel zur Verfügung gestellt wurde.
Der Vorteil dieses Ansatzes ist, neben dem verbesserten Schutz der Privatspäre, die Tatsache, dass zum Zeitpunkt der Produktion die Targetplattform (Cloud-Server) nicht bekannt sein muss.

Die wichtigsten Vorteile von Secure Device Onboard sind:

  • Ermöglicht Build-to-Plan Model - ODMs können identische IIoT Geräte in hohen Stückzahlen unter Verwendung eines standardisierten Fertigungsprozesses bauen. Reduziert Lagerbestände, Lieferzykluszeiten und Kosten.

  • SDO Late Binding - ermöglicht die Auswahl der Zielplattform des Geräts "spät" in der Lieferkette, beim ersten Einschalten.

  • It's Open - bedeutet, dass der Service und die Cloud unabhängig sind. Die Geräte werden bei der Installation an das gewünschte Ökosystem angebunden. Funktioniert mit bestehenden Cloud-Diensten, ersetzt diese aber nicht.

Das folgende Bild gibt einen Überblick über die Vertrauenskette bei diesem SDO Verfahren:

Beispiel einer IIoT Lieferkette und der dazugehörigen Schritte innerhalb des SDO Verfahren
Quelle: https://secure-device-onboard.github.io/docs/latest/

 

Gerne erarbeiten wir mit Ihnen zusammen die passende Lösung für Ihren Anwendungsfall.

Aus Azure Beschreibung:

Neben der Authentifizierung sind sicher signierte Fernbestätigungsdaten eine Schlüsselkomponente im End-to-End-Sicherheitspfad für jedes IoT-Gerät. Die Authentifizierung kann beweisen, dass ein Gerät ein echtes Azure-Sphere-Produkt ist, aber sie garantiert nicht, dass das Gerät einen zugelassenen und vertrauenswürdigen Software-Stack ausführt. Sicher signierte Fernauthentifizierungsdaten bescheinigen dem Azure Sphere Security Service, dass die Software des Geräts nicht kompromittiert ist. Nachdem die DAA die Identität und den Zustand des Geräts überprüft hat, stellt sie dem Gerät ein kurzlebiges Authentifizierungszertifikat aus.
Wenn ein Gerät noch kein Geräte-Authentifizierungszertifikat erhalten hat, verlangt der DAA-Dienst eine Fernbestätigung, bevor das Gerät und der Azure Sphere Security Service zusätzliche Nachrichten, Arbeiten oder andere Informationen austauschen.
Die Fernbestätigung (Beglaubigung), kombiniert mit der Authentifizierung, ist ein leistungsfähiges Werkzeug, um die Integrität und Authentizität jedes Geräts zu garantieren, das mit Azure IoT-Diensten kommuniziert.

 

1 Firmware TPM, besteht meist aus Trusted Zone (TZ) und einem dedizierten Speicher, oft einem eMMC mit einem replay protected memory block (RPMB)
2 TCG TPM v2.0 Provisioning Guidance, https://trustedcomputinggroup.org/resource/tcg-tpm-v2-0-provisioning-guidance/
3 https://azure.microsoft.com/de-de/resources/azure-sphere-device-authentication-and-attestation-service/
4 https://www.lfedge.org/projects/securedeviceonboard/
https://secure-device-onboard.github.io/docs/latest/