Seite 2: Autorisierung mit OAuth 2.0

Inhaltsverzeichnis

Eine weitere populäre Methode zur Absicherung von MQTT ist der Einsatz von OAuth 2.0. Dabei handelt es sich um ein Autorisierungs-Framework, das den Zugriff von Ressourcen für einen sogenannten Resource Owner regelt, ohne dabei Credentials wie die Kombination aus Benutzername und Passwort zur Ressource zu übermitteln.

Ursprünglich haben die Macher OAuth 2.0 nicht für den Einsatz von MQTT konzipiert, sondern für das Internet-Standardprotokoll HTTP. OAuth 2.0 definiert eine Reihe sogenannter "Grant Types" beziehungsweise "Flows", und der "Client Credentials Flow" eignet sich perfekt für den Einsatz mit MQTT.

Bei OAuth 2.0 fallen den Systemen unterschiedliche Rollen zu, die beim Einsatz mit MQTT folgende sind:

• Der Resource Server stellt Ressourcen bereit, die einen authentifizierten und autorisierten Zugriff voraussetzen. Im Falle von MQTT ist das ein MQTT-Broker.
• Der Resource Owner ist ein Mensch (oder eine Maschine), dem die Ressource gehört, auf die der Zugriff erfolgt. Dabei ist jedoch nicht der Administrator des Brokers gemeint, sondern der Benutzer, der auf bestimmte Teile des MQTT-Topic-Baums eine Publish- oder Subscribe-Aktion durchführen möchte.
• Ein Client ist die Applikation, die auf die Ressourcen am Resource Server für einen Resource Owner zugreifen möchte. Dabei handelt es sich im Normalfall um die MQTT-Client-Applikation.
• Der Authorization-Server ist ein zentraler Server, der den Zugriff auf alle Ressourcen steuert und regelt. Er kann sogenannte Tokens – kryptische Zeichenketten, die für den Zugriff auf die Ressourcen notwendig sind – ausstellen und zurücknehmen.

Dahinter steckt die Grundidee, dass der MQTT-Broker niemals mit Authentifizierungsinformationen in Berührung kommt, sondern nur sicherstellt, dass ein MQTT-Client tatsächlich die von ihm angefragte Operation durchführen darf.

Um den Zugriff und die Berechtigungen eines MQTT-Clients für den -Broker zu regeln, stellt der Authorization-Server sogenannge Access Tokens aus, die der Client benutzt, um sich beim Broker anzumelden. Das geschieht bei MQTT wie üblich mit dem Senden eines MQTT CONNECT-Pakets.

Der MQTT-Client meldet sich beim Authorization-Server an und bekommt ein Access Token zurück, das alle Eigenschaften kapselt, die zur Authentifizierung und Autorisierung des Clients am MQTT-Broker nötig sind. Anschließend meldet sich der Client beim Broker mit diesem Token an. Der Broker kann das Token validieren und dem Client bestimmte Operationen wie das Senden oder Abonnieren von Nachrichten erlauben oder untersagen.

Die Vorteile des Einsatzes von OAuth 2.0 in Verbindung mit MQTT sind:

• Der MQTT-Broker kommt niemals mit den Credentials des Clients in Berührung.
• Die Access Tokens haben nur eine begrenzte Gültigkeit, die bei MQTT meist im Stundenbereich liegt.
• Der Authorization-Server kann die Tokens jederzeit zurücknehmen.
• Derselbe Mechanismus lässt sich verwenden, um beispielsweise den Zugriff auf REST APIs und andere Applikationen zu regeln. Daher müssen Administratoren und Entwickler die Autorisierung und Authentifizierung nicht für jedes System von Neuem konzipieren.

Bei OAuth 2.0 handelt es sich um eine äußerst geeignete Methode, um MQTT abzusichern, da sich sowohl die Authentifizierung als auch die Autorisierung einfach abbilden lassen. Der Revokationsprozess ist bei OAuth im Vergleich zu X.509-Client-Zertifikaten deutlich einfacher. Zudem entfallen die Herausforderungen bezüglich der Provisionierung.

Verschlüsselung der Daten

Neben der Authentifizierung und Autorisierung kann eine zusätzliche Sicherheitsebene auf Applikationsschicht bei MQTT eingeführt werden, nämlich die Verschlüsselung.

Ein populärer Mechanismus für eine erhöhte Sicherheit in MQTT-Systemen ist die Nutzdatenverschlüsselung – speziell, wenn damit zu rechnen ist, dass nicht vertrauenswürdige MQTT-Clients an der Kommunikation teilnehmen.

Das ist besonders hilfreich für Geräte mit limitierten Ressourcen, die keine Verschlüsselung des Transportkanals über TLS durchführen können, weil sie entweder zu wenig Speicher oder eine unzureichende Rechenleistung aufweisen. Die Geräte können über die Verschlüsselung der Nutzdaten eines MQTT-Pakets zumindest sicherstellen, dass Angreifer die Daten nicht im Klartext lesen können.

Bei MQTT ist von Nutzdatenverschlüsselung die Rede, wenn nur der Inhalt des Payload-Feldes einer MQTT PUBLISH-Nachricht verschlüsselt wird. Die Metadaten des Pakets bleiben dagegen intakt – inklusive des MQTT Topic.

Ein MQTT PUBLISH-Paket besteht aus Nutzdaten und Metadaten. Dieses Paket kommt bei MQTT zum Einsatz, um Daten von einem Client zu einem MQTT-Broker zu versenden, der das Paket anschließend an die Subscriber verteilt.

Von einer solchen Verschlüsselung profitiert nur das MQTT PUBLISH-Paket, andere MQTT-Pakete wie SUBSCRIBE zum Abonnieren von Topics eignen sich nicht für eine Verschlüsselung. Da das MQTT-Protokoll den Vorgang nicht direkt vorsieht, muss die Applikation die Verschlüsselung der Nutzdaten übernehmen. Der Empfänger einer verschlüsselten Nachricht muss zudem in der Lage sein, sie zu entschlüsseln. Bei symmetrischen Verschlüsselungsverfahren, beispielsweise über ein Passwort, muss dieses auch dem Empfänger bekannt sein. Eine Alternative bietet eine asymmetrische Verschlüsselungsmethode, beispielsweise über Public-/Private-Key-Verfahren.

Generell ist der Einsatz von Nutzdatenverschlüsselung in erster Linie in Verbindung mit TLS sinnvoll. Denn wenn kein TLS zur Sicherung des Kommunikationskanals verwendet wird, schützt auch eine Verschlüsselung nicht vor Man-in-the-Middle- oder Replay- Attacken. Dennoch bietet die Verschlüsselung auch ohne TLS Vorteile, da zumindest die Daten nicht von Angreifern mitgelesen werden können.