Sicherheit geht vor

Machine-to-Machine-Kommunikation aus der Sicherheitsperspektive
Kommentare

Seit der Veröffentlichung der von Edward Snowden geleakten NSA-Daten wissen wir, dass die NSA und wahrscheinlich auch alle anderen Geheimdienste jede Kommunikation überwachen, die sie in ihre virtuellen Finger bekommen. Aber wie ist es eigentlich um den Bereich Machine-to-Machine bestellt? MQTT und CoAP sind zwei der wichtigsten Protokolle in der M2M-Kommunikation. Beide nehmen wir in diesem Artikel unter die Lupe.

Geheimdienstschnüfflern dürfte es ziemlich egal sein, wer kommuniziert: Menschen mit Menschen, Menschen mit Maschinen, oder auch Maschinen mit Maschinen. Erst einmal wird alles gespeichert, was man kriegen kann – vielleicht kann man es ja irgendwann einmal gebrauchen. Da hilft nur eines: Der Schutz jeder Kommunikation, insbesondere natürlich vor dem Ausspähen.

„Sichere Kommunikation“? Was ist das denn?

Was ist das eigentlich, eine „sichere Kommunikation“? Zunächst einmal muss man wissen, wer da kommuniziert:

Identifizieren, Authentifizieren, Autorisieren: Damit man weiß, mit wem man es bei einer Kommunikation zu tun hat, muss man das Gegenüber identifizieren, zum Beispiel anhand des Benutzernamens. Danach muss der so identifizierte Kommunikationspartner beweisen, dass er auch wirklich der ist, der er zu sein vorgibt. Diese Authentifizierung kann zum Beispiel durch das Senden eines Passworts erfolgen. Wenn man davon absieht, dass das Passwort ausgespäht oder abgephisht werden kann, gilt im allgemeinen die Regel „Wer das Passwort zu einem Benutzernamen kennt, ist der entsprechende Benutzer“. Und zu guter Letzt ist die Frage zu klären, ob der Benutzer überhaupt tun darf, was er tun möchte, zum Beispiel auf bestimmte Daten zugreifen. Das nennt sich Autorisierung.

Und wie geht es weiter? Für die Definition der IT-Sicherheit greift man bekanntlich auf die drei Schutzziele zurück, die zusammen die IT-Sicherheit ausmachen: Vertraulichkeit, Verfügbarkeit und Integrität. Diese allgemein definierten Ziele lassen sich auch auf die Kommunikation beschränken.

Vertraulichkeit: Die Inhalte der Kommunikation sind nur den Teilnehmern bekannt und keinem Dritten. Die übertragenen Daten müssen also vor dem Ausspähen geschützt werden. Zu diesem Zweck stehen bekanntlich etliche bewährte kryptografische Verfahren in Form der verschiedenen Verschlüsselungssysteme (Konzelationssysteme) zur Verfügung.

Verfügbarkeit: Die Kommunikation ist zum gewünschten Zeitpunkt im erforderlichen Umfang möglich. Das ist im Allgemeinen die Aufgabe von Schichten unterhalb der hier betrachteten Protokolle. Diese können höchstens durch den Einsatz von Bestätigungen sicherstellen, dass Fehler erkannt und wenn möglich korrigiert werden. Aber wenn zum Beispiel eine physikalische Verbindung unterbrochen oder eine Funkverbindung gestört ist, sind sie machtlos. Da können sie die Nachrichten, für die sie keine Empfangsbestätigung der Gegenseite erhalten haben, noch so oft erneut senden – wo es keine Verbindung gibt, ist nun einmal auch keine Übertragung von Daten möglich.

Integrität: Die übertragenen Daten sind vollständig und unverändert beim Empfänger angekommen. Die Integrität lässt sich ebenso wie die Vertraulichkeit mithilfe kryptografischer Verfahren sicherstellen. Solange nur geprüft werden muss, ob die Daten vollständig und unverändert sind, können Message-Authentication-Codes verwendet werden. Soll außerdem geprüft werden, ob die Daten wirklich vom angeblichen Absender stammen, müssen digitale Signatursysteme verwendet werden.

Zwei M2M-Protokolle: MQTT und CoAP

Ich habe völlig willkürlich zwei M2M-Protokolle ausgewählt, deren Sicherheit ich näher betrachten werde: Message Queue Telemetry Transport (MQTT) und Constrained Application Protocol (CoAP). Beide Protokolle haben eines gemeinsam: Sie sind für die Nutzung durch sehr einfache Kommunikationsteilnehmer vorgesehen, müssen also mit oft sehr beschränkten Ressourcen auskommen – was sich mit dem Einsatz von Kryptografie nicht so gut verträgt, da die entsprechenden Verfahren oft rechenintensiv sind und die Übertragungsprotokolle meist ziemlich viele Daten übertragen.

MQTT im Überblick

MQTT wurde von Andy Stanford-Clark von IBM und Arlen Nipper von Cirrus Link Solutions entwickelt und wird seit 2013 von einer Arbeitsgruppe der Organization for the Advancement of Structured Information Standards (OASIS) als Protokoll für das Internet of Things standardisiert.

Es dient der Übertragung von Nachrichten, zum Beispiel Telemetriedaten, zwischen verschiedenen Geräten und wurde speziell für den Einsatz in ressourcenbeschränkten Geräten sowie in unzuverlässigen Netzwerken mit geringer Bandbreite und/oder hoher Latenz entwickelt. Aber auch außerhalb des IoT kommt MQTT zum Einsatz, das Protokoll wird zum Beispiel von Facebook in den Messenger-Apps verwendet.

Neben dem „normalen“ MQTT, das auf TCP/IP-Netzwerken aufbaut, gibt es noch eine Version für das nicht auf TCP/IP basierende Sensor-Netzwerk, genannt MQTT-SN (früher MQTT-S). MQTT-SN wird für drahtlose Netzwerke wie zum Beispiel Zigbee verwendet. Im Folgenden geht es nur um die TCP/IP-Version MQTT.

Publisher, Message Broker und Subscriber im Einsatz

MQTT ist ein Publish-Subscribe-Protokoll mit drei Akteuren: Der als Publisher bezeichneten Datenquelle, der als Subscriber bezeichneten Datensenke und dem zwischengeschalteten Message Broker, der für die Steuerung der Kommunikation verantwortlich ist. Der Publisher, zum Beispiel ein Temperatursensor, sendet seine Daten an einen zentralen Server, den Message Broker (publish). Von dort können die Daten vom Subscriber, zum Beispiel einer Smartphone-App, abgefragt werden (subscribe).

Ein Topic zur Auswahl von Daten

Identifiziert werden die Daten dabei über die so genannten Topics. Dabei handelt es sich um Strings, die eine Art „Betreff“ der Daten darstellen und die vergleichbar mit einem URL aufgebaut sind. Der Temperatursensor im Wohnzimmer könnte seine aktuelle Temperatur zum Beispiel unter dem Topic Wohnung/Wohnzimmer/Temperatur veröffentlichen, während der Sensor im Esszimmer das Topic Wohnung/Esszimmer/Temperatur verwendet. Und die Luftfeuchtigkeit könnte zum Beispiel unter dem Topic Wohnung/Wohnzimmer/Luftfeuchtigkeit für das Wohnzimmer und unter Wohnung/Bad/Luftfeuchtigkeit für das Badezimmer veröffentlicht werden.

Ein Subscriber, zum Beispiel eine Smartphone-App, kann sich mit dem Message Broker verbinden und bestimmte Topics abonnieren. Danach erhält die App alle Nachrichten, die darüber gesendet werden. Die gesamte Kommunikation wird dabei über die Topics abgewickelt, weder Temperatursensor noch Smartphone-App wissen voneinander.

Die Auswahl der Topics kann auch über Wildcards erfolgen, zum Beispiel liefert Wohnung/Wohnzimmer/# die Daten aller Sensoren im Wohnzimmer und Wohnung/+/Temperatur nur die Werte der Temperatursensoren, aber die aus allen Räumen.

Entwickler Magazin

Entwickler Magazin abonnierenDieser Artikel ist im Entwickler Magazin erschienen.

Natürlich können Sie das Entwickler Magazin über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist das Entwickler Magazin ferner im Abonnement oder als Einzelheft erhältlich.

Alles eine Frage der Qualität…

MQTT kennt drei Servicequalitäten (QoS-Level, Quality of Service):

  • Level 0: Es gibt keine Garantie dafür, dass eine Nachricht ankommt (was man auch als „Die Nachricht kommt höchstens einmal an“ umschreiben kann)
  • Level 1: Die Nachricht kommt mindestens einmal an
  •  Level 2: Die Nachricht kommt genau einmal an

Der Unterschied zwischen Level 1 und 2 besteht darin, dass es bei Level 1 passieren kann, dass eine Nachricht einen Client mehrmals erreicht. Je nach Anwendung sollte der passende Level gewählt werden, denn je höher der QoS-Level, desto höher ist auch die benötigte Bandbreite. Sofern es auf die Bandbreite nicht ankommt, kann man natürlich problemlos Level 2 wählen. Ansonsten ist es angeraten, entweder den Verlust mancher Nachrichten in Kauf zu nehmen oder eine Lösung für die Verarbeitung mehrfach erhaltener Nachrichten zu implementieren.

… und des letzten Willens …

Trotz des Publish/Subscribe-Ansatzes und der QoS-Level bleibt ein Problem bestehen: Was passiert, wenn Clients die Verbindung verlieren? Wenn sich zum Beispiel eine Smartphone-App neu mit dem Message Broker verbindet, weiß sie ja vielleicht gar nicht, welche Temperatursensoren es überhaupt gibt oder welche Sensoren im Wohnzimmer vorhanden und wie deren aktuellen Werte sind. Dieses Problem wird durch zwei Konzepte gelöst.

Konzept eins nennt sich Last Will and Testament. Hier kann jeder Client beim Verbinden mit dem Message Broker diesem eine Nachricht mit seinem „Letzten Willen“ schicken. Der besteht aus einem Topic und einer Nachricht, die der Message Broker im Auftrag des Clients verschickt, wenn er eine Unterbrechung der Verbindung erkennt.

Über diese „Abschiedsnachricht“ wird die Smartphone-App also zum Beispiel über den Abbruch der Verbindung zum Temperatursensor im Wohnzimmer informiert. Aber nur, wenn sie zum Zeitpunkt des Verbindungsabbruchs durch den Sensor auch mit dem Message Broker verbunden ist. Was ist, wenn der Sensor die Verbindung verliert, während die App ebenfalls offline ist? Dieses Problem wird durch die Speicherung einer Nachricht gelöst.

… und der gespeicherten Nachricht

Konzept zwei, die Retained Message – ist eine Nachricht, die vom Message Broker gespeichert und an jeden Client, der sich neu mit ihm verbindet und den jeweiligen Topic abonniert, gesendet wird. Dabei kann für jeden Topic nur eine Nachricht gespeichert werden.

So könnte zum Beispiel der jeweils letzte Sensorwert unter dem Topic Wohnung/Wohnzimmer/Temperatur oder der Status des Temperatursensors im Wohnzimmer unter dem Topic Wohnung/Wohnzimmer/Temperatur/Status gespeichert werden. Sich neu mit dem Message Broker verbindende Subscriber werden so mit dem jeweils letzten Temperaturwert versorgt, auch wenn sie zum Zeitpunkt des ursprünglichen Sendens nicht mit dem Message Broker verbunden waren.

Schutzziel „Verfügbarkeit“ ist erfüllt

Durch QoS-Level, Last Will and Testament und Retained Message ist die Verfügbarkeit weitestgehend sichergestellt. Zunächst sorgt das QoS-Level bei Bedarf dafür, dass Nachrichten so oft gesendet werden, bis sie genau oder mindestens einmal den Message Broker oder Subscriber erreicht haben. Wenn es zu einem Verbindungsabbruch auf Seiten eines Publishers kommt, werden die Subscriber über den Ausfall informiert und/oder zum Beispiel mit dem letzten verfügbaren Wert oder einem generischen Wert versorgt. Und wenn die Verbindung zu einem Subscriber abbricht, wird der über Status- oder Werteänderungen der von ihm abonnierten Topics informiert, sobald die Verbindung wieder hergestellt wurde.

Kommen wir nun zu den weiteren Schutzzielen bzw. Schutzmaßnahmen. Die aktuelle Spezifikation von MQTT enthält zwar ein Kapitel „Security“, das ist aber non normative, die Umsetzung also nicht zwingend erforderlich. Sie wird zwar empfohlen, es kann aber Clients und Server geben, die sie nicht unterstützen.

IAA – Identifizieren, Authentifizieren, Autorisieren

MQTT-Clients identifizieren sich mittels eines Client Identifiers, der pro Message Broker eindeutig sein muss. Zum Zweck der Authentifizierung können in MQTT-Paketen der aktuellen Version 3.1 beim Verbindungsaufbau durch den Client Benutzernamen und Passwörter übertragen werden. Die Übertragung erfolgt als Klartext, sofern keine externe Verschlüsselung über TLS erfolgt. TLS-Verschlüsselung ist zwar prinzipiell möglich, widerspricht aber der „Leichtgewichtigkeit“ von MQTT, denn TLS ist alles, aber nicht ressourcenschonend.

Der Server (Message Broker) kann für die Clients bei Bedarf eine Autorisierung anhand der vom Client gelieferten Informationen (Client Identifier, Benutzername und Passwort, Hostname/IP-Adresse des Clients) durchführen. In der Gegenrichtung gibt es keine Authentifizierung: MQTT stellt dem Client keine Möglichkeit zur Verfügung, um einen Server zu authentifizieren. Wird TLS verwendet, kann der Server sich allerdings über sein SSL-Zertifikat ausweisen.

Vertraulichkeit und Integrität …

… sind nicht Bestandteil von MQTT. Die Vertraulichkeit der übertragenen Daten kann auf der Anwendungsebene durch eine eigene Verschlüsselung der gesendeten Daten sichergestellt werden. MQTT ist es egal, ob Klartext (oder auch allgemein unverschlüsselte Daten) oder Schlüsseltext darüber übertragen wird. Dabei sollte aber bedacht werden, dass die Protokolldaten vom MQTT wie zum Beispiel die Topics dabei nicht verschlüsselt werden. Sollen auch diese vor unbefugten Beobachtern verborgen werden, muss die gesamte MQTT-Kommunikation über TLS geschützt werden.

Analog kann die Integrität der Daten auf der Anwendungsebene zum Beispiel durch das Hinzufügen von Hash-Werten, oder die gesamte Kommunikation mittels TLS geschützt werden. Alternativ können die Daten auch über ein VPN übertragen werden.

Besser ein externer als gar kein Schutz

Externer Schutz hat einen Vorteil: Er erspart es, das Rad mehrmals zu erfinden oder zumindest zu implementieren. MQTT ist primär für den Austausch von Daten vorgesehen, und zwar möglichst ressourcenschonend. Deren Schutz bei Bedarf entweder der Anwendung oder der Verbindung (mittels TLS) zu überlassen, ist nicht die schlechteste Idee.

Wenn man einmal davon absieht, dass TLS und dessen Implementierungen das eine oder andere Problem hatten/haben (siehe: Eilers, Carsten: „Quo vadis, SSL?“, in: Entwickler Magazin 4.2012 & Eilers, Carsten: „Herzbluten, ein bissiger Poodle und Co.“, in: Entwickler Magazin 1.2015), ist es allemal besser, auf eine zumindest halbwegs bewährte Technologie zu setzen, als selbst entsprechende Funktionen zu standardisieren und danach zu implementieren. Diese Funktionen könnten darüber hinaus noch dem Ziel widersprechen, das Protokoll auch mit knappen Ressourcen zu verwenden.

Es gibt zwar ressourcenschonende Kryptoverfahren, die können aber genauso gut bei Bedarf zusätzlich zu MQTT verwendet werden und müssen nicht Bestandteil des Protokolls sein. So wurde zum Beispiel bei der Entwicklung von AES unter anderem auf geringen Ressourcenbedarf Wert gelegt, sodass eine Implementierung auf Smartcards möglich ist. Es spricht nichts dagegen, dass zum Beispiel ein Sensor bei entsprechendem Schutzbedarf seine Daten mittels einer Verschlüsselung durch einen entsprechenden AES-Prozessor vor dem Ausspähen oder Manipulieren während der Übertragung über MQTT schützt.

CoAP im Überblick

Kommen wir zum zweiten Protokoll, dem Constrained Application Protocol oder kurz CoAP. Es wird von der CoRE (Constrained Resource Environments) Working Group der IETF entwickelt , die aktuelle Version im RFC 7252 standardisiert.

Es handelt sich wie bei HTTP um ein Client-Server-basiertes Protokoll zur Übertragung von Dokumenten, wurde im Gegensatz zu HTTP aber speziell für den Einsatz in leistungsschwachen Geräten entwickelt. CoAP-Pakete sind sehr viel kleiner als HTTP-Pakete, und durch den weitgehenden Einsatz von Bitfeldern und String-Integer-Mappings wird möglichst viel Platz gespart. Daher lassen sie sich einfach erzeugen und benötigen beim Parsen keinen zusätzlichen Speicher.

Im Gegensatz zu HTTP und MQTT verwendet CoAP UDP statt TCP, und es können sowohl Broadcast als auch Multicast für die Adressierung verwendet werden. Clients und Server kommunizieren über verbindungslose Datagramme. Daher kann CoAP auch über SMS und andere paketbasierte Kommunikationsprotokolle verwendet werden.

Clients können GET-, PUT-, POST- und DELETE-Requests an die Server senden, die darauf mit Responses antworten. Außerdem kann CoAP über Proxies mit HTTP und RESTful Services im Web interagieren.

Lass uns eine Vereinbarung treffen…

CoAP erlaubt wie HTTP eine „Content Negotiation“: Clients geben über eine Accept-Angabe an, welche Repräsentation einer Ressource sie bevorzugen, und der Server teilt über den Content Type mit, was er liefert. Wie HTTP verwendet auch CoAP Query-Strings der Form ?a=b&c=d, um den Clients den Zugriff auf verschiedene Features oder Ressourcen des Servers zu ermöglichen.

Auch hier: Alles eine Frage von Qualität

Requests und Response können zwei Qualitätsstufen haben:

  • Confirmable: Der Empfänger muss den Empfang der Nachricht mit einem Ack-Paket quittieren
  • Nonconfirmable: Es gibt keine Empfangsbestätigung, die Nachrichten werden quasi blind gesendet (Fire and Forget)

Kommen wir zur Sicherheit

Wie schon bei MQTT wird die Verfügbarkeit durch die Qualitätsstufen sichergestellt. Genauer: durch die einzige, die eine Quittierung der Nachrichten erfordert, und zwar Confirmable. Empfängt der Sender kein Ack-Paket, kann er die Nachricht ggf. so lange wiederholt senden, bis ihr Empfang irgendwann bestätigt wird (oder bis sie so veraltet ist, dass sie verworfen werden kann).

Während bei MQTT jedoch auch das zur Übertragung der Nachrichten verwendete TCP deren Ankommen sicherstellt, ist das beim UDP nutzenden CoAP nicht der Fall. Bei der Verwendung von UDP gibt es keine Garantie dafür, dass ein Paket überhaupt ankommt oder dass Pakete in der gleichen Reihenfolge ankommen, in der sie gesendet werden. Daher werden die oft nötigen Wiederholungen und Umsortierungen bei CoAP vom Application Stack übernommen.

Vertraulichkeit und Integrität…

… sind wie bei MQTT nicht Bestandteil des Protokolls. Und da CoAP auf UDP und nicht auf TCP basiert, kann auch nicht auf TLS zur Absicherung zurückgegriffen werden. Mit Datagram Transport Layer Security (DTLS, RFC 6347) steht aber eine gleichwertige Lösung für UDP zur Verfügung. Alternativ können die Nachrichten auch von der Anwendung selbst verschlüsselt und/oder ihre Integrität geschützt werden. Ebenso wie im Fall von MQTT kann auch auf ein VPN zur Verbindung von Client und Server zurückgegriffen werden. In RFC 7252 wird dafür IPsec empfohlen.

Eine Sicherheitsanalyse von CoAP in Verbindung mit DTLS und IPsec wurde von Forschern der Middlesex University in London veröffentlicht. Sie haben mehrere Kritikpunkte aufgeführt. Zum einen ist der Einsatz von DTLS und IPsec auf eingeschränkten Geräten unter Umständen problematisch, da beide Protokolle nicht gerade als ressourcenschonend bekannt sind. Zum anderen können die Protokolle einige Sicherheitsanforderungen nicht erfüllen.

So unterstützt DTLS keine Multicast-Kommunikation und ist in vielen Fällen unnötig aufwändig, was DoS-Angriffe ermöglicht. Im Fall von IPsec wird unter anderem kritisiert, dass es bekannte Probleme beim Einsatz mit Network Address Translation (NAT) und Port Address Translation (PAT) gibt. Auch kommt IPsec nicht gut mit mobilen Umgebungen klar, in denen sich die IP-Adressen der Clients ändern.

Bei jeder Änderung der IP-Adresse muss die Security Association (SA) von IPsec neu ausgehandelt werden. Immerhin unterstützt IPsec Multicast, auch wenn dessen Einsatz nicht einfach ist. Aber das trifft ja auf das gesamte IPsec zu, was wir bekanntlich der NSA zu verdanken haben (siehe: Eilers, Carsten: „Kryptostandards im NSA-Zeitalter – Teil 3: Die NSA und ihr Einfluss auf Standards“, in: Entwickler Magazin 3.2014).

IAA – Identifizieren, Authentifizieren, Autorisieren

Im Gegensatz zu MQTT gibt es bei CoAP keine Möglichkeit, Zugangsdaten im Rahmen des Protokolls zu übertragen. Es spricht aber nichts dagegen, sie als Teil der Nachricht zu senden. Allerdings sollte man die Nachricht dann von der Anwendung verschlüsseln lassen, sofern man nicht DTLS verwendet. Denn sonst würden die Zugangsdaten als Klartext übertragen. In der Protokollspezifikation wird für die Authentifizierung auf DTLS zurückgegriffen.

Was gibt es sonst noch zu beachten?

Prinzipiell gilt bei der M2M-Kommunikation der gleiche Grundsatz wie bei jeder Kommunikation: „Traue nie dem anderen“! So wie im Web der Server alle vom Client und damit von einem möglichen Angreifer gelieferten Daten vor ihrer Verwendung prüfen muss, muss bei jeder Kommunikationsverbindung davon ausgegangen werden, dass die gelieferten Daten schädlich sind.

Nehmen wir das Beispiel der Temperatursensoren für MQTT: Normalerweise liefert so ein Sensor im Wohnzimmer Werte zwischen zum Beispiel +5 Grad Celsius und +40 Grad Celsius. Ein Angreifer könnte den Sensor aber kompromittiert haben oder sich einfach als Sensor ausgeben und zum Beispiel sehr große oder sehr kleine (im Sinne von negativen) Werte liefern, über die dann ein Puffer- oder Integerüberlauf im Client ausgelöst wird. Es könnte auch statt einer Zahl ein String geliefert werden, der zum Beispiel Shell-Befehle einschleust. Immer vorausgesetzt natürlich, der Client (oder auch der Server) enthält eine entsprechende Schwachstelle. Was gar nicht mal so unwahrscheinlich ist, wenn die Eingaben nicht geprüft werden. Denn genau dadurch entstehen Schwachstellen ja.

Also: Alle über die M2M-Kommunikation gelieferten Daten müssen auf Korrektheit geprüft werden. Denn auch von ganz harmlosen Sensoren können Angriffe ausgehen, wie zum Beispiel Alexander Bolshev und Gleb Cherbov auf der Black Hat USA 2014 gezeigt haben: Über ein Low-Level-Protokoll für Industriesteuerungen schleusten sie XML-Code ein, der über Server-Side Request Forgery (SSRF) einen Exploit für eine Remote Command Execution auf einem SAP-System ausführte.

Statt der üblichen Verdächtigen die üblichen Vorsichtsmaßnahmen

Im Bereich „Security Considerations“ des CoAP-RFC 7252 wird deshalb aus gutem Grund auf die üblichen Vorsichtsmaßnahmen hingewiesen, wie sie auch für HTTP gelten. Also vor allem: Vorsicht beim Parsen des Protokolls und der Verarbeitung der URIs!

Werden für CoAP Proxys eingesetzt, wird dadurch der Schutz von DTLS oder einem VPN aufgebrochen, ein Angreifer könnte über einen kompromittierten Proxy als MitM agieren.

Da Responses deutlich größer als Requests sein können, bieten sich CoAP-Server für Amplification-Angriffe an, bei denen kleine Request-Pakete mit gefälschter Absenderadresse große Responses an den angeblichen Absender auslösen und dort zu einem DoS führen.

Außerdem besteht durch die Verwendung des verbindungslosen UDP die Gefahr von IP-Address-Spoofing-Angriffen, bei denen ein Angreifer mit gefälschten UDP-Paketen Unheil anrichtet.

Darüber hinaus sind Cross-Protocol-Angriffe ähnlich einer SSRF möglich, mit denen unter Umständen Firewalls und ähnliche Schutzmaßnahmen umgangen werden können.

Fazit

Protokolle für die M2M-Kommunikation müssen vor allem eins sein: Leichtgewichte. Das verträgt sich nicht gut mit dem Einsatz kryptografischer Verfahren. Dementsprechend enthalten die Protokolle auch keine entsprechenden Funktionen, sondern nutzen zur Absicherung der Kommunikation externe Protokolle wie TLS/DTLS oder VPNs oder überlassen sie der Anwendung.

Meist wird jedoch eine Verschlüsselung oder die Berechnung eines MAC durch die Anwendung die effektivere Lösung sein. Denn Protokolle wie TLS/DTLS oder IPsec sind alles andere als leichte Kost, weder was ihren Ressourcenbedarf auf Client oder Server, noch was den Umfang der ausgetauschten Daten betrifft.

Clients wie zum Beispiel einen Temperatursensor, der doch eigentlich nur die Temperatur messen und an einen Server senden muss, damit zu belasten, dürfte diesen schnell überlasten. Aber sofern überhaupt die Notwendigkeit besteht, die Daten eines einfachen Sensors verschlüsselt und/oder integritätsgeschützt zu übertragen, kann das ja auch von der Anwendung selbst übernommen werden. Dabei können die nötigen Kryptoverfahren gezielt für den jeweiligen Zweck ausgewählt und entsprechend sorgfältig implementiert werden, sodass sie Gerät und Netz deutlich weniger belasten als die allgemeinen Protokolle.

Von daher gilt: Die Kommunikationsprotokolle tun, was sie tun sollen – die Kommunikation abwickeln. Für den Schutz der übertragenen Daten müssen die Nutzer selbst sorgen – so, wie es auch bei den meisten anderen Kommunikationsprotokollen üblich ist.

Aufmacherbild: machine to machine: laptop and connected devices von Shutterstock / Urheberrecht: faithie

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -