Sicherer Datenaustausch über Narrowband-IoT dank DTLS (Teil 3)

Während sich der erste Teil dieser Blog-Serie mit der Technologie Narrowband-IoT beschäftigte und ich im zweiten Teil auf die Besonderheiten der Kommunikation auf Basis von MQTT-SN über NB-IoT eingegangen bin, steht im dritten und letzten Teil der Serie der für das Internet der Dinge wichtige Aspekt der Sicherheit im Mittelpunkt.

Verschlüsselung durch DTLS

Über die Tarife der gängigen Mobilfunkanbieter ist es zwar möglich, eine Verbindung zwischen Endgerät und Cloud-Infrastruktur über VPN herzustellen. Eine echte Ende-zu-Ende-Verschlüsselung liegt in diesem Fall jedoch nicht vor. Die VPN-Verbindung kann zwar zum Beispiel über IPSec verschlüsselt werden, die über das VPN übertragenen Daten jedoch nicht. Der Mobilfunkbetreiber (Access Point) hat somit theoretisch die Möglichkeit, die Daten einzusehen und zu manipulieren.

Je nach Anwendungsfall, etwa wenn im Bereich Smart Metering die Unverfälschbarkeit und Vertraulichkeit der übertragenen Daten sichergestellt werden muss, ist eine solche nicht Ende-zu-Ende-verschlüsselte Übertragung keine Option.

Wie bereits im letzten Blog-Beitrag erwähnt, empfiehlt es sich für die Cloud-Kommunikation via Narrowband-IoT UDP-basierte Kommunikationsprotokolle zu nutzen.

Während für TCP-basierte Verbindungen mit Transport Layer Security (TLS) ein weit verbreitetes Verschlüsselungsprotokoll zur Verfügung steht, muss für UDP auf das an TCP angelehnte Protokoll Datagram Transport Layer Security (DTLS) zurückgegriffen werden. Die Zahl der DTLS-Implementierungen, insbesondere auf Serverseite, ist jedoch im Vergleich zu den TLS-Implementierungen überschaubar.

Trotzdem bietet DTLS eine Vielzahl von Algorithmen, die zur Verschlüsselung eingesetzt werden können. Unter anderem werden auch Pre-Shared-Key-Verfahren (kurz: PSK) unterstützt. Dabei wird ein geheimer Schlüssel, der Sender und Empfänger – also der Cloud-Plattform und dem Endgerät im Feld – bekannt ist, verwendet, um eine verschlüsselte Verbindung aufzubauen.

Authentifizierung durch DTLS

Unabhängig davon, ob MQTT-SN oder CoAP als Kommunikationsprotokoll eingesetzt wird, unterstützen beide Protokolle jedoch zunächst keine Authentifizierung der verbundenen Geräte.

Beispielsweise bietet MQTT-SN in der aktuellen Implementierung der Spezifikation (v1.2) keine Möglichkeit, die Identität von Clients festzustellen. Es wird lediglich eine ClientID in der CONNECT-Message übertragen. Sofern eine Authentifizierung der Clients erforderlich ist, müsste diese daher in Form eines „eigenen Protokolls“ auf Basis von MQTT-SN implementiert werden.

Die fehlende Authentifizierungsmöglichkeit mag in einem geschlossenen System ausreichend erscheinen, setzt aber ein hohes Vertrauen in die Gegenseite voraus. Im Fall eines Narrowband-IoT-Szenarios, das die Verbindung smarter Stromzähler mit einer Cloud vorsieht, könnte beispielsweise die global eindeutige Seriennummer des Zählers als ClientID herangezogen werden. Eine Angreiferin oder ein Angreifer hätte damit die Möglichkeit, durch Auslesen oder Auslesen von (Geräte-)Seriennummern oder auch durch bloßes Raten fremde ClientIDs zu ermitteln und im Namen fremder Geräte Daten auszulesen. So könnten vertrauliche Informationen abgefangen oder Nachrichten an die Cloud gesendet werden, was wiederum zu einer Manipulation der Daten führen würde.

Um die fehlende Authentisierung bei MQTT-SN (oder CoAP) zu kompensieren, kann auch hier DTLS-PSK eingesetzt werden. Für den Aufbau der sicheren Verbindung müssen korrekte, dem Server bekannte Credentials in Form eines Client Identifier sowie eines Pre-Shared Key übermittelt werden. Eingehende MQTT-SN-Nachrichten können dann cloudseitig anhand des verwendeten Client Identifier dem jeweiligen Gerät zugeordnet werden.

DTLS-Implementierungen

Die Zahl der derzeit verfügbaren DTLS-Implementierungen ist vor allem serverseitig überschaubar: Die vorhandenen befinden sich allenfalls in einem experimentellen Stadium oder werden nicht mehr aktiv weiterentwickelt. Als positives Beispiel für eine DTLS-Implementierung, die eine Vielzahl von Cipher Suites unterstützt und aktiv weiterentwickelt wird, ist jedoch das in der Programmiersprache Java entwickelte Eclipse-Projekt Scandium hervorzuheben. Diese Implementierung bildet die Grundlage für die CoAP-Implementierung Californium und wird daher in größerem Umfang eingesetzt.

Besonders wenn batteriebetriebene Endgeräte eingesetzt werden, ist die Nutzung von in Hardware implementierten Verschlüsselungsalgorithmen nicht bloß aufgrund der höheren Verarbeitungsgeschwindigkeit, sondern vor allem aufgrund des geringeren Energiebedarfs essenziell.

Sollte die langlebige Spannungsversorgung ein relevanter Faktor sein, ist von softwareseitig implementierten Algorithmen unbedingt abzusehen.

Fazit

Die Anbindung von Geräten über Narrowband-IoT ist in verschiedenen Anwendungsfällen sinnvoll, oft aber auch – aufgrund der Betriebsumgebung der Geräte – schlicht notwendig. Obwohl die Technologie seit mindestens einem Jahr prinzipiell flächendeckend verfügbar ist, wird sie erst nach und nach eingesetzt. Die verfügbaren Ressourcen sind daher begrenzt. Die größte Hürde liegt in der Umsetzung der Sicherheit, das heißt der Ende-zu-Ende-Verschlüsselung sowie der Geräteauthentifizierung.

Dennoch steht dem Einsatz nichts mehr im Wege, wenn die eingesetzte Software sowohl geräte- als auch cloudseitig an den speziellen Anwendungsfall angepasst und die notwendige Architektur geschaffen wurde.

Wenn diese Blog-Serie euer Interesse geweckt hat oder ihr einen spannenden Anwendungsfall für LPWAN-Technologien habt, dann meldet euch bei uns – wir beraten euch gerne.

Kontakt

Ihr wollt eure Produktion datenbasiert optimieren, aber die Daten nicht aus unterschiedlichen Softwaresystemen und Datenbanken zusammensuchen müssen? Ihr möchtet nicht für jede Datenabfrage eine Fachkraft fragen müssen? Dann werft einen Blick auf unsere Website und erfahrt, wie Industrial-Internet-of-Things-Plattformen – kurz IIoT-Plattformen – dabei unterstützen können.