Verbesserte Authentifizierung – MQTT 5.0 Neue Funktionen

MQTT v5 bringt viele neue Funktionen, und wir werden unser Bestes geben, um diese Funktionen auf leicht verständliche Weise zu präsentieren und die Auswirkungen dieser Funktionen auf Entwickler zu diskutieren. Bisher haben wir diese besprochen neue Funktionen von MQTT v5. Heute werden wir weiter diskutieren: erweiterte Authentifizierung.

Im IoT-Szenario ist sicheres Design ein sehr wichtiger Teil des Prozesses. Das Durchsickern sensibler Daten oder die unbefugte Kontrolle von Edge-Geräten sind nicht akzeptabel, aber im Vergleich zu anderen Szenarien hat das IoT-Projekt immer noch die folgenden Einschränkungen:

  • Kann Sicherheit und hohe Leistung nicht ausbalancieren;
  • Verschlüsselungsalgorithmen erfordern mehr Rechenleistung, aber die Leistung von IoT-Geräten ist oft sehr begrenzt;
  • Die Netzwerkbedingungen des IoT sind oft viel schlechter als zu Hause oder im Büro.

Um die obigen Fragen zu lösen, muss die MQTT-Protokoll bietet die einfache Authentifizierung und die erweiterte Authentifizierung, wodurch Geräte auf Anwendungsebene einfach zu validieren sind.

Einfache Authentifizierung

Das MQTT CONNECT-Paket verwendet den Benutzernamen und das Passwort, um die grundlegende Netzwerkverbindungsauthentifizierung zu unterstützen, die als einfache Authentifizierung bezeichnet wird. Diese Methode kann auch verwendet werden, um andere Formen der Authentifizierung zu hosten, beispielsweise die Bereitstellung des Passworts als Token.

Nach Erhalt des CONNECT-Pakets kann der Broker die Legitimität des Kunden anhand des enthaltenen Benutzernamens und Passworts überprüfen, um die Sicherheit des Geschäfts zu gewährleisten.

Im Vergleich zur erweiterten Authentifizierung hat die einfache Authentifizierung einen geringen Rechenaufwand für Client und Server und kann für Dienste verwendet werden, bei denen die Sicherheitsanforderungen nicht so hoch und die Rechenressourcen knapp sind.

Bei dem Protokoll, das auf dem einfachen Authentifizierungsmodell von Benutzername und Passwort basiert, wissen der Client und der Broker jedoch, dass ein Benutzername einem Passwort entspricht. Ohne Verschlüsselung des Kanals ist entweder die direkte Verwendung von Klartext zur Übertragung des Benutzernamens und des Passworts oder die Methode des Hashings des Passworts anfällig für Angriffe.

Verbesserte Authentifizierung

Zur Berücksichtigung einer stärkeren Sicherheit fügt MQTT v5 eine neue Funktion hinzu erweiterte Authentifizierung. Die erweiterte Authentifizierung umfasst eine Abfrage/Antwort-Authentifizierung, die eine bidirektionale Authentifizierung des Clients und des Brokers implementieren kann. Das MQTT-Broker kann überprüfen, ob der verbundene Client ein echter Client ist, und der Client kann auch überprüfen, ob der verbundene Broker ein echter Broker ist, wodurch eine höhere Sicherheit bereitgestellt wird.

Die erweiterte Authentifizierung stützt sich auf die Authentifizierungsmethode und die Authentifizierungsdaten, um den gesamten Authentifizierungsprozess abzuschließen. Bei der erweiterten Authentifizierung ist die Authentifizierungsmethode normalerweise SASL (Simple Authentication and Security Layer) Mechanismus, der einen registrierten Namen verwendet, um Informationen einfach auszutauschen. Das Authentifizierungsverfahren ist jedoch nicht auf die Verwendung eines registrierten SASL-Mechanismus beschränkt, und der Broker und der Client können vereinbaren, einen beliebigen Abfrage/Antwort-Authentifizierungsstil zu verwenden.

Authentifizierungsmethoden

Die Authentifizierungsmethode ist eine UTF-8-Zeichenfolge zur Angabe einer Authentifizierungsmethode, und der Client und der Broker müssen die angegebene Authentifizierungsmethode gleichzeitig unterstützen. Der Client initiiert eine erweiterte Authentifizierung, indem er das Authentifizierungsverfahrensfeld zum CONNECT-Paket hinzufügt. Im Prozess der erweiterten Authentifizierung muss das zwischen dem Client und dem Broker ausgetauschte Paket das Feld für die Authentifizierungsmethode enthalten, und die Authentifizierungsmethode muss mit dem CONNECT-Paket konsistent sein.

Authentifizierungsdaten

Authentifizierungsdaten sind binäre Informationen, die verwendet werden, um mehrere Iterationen von kryptografischen Geheimnissen von Protokollschritten zu übertragen. Der Inhalt der Authentifizierungsdaten hängt stark von der konkreten Implementierung des Authentifizierungsverfahrens ab.

Verbesserter Authentifizierungsprozess

Im Vergleich zur einfachen Authentifizierung, die auf einer Interaktion zwischen dem CONNECT-Paket und dem CONNACK-Paket beruht, erfordert die erweiterte Authentifizierung einen mehrfachen Austausch von Authentifizierungsdaten zwischen dem Client und dem Broker. Daher fügt MQTT v5 das AUTH-Paket hinzu, um dies zu implementieren. Die Implementierung der erweiterten Authentifizierung basiert auf drei Arten von MQTT-Pakettypen: CONNECT, CONNACK und AUTH. Diese drei Arten von Paketen müssen das Authentifizierungsverfahren und die Authentifizierungsdaten für die bidirektionale Authentifizierung tragen.

Um den erweiterten Authentifizierungsprozess zu starten, muss der Client das CONNECT-Paket, das das Authentifizierungsverfahrensfeld enthält, an den Broker senden. Nach dem Empfang des CONNECT-Pakets kann der Broker den Austausch von Authentifizierungsdaten mit dem Client über das AUTH-Paket fortsetzen und das CONNACK-Paket an den Client senden, nachdem die Authentifizierung abgeschlossen ist.

Nicht standardmäßiges Beispiel für SCRAM-Authentifizierung

  • Client zu Server: Authentifizierungsmethode CONNECT = “SCRAM-SHA-1”, Authentifizierungsdaten = Client-First-Data

  • Server an Client: AUTH-Ursachencode = 0x18, Authentifizierungsmethode = “SCRAM-SHA-1”, Authentifizierungsdaten = Server-First-Data

  • Client zu Server: AUTH-Ursachencode = 0x18, Authentifizierungsmethode = “SCRAM-SHA-1”, Authentifizierungsdaten = Client-Final-Data

  • Server zu Client: CONNACK-Ursachencode = 0, Authentifizierungsmethode = “SCRAM-SHA-1”, Authentifizierungsdaten = server-final-data

Nicht standardmäßiges Beispiel für die Kerberos-Authentifizierung

  • Client zu Server: Authentifizierungsmethode CONNECT = “GS2-KRB5”
  • Server zu Client: AUTH-Ursachencode = 0x18, Authentifizierungsmethode = “GS2-KRB5”
  • Client zu Server: AUTH-Ursachencode = 0x18, Authentifizierungsmethode = „GS2-KRB5“, Authentifizierungsdaten = Anfangskontext-Token
  • Server an Client: AUTH-Ursachencode = 0x18, Authentifizierungsmethode = „GS2-KRB5“, Authentifizierungsdaten = Reply-Context-Token
  • Client zu Server: AUTH-Ursachencode = 0x18, Authentifizierungsmethode = „GS2-KRB5“
  • Server zu Client: CONNACK Reason Code = 0, Authentifizierungsmethode = „GS2-KRB5“, Authentifizierungsdaten = Ergebnis der Authentifizierung

Beim erweiterten Authentifizierungsprozess müssen der Client und der Broker Authentifizierungsdaten mehrmals austauschen, und jeder Austausch muss vom Authentifizierungsalgorithmus entschlüsselt und berechnet werden, sodass mehr Rechenressourcen und eine stabilere Netzwerkumgebung erforderlich sind. Daher ist es nicht für Edge-Geräte mit schwacher Rechenleistung und großen Netzwerkschwankungen geeignet, und MQTT-Broker, der eine erweiterte Authentifizierung unterstützt, muss auch mehr Rechenressourcen bereitstellen, um mit einer großen Anzahl von Verbindungen fertig zu werden.

Re-Authentifizierung

Nachdem die erweiterte Authentifizierung abgeschlossen ist, kann der Client jederzeit eine erneute Authentifizierung einleiten, indem er ein AUTH-Paket sendet. Nachdem die erneute Authentifizierung gestartet wurde, tauschen der Client und der Broker Authentifizierungsdaten aus, indem sie das AUTH-Paket austauschen, genau wie bei der erweiterten Authentifizierung, bis der Broker ein AUTH-Paket mit dem Ursachencode 0x00 (Erfolg) an den Client sendet, um anzuzeigen, dass die erneute Authentifizierung war erfolgreich. Es ist zu beachten, dass die Authentifizierungsmethode für die erneute Authentifizierung dieselbe sein muss wie bei der erweiterten Authentifizierung.

Während des erneuten Authentifizierungsprozesses können andere Pakete des Clients und des Brokers weiterhin die vorherige Authentifizierung verwenden.

Ursprünglich erschienen bei

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *