Neuentwicklung MLS/100EV ...

[kdw]

Technische Daten MLS/100EV

- 2x interner mikroBUS™-Steckplatz für Sensorik-Erweiterungsmodule
- 1x interner Qwicc-Steckverbinder für I2C-basierte Erweiterungen
- 1x LM75A Digitaler Temperatursensor
- RFSoC-basiertes LTE-M-Mobilfunkmodem (vorzertifiziert)
- Frequenzbereich 700 - 2.200 MHz
- Unterstützung der internationalen LTE-M-Bänder B1 - B5, B8, B12, B13, B14, B17 - B20, B25, B26, B28, B66
- Max. Datenrate LTE-M: 300 Kbps Downlink / 375 kbps Uplink
- 3GPP AT-Kommandos gemäß TS 27.007 plus Erweiterungen
- IoT-Protokollstack mit (D)TLS-Support für Internet-Funkverbindungen
- Interner nanoSIM-Kartenhalter (Fourth Form Factor 4FF)
- Mobile Virtual Network Operator (MVNO)-SIM-Karte mit IoT-Datenplan vorinstalliert (weltweit nutzbar)
- Arm Cortex M33 Application MCU zur KI-basierten Sensordatenanalyse
-1 Mbytes Flash, 256 Kbytes RAM
- Embedded LTE-M-Antenne im Gehäuseinneren
- USB-Steckverbinder zur Spannungsversorgung und Datenkommunikation
- Firmware Updates und Konfigurationseinstellungen per USB
- Optionale Firmware-Varianten für den Normal- und Testbed-Betrieb
- Gehäuseabmessungen 109,96 x 57,04 x 27mm, Haube 83,77 x 54,57mm
- Mehrfarbige Status-LED (RGB LED)
- Interner Debug-Steckverbinder plus Tasten für DFU-Mode
- Maschinenmontage durch Aufkleben auf glatte Oberflächen (alternativ Montage per Schraubverbindung oder Magnethalterung)

Use Case-Übersicht

Für den MLS/100EV existieren einige vorentwickelte Beispielanwendungen (Use Cases). Zu jedem Use Case gehört jeweils ein binäres Firmware-Image. Hier eine Übersicht:

1. IMU Data Use Case: Erfassen und visualisieren von IMU-Daten, um eine „Maschinenzustandsdatenperspektive“ zu entwickeln. Siehe https://github.com/SSV-embedded/MLS100EV.



2. LTE-M Telemetry Data Use Case: Periodischer Versand von Telemetriedaten, um die Qualität der LTE-M-Funkabdeckung für einen bestimmten Standort zu bewerten. Siehe https://github.com/SSV-embedded/MLS100EV/tree/main/LTE-Explorer.



3. ML Model Use Case: Erfassen unterschiedlicher IMU-Zustandsdaten mit der Firmware für den 1. Use Case. Erzeugen eines Klassifizierungs-ML-Modells aus den erfassten Daten. Erstellen eines binäres Firmware-Image mit einem Inferenz-Beispiel für die Echtzeit-Zustandsklassifizierung. Siehe https://github.com/SSV-embedded/MLS100EV/tree/main/Machine_Learning.



Siehe auch (Q & A) https://github.com/SSV-embedded/MLS100EV/blob/main/FAQ.md.

VG KDW

[kdw]

Hallo Forum.

"RED DA" steht für "Radio Equipment Directive Delegated Act 2022/30" [1]. Es ist eine Erweiterung der EU-Funkanlagenrichtlinie (RED) 2014/53/EU, die ab dem 1. August 2025 verbindliche Cybersicherheitsanforderungen für drahtlose Geräte, die auf dem EU-Markt verkauft werden, einführt. Sie gilt somit auch für den MLS/100EV.

Diese Verordnung zielt darauf ab, die Sicherheit von Geräten zu verbessern, die mit dem Internet verbunden sind, und die Anwender vor potenziellen Risiken zu schützen, die mit der Nutzung solcher Geräte verbunden sind.

Genauer gesagt, bezieht sich RED DA auf Artikel 3.3 der RED-Richtlinie und aktiviert die Absätze (d), (e) und (f), welche die folgenden Aspekte der Cybersicherheit betreffen:

• Artikel 3.3(d): Verhindert, dass Funkanlagen Netzwerke beschädigen, Netzwerkressourcen missbrauchen oder die Dienstqualität beeinträchtigen. Die Umsetzungsdetails sind in der EN 18031-1 zu finden.

• Artikel 3.3(e): Stellt sicher, dass personenbezogene Daten und die Privatsphäre geschützt werden. Die jeweiligen Umsetzungsdetails sind in der EN 18031-2 zu finden.

• Artikel 3.3(f): Verhindert finanzielle Schäden, die durch Betrug im Zusammenhang mit Funkanlagen entstehen können. Die erforderlichen Umsetzungsdetails sind in der EN 18031-3 zu finden.

Für Hersteller bedeutet dies, dass sie ihre Produkte so gestalten müssen, dass sie diese Anforderungen erfüllen, um sie ab dem 1. August 2025 legal auf dem EU-Markt anbieten zu können. Dazu gehören in der Regel umfassende Sicherheitsbewertungen und Konformitätsprüfungen, um sicherzustellen, dass die Geräte den neuen Vorschriften entsprechen.

Zusammenfassend lässt sich sagen, dass der RED DA ein wichtiger Schritt ist, um die Cybersicherheit von drahtlosen Geräten zu erhöhen und das Vertrauen der Anwender in diese Geräte zu stärken.

VG KDW

Siehe [1]: https://eur-lex.europa.eu/legal-content/DE/TXT/PDF/?uri=CELEX:32022R0030

Auch das BSI hat sich zum Thema geäußert. Siehe https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2025/250130_RED_Cybersicherheit.html

[kdw]

Hallo Forum.

Wir wollen den Anwendern eine einfache, aber gleichzeitig auch sehr sichere Datenverbindung zur Verfügung stellen, die in Bezug auf den Datendurchsatz auch perfekt zu LTE-M passt. Ein per MQTT übertragener Sensormesswert ist in der Regel ein besonders schützenswerter Datenbaustein (Security Asset). In vielen Anwendungen muss man sich schließlich auf die Authentizität und Integrität der Sensordaten verlassen können. Daher kommt immer auch TLS zum Einsatz. Dabei werden vom MLS/100EV unterschiedliche TLS-Optionen unterstützt. MQTT per TLS ist für uns des Weiteren auch ein wichtiger Funktionsbaustein, um die RED DA- und EN 18031-Konformität zu gewährleisten.

TLS-Verbindungen zwischen einem MQTT-Client und MQTT-Broker als Server lassen sich mit oder ohne Zertifikatsprüfung (Client- oder Serverauthentifizierung) betreiben. Im einfachsten Fall wird ein Zertifikat nur für eine verschlüsselte Verbindung zwischen beiden Systemen genutzt. Eine spezielle Zertifikatsprüfung erfolgt in diesem Fall nicht. Die tatsächliche Identität der beteiligten Parteien bleibt somit ungeprüft. Dadurch existiert hinsichtlich gefälschter Verbindungen ein erhebliches Sicherheitsrisiko: ein möglicher Cyberangreifer kann sich als Server ausgeben und Daten vom Client empfangen. Insofern sollte zumindest der Client das vom Server im Rahmen des TLS-Verbindungsaufbaus erhaltene Zertifikat prüfen (und zwar nicht nur das Gültigkeitsdatum), um eine vollständige Serverauthentifizierung durchzuführen. Nur nach einer erfolgreichen Authentifizierung übermittelt der Client die Payload-Daten an den Server. Zusätzlich kann auch der Server das Zertifikat des Clients anfordern und eine Clientauthentifizierung vornehmen (TLS-Client-Auth). Erst nach dieser zweiten erfolgreichen Zertifikatsprüfung wurde die Identität beider Kommunikationspartner vollumfänglich geprüft (man spricht dann auch von einer „mutual TLS-Verbindung, mTLS“). Eine in beide Richtungen sichere und vertrauenswürdige Verbindung (also die Authentizität, Integrität und Vertraulichkeit der MQTT-basierten Sensordaten und der Antworten) ist also gewährleistet.



Um die RED DA-Konformität einer „MQTT per TLS und LTE-M“-Kommunikationsbeziehung zu gewährleisten, sollte immer ein entsprechendes Datenflussdiagramm erstellt und eine dazu passende STRIDE-Bedrohungsanalyse durchgeführt werden (siehe Abbildung).

Durch den Datenfluss wird deutlich, dass ein Interface existiert – aus Sicht der EN 18031 eine gemeinsame Grenze, über die Entitäten bestimmte Informationen austauschen (siehe [E.Info.SCM-1.NetworkInterface.Radio] in der Abbildung). Zu einem Interface und den damit verbundenen Network Assets gehören des Weiteren auch Security Assets. Darunter versteht die EN 18031 sensible oder vertrauliche Sicherheitsparameter bzw. Sicherheitsfunktionen.

Da wir es durch LTE-M in diesem Beispiel mit einer Wireless-Verbindung zu tun haben, sind auf jeden Fall die elementaren Gefahren (Threats) durch Jamming (Störung des Funksignals, z. B. durch einen Störsender) und Spoofing (Vortäuschen oder Fälschen, z. B. Aussenden gefälschter Sensordaten) zu beachten. Die folgende Tabelle beinhaltet die zur Abbildung passenden STRIDE-Bedrohungsanalyse.



Durch die STRIDE-Bedrohungsanalyse wird deutlich, dass in sensiblen Anwendungen TLS schon mit Server- und Client-Authentifizierung sowie in Kombination mit einer signierten Firmware genutzt werden sollte. Dadurch lässt sich bestmöglich sicherstellen, dass die Sensormesswerte an den „richtigen“ MQTT Broker übermittelt werden und im Rahmen der weiteren Nutzung durch andere Anwendungen auch als 100% vertrauenswürdig einzustufen sind. Erfolgreiches Spoofing wird durch diese Gegenmaßnahmen weitestgehend ausgeschlossen.

In Bezug auf Denial of Service durch Jamming sind aktive Gegenmaßnahmen in der „MQTT per TLS und LTE-M“-Kommunikationsbeziehung praktisch unmöglich. Die jeweilige Firmware sollte erkennen, dass die MQTT-Übertragung der Sensormesswerte an den Broker nicht möglich ist, weil der entsprechende Server überhaupt nicht erreichbar ist und auch das LTE-M-Funknetz nicht zur Verfügung steht. Im Rahmen einer erfolgreichen Fehlerbehandlung muss zunächst wieder eine „Einwahl“ in das Funknetz erfolgen und eine Verbindung zum MQTT Broker hergestellt werden, um den letzten Messwert erfolgreich zu übermitteln.

VG KDW

Siehe hierzu auch https://ssv-comm.de/forum/dokumente/_Risk-Assessment-Beispiel-2025_1.pdf

[kdw]

Hallo Forum.

Drei wichtige Fragen in Zusammenhang mit der RED DA und der EN 1803-1 Compilance sind „Was ist ein Network Asset?“, „Was ist ein Security Asset?“ sowie „Wie sieht das Zusammenspiel aus?“. Hier ein paar Antworten:

Was ist ein Network Asset? Ein EN 18031-1 Network Asset besteht aus Network Functions und Network Function Configuration: also insgesamt aus Softwarebausteinen (Protokoll-Stacks, Client- und Serverfunktionen) sowie den erforderlichen Konfigurationsdaten für den Betrieb dieser Softwarebausteine.

Was ist ein Security Asset? Ein EN 18031-1 Security Asset besteht aus Security Functions und Security Parametern: also insgesamt aus Funktionen, Daten und Zuständen. Der Verlust, die Manipulation oder die Offenlegung eines Security Assets wäre ein sicherheitskritischer Vorfall, weil der Schutz des jeweiligen Netzwerks nicht mehr gewährleistet wäre oder aber Netzwerkressourcen bzw. Funktionen missbräuchlich genutzt werden könnten.

Die folgende Abbildung visualisiert das Zusammenspiel zwischen EN 18031-1 Network Assets und Security Assets: Zu einem Network Asset gehören die Softwarefunktionen und Konfigurationsdaten, um mit einem externen System oder einem Benutzer zu kommunizieren. Security Assets unterstützen Network Assets bei der Umsetzung der erforderlichen Security-Anforderungen für die jeweiligen Kommunikationsverbindungen, indem sie die erforderlichen Security-Bausteine zur Verfügung stellen.



Beispiel: TLS-basierte Kommunikation eines MLS/100EV mit einem MQTT Broker. Der MQTT Client plus die erforderlichen Daten (z. B. Broker URL, MQTT-Topic-Namen, evtl. Anmeldedaten) für die Kommunikationsverbindung zu einem MQTT Broker im Internet bilden ein EN 18031-1 Network Asset. Für eine TLS-basierte Verbindung benötigt der MQTT-Client-Code des MLS/100EV zusätzliche TLS-Funktionen, die üblicherweise in einer Kryptobibliothek (Cryptographic Library) zusammengefasst werden. Die TLS-Funktionen einer solchen Bibliothek werden durch Parameter an einen bestimmten Anwendungsfall angepasst. Dazu gehören das jeweilige Schlüsselmaterial bzw. die jeweiligen Zertifikate, um beispielsweise die individuellen verschlüsselten Verbindungen zu realisieren und eine MQTT-Broker-Authentifizierung durchzuführen.

VG KDW