16 MQTT
Message Queuing Telemetry Transport, kurz MQTT, ist ein Protokoll das längst in der Automationswelt angekommen ist. In diesem Kapitel werden die wichtigsten Aspekte zusammengefasst.
17 Einleitung
MQTT ist ein leichtgewichtiges Publish/Subscriber (Siehe ?sec-pattern-pubsub) Protokoll und ist mittlerweile Standard in der IT/OT Umgebung. Entwickelt wurde MQTT in den 1990er Jahren von Andy Standford-Clark und Arlen Nipper. Als zugrundeliegendes Problem gilt die Kommunikation von abgelegenen Öl-Pipelines. In diesen Gebieten war die Kommunikationsinfrastruktur fernab von stabil, was Anforderungen an ein sehr fehlertolerantes Protokoll mit kleinem Fussabdruck laut werden liess. 20 Jahre später, forderte die Industrie im Umfeld von 4.0 und IoT gleiche Anforderungen. Die Netzinfrastruktur ist zwar deutlich besser, aber die Anzahl Teilnehmer ist dramatisch gestiegen. Andere Umgebung aber gleiche Anforderungen. Damit kam MQTT wieder auf und ist heute defacto Standrad in vielen Netzwerken. OASIS hat MQTT später standardisiert und aktuell spricht man hauptsächlich von der Version 3.1 (Immernoch am verbreitesten) und Version 5.0, die immer mehr Relevanz erhält.
18 Kommunikationsprinzip
MQTT Kommunikation basiert auf einem Broker als zentrales Element. Alle Kommunikationsteilnehmer sind Clients und senden (publishen) oder abonnieren (subscriben) Daten vom Broker. Der Broker ist dabei der Server und dient dabei als Vermittlungszentrale. Jeder Client kann gleichzeitig Publisher und Subscriber sein. Wichtig ist zu verstehen, dass der Broker völlig unabhängig von der Logik ist und ist ausschliesslich um das Weiterleiten der Nachrichten kümmert.
Zur besser Vorstellung dient nachfolgendes Beispiel.
Beispiel Haus In einem Haus gibt es ein Wohnzimmer, Küche, Badezimmer und Keller. Das Haus wird modernisiert und verfügt über folgende Sensorik und Aktorik:
- Küche - Temperatursensor
- Wohnzimmer - Temperatursensor
- Badezimmer - Temperatur- und Feuchtigkeitssensor
- Keller - Heizung
Jeder Sensor ist ein Client und published seine Daten an ein Topic. Das Topic fungiert dabei als Postfach und folgt einer ähnlichen Hierarchie wie ein Filesystem. Alle Sensoren und Aktoren gehören zum Haus, untergeordnet davon sind Räume und darin die Sensoren. Diese Hierarchie könnte wie folgt abgebildet werden:
Die Sensoren publishen an folgende Topics: - Haus/Küche/Temperatur - Haus/Wohnzimmer/Temperatur - Haus/Badezimmer/Temperatur - Haus/Badezimmer/Feuchtigkeit
Die Heizung abonniert die Messwerte am Broker um darauf basierend die optimale Heizungstemperatur vorzugeben.
19 Konfigurationsbeispiele
19.1 TLS Connection mit Mosquitto Broker
Mit MQTT kann sehr schnell ein Publish/Subscriber Netzwerk aufgebaut werden, um Daten zu empfangen oder zu senden. Was bei all der Einfachheit aber oft etwas untergeht, ist das Thema der Security. Im folgenden wird daher ein einfaches Beispiel gezeigt, wie eine TLS gesicherte Verbindung zu einem Mosquitto Broker aufgebaut werden kann. Die Details zu TLS werden dabei nur soweit als nötig eingeführt, um die Abfolge der einzelnen Schritte verstehen zu können.
19.1.1 Vorbereitung
Als Broker wird Mosquitto als Docker Container verwendet. Ausserdem werden TLS Zertifikate genutzt, die sehr oft mit openSSL erstellt werden. Für diese Demo möchten wir aber nur soviel als nötig mit Zertifikaten zu tun haben und nutzen daher XCA, welches uns einige Arbeit abnimmt (https://www.hohnstaedt.de/xca/).
Hinweis: Im Folgenden werden in XCA nur die nötigen Anpassungen gemacht, um eine TLS Verbindung aufbauen zu können. Für den Produktiven Einsatz müssen diese unbedingt genauer hinterfragt und vollständig ausgefüllt werden.
19.1.3 Erstellen des Broker Zertifikats
Da die CA nun eingerichtet ist, können wir Zertifikate anfordern. In der Regel wird dies durch einen Zertifikatsantrag (Certificate Signing Request (CSR)) iniitiert.
Erstellen wir unter “Zertifikatsantrag” einen neuen Antrag und verwenden dafür die Vorlage “TLS_Server”. Ebenfalls nutzen wir die damit verbundenen Einstellungen. Wichtig ist nun den richtigen “Common Name” zu wählen. Dies muss der FQDN (Full Qualified Domain Name) sein. Mit anderen Worten ist dies eine Domäne oder der Hostname. Für unsere lokalen Tests nutzen wir den Hostname “localhost”. Zusätzlich wird ein privater Schlüssel für den Server erstellt. Dieser wird benutzt, um eine sichere Verbindung zu seinen Clients aufzubauen. Wurde der Antrag erstellt, können wir diesen direkt signieren. Dazu können wir mit Rechtsklick “Unterschreiben”, den Prozess einleiten. Beim nun erscheinenden Dialog stellen wir sicher, dass dieser Antrag mit unserem “CA Zertifikat” signiert wird. Zusätzlich nutzen wir die “TLS Server” Vorlage und entfernen den Haken bei “Erweiterungen aus dem Antrag kopieren”. Bestätigen wir den Dialog sollte unser Zertifikat signiert sein und unter “Zertifikate” unter unserem Root-CA Zertifikat auftauchen. Voila! MQTT TLS Certificate Signing Request Abbildung 4.2: MQTT TLS Certificate Signing Request
Hinweis: Achtung 127.0.0.1 kann nicht als Common Name verwendet werden. Es muss der Hostname oder Localhost sein.
19.1.4 Client Zertifikate
Im World Wide Web ist es üblich, dass nur der Server ein Zertifikat hat und der Client über eine CA das Server Zertifikat überprüfen kann. Mit anderen Worten, jeder Client kann mit dem Webserver sicher kommunizieren. Mit unseren aktuellen Schritten, haben wir alle nötigen Zertifikate erstellt, um auf dem selben Level eine sichere Verbindung zum Broker aufbauen zu können.
In einem MQTT Netzwerk kann es nötig sein, dass auch die Identität der Clients überprüft werden muss. Dafür müssen Zertifikate nach dem gleichen Prinzip des Server Zertifikats erstellt werden und auf dem Client installiert. Da nun auch der Client Zertifikate überprüfen können muss, braucht der Client neben seinem Private Key und Zertifikat, ebenfalls das Zertifikat der CA.
19.1.5 Installation der Zertifikate
Wir möchten uns hier auf das Server Zertifikat fokusieren. Dafür müssen wir von unserer XCA Datenbank folgende Dinge exportieren:
Zertifikat der CA (Export als .crt) - Dient zum Überprüfen allfälliger Zertifikate Zertifikat für den Broker (Export als .crt) - Der Ausweis unserers Brokers Private Key des Brokers (Export als *.pem) - Benötigt für den Aufbau der sicheren Verbindung Im nächsten Schritt müssen wir diese Files auf dem Broker einrichten. Haben wir bei unserem Container ein Volume genutzt, können wir die Files einfach ins Volume kopieren (z.B. in einen Ordner certs). Wurde kein Volume genutzt, können wir die Files auch in den Docker Container verschieben. Docker bietet dafür das Kommando cp.
Beispiel in einem Terminal:
docker cp
Beispiel: docker cp hallo.txt MeinMosquittoContainer:/hello.txt 4.2.6 Anpassen des Konfig Files Als letzten Schritt muss die Datei mosquitto.conf gemäss nachfolgendem Beispiel angepasst werden (Pfade auf die eigenen Dateien anpassen).
CA Zertifikat - cafile /fhnw.mqtt.crt TLS Server Zertifikat - certfile /localhostmqtt.crt Private Server Key - keyfile /mqtt.brokerkey.pem Danach muss der Container neu gestartet werden, damit die Änderungen wirksam werden.
19.1.6 Verbinden als Client
Nutzt man einen MQTT Client wie z.B. MQTT-Explorer, können im Connect Window unter Advanced Zertifikate konfiguriert werden, wie auch die Verbindung auf TLS umgestellt werden. Ohne Client Zertifikate muss auf dem Client nur das CA Zertifikat konfiguriert werden, damit der Client das beim Verbindungsaufbau erhaltene Server Zertifikat überprüfen kann.