Die Vielfalt der Geräte im Internet der Dinge (eng. Internet of Things, IoT) ist in den letzten Jahren beinahe explodiert. Viele Haushaltsgeräte oder alltäglichen Gegenstände verfügen über eine IoT-Anbindung oder lassen sich in ein Smart Home System integrieren.

Wie aber funktioniert die Kommunikation der IoT-Geräte und welche Protokolle kommen dabei zum Einsatz? In diesem Artikel geht es um IoT-Protokolle, welche in der Anwendungsschicht angesiedelt sind mit Fokus auf MQTT und um die Absicherung der Protokolle, nicht aber der Absicherung der Infrastruktur.

Message Queuing Telemetry Transport (MQTT)

Das zurzeit wohl bekannteste IoT-Kommunikationsprotokoll ist Message Queuing Telemetry Transport (MQTT). Hierbei handelt es sich um ein Netzwerkprotokoll, welches für Machine-to-Machine-Kommunikation (M2M) konzipiert ist. Das Client-Server-Protokoll setzt auf das Publish Subscribe Modell. MQTT funktioniert üblicherweise über TCP. Es gibt jedoch auch Varianten des Protokolls, welche mit UDP funktionieren.

IoT-Anwendungsbeispiel mit MQTT

Der Client, in diesem Fall ein Raspberry Pi mit Raumtemperatursensor, sendet Sensordaten an den Server (MQTT Broker). Nach Verbindungsaufbau zwischen Client und Server wird auf einem im Voraus bestimmtem Topic Daten gesendet. Dieses Topic kann zum Beispiel Office/Meetingroom/Temperature heissen. Der Anwendungsfall kann sein, dass die Bürosteuerung dieses Topic abonniert und Mitarbeitende kurz vor ihrer nächsten Besprechung im Meetingroom über die Temperatur informiert und ihnen so die Möglichkeit für frühzeitiges Lüften ermöglicht.

MQTT findet breite Verwendung in Sensoren und Aktoren, Mobiletelefonen, eingebettete Systemen oder auch vollwertige Desktopcomputer. Die Ports 1883 und 8883 sind für MQTT reserviert. Ein grosser Vorteil von MQTT ist der MQTT-Broker, welcher wichtige Aufgaben vom oftmals ressourcenarmen Client übernimmt. Darauf lässt sich auch die grosse Verbreitung in Automatisierungs- und Steuerungslösungen zurückführen.

Das Zusammenspiel funktioniert wie folgt: IoT-Geräte senden Daten, Zustände oder andere Informationen an den MQTT-Broker, dieser sendet die erhaltenen Daten an weitere Geräte und Systeme, welche das dazugehörige Topic abonniert haben. Dadurch muss das IoT-Gerät, die Daten nur an den MQTT-Broker senden, was einiges an Komplexität und Leistung einspart.

Konfigurationsmöglichkeiten von MQTT

Das MQTT-Protokoll bietet folgende Konfigurationsmöglichkeiten bei Quality of Service (QoS), die Sicherstellung der Ankunft einer Nachricht:

Die Retain-Option beim Broker ermöglicht es, Nachrichten zu speichern und bei einer neuen Subscription die letzte Nachricht des Topics sofort zuzustellen. Beim Verbindungsaufbau kann definiert werden, was im Fall eines Unterbruchs oder eines kompletten Abbruchs einer Verbindung passiert, beziehungsweise welche Nachricht in so einem Fall an die Subscriber gesendet werden soll.

Aufbau eines MQTT-Pakets

Der Protokoll-Header ist 2 Byte gross, das erste Byte beinhaltet den Nachrichtentyp (4 Bit) sowie spezifische Flags je nach Nachrichtentyp, bei einer Publish Nachricht zum Beispiel Duplicate Delivery (1 Bit), Quality of Service (2 Bit) und das Retain-Flag (1 Bit). Im zweiten Byte ist die Länge des restlichen Payloads vermerkt. Danach folgt der variable Teil mit MQTT-Topic und dem Payload.

Wie sichert man MQTT ab?

MQTT kann mit dem Einsatz von TLS auf Transportschicht verschlüsselt und somit geschützt werden, dabei wird der Port 8883 (secure-MQTT) verwendet. Im Artikel Transport Layer Security werden die neusten Änderungen erläutert und die empfohlene TLS-Konfiguration aufgezeigt. Zusätzlich besteht die Option, dass sich der Sender beim MQTT-Broker mittels X.509 Zertifikat authentifiziert.

MQTT selbst verfügt über eine Authentifizierung durch Benutzername und Passwort. Es muss beachtet werden, dass ohne den Einsatz von TLS die Übertragung im Klartext stattfindet und somit einfach abgehört werden kann. Zusätzlich zu Benutzername und Passwort kann auch noch ein Clientidentifier der Connect Message hinzugefügt werden. Bei diesem Vorgang wird zuerst die Benutzername und Passwort Kombination geprüft und danach, ob der mitgesendete Clientidentifier dazu passt. Es gibt es eine Option für die Verschlüsselung des Payloads, diese sollte in Betracht gezogen werden, wenn TLS aufgrund sehr geringer verfügbarer Hardware nicht eingesetzt werden kann.

Wie funktioniert Autorisierung in MQTT?

Die Steuerung wird auf dem MQTT-Broker vorgenommen, und zwar über sogenannte Topic Permissions. Folgende Möglichkeiten gibt es hier:

• Erlaubte Topics: Spezifisches Topic, Wild card Topic
• Erlaubte Operationen: Publish, Subscribe, Beides
• Erlaubte Quality of Service Einstellung: 0, 1 ,2 oder alle

Constrained Application Protocol (CoAP)

CoAP ist ein IoT-Protokoll, welches sich für Nodes mit wenig Ressourcen, sprich low-power Prozessoren wie 8-bit Microkontroller mit wenig RAM und ROM bestens eignet. Das Protokoll ist ebenso für Machine-to-Machine (M2M) Applikationen designt, sei dies im gleichen Netzwerk oder über das Internet. Einsatzzwecke finden sich in Smart Energy und Gebäudeautomation wieder. CoAP funktioniert anders als MQTT in einem Request/Response Interaktion Modell zwischen Endpunkten.

Die grossen Vorteile von CoAP sind die einfache Umwandlung zu HTTP, die Unterstützung von Multicast sowie der geringe Overhead des Protokolls und die Einfachheit für Geräte mit sehr geringen Ressourcen. CoAP läuft auf den meisten Geräten, welche UDP unterstützen.

Wie kann man CoAP absichern?

Das CoAP-Protokoll bietet vier verschiedene Security Modelle, die meisten verwenden Datagram Transport Layer Security (DTLS). DTLS ist ein Verschlüsselungsprotokoll für unzuverlässige Transportprotokolle wie UDP oder SCTP. DTLS basiert auf TLS und bringt ähnliche Sicherheit mit sich.

Security Modelle von CoAP:

• NoSec: Hierbei ist DTLS deaktiviert. Dieses Modell verzichtet auf Security.
• PreSharedKey: DTLS ist aktiviert. Eine Liste von pre-shared Keys ist vorhanden. Darin steht zu jedem Schlüssel mit welchen Nodes er verwendet werden kann. Die Nodes müssen AES Cipher Suites unterstützen.
• RawPublicKey: DTLS ist aktiviert. Jeder Node verwendet ein asymmetrisches Schlüsselpaar ohne Zertifikat. Die Geräte müssen AES Cipher Suites unterstützen sowie Elliptic Curve Algorithmen für den Schlüsselaustausch.
• Certifacte: DTLS ist aktiviert und der Node verwendet ein X.509-Zertifikat. Hierbei muss jedoch darauf geachtet werden, dass zum Beispiel nicht RSA für ressourcenarme Nodes eingesetzt wird.

Advanced Message Queuing Protocol (AMQP)

AMQP ist ein offener Standard, bei welchem es sich um ein binäres Netzwerkprotokoll auf Anwendungsebene für Message-orientierte Middleware (MOM) handelt. AMQP baut auf TCP auf. Das AMQP-Protokoll wurde erschaffen, um viele verschiedene Arten von Nachrichten und Kommunikationsmuster zu unterstützen. Es unterstützt verschiedene Message-delivery guarantees, welche den Quality of Service von MQTT entsprechen.

Wie sichert man AMQP ab?

AMQP kann mit TLS verschlüsselt werden, dann wird der Port 5671 (amqps) verwendet. Der Client muss dabei das Zertifikat des Servers validieren. Eine zusätzliche Sicherheit bietet die Authentifizierung des Clients mittels Client-Zertifikat beim Server.

Mit der Unterstützung des Simple Authentication and Security Layer (SASL) Frameworks gibt es eine weitere Option für die Authentifizierung und das Aushandeln von Kommunikationsparametern. SASL bietet viele verschiedene Mechanismen zur Authentifizierung darunter OAuth 2.0 bearer tokens, Kerberos, NTLM, OTP und viele weitere. Darunter gibt es auch eine ANONYMOUS-Variante, wobei es sich um eine nicht authentifiziert Variante handelt und daher nicht unterstützt werden sollte.

Data Distribution Service (DDS)

DDS (Data Distribution Service) ist ein offener Standard, welcher sich ideal für zeitkritische Systeme eignet. DDS bietet eine breite Unterstützung von kleinsten Geräten bis zum schnellen Desktopcomputer und soll komplizierte Netzwerkprogrammierung verhindern. DDS erhöht die Zuverlässigkeit, ist simpel gehalten und verwendet dabei das Publish Subscribe Modell. Das DDS-Protokoll findet oft Verwendung in den Bereichen Luft- und Raumfahrt, Luftverkehrskontrolle, autonome Fahrzeuge, medizinische Geräte, Roboter und andere Anwendungsbereiche welche Echtzeit Datenaustausch benötigen.

Ähnlich wie beim MQTT-Protokoll gibt es Publishers, diese erstellen Topics und versenden Samples. DDS verteilt diese Samples an die Abonnenten (Subscribers) der jeweiligen Topics.

DDS wird auch als Netzwerk Middleware bezeichnet, welche die Adressierung der Nachrichten und die Serialisierung sowie Deserialisierung der Nachrichten bei plattformübergreifender Kommunikation handhabt. DDS managt zudem auch Autorisierung und Fehlerbehandlung, wenn eine Nachricht nicht zugestellt werden kann. Die Quality of Service (QoS) kann bei DDS auch konfiguriert werden. DDS unterstützt Hot-Swapping zwischen redundanten Publishers, dabei springt ein Backupnode ein beim Ausfall des primären Publishers.

Wie sichert man DDS ab?

Bevor es das DDS-Securitymodell gegeben hatte, wurden vor allem TLS und DTLS für die Sicherung von DDS verwendet, dies funktionierte jedoch nur mit Unicast.

Das DDS-Securitymodell, was im Nachhinein dazu kam, ist modular und ermöglicht verschiedene Bereiche als Plug-ins hinzuzufügen. Es stehen folgende Plug-ins im Security Bereich zur Auswahl:

• Authentifizierung
• Access Control
• Kryptographie
• Logging
• Data Tagging

Die Plug-ins Authentifizierung, Access Control und Kryptographie sollten auf jeden Fall verwendet werden beim Einsatz von DDS. Je nach Einsatzgebiet und Anwendungszweck sollten auch die restlichen Plug-ins Logging und Data Tagging eingesetzt werden.

Fazit

Alle Protokolle bringen ihre eigenen Stärken mit sich, daher lohnt es sich zu evaluieren, welche Eigenschaft im eigenen Umfeld am wichtigsten ist. Dies kann je nach Anwendungszweck die Real-Time-Fähigkeit, der gute Einsatz für ressourcenarme Geräte oder die simple Entwicklung sein. Der Sicherung des verwendeten IoT-Protokolls ist wichtig und sollte präzise vorgenommen und wenn möglich vor Inbetriebnahme geprüft werden. Viele der vorgestellten IoT-Protokolle können mit TLS abgesichert werden, hierbei ist es wichtig eine sichere TLS-Konfiguration einzusetzen.

Über den Autor

Ralph Meier hat eine Lehre als Applikationsentwickler, Fokus Webentwicklung mit Java, bei einer Schweizer Grossbank absolviert und danach einen Bachelor of Science ZFH in Informatik an der ZHAW School of Engineering abgeschlossen. Er fokussiert sich auf die sicherheitstechnische Untersuchung von Webapplikationen. (ORCID 0000-0002-3997-8482)

Links

• https://datatracker.ietf.org/doc/html/rfc7252
• https://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-overview-v1.0-os.html
• https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html
• https://www.omg.org/spec/DDS/1.4