Mit MQQ und TLS in die Cloud
Eine sichere IoT-Cloud-Anwendung realisieren
Wie auch immer das IoT konfiguriert sein wird – es wird Mengen mit Mikrocontrollern bestückter Geräte geben, die über große Bereiche verteilt und mit Cloud-basierten Daten-Hubs verbunden sind. Hierfür benötigen die Ingenieure ein Verbindungs-Protokoll, das kompakt, einfach, robust und sicher ist.
Ablauf einer einfachen Publish/Subscribe-Operation (Bild: HCC Embedded)
Ein erstklassiger Kandidat, der diese Eigenschaften mitbringt, ist MQTT (Message Queue Telemetry Transport). Dieses einfache Protokoll erlaubt es eingebetteten Geräten, Nachrichten in der Cloud zu publizieren und zu empfangen. Es zeichnet sich gegenüber anderen Protokollen wie etwa HTTP durch einen geringen Paket-Overhead aus, wodurch es sehr effizient ist und sich für die Verwendung in stromsparenden Umgebungen anbietet. Um die Übertragung von MQTT-Nachrichten sicher zu machen, wird TLS (Transport Layer Security) benutzt. TLS ist der Standard für die sichere Kommunikation per Internet und kommt beim Surfen im Internet ebenso zum Einsatz wie bei Email und anderen Anwendungen. TLS sorgt auf folgende Weise für eine sichere Kommunikation:
• Authentisierung der an der Kommunikation beteiligten Parteien, um die Identität der Beteiligten zu verifizieren
• Verschlüsselung der Kommunikation, um sicherzustellen, dass die Nachrichten von keinem Dritten verstanden werden können
• Garantie der Verbindungssicherheit zwischen zwei Knoten, wodurch es sich für den Einsatz mit einer Client-Server-Technologie wie MQTT eignet.
MQTT im Überblick
Das Publish/Subscribe-System von MQTT besteht aus vielen Clients, die mit einem als Broker (Makler) fungierenden Server verbunden sind. Ein Client ist sowohl Produzent als auch Konsument von MQTT-Daten. Bild 1 zeigt den Ablauf einer einfachen MQTT-Publish/Subscribe-Transaktion. Das MQTT-Messaging-Protokoll wurde auf der Basis einiger Grundprinzipien gestaltet:
• Ein Message Broker fungiert als Mittler zwischen einem Publisher (Veröffentlicher) eines Topics und einem Subscriber (Abonnent) dieses Topics. Er ist ein Server und bildet das zentralisierte System, über das die Client-Daten übertragen werden.
• Ein Subscriber kann ein oder mehrere Topics ‚abonnieren‘.
• Eine veröffentlichte Nachricht kann an mehrere Subscriber versendet werden, die am Empfang von Informationen zu einem Topic interessiert sind.
• Ein Subscriber kann Nachrichten von mehreren Publishern empfangen.
• Ein Subscriber kann das Abonnement eines Topics jederzeit aufheben.
Die MQTT-Version 3.1 erlaubt die Verwendung eines Benutzernamens und eines Passworts in einem Paket, um einem Client die Möglichkeit zu geben, sich beim Broker zu authentisieren. Ein Client veröffentlicht mit einem von der Applikation definierten ‚Topic‘ frei formatierte Daten an einen Broker, und der Broker überträgt diese Daten anschließend an all jene Clients, die dieses Topic abonniert haben. Die Verwendung von Wildcards macht es möglich, mit einer einzigen Subskription Daten von mehreren Clients zu empfangen. Ebenso können Daten aus einer Publish-Aktion an mehrere Clients weitergeleitet werden. Bild 2 zeigt exemplarisch, wie ein Mobiltelefon mit einem entfernten Auto kommunizieren könnte, um eine Fahrzeugtür zu verriegeln.
• Die auf dem Smartphone des Anwenders laufende App fordert das Auto auf, die Türverriegelung das Topic ‚Message_Car001‘ abonnieren zu lassen.
• Der Broker erhält eine Anfrage.
• Car001 erhält durch Subskription die Nachricht.
• Das Auto verriegelt die Tür und sendet eine Bestätigungsmeldung.
• Die App erhält die Bestätigung.
Die Nutzdaten der Nachricht enthalten die Anweisung zum Verriegeln der Tür. Über dasselbe Publish/Subscribe-System kann außerdem eine ganze Reihe weiterer Befehle versendet werden.
Verwendung von MQTT zum Steuern und Überwachen eines Kfz-Türverriegelungssystems (Bild HCC Embedded)
Dienstqualität (Quality of Service – QoS)
MQTT bietet drei QoS-Levels, die einen Kompromiss bieten zwischen dem Kommunikationsaufwand und der Sicherheit, dass eine Nachricht ankommt. Level 0 bietet nach dem Prinzip ‚Fire and Forget‘ keinerlei Gewähr, dass die gesendete Nachricht zugestellt wird. Level 1 garantiert, dass die Nachricht mindestens einmal ankommt, eventuell aber auch mehr als einmal. Level 2 garantiert, dass die Nachricht genau einmal empfangen wird. Die Entscheidung für eine MQTT-Implementierung mit Unterstützung für alle drei Levels verleiht dem Entwickler die Flexibilität zur Verbesserung gemäß seinen individuellen Datenanforderungen.
End-to-End Security mit TLS
Das MQTT-Protokoll enthält kein Security-Konzept, sondern stützt sich zum Garantieren der Verbindungssicherheit allein auf die Transportschicht. Das TLS-Protokoll richtet zwischen Client und Broker eine abgesicherte Verbindung ein, die anschließend von MQTT genutzt wird. Die Verwendung von TLS ist für den Benutzer des MQTT-API vollkommen transparent, wenn man von der Wahl des zu benutzenden Transportprotokolls (TCP-Portnummer) absieht. Das TLS-Protokoll ist weitreichend konfigurierbar: Client und Broker handeln beim Aufbau der Verbindung ein für beide Seiten akzeptables Security-Level aus. Client und Server können bestimmen, welches Security-Level sie für ihren Datenaustausch minimal akzeptieren. In der Regel authentisiert sich der Server beim Client mithilfe von Zertifikaten, woraufhin beide wichtige Informationen austauschen. Sie einigen sich für die Konversation auf einen geeigneten Verschlüsselungs-Algorithmus (zum Verschleiern der Daten) und einen Hash-Algorithmus (um sicherzustellen, dass die Daten nicht verändert werden). Das tatsächliche Maß an Schutz, das dem Benutzer geboten wird, hängt von den jeweils ausgehandelten Algorithmen ab.
Eine gravierende Schwachstelle der IoT-Sicherheit
Eine bei den Security-Strategien häufig übersehene Schwachstelle ist die Qualität der MQTT-Messaging-Software selbst. Die seit einiger Zeit zu beobachtende Flut gravierender Sicherheitsverletzungen hat ihre Ursache nicht etwa in gehackten Algorithmen, sondern in der unzureichenden Qualität des Quellcodes (meist geht es um die Implementierung des TLS-Protokolls). Vorfälle wie der Heartbleed-Hack zeigen, dass Code von mäßiger Qualität etwaigen Hackern Schlupflöcher öffnen kann. Aus diesen Gründen ist es vorteilhaft, sich für einen Anbieter zu entscheiden, der qualitativ hochwertige Softwareentwicklungs-Prozesse anwendet und dies auch nachweisen kann. HCC Embedded hat ein MQTT-Protokoll implementiert, das auf seinem TLS-Stack und seinem vertrauenswürdigen, MISRA-konformen TCP/IP-Stack aufbaut, und bietet über den gesamten Lebenszyklus Nachweise zur Validierung seiner Qualitätszusagen. HCC kann außerdem basierend auf der MQTT-Spezifikation 3.1.1 ein MQTT-Konformitäts-Statement für jede in Anhang B spezifizierte Anforderung vorlegen. MQTT ist ein kompaktes, vielseitiges Kommunikations-Protokoll, das im Verbund mit einem Security-Mechanismus wie TLS effiziente, zuverlässige und sichere Konnektivität für zahllose kleine Geräte bereitstellen kann. Allerdings sind nicht alle MQTT-Implementierungen gleich. Eine Applikation muss sich auf einer Plattform aus qualitativ hochwertiger, zuverlässiger Software stützen, damit Sicherheit und Zuverlässigkeit gewährleistet sind.
Autor: David Brooks,
Director Sales & Marketing,
HCC Embedded
www.hcc-embedded.com
