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

Inhaltsverzeichnis

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

• Die Kommunikation über das Internet mit dem MQTT zugrundeliegenden Protokoll TCP/IP sollte immer mit TLS-Verschlüsselung erfolgen.
• Administratoren sollten die MQTT-Broker mit Authentifizierungs- und Autorisierungsoptionen einrichten.
• Das Protokoll bringt die Authentifizierung über Benutzername und Passwort als Standardfunktion mit, indem es jeweils ein Feld für die beiden Eigenschaften bei der initialen MQTT-Nachricht beim Verbindungsaufbau vorsieht.

Verbesserte Authentifizierung

Mehr Infos

Sichere IoT-Kommunikation mit MQTT

• Teil 1: Grundlagen
• Teil 2: Weitere Sicherungsmaßnahmen

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.

Zertifizierte Clients

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:

• Der Broker kann die Identität des MQTT-Clients verifizieren.
• Die Authentifizierung des Clients findet bereits auf Ebene der Transportschicht statt.
• MQTT-Verbindungen lassen sich bereits vor dem ersten Versenden eines MQTT CONNECT-Pakets ablehnen, das eine MQTT-Verbindung initialisiert.
• Falls das Terminieren der TLS-Verbindung bereits an einem Load Balancer stattfindet, werden die Broker niemals mit ungültigen Verbindungsversuchen belastet.

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:

• CRL: Certificate Revocation Lists sind Listen ungültiger Clientzertifikate. Die Administratoren verteilen sie auf alle MQTT-Broker, die somit in der Lage sind, die betroffenen Clientzertifikate abzulehnen. Es handelt sich um einen Blacklist-Ansatz. Über die Zeit können die Listen bei großen MQTT-Deployments sehr groß und schwierig zu warten werden.
• OCSP: Beim Online Certificate Status Protocol kommt ein externer Service zum Einsatz, um Revokation-Informationen einzelner Zertifikate zentral bei einem sogenannten OCSP Responder zu hinterlegen. Der MQTT-Broker fragt nun die Gültigkeit eines bestimmten Clientzertifikats bei diesem Service nach. Damit lassen sich die Informationen zentral verwalten, statt sie auf alle MQTT-Broker auszurollen.

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.