MQTT trifft PKI: Wie Zertifikate das MQTT-Protokoll absichern können
Vertrauenswürdige IoT-Infrastrukturen durch digitale Identitäten
Das MQTT-Protokoll hat sich für die Machine-to-Machine-Kommunikation (M2M) als Standard etabliert. Besonders im Internet der Dinge erfreut sich das Protokoll aufgrund seiner Leichtgewichtigkeit großer Beliebtheit. Doch wie sicher ist MQTT und wie können vertrauenswürdige IoT-Infrastrukturen aufgebaut werden?
Was ist das MQTT-Protokoll?
Es handelt es sich um ein offenes Netzwerkprotokoll für die Kommunikation zwischen Geräten und Maschinen. MQTT bedeutet Message Queueing Telemetry Transport. Es ist ressourcensparend und zuverlässig, daher kommt es vor allem im IoT und IIoT zum Einsatz und wird genutzt, um alle Arten von Daten in zum Teil instabilen oder bandbreitenbeschränkten Netzwerken auszutauschen.
Wie funktioniert das MQTT-Protokoll?
Das Protokoll funktioniert nach dem PUBLISH/SUBSCRIBE-Prinzip über einen zentralen Server, dem sogenannten MQTT-Broker. Ein MQTT-Client, z.B. ein Sensor, veröffentlicht (PUBLISH) seine Informationen und Werte in einem Topic an den MQTT-Broker. Ein anderer MQTT-Client, z.B. eine Software, kann das Topic abonnieren (SUBSCRIBE) und erhält die entsprechenden Daten vom MQTT-Broker. Zwischen den beiden Clients besteht keine direkte Kommunikationsverbindung. Daher funktioniert die Kommunikation nicht ohne MQTT-Broker.
Ein Topic ist hierarchisch, ähnlich einem Dateipfad, aufgebaut. MQTT-Clients können spezifische Topics, z.B. die Temperaturwerte eines bestimmten Geräts, abonnieren oder aber mit Wildcards allgemeinere Topics, z.B. die Temperaturwerte aller Geräte oder alle Werte eines bestimmten Geräts, anfordern.
MQTT-Nachrichten bestehen aus dem Topic und der sog. Payload. Dabei handelt es sich um den eigentlichen Inhalt der Nachricht, z.B. der Wert eines bestimmten Sensors. Dadurch ist das Protokoll so leichtgewichtig. Die Payload hat keine standardisierte Datenstruktur.
Bricht die Verbindung zwischen einem MQTT-Client und dem MQTT-Broker unerwartet ab, kann der Client eine Nachricht hinterlegen, die der Broker an die Abonnenten schickt, um sie über den Verbindungsabbruch in Kenntnis zu setzen. Diese Nachricht wird als Last Will oder Testament bezeichnet.
Ist die Verbindung zwischen dem Broker und einem Abonnenten unterbrochen, kann der Broker die abonnierten Nachrichten zwischenspeichern, um sie zu schicken, sobald die Verbindung zum Abonnenten wieder aktiv ist. Dadurch eignet sich das Protokoll besonders für unzuverlässige und bandbreitenbeschränkte Netzwerke.
Quality of Service
Die Nachrichten eines MQTT-Publishers können in drei unterschiedlichen Quality-of-Service-Stufen (QoS) an den Broker übertragen werden. Eine Nachricht mit QoS 0 wird genau einmal an den Broker geschickt. Der Broker sendet keine Bestätigung, dass er die Nachricht erhalten hat. Bei einer Nachricht mit QoS 1 sendet der MQTT-Client die Nachricht in regelmäßigen Abständen so oft an den Broker, bis er eine Empfangsbestätigung erhalten hat. Die Nachrichten können unter Umständen mehrfach beim Broker ankommen. Verschickt ein Client Nachrichten mit QoS 2 an den Broker, stellen sie durch einen vierstufigen Handshake sicher, dass die Nachricht nach einmaligem Senden auch tatsächlich ankommt. Die QoS 2-Stufe ist am ressourcenintensivsten.
Wie sicher ist das MQTT-Protokoll?
Als das Protokoll 1999 entwickelt wurde, hatte die Sicherheit von MQTT keine Priorität. Clients und Broker kommunizieren unverschlüsselt und ohne Authentifizierung über Port 1883 miteinander.
Erfolgt die Kommunikation über das Internet, kann sie mit TLS verschlüsselt werden. Dies wird als MQTT over TLS bezeichnet. Das schützt die Verbindungen zwischen Client und Broker. Auf dem Broker selbst sind die Nachrichten aber nach wie vor ungeschützt. Für diese Verbindungen wird der Port 8883 genutzt.
Für die Authentifizierung der Clients am Broker können verschiedene Methoden eingerichtet werden. Die einfachste ist die Authentifizierung mit Benutzername und Kennwort. Allerdings werden die Anmeldedaten im Klartext übertragen, was die Nutzung von TLS erfordert, wenn die Authentifizierung sicher sein soll. Zusätzlich müssen die Zugangsdaten auch sicher gespeichert und verteilt werden, was bei einer Vielzahl an Clients schwierig und unübersichtlich werden kann.
Eine andere Methode zur Authentifizierung sind Maschinenidentitäten. Sie bestehen aus einem Schlüsselpaar (öffentlicher und privater Schlüssel) und einem Zertifikat. Jeder MQTT-Client und der MQTT-Broker erhalten eine Maschinenidentität. Diese werden durch eine Public Key Infrastruktur (PKI) zur Verfügung gestellt. Dadurch kann Vertrauen zwischen Client und Broker aufgebaut werden und trotzdem der Verwaltungsaufwand im Rahmen gehalten werden. Um die Übersicht über die Zertifikate und Identitäten zu behalten, sollte eine gute Zertifikatverwaltungs- und PKI-Software zum Einsatz kommen.
Eine weitere Möglichkeit ist die Authentifizierung per OAuth. Allerdings benötigt sie eine umfangreiche OAuth-Infrastruktur. Zertifikate kommen bei OAuth zum Einsatz, um sich am Identity-Provider zu authentisieren und das für OAuth notwendige Token zu erhalten.
Des Weiteren ist es unabdingbar den MQTT-Broker sicher zu konfigurieren. Jeder Client sollte nur Zugriff auf die von ihm benötigten Topics haben. Das wird Least Privilege genannt. Dadurch wird verhindert, dass MQTT-Clients Daten manipulieren oder abgreifen können, die sie nicht benötigen.
Whitepaper
»Sichere Maschinenidentitäten für IoT und OT«
Lesen Sie hier, wie Ihnen eine gut durchdachte Zertifikathierarchie dabei hilft, Maschinenidentitäten effektiv abzusichern.
Weitere Artikel
Lesen Sie weitere spannende Artikel über PKI, Zertifikate und Maschinenidentäten in OT und IoT.
Wie können Zertifikate das MQTT-Protokoll absichern?
Digitale Zertifikate können Kommunikation absichern, Daten schützen, Zugriffsrechte autorisieren und Vertrauen aufbauen.
Was ist ein digitales Zertifikat?
Ein Zertifikat reichert ein Schlüsselpaar, bestehend aus einem öffentlichen und privaten Schlüssel, mit Zusatzinformationen an. Die wichtigsten Zusatzinformationen sind die Zertifizierungsstelle (Certificate Authority, CA), die das Zertifikat signiert hat, das Subjekt und die Gültigkeit des Schlüsselpaars bzw. des Zertifikats.
Vertrauen und Zugriffsrechte bei MQTT
Zertifikate können genutzt werden, um Vertrauen zwischen einem MQTT-Client und dem MQTT-Broker aufzubauen. Hier kommt die CA ins Spiel. Alle Beteiligten müssen lediglich der CA (dem Aussteller der Zertifikate) vertrauen, um gegenseitige Vertrauensbeziehungen aufzubauen. Dies erleichtert das Management, auch von großen Mengen, von Identitäten enorm.
Dieses Vertrauen, dass durch die CA hergestellt wird, kann auch genutzt werden, damit sich ein Client mit einem Zertifikat am Broker authentisieren kann. Dadurch kann der Broker den Client entsprechend seinen Zugriffrechten autorisieren, auf die für diesen Client erlaubten Topics zuzugreifen. Für eine möglichst hohe Sicherheit gilt: Nur so viele Rechte wie nötig und so wenig wie möglich. Je mehr Rechte ein Client besitzt, desto größer ist die Gefahr, dass dieser, ob absichtlich oder unabsichtlich, diese Rechte missbraucht. Deshalb sollten Rechte individuell für jeden Client vergeben werden und nicht alle Clients die gleichen Rechte bekommen, was wiederrum nur mit eindeutig nachweisbaren Maschinenidentitäten möglich ist.
Kommunikation und Daten absichern
Besteht kein Vertrauen zum MQTT-Broker, weil dieser vielleicht nicht unter der eigenen Kontrolle steht oder ungeschützt ist, können Clients trotzdem über diesen Broker Daten sicher senden und abrufen.
Beim sogenannten MQTT Payload Stamping signiert ein MQTT-Client seine Payload, indem er mit einem Hashalgorithmus einen Hash auf seine Daten berechnet. Diesen Hashwert verschlüsselt er mit seinem privaten Schlüssel, den nur dieser Client kennt. Die so signierten Daten werden an den Broker publiziert. Ein Abonnent kann wiederrum die signierten Daten abrufen und mit dem öffentlichen Schlüssel des Clients den Hashwert entschlüsseln. Außerdem berechnet der Abonnent ebenfalls den Hashwert auf die Payload. Stimmen beide Hashwerte überein, kann der Abonnent sicher sein, dass die Daten auf dem Transport über den Client nicht manipuliert wurden.
Eine weitere Möglichkeit zur Absicherung ist die MQTT Payload Encryption, also die Verschlüsselung der Payload mit dem öffentlichen Schlüssel des Abonnenten. In diesem Fall kann nur der Abonnent die Daten entschlüsseln, weil er den privaten Schlüssel besitzt. Wirklich sicher wird das Ganze aber erst, wenn sowohl Payload Stamping und wie auch Payload Encryption angewandt werden. Nur das verhindert das der Broker die Nachrichten weder mitlesen noch manipulieren kann. Es verhindert auch das der MQTT-Broker selbst eine verschlüsselte Nachricht mit dem öffentlichen Schlüssel des Abonnenten erstellt und diese übermittelt. Greifen allerdings verschiedene Abonnenten auf die Daten zu, muss die Payload für jeden Abonnenten einzeln mit dessen öffentlichen Schlüssel verschlüsselt werden.
PKI- und Key-Management mit der ECOS TrustManagementAppliance®
Mit der Trust Management Appliance (TMA) stellt ECOS Technology eine PKI- und Key-Management-Lösung für ein sicheres Zertifikatsmanagement zur Verfügung.
Erstellen, Speichern, Verteilen, Verlängern und Zurückziehen - das Lifecycle-Management von Zertifikaten und Schlüsseln ist Kernaufgabe der Trust Management Appliance (TMA).
Zusätzlich bietet die TMA verschiedene Schnittstellen sowie eine REST API zur Automatisierung aller Vorgänge rund um das Zertifikat- und Schlüsselmanagement – für eine nahtlose Integration in bestehende IT-, OT- und IoT-Umgebungen.
Neugierig geworden?
Vereinbaren Sie ein kostenloses Beratungsgespräch mit uns oder abonnieren Sie unseren IT-Security-Newsletter.