MQTT Essentials - Einführung in MQTT

Klaus Pittig

Smarthome

  • Energie-Management

  • Entertainment und Kommunikation

  • Gebäude- und Wohnungssicherheit

  • Hausautomation und Komfort

  • O-Töne…​

Was ist für Euch "SmartHome"?

Automatische Jalousiensteuerung, Licht- und Heizungssteuerung, Einbruchsschutz, Energie-Kostenkontrolle und -steuerung, Irisscanner, Fingerabdruckscanner für die Tür…​

Was würde Dir am meisten bringen:

Kochen und putzen

Was ist für Euch "SmartHome"?

Sprachsteuerung für Infos/Unterhaltung und einfache Dinge wie das Setzen von Timern. Sensorwerte anzeigen/abrufen, Signale bei wichtigen Nachrichten/Twitter oder anderen Ereignissen.
Hörbücher vorlesen, Wetter ansagen, Musik und Filme am gewünschten Ort im Haus streamen. Brauche irgendwas, um TV mit Alexa umzuschalten.
— Anwender im Alexa-Fieber

Was ist für Euch "SmartHome"?

Weniger Fläche putzen müssen.
Ich find' das ja sowas von dämlich. Dann wird alles gehackt und Du kannst dein eigenes Heim nicht mehr kontrollieren…​

Was ist für Euch "SmartHome"?

Sicherheit in jeder Hinsicht, und Komfort. Mit Sicherheit meine ich auch Infos zu offenen Türen oer Fenstern - oder erforderliche Wartungen noch vor Eintritt eines Schadens. Und unter Komfort kann ich mir durchaus schlüsselloses Öffnen vorstellen.

Überwiegt für Dich irgendwann der Komfort die Sicherheit?

Nein.

Smart Home – Sicherheitsaspekte

  • Die Smart Home Technik hat Zukunft, ist jedoch oft unsicher

  • Produkte: Komfort, sinkende Kosten, unbefriedigende Sicherheit

  • Risiken: Zugriff auf Heizung, Beleuchtung, Schlösser etc.

  • Kunden: Sicherheitsbedenken ja, Sorge nein

Eigenverantwortung, Security First!

  • Es gibt keinen einheitlichen Sicherheitsstandard wie etwa für WLAN-Router

  • Zu regeln: Verschlüsselung, Authentifizierung, Autorisierung, Vermeidung von Hackerangriffen

  • Produkte: Prüfen auf Sinnhaftigkeit, Notwendigkeit und echte Funktionalität

  • Smart Home mit allen verfügbaren Mitteln und Sicherheitsmaßnahmen schützen

Agenda

  • Grundlagen und Funktionalität von MQTT

  • Key Features

  • Good Practices

  • Broker Bridges im Attraktor

  • MQTT Security…​ first?

  • Entscheidungshilfen und Anwendungsfälle

Offene Agenda im Nachgang?

  • Unterschiede MQTT v3.1 und v3.1.1

  • Aufbau von MQTT Broker Bridges (Mosquitto)

  • SSL Zertifikate, Security Details

  • MQTT Protocol Details

  • MQTT und WebSockets

  • Node-RED, Konkrete Programmierung in Sprache X

MQTT

  • Web: http://mqtt.org

  • Twitter: @mqttorg

  • Message Queuing Telemetry Transport (MQTT) v3.1.1

  • Seit 2010 Freigabe v3.1 durch Eurotech und IBM

  • Seit 2014 Standard OASIS v3.1.1

  • Seit 2016 Standard ISO/IEC 20922:2016

MQTT Schlüsselmerkmale

  • Publish-/Subscribe Muster

  • Quality of Service Level

  • Persistent sessions

  • Retained Messages

  • LWT (Last Will and Testament)

  • Keep-Alive und Client-Takeover

Herausforderungen für das "IoT"

  • Wachsende Anzahl und stärkere Nutzung mobiler Geräte

  • Erforderlich: Gleichzeitige Nachrichtenübermittlung an viele Geräte

  • Erforderlich: Gerantie fehlerfreier Übertragung

  • Hohe Komplexität durch verschiedenste Hardwarekomponenten und Software

  • Erforderlich: Vereinfachung der Kommunikation

Herausforderungen für das "IoT"

  • Interoperabilität: Große Menge proprietärer und offener Protokolle

  • Erforderlich: daten-agnostisches, offenes Protokoll

  • Kommunikation von Consumer-Hardware über das Internet soll überall funktionieren

  • Impakt im Mobilfunk: hohe Latenz, große Timeouts, niedrige Bandbreite

MQTT Einführung

MQTT is a Client Server publish/subscribe messaging transport protocol. It is light weight, open, simple, and designed so as to be easy to implement. These characteristics make it ideal for use in many situations, including constrained environments such as for communication in Machine to Machine (M2M) and Internet of Things (IoT) contexts where a small code footprint is required and/or network bandwidth is at a premium.
Official MQTT 3.1.1 Spec
— OASIS

MQTT Einführung

  • MQTT ist ein leichtgewichtiges Binärprotokoll

  • für TCP/IP bzw. geordnete, verlustfreie, bidirektionale Netzwerkprotokolle

  • minimaler Protokolloverhead

  • batterie- und bandbreitenschonend

  • ideal für Embedded Devices, kleine Transferraten, unzuverlässige Umgebungen

MQTT Einführung

  • Verschiedene Service-Qualitäten

  • Daten-agnostisch (keine Präferenz zu bestimmten Datenformaten).

  • Entkopplung von Sender und Empfängern

  • Effiziente Verteilung von Nachrichten an viele Empfänger

  • Publish/Subscribe Paradigma

MQTT Standard-Ports

  • MQTT + TCP: 1883 (Offizieller IANA Port)

  • MQTT + TLS: 8883 (Offizieller IANA Port)

  • MQTT + Websockets: 80/443 (Standard HTTP Ports)

Geschichte

  • Entwickelt 1999 von Andy Stanford-Clark (IBM) und Arlen Nipper (Cirrus Link)

  • M2M Kommunikationsprotokoll für SCADA-Systeme mit mininmalem Protokoll-Overhead

  • Projekt zum Monitoring von Ölpipelines

  • Zu dieser Zeit mussten die Daten kostspielig über Satellit übertragen werden

  • Aus diesem Grund wurde MQTT mit den oben genannten Eigenschaften entwickelt

Geschichte

  • Danach Nutzung/Weiterentwicklung von MQTT als proprietäres Protokoll bei IBM

  • 2010 Freigabe der Spezifikation, Ökosystems um MQTT, Eclipse Paho etc.

  • 2013 Beginn der Standardisierung der Protokollversion 3.1.1

  • 2014 Offizieller finaler OASIS Standard v3.1.1

  • 2016 Offizieller Standard ISO/IEC 20922:2016

Publish & Subscribe Grundlagen

  • Alternative zum traditionellen Request/Response Ansatz

  • Pub/Sub entkoppelt Nachrichtensender von -empfängern

  • Sender ist der Publisher, Empfänger sind Subscriber

  • Sender um Empfänger kennen sich nicht

  • Beide verwenden einen Vermittlerdienst, den Broker

Publish / Subscribe

mqtt pubsub

Entkopplung

3 Dimensionen der Entkopplung

  • Räumlich: Publisher und Subscriber müssen sich nicht kennen

  • Zeitlich: Publisher und Subscriber müssen nicht zur gleichen Zeit laufen

  • Synchronisation: Versand/Empfang blockiert keine laufenden Operationen

Skalierbarkeit

Höhere Skalierbarkeit als bei klassischem Client/Server Modell

  • Operationen parallelisierbar, ereignisgetrieben

  • Caching und intelligentes Routing

  • Bei sehr vielen Geräten Load-Balancing und Clustering erforderlich

  • Effiziente Filterung (über Topics)

Speicherung von Nachrichten

  • Nachrichten ohne Subscriber können i.d.R. verworfen werden

  • Broker kann für Clients zwischenspeichern, wenn sie

    • sie sich bereits einmal angemeldet haben

    • eine persistente Sitzung haben

    • ein Topic mit QoS Level >0 abonniert haben

Abgrenzung von Message Queues

  • Verwirrung um MQ im Namen MQTT.

    • Stammt von dem IBM Produkt MQseries,

    • hat nichts mit "message queue" zu tun

  • Eine Message Queue speichert Nachrichten, bis sie konsumiert werden

  • Eine Nachricht wird von einem Client konsumiert

  • Queues sind benannt und müssen explizit erzeugt werden

Client, Broker and Verbindungsaufbau

MQTT Client

  • Publisher oder Subscriber

  • Jedes Gerät/Software, die eine MQTT Bibliothek für eine Broker-Verbindung nutzt

  • Wegen MQTT Einfachheit auch mit eingeschränkten Geräten möglich

  • MQTT Client Bibliotheken verfügbar für viele Programmiersprachen

MQTT Broker

  • Gegenstück zum Client, Kern der Pub/Sub Infrastruktur

  • Tausende gleichzeitig verbundene Clients möglich

  • verantwortlich für Empfang, Filterung und Zustellung zu Clients

  • verwaltet Sitzungen für Clients

  • Authentifizierung und Autorisierung von Clients

  • muss entsprechend leistungsfähig sein

MQTT Verbindung

  • Das MQTT Protokoll baut auf dem TCP/IP Stack auf

  • Jeder Client ist mit dem Broker, nicht mit anderen Clients verbunden

  • Client sendet eine CONNECT Nachricht

  • Broker antwort mit CONNACK

  • Die Verbindung bleibt offen bis DISCONNECT

MQTT Verbindung über NAT

  • Nur der Client initiiert die Verbindung per CONNECT

  • Die Verbindung bleibt für bidirektionale Kommunikation offen

  • Daher keine Probleme mit Clients hinter einem NAT

  • Clients benötigen keine öffentliche Adresse

CONNECT Nachricht

mqtt packet connect

CONNECT Nachricht

  • Client Id: Client-Identifizierung, leer u.U. möglich

  • Clean Session Flag: Persistente Sitzung nein/ja

    • speichert Subscriptions und u.U. verpasste Nachrichten

  • Username/Password: einfache Authentifizierung/Autorisierung

  • Will Message: Benachrichtung anderer Clients bei unerwartetem Ende

  • Keep alive: Zeitintervall für PING Nachricht

CONNACK Nachricht

mqtt packet connack

CONNACK Nachricht

  • Der Broker muss auf CONNECT mit CONNACK antworten

  • Session Present Flag: Zeigt dem Client eine persistente Sitzung an

  • Connect acknowledge Flag: Informiert über Erfolg oder Details der Ablehnung

Publish, Subscribe & Unsubscribe

Publish

  • Client sendet Nachrichten mit PUBLISH

  • Jede Nachricht benötigt einen topicName für die Subscriber

  • Jede Nachricht enthält den payload im als Menge von Bytes

  • MQTT ist daten-agnostisch, das Format hängt vom Usecase ab.

  • Der Sender bestimmt die Datenstruktur (binary, text, json etc.)

Publish

  • Der Client ist mit dem Versand an den Broker fertig

  • Der Broker bestätigt nur bei QoS Level > 0

  • Nur der Broker sorgt für die Auslieferung an Subscriber

  • Es gibt kein Feedback zu Existenz und Anzahl der Subscriber

PUBLISH Nachricht

  • Topic Name: UTF-8 String, hierarchisch strukturiert mit /

    • Beispiel: "home/kitchen/temperature" oder "attraktor/door"

  • QoS: Quality of Service Level (0,1,2) zur Garantie der Übertragung

  • Retain-Flag: Als letzte Nachricht am Broker speichern ja/nein

    • Neue Subscriber erhalten diese Nachricht direct nach dem Subscribe

PUBLISH Nachricht

  • Payload: beliebige Binärdaten

  • Packet Identifier (intern): Eindeutige Id der Nachricht für QoS 1 oder 2

  • DUP Flag (intern): Nachricht wird erneut gesendet

    • wichtig für QoS 1 oder 2 bei erneutem Versand unbestätigter Nachrichten.

Subscribe

  • Client abonniert Topics mit SUBSCRIBE

  • Die Nachricht besteht PacketId und beliebigen Subscriptions

  • Eine Subscription besteht aus Topic-Name und QoS-Level

  • Bei Überlappungen zählt das höchste QoS Level

Subscribe

  • Der Broker bestätigt mit SUBACK

  • Für jede Subscription meldet der Broker einen Status

  • Bei Erfolg wird je Topic das QoS Level zurückgemeldet

  • Der Client erhält danach PUBLISH Nachrichten vom Broker

Unsubscribe

  • Client ruft sein Abonnement zurück mit UNSUBSCRIBE

  • Die Nachricht besteht PacketId und den Topic-Namen

  • Der Broker bestätigt mit UNSUBACK

  • Die Abonnenments des Clients sind danach am Broker gelöscht

MQTT Control Packets

MQTT Control Packets

Control PacketBeschreibung

CONNECT

Client fordert Verbindung an

CONNACK

Server bestätigt Anfrage

PUBLISH

Nachricht veröffentlichen

PUBACK

Server bestätigt PUBLISH

MQTT Control Packets

Control PacketBeschreibung

PUBREC

Bestätigt PUBLISH (QoS 2, Teil 1)

PUBREL

Bestätigt PUBREC (QoS 2, Teil 2)

PUBCOMP

Bestätigt PUBREL (QoS 2, Teil 3)

MQTT Control Packets

Control PacketBeschreibung

SUBSCRIBE

Topic abonnieren

SUBACK

Server bestätigt Abonnement

UNSUBSCRIBE

Server bestätigt Anfrage

UNSUBACK

Server bestätigt Abbestellung

MQTT Control Packets

Control PacketBeschreibung

PINGREQ

PING Anfrage

PINGRESP

PING Antwort

DISCONNECT

Benachrichtigung über Verbindungsabbruch

Topics and Good Practices

Topics

  • UTF-8 Zeichenkette

  • Zum Filtern von Nachrichten für verbundene Clients

  • Ein Topic besteht aus 1 oder mehr Topic Leveln

  • Jedes Level ist separiert durch ein Forward Slash (/)

  • Leichtgewichtig: dynamisch, ohne vorherige Initialisierung

Topics

home/groundfloor/kitchen/temperature
tinkerforge/bricklet/segment_display_4x7/pUj/segments/set
v1/715e44c0-e260-11e6-a446-0d180dc59d42/things/7c236110-e260-11e6-bac1-91ed518c84d3/data/0

Topics

  • Jedes Topic hat mindestens 1 Zeichen

  • Leerzeichen sind erlaubt

  • Topic-Name ist case-sensitiv

  • Ein einzelner Forward-Slash / ist erlaubt.

Wildcards

  • Ein Client kann mehrere Topics auf einmal abonnieren

  • Wildcards sind nicht beim Publishing erlaubt

  • Single Level Wildcard: +

    • Match für irgendeine Zeichenkette in diesem Level

  • Multi Level Wildcard: #

    • Match für beliebige Topic-Levels

Single Level: +

home/groundfloor/+/temperature
MATCH:    home/groundfloor/kitchen/temperature
MATCH:    home/groundfloor/bathroom/temperature
NO MATCH: home/firstfloor/kitchen/temperature
NO MATCH: home/groundfloor/kitchen/fridge/temperature

Multi Level: #

home/groundfloor/#
MATCH:    home/groundfloor/kitchen/temperature
MATCH:    home/groundfloor/bathroom/temperature
NO MATCH: home/firstfloor/kitchen/temperature
MATCH:    home/groundfloor/kitchen/fridge/temperature

Topic mit $ Präfix

  • Die Benennung von Topics ist frei, ausgenommen Topics mit $ Präfix

  • Nicht standardisiert, interne Statistiken am MQTT Broker

  • Kein Publish, bei Subscription auf # ausgeblendet

$SYS/broker/clients/connected
$SYS/broker/clients/disconnected
$SYS/broker/clients/total
$SYS/broker/messages/sent
$SYS/broker/uptime

Good practices

  • Verwende kein führendes Forward Slash (/)

  • Verwende keine Leerzeichen im Topic

  • Topic kurz und prägnant benennen

  • Verwende nur ASCII, vermeide nicht druckbare Zeichen

Good practices

  • Nutze eine Id oder ClientId im Topic-Namen

  • Abonniere nicht #

  • Berücksichtige die Erweiterbarkeit

  • Verwende spezifische Topics statt zu allgemein gehaltener

Homie Convention

Es gibt eine "opinionated" Konvention, die für SmartHome praktisch erscheint

A lightweight MQTT convention for the IoT
— homieiot

Quality of Service

  • Eine Vereinbarung zw. Sender und Empfänger über die Garantie der Zustellung

  • MQTT kennt 3 QoS Level:

    • (0) At most once - bestenfalls einmal

    • (1) At least once - mindestens einmal

    • (2) Exactly once - genau einmal

Warum ist QoS wichtig?

  • Eines der zentralen Features von MQTT

  • Erleichtert Kommunikation in unzuverlässigen Netzwerken

    • Behandelt erneuten Versand und Zustellgarantie

  • Erlaubt dem Client eine für ihn passende Wahl

    • Anwendungslogik und Zuverlässigkeit seines Netzwerks

QoS Level 0 - At most once

  • Zustellung wird nicht garantiert, es können Verluste auftreten

  • Beispielsweise sinnvoll für kontinuierliche Sensordaten

  • Ausreichend für viele Anwendungsfälle

  • Client sendet PUBLISH, keine Server-Antwort

QoS Level 1 - At least once

  • Zustellung wird garantiert, aber Duplikate sind möglich

  • Client sendet PUBLISH, Server antwort mit PUBACK

QoS Level 2 - Exactly once

  • Es wird die einmalige Zustellung sichergestellt

  • Auch für kritische Geschäftsabläufe sinnvoll

  • Client sendet PUBLISH mit QoS 2, Server antwortet mit PUBREC

  • Client reagiert mit PUBREL, Server antwortet mit PUBCOMP

MQTT Pakete je QoS Level

mqtt qos

QoS - Gut zu wissen…​

  • Der Sender ist verantwortlich für erneuten Versand

  • Der Empfänger muss für QoS jeweils korrekt antworten

  • Packet Id sind eindeutig je Client

  • Downgrade von QoS bei unterschiedlichen Leveln der clients

QoS - Good Practices

Verwende QoS 0, falls…​

  • bei einer in der Regeln stabilen Verbindung zw. Sender und Empfänger

    • Beispiel: Test client oder Frontend über LAN

  • einige verlorengegangene Nachrichten nicht relevant sind

    • Beispiel: in kurzen Intervallen gesendete Daten

  • kein Queing erforderlich ist

    • Für abgekoppelte Clients mit QoS 1,2 und persistenter Sitzung

Verwende QoS 1, falls…​

  • jede Nachricht erforderlich ist und Duplikate behandelt werden können

    • QoS 1 ist das am häufigsten verwendete Level

  • der Overhead von QoS 2 nicht akzeptabel ist

Verwende QoS 2, falls…​

  • es zwingend erforderlich ist, jede Nachricht nur genau einmal zu erhalten

    • Beispiel: Buchungsdaten eines Kunden dürfen nicht mehrfach verarbeitet werden

  • Hinweis: Qos 2 hat deutlichen Overhead und verzögert den Ablauf

Persistente Sitzung

  • Subscriptions werden normalerweise bei Reconnect verworfen

  • Der Client muss die Topics daher erneut abonnieren

  • Problematisch für eingeschränkte Geräte bei Verbindungsverlust

  • Eine Persistent Session speichert diese Information für den Client

  • Bei Reconnect erhält der Client alle Information

Gespeicherte Sitzungsinformationen

  • Existenz einer Sitzung, auch ohne Subscriptions

  • Alle Subscriptions

  • Alle QoS 1,2-Nachrichten ohne Client-Bestätigung

  • Alle neuen QoS 1,2-Nachrichten, die der Client verpasst hat

  • Alle empfangenen QoS 2-Nachrichten ohne Betätigung für den Client

Starten/Beenden einer Persistenten Sitzung

  • Steuerung bei CONNECT über das cleanSession Flag

  • cleanSession = true: keine persistenze Sitzung

    • alle Nachrichten gehen bei DISCONNECT verloren

  • cleanSession = false: persistenze Sitzung

    • bei Reconnect werden die vorhandenen Informationen geliefert

  • Client erkennt eine vorhandene Sitzung bei CONNACK am sessionPresent flag

Persistente Sitzung auf Client-Seite

  • Alle QoS 1,2-Nachrichten ohne Broker-Bestätigung

  • Alle empfangenen QoS 2-Nachrichten ohne Betätigung für den Broker

Good practices

Wann sollte eine persistente Sitzung verwendet werden und wann nicht

Persistente Sitzung

  • Ein Client muss alle Nachrichten erhalten, selbst wenn er offline ist.

    • Der Broker soll die Nachrichten in einer Warteschlange solange vorhalten

  • Ein Client hat eingeschränkte Ressourcen und der Broker soll seine Subscription halten

    • zur schnelle Wiederaufnahme der Kommunikation nach der Unterbrechung

  • Der Client soll nach dem Reconnect alle Qos 1 und 2 Nachrichten verarbeitet.

Clean Session

  • Ein Client abonniet nicht, sondern sendet nur Nachrichten an Topics

    • Er benötigt keinerlei Sitzungsinformationen, auch nicht für QoS 1,2

  • Ein Client soll explizit keine Nachrichten für seine Offline-Zeit erhalten

Retained Messages

  • Bei Subscriptions ist unklar, ob und wann eine Nachricht eintreffen wird

  • Der Client ist im Unklaren über den aktuellen Status.

  • Hierfür sind sog. Retained Messages nützlich

Retained Messages

  • Eine Retained Message ist eine normale MQTT Nachricht mit retained Flag

  • Der Broker speichert die letzte Retained Message und QoS Level für das Topic

  • Jeder Subscriber erhält die Nachricht direkt nach SUBSCRIBE

  • Gilt auch für Wildcard Subscriptions, das retained Flag wird mitgeliefert

  • Kein Zusammenhang mit persistenten Sitzungen

  • Löschung durch Senden einer Retained Message mit 0-byte Payload

Warum und wann sollte man Retained Message verwenden?

  • Wenn neue Subscriber ohne Wartezeit sofort eine Nachricht erhalten sollten

    • Nützlich bei Status-Updates auf geräte-individuellen Topics

    • Ähnliches gilt bei Clients, die Daten in Intervallen senden

  • Ohne Retained Messages müssen neue Subscriber ein Publish Interval abwarten

Last Will and Testament

  • MQTT wird oft in Szenarien mit unzuverlässigen Netzen genutzt.

  • Daher wird angenommen, dass Clients ab und zu unsauber abbrechen

    • durch Verbindungsverlust, leere Batterie etc.

  • Daher wäre eine Information hilfreich über DISCONNECT oder unsauberem Ende

  • Hierfür ist Last Will and Testament (LWT) nützlich

Last Will and Testament

  • LWT wird zur Benachrichtung anderer Clients über unsaubere Abbrüche verwendet

  • Jeder Client kann seinen LWT mit einer normalen CONNECT spezifizieren

  • Der Broker benachrichtigt die Subscriber auf das LWT Topic bei abruptem Abbruch

  • Die gespeicherte LWT Nachricht wird bei korrektem DISCONNECT verworfen

Spezifizieren einer LWT Nachricht für einen Client

mqtt packet connect

Wann sendet ein Broker die LWT Nachricht?

  • Ein I/O Fehler oder Netzwerkfehler wird vom Server festgestellt

  • Der Client konnte nicht innerhalb der KeepAlive Zeit kommunizieren

  • Der Client beendet die Verbindung ohne vorherige DISCONNECT Nachricht

  • Der Server beendet die Verbindung aufgrund eines Protokollfehlers

Good Practice - Wann sollte man LWT verwenden?

  • Benachrichtigung interessierter Clients über Verbindungsverluste

  • In realen Projekten verwendet mit Retained Messages zur Statusüberwachung

    • Client meldet seinen Status mit retained und setzt LWT retained auf dasselbe Topic

    • Mit der Retained Message online und der LWT Nachricht offline ist der Status stets aktuell.

Keep Alive & Client Take-Over

Problem halb-offener TCP Verbindungen

  • Über TCP wird garantiert dass Pakete "zuverlässig, geordnet und geprüft" transferiert werden

  • Es ist möglich, dass ein Kommunikationspartner mit dem anderen aus dem Tritt kommt

    • Oft durch einen Crash auf einer Seite oder durch Übertragungsfehler

    • Dieser Status wird halb-offene Verbindung genannt

Problem halb-offener TCP Verbindungen

  • Entscheidend: der funktionierende Part ist nicht darüber informiert wird

    • Er sendet weiterhin Daten oder warten auf Bestätigung

  • Problem verschärft durch Behandlung von TCP in mobile Netzwerke und Satelliten-Links

MQTT Keep Alive

  • MQTT bietet keep alive zur Sicherstellung der offenen Verbindung zwischen Broker und Client

  • Client setzt ein Intervall in Sekunden und meldet es dem Broker bei CONNECT

  • Das Intervall ist der längste mögliche Zeitraum ohne Nachrichtenverstand

  • Client ist verantwortlich und muss bei Fehlen anderer Nachrichten ein PINGREQ senden

  • Broker muss dann mit PINGRESP antworten

Gut zu wissen

  • Der Broker sendet LWT, wenn kein PINGREQ oder andere Nachrichten eintreffen

  • Der Broker muss die Verbindung bei Ausbleiben von Nachrichten schließen

  • Der Client ist verantwortlich für das Setzen des richtigen keep alive Werts.

  • Die längste keep alive Zeit ist 18h 12m 15s (65535 Sekunden)

  • Mit 0 wird der Keep Alive Mechanismus deaktiviert

Client Take-Over

  • Ein DISCONNECTED Client wird meist versuchen, sich erneut zu verbinden

  • Der Broker könnte eine halb-offene Verbindung zum gleichen Client haben

  • MQTT wird dann einen sog. Client Take-Over ausführen

    • Der Broker schließt die vorherige Verbindung und verbindet den neuen Client

    • Damit wird eine Blockade durch halb-offene Verbindungen verhindert

Beispielarchitektur

  • Internes Netzwerk mit Sensoren

  • Eine Gruppe Sensoren mit Gateway (Raspi)

  • Übergabe an Cloud über IoT-Gateway (Raspi)

  • Keine Zugriffe von innen auf externen Broker.

  • Keine Zugriffe von außen auf interne Geräte.

MQTT Clients

Einfaches Setup mit Raspberry Pi

  • Raspberry Pi

  • Standard Jessie Lite Image

  • Mosquitto (MQTT Broker)

  • optional: Avahi Daemon (Multicast DNS)

  • ⇒ "attraktor-gw0.local:1883"

Vermeidung von Sicherheitsproblemen/Aufwänden

  • keine direkten Zugriffspfade aus dem Internet auf Geräte

  • Entkopplung aller Geräte über Publish/Subscribe Paradigma

  • Sicherung gegen Abhören/Verändern mit Verschlüsselung

  • Sicherung gegen unbekannte Clients mit Authentifizierung

  • Sicherung gegen unerlaubte Zugriffe mit Autorisierung.

MQTT Broker Demo Aufbau (Start)

mosquitto setup1

MQTT Broker Demo Aufbau (Demo-Broker)

mosquitto setup2

MQTT Broker Demo Aufbau (Bridge)

mosquitto setup3

MQTT Broker Demo Aufbau (TLS Bridge)

mosquitto setup4

MQTT Broker Demo Aufbau (Auth²)

mosquitto setup5

Security…​ First!

Security is a not a product, but a process.' It’s more than designing strong cryptography into a system; it’s designing the entire system such that all security measures, including cryptography, work together.
— Bruce Schneier

Security…​ First!

  • Authentifizierung

  • Autorisierung

  • Verschlüsselung

  • Absicherung

MQTT Security Grundlagen

  • Authentifizierung mit Username und Passwort

  • Autorisierung

  • Verschlüsselung mit TLS / SSL

Authentifizierung

Authentication is the act of conforming the truth of an attribute of a single piece of data or entity.
— Wikipedia

Authentifizierung mit MQTT

mqtt packet connect auth

Authentifizierung mit MQTT

mqtt packet connack

Autorisierung

  • Konfigurationen am Broker

  • Autorisierung kann den Zugriff auf Topics für Publish/Subscribe beschränken

  • Black- und Whitelists

  • Charakteristiken von Nachrichten ebenfalls einschränkbar (Retained, QoS)

  • OAuth 2.0 (Autorisierung mit Access Tokens über Autorisierungsserver)

Verschlüsselung

TLS v1.2 - Transport Layer Security

  • TLS mit X.509 Zertifikaten

  • TLS-PSK (Pre-shared Keys)

Overhead durch Verschlüsselung

in BytesQoS 0Qos 1QoS 2

ohne Verschlüsselung

72

78

86

TLS-PSK

1172

1224

1331

TLS/SSL

3742

3777

3843

MQTT over TLS mit Mosquitto

  • TLS mit selbst signierten Zertifikaten

  • TLS mit Let’s Encrypt Zertifikaten für öffentliche Broker

Zertifikate erstellen

Selbst signierte Zertifikate
$ wget https://github.com/owntracks/tools/raw/master/TLS/generate-CA.sh .
$ bash ./generate-CA.sh

Zertifikate erstellen

Öffentliche und valide Zertifikate mit Let’s Encrypt
Let's Encrypt für Mosquitto: https://goo.gl/hFYrtH

$ wget https://dl.eff.org/certbot-auto
$ chmod a+x certbot-auto
$ ./certbot-auto certonly --manual

# Enter your domain name (you need to own it & have access to the webserver)
# Follow the instruction for the ACME challenge
# Wait for the certificate generation
# copy ca-, cert- und privkey- Files to the respective mosquitto folder.

Entscheidungshilfen

Mein Gerät kann nur HTTP

  • Lösen mit einer HTTP over MQTT Fassade

  • bieten Clouddienstleister an.

  • Es würde am Gateway ein kleiner Node-Server genügen, der HTTP-Anfragen in MQTT übersetzt.

Ich zeige alle 2 Minuten aktuelle Wetterdaten an

  • Die Wetterdaten ändern sich in 2 Minuten

  • Also ist das Polling und die direkte Anzeige per HTTP OK.

  • CoAP als leichtgewichtigere Alternative lohnt sich aufgrund fehlender Hochfrequenz nicht.

  • MQTT sorgt für Entkopplung, liefert in diesem Fall keinen Vorteil.

  • Sobald mehrere Datenempfänger vorgesehen sind, lohnt sich eine Entkopplung mit MQTT

Mein Inertialsensor soll alle 10 Millisekunden Daten liefern

  • Ideal ist die Verschaltung für eine Funktion möglich physikalisch nah.

  • Herausforderungen für ein Wearable und entkoppelter nicht blockierender Aufzeichnung

  • MQTT ist leichtgewichtig genug und publiziert sehr schnell

  • Ein weiterer Prozess zeichnet kontinuierlich auf (Zeitreihen-DB)

  • Weitere Prozesse für Anzeige von Stichproben, etwa auf einem OLED des Wearable.

Anwendungsfälle

UC: Verteilter optischer und akustischer Tür-Alarm

UC 1 - Verteilter Tür-Alarm

  • Bewegungssensor, Mikrofon für Türklingel oder einfacher

  • Private Benachrichtigung im Haus und unterwegs per App

  • TinkerForge: Raspi, Brickd, Mosquitto, NodeRed

  • Raspberry Pi mit Sound-Ausgabe, Zero mit OLED-Alarmanzeige.

Entscheidungshilfen 1

  • Technische Lösung für die Erkennung Türklingel ist zweitrangig.

  • Der Sensor hat nicht die Aufgabe, die interessierten Client zu kennen.

  • Wir möchten nicht ständig den Sensor auf Klingelstatus abfragen.

  • Anwendungsfall direkt realisierbar mit MQTT und den Aktoren.

  • Prototyping mit Node-Red, später ersetzen durch technische Erkennung.

Entscheidungshilfen 2

  • Einfacher (dummer) Sensor, der ein Gateway benötigt.

  • Leichgewichtige MQTT-Nachricht genügt, Interpretation auf dem Client.

  • Die Clients teilen sich eine Schnittstellenvereinbarung und ein Topic.

  • Senden an App über verschlüsselt per Bridge angeschlossenen Broker.

  • Alternativ Nutzen bestehender Kanäle, Einsatz von MQTTwarn für Telegram etc.

Entscheidungshilfen 3

  • Einfach bleiben: Es wird keine Aufzeichnung für Langzeitauswertung benötigt.

  • Entscheidung über Alarm-Verlässlichkeit mittels QoS-Level

  • Den Zustand der Anlage kann man über LWT überwachen.

  • Letzter bekannter Alarm-Status beim Client-Start mit Retained Message.

Anwendungsfälle

UC: Küchenrezepte halb-automatisch zusammenstellen

UC 2 - "Kitchenlog"

  • Zutaten abwiegen und gemessenes Gewicht kontinuierlich senden

  • Per Knopfdruck Gewicht und Zutat speichern,

  • Wägezelle und Dual Button

  • TinkerForge: Raspi, Brickd, Mosquitto, NodeRed, Datenbank, UI

  • Protokoll, Rezeptdatenbank öffentlich, privates Netzwerk

Anwendungsfälle

UC: Wetter-Dashboard mit MyDevices Cayenne

UC 3 - Cayenne Wetter-Dashboard

  • Mit MyDevices App Wetterdaten darstellen

  • Öffentliche Oberfläche, privates Netzwerk

  • Temperatur, Luftfeuchtigkeit üer Sense-Hat

  • Cayenne Account und UI-Widgets

  • Manuelle Versorgung mit MQTT

UC 3 - Cayenne Wetter-Dashboard

  • Proxy Dienst für Sense-Hat Übersetzung in Cayenne-Topics

  • Entkopplung über MQTT Bridge

  • Test mit MQTT.fx und Javascript Test-Script

  • Alternativ Transformation und Entsorgung mit Node-RED

Anwendungsfälle

UC: Dashboard für Tinkerforge-Sensoren

UC 4 - Dashboard-Oberfläche für Tinkerforge

Fragestellung

tfmqttv draft1

Schritt 1 (Abgrenzung)

tfmqttv draft2

Schritt 2 (TinkerForge)

tfmqttv draft3

Schritt 3 (Keine Hardware am Server!)

tfmqttv draft3b

Schritt 4 (Brick MQTT Proxy)

tfmqttv draft4

Schritt 5 (Finaler Aufbau)

tfmqttv

Weitere Ressourcen

Cloud Dienstleister

  • MyDevices Cayenne: https://mydevices.com

  • Xively

  • InitialState.com + Flowthings.io

  • Amazon AWS IoT

  • IBM Bluemix Message Hub

Q & A

Vielen Dank für Eure Aufmerksamkeit

E-mail: klaus@pittig.de

Twitter: @jforge