TOP
SSV Software Systems Register  Register
Log in to check your private messages  Log in to check your private messages
Startseite FAQ Search Mitglieder Profile  Log in 
SSV Support-Forum
Wie funktioniert SDU (Secure Device Update)?

 
Post new topic   Reply to topic    SSV-Forum Forum Index >>> RMG/941
<<< Previous topic - Next topic >>>  
Display posts from previous:   
Author Message
kdw



Joined: 05 May 2006
Posts: 1460

PostPosted: 14.12.2020, 21:33    Post subject: Wie funktioniert SDU (Secure Device Update)? Reply with quote

Hallo Forum.

Eine SDU-Anwendung soll eine Komponente (Device) hinter dem RMG/941 über eine IoT-Anbindung mit Software-, Konfigurations- und Machine-Learning-Modell-Updates versorgen. Dabei liegt der Schwerpunkt, neben der Remote-Update-Funktion, im Bereich der IT-Sicherheit. Um eine dem Stand der Technik entsprechende Sicherheit zu gewährleisten, nutzt SDU eine Public-Key-Infrastruktur (PKI) für digitale Signaturen mit privaten und öffentlichen Schlüsseln, Zertifikaten und einer Sperrliste (Blacklist).



Der gesamte Update-Prozess wurde für den vollautomatischen Betrieb entwickelt und lässt sich in Bezug auf die Device-Anzahl nahezu beliebig skalieren. Die Abbildung zeigt die wichtigsten SDU-Funktionsbausteine.

1: SDU Server. Dieser Serverprozess läuft im Internet und dient für die Weitergabe der Updates als Bindeglied zwischen dem PC des Softwareentwickler (bzw. zuständigen Maintainer) und der Device hinter dem RMG/941. Ein SDU Server wird als Docker Container Image ausgeliefert und ist daher nahezu in jeder geeigneten Docker-Laufzeitumgebung ausführbar.

2: RMG/941 mit SDU Agent und SDU Gateway Update Client (SDU GUC). Der SDU GUC ist für die Kommunikation mit dem SDU Server zuständig. Er sorgt dafür, dass eine gültige Update-Datei bei Bedarf vom Server zum RMG/941 heruntergeladen und dem SDU Agent zur Verfügung gestellt wird. Ein anwendungsbezogener SDU Agent übernimmt die Kommunikation mit der jeweiligen Device hinter dem RMG/941, z. B. um die Update-Datei an die Device zu übertragen. Der SDU Agent muss daher projektspezifisch an das Protokoll der jeweiligen Device angepasst werden. Beide Softwarekomponenten werden in der Regel von SSV werksseitig vorinstalliert und für eine bestimmte Anwendung konfiguriert.

3: Entwickler-PC bzw. Maintainer Workstation (MTWS) mit SDU Signing Tool und SDU Maintainer Update Client (SDU MUC). Mit dem Signing Tool werden die für den Update erforderlichen einzelnen Dateien auf dem PC bzw. der MTWS zu einer SDU-Update-Datei zusammengefügt und mit einer digitalen Unterschrift (digital Signature) versehen. Mit Hilfe des SDU MUC wird diese signierte Datei dann zum SDU Server hochgeladen. Sowohl das SDU Signing Tool als auch der SDU Maintainer Update Client wurden als Electron-Cross-Plattform-Desktop-Anwendung entwickelt. Sie lassen sich auf Linux-, macOS- und Windows-Rechnern ausführen.

Device: Das eigentliche Zielsystem für den Update. Es ist per CAN, Modbus (RTU, TCP), Nahbereichs-Funkschnittstelle usw. mit dem RMG/941 verbunden. Über den RMG/941-SDU-Agent wurde das Gateway an das jeweilige Update-Protokoll der Device angepasst.

Die Kommunikation mit dem SDU Server erfolgt über das SDU Server API. Eine Beschreibung der aktuellen API-Version ist jeweils unter

https://ssv-embedded.github.io/SDU-API/

VG KDW


Last edited by kdw on 12.11.2021, 17:59; edited 2 times in total
Back to top
View user's profile Send private message
kdw



Joined: 05 May 2006
Posts: 1460

PostPosted: 16.12.2020, 18:42    Post subject: Wird die NISTIR 8259 erfüllt? Reply with quote

Hallo Forum.

Im Bereich der Cybersecurity für IoT-Devices und Anwendungen gibt es inzwischen verschiedene Standards und Normen. Insofern erhalten wir immer wieder Fragen, ob wir mit unserem SDU-Konzept die eine oder andere Vorgabe erfüllen, z. B. die NISTIR 8259 „Foundational Cybersecurity Activities for IoT Device Manufacturers“ aus Mai 2020. Aktueller Download-Link https://nvlpubs.nist.gov/nistpubs/ir/2020/NIST.IR.8259.pdf

In diesem Dokument findet man unter „4.2.4 Software Updates“ die folgenden sechs Punkte mit den hier folgenden Fragestellungen:

1. Werden Software-Updates zur Verfügung gestellt? Wenn ja, wann werden sie veröffentlicht? Wenn Sie beispielsweise wissen, ob Aktualisierungen nach einem festgelegten Zeitplan oder sporadisch bereitgestellt werden, können Kunden deren Anwendung besser planen.

2. Aus welchen Gründen werden Updates veröffentlicht? Beispiele hierfür sind Bugfixes für fehlerhafte Software und die Korrektur einer zuvor unbekannten Sicherheitsschwachstelle in einem Kommunikationsprotokoll oder einer Systembibliothek.

3. Wie werden Updates zur Verfügung gestellt oder geliefert? Gibt es hinsichtlich der Update-Verfügbarkeit gezielte Benachrichtigungen vom Anbieter an die Nutzer? Beispielsweise können Kunden den Einsatz eines Software-Updates besser planen, wenn sie wissen, dass ab einem bestimmten Termin ein Update in einem Portal zur Verfügung steht. Kunden profitieren von einer Benachrichtigung auch dann, wenn der gesamte Update-Prozess vollständig automatisch abläuft und der Kunden selbst keinerlei manuelle Aktivitäten durchführen muss.

4. Welches Unternehmen bzw. welche Instanz ist für die Durchführung von Aktualisierungen verantwortlich (beispielsweise Kunde, Hersteller, Dritter)? Kann der Kunde selbst bestimmen, wer verantwortlich ist (z. B. Updates werden immer automatisch vom Hersteller durchgeführt)? Für Kunden ist es hilfreich, wenn auch ein Dritter (Third Party als Serviceanbieter) Updates zur Verfügung stellen kann und die Verantwortlichkeiten den Erfordernissen entsprechend geregelt werden können.

5. Wie können Kunden die Updates selbst überprüfen und authentifizieren? Beispiele sind der kryptografische Hash-Vergleich, die Validierung der Codesignatur und das Vertrauen in die vom Hersteller bereitgestellte Software, die automatisch die Überprüfung und Authentifizierung von Updates durchführt.

6. Welche Informationen sollten bei jedem einzelnen Update mitgeteilt werden? Beispiele sind die Art des Updates (z. B. Korrekturen von Fehlern, geänderte oder neue Funktionen) und mögliche Auswirkungen einer Update-Installation auf die vorhandenen Konfigurationseinstellungen eines Kunden.

Diese Fragestellungen sind in unsere SDU-Entwicklung eingeflossen, weil wir uns hinsichtlich der IoT-Cybersecurity seit einiger Zeit u.a. auch an dem entsprechenden NIST-Dokument orientieren. Insofern werden wir zu diesen Fragen nach und nach auch passende Antworten liefern, aus denen erkennbar wird, wie die jeweilige NIST-Fragestellung innerhalb von SDU behandelt wird.

VG KDW

P.S.: Siehe auch https://www.nist.gov/programs-projects/nist-cybersecurity-iot-program

P.S: Nach Durchsicht des NIST-Dokuments gibt es eine Frage, die sich jeder Operation Technology (OT) -Technikverantwortliche eigentlich stellen müsste, z. B.: Wie gehen mein IO-Link-Sensoriklieferant, mein Steuerungsanbieter, der Frequenzumrichter- und Edge-Gateway-Hersteller sowie all die anderen Device-Hersteller eigentlich mit Software-Updates um, damit wir in unserer Smart Factory nicht die gleichen Probleme wie in der IoT-Welt bekommen? (unzählige Devices im Einsatz, die bekannte Sicherheitslücken aufweisen – z. B. fehlerhafte TCP/IP-Protokollstacks) Die Antworten sind häufig nicht zufriedenstellend.
Back to top
View user's profile Send private message
kdw



Joined: 05 May 2006
Posts: 1460

PostPosted: 26.01.2021, 06:58    Post subject: SDU Server ... Reply with quote

Hallo Forum.

Die zentrale Funktionseinheit einer SDU-Anwendung ist der SDU Server. Ein SDU Server wird als Docker Container Image ausgeliefert und ist daher nahezu in jeder geeigneten Docker-Laufzeitumgebung ausführbar.



Die Kommunikation mit dem SDU Server erfolgt über das SDU Server API. Eine Beschreibung der aktuellen API-Version ist jeweils unter

https://ssv-embedded.github.io/SDU-API/

zu finden. Das SDU Server API ist ein sogenanntes REST-API. Es nutzt das HTTP(S)-Protokoll. Mit Hilfe der jeweiligen API-Funktionen überträgt die Maintainer Workstation ein neues Update zum SDU Server. Über die entsprechenden API-Funktionen kann ein SDU Gateway des Weiteren feststellen, ob ein neues Update vorliegt und – falls dies der Fall ist – die entsprechende Update-Datei als BLOB (Binary Large Object) von Server in das Gateway-Dateisystem herunterladen.

VG KDW


Last edited by kdw on 12.11.2021, 17:57; edited 1 time in total
Back to top
View user's profile Send private message
kdw



Joined: 05 May 2006
Posts: 1460

PostPosted: 02.02.2021, 07:55    Post subject: BLOB und Manifest … Reply with quote

Hallo Forum.

Der Austausch von Updates zwischen Maintainer Workstation (MTWS) und SDU Gateway wird durch eine Public Key Infrastructure (PKI) abgesichert. Zu dieser PKI gehören private und öffentliche Schlüssel (Public Keys, Private Keys) sowie X.509-Zertifikate. Für jedes einzelne Update werden mit Hilfe des SDU Signing Tools auf der MTWS je eine BLOB- und Manifest-Datei erzeugt (BLOB = Binary Large Object).

Im BLOB sind alle zu einem Update gehörenden Dateien zu einem einzigen binären Objekt zusammenfasst. Das Mainfest beinhaltet neben Produktname und Versionsnummer einen zum BLOB gehörenden Hashwert, der vom SDU Signing Tool über eine spezielle Hashfunktion erzeugt wurde. Des Weiteren sind in der Manifest-Datei zusätzliche zur PKI gehörende Informationen gespeichert, damit ein SDU Gateway eine Gültigkeitsprüfung für den BLOB durchführen kann.

VG KDW
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    SSV-Forum Forum Index >>> RMG/941 All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

SSV Software Systems GmbH

Dünenweg 5
30419 Hannover

Fon: +49(0)511  ·  40 000-0
Fax: +49(0)511  ·  40 000-40

sales@ssv-embedded.de


Impressum    ·    Datenschutz    ·    AGB

© 2023 SSV SOFTWARE SYSTEMS GmbH. Alle Rechte vorbehalten.

ISO 9001:2015