Logo von Developer

Suche
Abonnieren

Tägliche Top-News bei WhatsApp, Facebook Messenger, Telegram & Insta

preisvergleich_weiss

Recherche in 1.760.893 Produkten

Dominik Obermaier 8

Sichere IoT-Kommunikation mit MQTT, Teil 2: Weitere Sicherungsmaßnahmen

Sichere IoT-Kommunikation mit MQTT, Teil 2: Weitere Sicherungsmaßnahmen

Das MQTT-Protokoll lässt sich effizient über Methoden absichern, die über die Standardfunktion mit Name und Passwort hinausgehen.

Der erste Teil der Artikelserie diskutierte die Grundlage für eine sichere Kommunikation über das Internet mit MQTT und stellte dabei folgende Punkte heraus:

Sichere IoT-Kommunikation mit MQTT

In professionellen MQTT-Deployments sollte eine Authentifizierung mit Benutzername und Passwort jedoch nicht die erste Wahl sein, da bei Tausenden von MQTT-Clients Passwortlisten – gehashte und gesalzene – schwer zu pflegen sind und deutlich bessere Optionen zur Verfügung stehen. Spätestens wenn sehr viele MQTT-Clients im System vorhanden und erhöhte Anforderungen an die Sicherheit des MQTT-Deployments gefordert sind, lohnt es sich, fortgeschritterene Techniken zur Absicherung der MQTT-Kommunikation zu betrachten. Der zweite Teil der Serie widmet sich daher den Themen X509-Client-Zertifikate, OAuth 2.0 und Nutzdatenverschlüsselung.

Beim Betrachten der Absicherung und Verschlüsselung der gesamten Kommunikation mit TLS (Transport Layer Security) ist zu beachten, dass TLS ein Standardprotokoll ist, das unter anderem auch beim Ausliefern von Webseiten über HTTP zum Einsatz kommt und nicht spezifisch für MQTT ist.

Vor der verschlüsselten Übertragung von (MQTT)-Nutzdaten fordert das TLS-Protokoll einen sogenannten Handshake zwischen Client und Server. Dabei präsentiert der Server ein X.509-Server-Zertifikat, das üblicherweise eine vertrauenswürdige Certificate Authority (CA) ausgestellt hat. MQTT-Clients überprüfen während des TLS-Handshake das vom Broker präsentierte Zertifikat auf Gültigkeit – und darauf, ob sie dem konkreten Zertifikat vertrauen möchten. Wenn es sich um keinen vertrauenswürden Server handelt, schließen sie die Verbindung. Ein MQTT-Client überprüft mit dem Serverzertifikat also die Identität des Brokers.

Optional kann ein MQTT-Client im Rahmen des TLS-Handshake seinerseits ein X.509-Zertifikat an den Broker senden. Damit ist es dem MQTT-Broker möglich, vor der eigentlichen MQTT-Kommunikation die Identität des Clients zu überprüfen. Falls der Client dem Broker ein ungültiges Zertifikat präsentieren sollte, lehnt der Server den Verbindungsaufbau ab und schließt die Verbindung. Die beidseitige Überprüfung der Identität heißt "Mutual TLS Handshake".

Die Verwendung von X.509-Client-Zertifikaten in Verbindung mit MQTT bietet einige Vorteile:

Anzeige

Trotz der genannten Vorteile kommen X.509-Client-Zertifikate nur in seltenen Fällen zum Einsatz, da ihre Verwendung in der Praxis einige Herausforderungen mitbringt. Die größte Schwierigkeit für professionelle MQTT-Deployments sind – wie häufig in der IT – nicht technischer Natur: Der Provisionierungs- und Revokationsprozess für die Zertifikate muss im Unternehmen definiert und umsetzbar sein, was einige Herausforderungen mitbringt.

Der Provisionierungsprozess definiert, wie sich Zertifikate sicher auf einzelne MQTT-Clients ausrollen lassen. Da Letztere oft in Verbindung mit (Mini-)Rechnern in ungeschützten Umgebungen im Einsatz sind, gestaltet sich das in der Praxis als schwierig. Wenn die MQTT-Clients beispielsweise in Hardwareprodukten für Konsumenten verbaut sind, die weltweit zum Kauf verfügbar sind, stellt sich die Frage, wie das sichere Zertifikat auf das Endgerät kommt: Entweder rollt der Hersteller die Zertifikate bei der Fertigung der Hardware in einer sicheren Umgebung direkt aus oder er installiert sie im Rahmen von Firmware-Updates oder ähnlichen Mechanismen.

X.509-Zertifikate haben eine bestimmte Gültigkeit und erfordern anschließend den Austausch, was in den meisten Fällen ein Over-the-air-Update erfordert. Dabei ist zu beachten, dass jeder individuelle MQTT-Client ein eigenes Zertifikat erhält und sich mehrere Clients niemals Zertifikate teilen. Sonst wäre eine Revokation unmöglich, also eine Rücknahme von nicht mehr vertrauenswürdigen Zertifikaten.

Ein Revokationsprozess definiert, wie sich Zertifikate zurücknehmen lassen, falls ein Zertifikat gestohlen wurde oder ein Client aus anderen Gründen vom System ausgesperrt werden soll. Grundlegend gibt es hierfür zwei Mechanismen:

Obwohl X.509-Clientzertifikate vom Grundsatz her ein guter Weg sind, Authentifizierung für MQTT umzusetzen, scheitert es in der Praxis oft an nicht vorhandenen Prozessen für die Provisionierung und Revokation von Zertifikaten. Nach der Lösung der prozesstechnischen Probleme ist eine clientzertifikatsbasierte Authentifizierung eine sehr gute Option, um MQTT abzusichern.

Für die Fälle, in denen das nicht möglich ist, gibt es weitere Ansätze.

8 Kommentare

Themen:

Anzeige
Anzeige