embedded world 2024 ...

[kdw]

Zu unserem Schwerpunktthema „Wireless IoT Retrofit“ präsentieren wir auf der embedded world 2024 auf unserem Stand in Halle 3, 633A drei Beispiele:

1. BoM-Kostenoptimierung und Produzierbarkeit (Producibility): Die erste Produktversion einer IoT-Baugruppe im Umfeld von Sensordaten und Cloudverbindungen wird oft direkt aus den Proof of Concept-Prototypen abgeleitet. Serientauglich ist diese Produktvarinate in der Regel nicht. Wir zeigen Ihnen gerne ein eDNP/8331-basiertes Problemlösungsbeispiel aus der Praxis.

2. LoRaWAN mit OTA Device Updates: Im 868 MHz-Frequenzbereich gibt es verschiedene Reglementierungen. Ein davon ist der sogenannte Duty Cycle. Gemeint ist damit eine gesetzlich geregelte Begrenzung der Sendezeit einzelner Geräte. Dadurch lassen sich nicht ohne weiteres Firmware-Updates von einem Gateway zu den Sensoren übertragen. Mit unserem universellen Wireless IoT Gateway-Konzept haben wir nun auch für diese Herausforderung eine Lösung.

3. Wireless IoT Security Intrusion Detection System (IDS): Komponenten einer IoT-Lösung sind ein potenzielles Ziel mehrstufiger Cyberangriffe (sogenannte Advanced Persistent Threats [APTs]). Da IoT-Anwendungen einen dezentralen Charakter aufweisen, wird aus unserer Sicht eine automatische Angriffserkennung in den Endpunkten benötigt. Wir zeigen ein Beispiel, wie sich so etwas KI-basiert realisieren lässt.

Beitrag zur embedded world conference

Wir beteiligen uns auch in diesem Jahr wieder mit einem Beitrag an der embedded world conference, siehe den Vortrag von Jürgen Fitschen in Session 4.7 am 11.04.2024, 10:00 – 10:30 Uhr unter https://events.weka-fachmedien.de/embedded-world-conference/program. Hier einige Details zunTitel und Abstract:

Insecure Passwords? MFA Methods for Embedded Systems as Problem Solvers!
Authorizing users based upon username and password is common practice utilized by all sorts of machines and applications ranging from small embedded devices to large-scale cloud platforms. But this authentication method comes with the inherent risk of identity theft: Humans tend to select weak passwords that can be guessed by attackers easily, passwords are reused among different applications, passwords are shared with other users, and phishing attacks are getting more and more sophisticated and difficult to detect even for experienced users.

This threat has been recognized by politics and has influenced legislation. The EU directive NIS-2 and the upcoming Cyber Resilience Act (CRA) identify password-based authentication as insecure and demand multi-factor authentication (MFA).

The lecture presents secure and yet easy-to-use techniques for user authentication that mitigate the mentioned attack vectors. We make use of arising technologies like FIDO2 and utilize tools like the programming language Rust in the context of embedded devices. The lecture will conclude with a quick demo showcasing a compliant multi-factor authentication.

[kdw]

Linux-basierte Maker-Baugruppen lassen sich durch Zusatzmodule beispielsweise mit einer 868 MHz-Funkschnittstelle für Sensordatenübertragungen sowie einem USB-basierten Mobilfunkmodem als IoT-Cloudverbindung erweitern. Die Software dafür lässt sich aus verschiedenen Open-Source-Quellen zusammenstellen, so dass nur ein relativ überschaubarer Anteil an eigener Firmware in Python zu entwickeln ist. Die Fragestellung „Eignen sich die Bausteine für ein professionelles Serienprodukt?“ wird in den meisten Fällen allerdings nicht mit einem klaren „Ja“ beantwortet.



Die folgende Abbildung zeigt eine Problemlösung aus der Praxis: Die beiden externen Zusatzmodule für die 868 MHz-Funkschnittstelle (Wireless Tx/Rx #1) und 4G-WWAN-Anbindung (Wireless Tx/Rx #2) wurden zusammen mit den Schaltungskomponenten des virtuellen System-on-Module (vSoM) eDNP/8331 auf eine gemeinsame 6-Lagen-Leiterplatte integriert und an das jeweilige Gehäuse angepasst. Der Protokoll-Stack des vSoM-Linux-Betriebssystems unterstützt beide Wireless-Schnittstellen in Bezug auf die jeweils erforderliche Connectivity und Cybersecurity.



Siehe hierzu auch https://ssv-comm.de/forum/dokumente/_eDNP8331-Overview-2024_1.pdf

[kdw]

Hierzu haben wir eine User Story mit dem Thema „Betriebskostenoptimierung“ vorbereitet: Auf einem größeren Betriebsgelände wurden vor einigen Jahren an verschiedenen Standorten eine größere Anzahl diverser batteriebetriebener Sensoren zur Datenerfassung installiert, um eine zentrale IoT-Monitoringanwendung mit Daten zu versorgen. Auf Grund der weitläufigen Ausdehnung und einer speziellen Anforderung (es müssen mindestens ein- bis zweimal pro Woche neue Konfigurationseinstellungen als OTA-Updates an die Sensorik übertragen werden) wurden die Sensoren mit Mobilfunkmodems und SIM-Karten ausgestattet.

Die Monitoringanwendung selbst wurde in der Cloud eines marktführenden Anbieters realisiert. Auf Grund der nicht unerheblichen Betriebskosten und einiger Sicherheitsbedenken im Zusammenhang mit der Cloud und der damit verbundenen Internetnutzung ist nun ein Retrofit geplant. Die Monitoring-Applikation soll On-Premises in der eigenen IT laufen. Auf die Mobilfunknetznutzung und die SIM-Karten wird in Zukunft verzichtet. Stattdessen soll ein kostenlos nutzbares Industrial Scientific Medial (ISM)-Frequenzband genutzt werden. Um eine möglichst große Reichweite zwischen den Sensoren und Gateways sowie eine deutlich längere Batterielebensdauer der Sensoren zu ermöglichen, soll ein Sub-Gigahertz-Band genutzt werden.



Mittels LoRaWAN lassen sich die Betriebskosten von Mobilfunk-basierten IoT-Anwendungen mit batteriebetriebenen Sensoren deutlich senken. Ein solcher Retrofit bewirkt auch einen Zugewinn an Cybersicherheit, wenn sensorseitig auf die Nutzung des öffentlichen Internet verzichtet wird. Eine technische Herausforderung sind allerdings die gesetzlichen Sendezeitbegrenzungen (Duty Cycle), besonders bei OTA-Updates und die damit verbundene 1-auf-n-Topologie. Aber auch dieses Problem ist in den meisten Anwendungen mit einer speziellen Technik lösbar.

[kdw]

Hierzu ein Beispiel zum Thema „Die Cyberangriffserkennung gehört in den Endpunkt“: Der Endpunkt einer IoT-Applikation sollte in der Lage sein, einen möglichen Cyberangriff zu erkennen. Dazu gehört zum einen, dass Backend-Anwendungen beispielsweise manipulierte Daten sowie Frontend-Softwarefunktionen unzulässige Nutzerzugriffe erkennen sollen. Es ist zum anderen aber auch darauf zu achten, dass die sensorseitigen Embedded Systeme sich durch einen Cyberangriff nicht unbemerkt in ein Botnet integrieren lassen. Mit Hilfe eines KI-basierten Intrusion Detection System (IDS) lässt sich so etwas verhindern. Ein solches IDS hat in der Regel zwei Betriebsarten: Einen Lern- und einen Inferenzmodus. Im Lernmodus werden typische Verkehrsdaten gesammelt, um daraus Machine Learning (ML)-Modelle zu bauen. Im Inferenzmode werden Verkehrsdatensegmente aus der Echtzeitkommunikation ausgewählter Netzwerkschnittstellen mit Hilfe des ML-Modells klassifiziert, um Anomalien zu erkennen. Wir zeigen Ihnen gerne die Details einer solchen Angriffserkennung plus den Workflow für die vorbereitende Data Exploration-Phase zu den jeweiligen Diensten in einem Subnetzwerk.



(1) Das zu schützende Netzwerksegment bzw. Subnetz wird hinsichtlich der physikalischen und logischen Verbindungen analysiert. Dabei wird u. a. festgelegt, welche Baugruppe sich für den IDS-Einsatz eignet. Für diesen ersten Schritt ist in der Regel ein umfassendes Domainwissen erforderlich, besonders hinsichtlich der genutzten Kommunikationsprotokolle. Falls erforderlich, sollte ein Experte für IoT- bzw. OT-Kommunikation hinzugezogen werden.

(2) Es wird ein einfaches Datenflussdiagram (DFD) erstellt, in dem die Entitäten mit eigener IP-Adresse und deren Client-Server-Beziehungen für die TCP- und UDP-basierte Kommunikation innerhalb des Subnetzes erkennbar sind. Den Mittelpunkt im DFD bildet die Baugruppe mit dem IDS.

(3) Abschließend werden die Kommunikationsbeziehungen in einer Whitelist zusammengefasst. Diese Liste beschreibt hinsichtlich der existierenden IT-Adressen- bzw. Adressbereiche sowie der TCP- und UDP-Portnummern die vorgesehenen Kommunikationsbeziehungen. Mit Hilfe der Whitelist lassen sich die erforderlichen Verkehrsdaten für die ML-Modellbildung relativ einfach vorbereiten.

[kdw]

Hallo Forum.

Die meisten erfolgreichen IoT-Projekte beginnen mit einer Proof-of-Concept (PoC)-Phase, zu der auch Feldtests gehören, um den Anwendernutzen zu optimieren. Für solche Aktivitäten können wir mit Hilfe eines Baukastensystems sehr schnell professionelle Prototypen mit CE-Zertifizierung liefern.



(1) Linux-basierte virtuelle System-on-Chip (vSoC) stehen als 40-polige Steckmodule zur Verfügung. Um sie für Entwicklungen zu nutzen, werden des Weiteren verschiedene Evaluierungs-Boards mit unterschiedlichen Peripheriefunktionen (z. B. 4G-Modems) angeboten.

(2) Erweiterungen, beispielsweise eine 868 MHz- oder 2,4 GHZ-Funkschnittstelle mit IEEE 802.15.4 und 6LoWPAN-Protokollstack lassen sich als Bibliotheksfunktionen für Schaltungsentwickler in eigene Projekte einbinden, um innerhalb von wenigen Tagen eine Erweiterungsbaugruppe für PoC-Prototypen zu erstellen.

(3) Die erforderlichen vSoC-Firmware-Funktionen zur Software-Integration der zusätzlichen I/O-Funktionen (also beispielsweise der IEEE 802.15.4- und 6LoWPAN-Protokoll-Stack) befinden sich in einem Repository und werden in das vSoM-Boot Image eingebunden.

(4) Sowohl für die vSoM-Evaluierungsbaugruppen als auch eine neu entwickelte I/O-Erweiterung steht ein modulares Standard-Gehäusekonzept zur Verfügung. Die einzelnen Gehäuse sind für industrielle Anwendungsumgebungen vorgesehen und lassen sich auf 35mm-DIN-Hutschinen montieren.

VG KDW