LoRaWAN Security Assessment

From Embedded Lab Vienna for IoT & Security
Revision as of 09:46, 13 May 2020 by PMandl (talk | contribs) (→‎IoT-Protokoll Security Testing Guide)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Summary

Dieses Wiki bietet eine Übersicht zu der Sicherheit in LoRaWAN 1.0.3 und LoRaWAN 1.1. Durch Anwendung eines IoT Protokoll Guides (MIST-Guide) werden Vorschläge zur weiteren Vorgehensweise erstellt und abgegeben. Zusätzlich werden Vorschläge präsentiert, die die Sicherheit in diesem Protokoll erhöhen.

Sicherheitsprobleme in LoRaWAN 1.0.3

In LoRaWAN 1.0.3 wird immer wieder angepriesen, dass diese Technik eine eingebaute Verschlüsselung hat. Diese Aussage ist auch korrekt, doch das führt zu grundlegenden Verständnisproblemen bei Technikern und Technikerinnen, sowie Entwicklern und Entwicklerinnen, die sich somit voll und ganz auf die eingebauten Sicherheitsmechanismen verlassen. Einige der beschriebenen Sicherheitsprobleme sind nicht vollständig dem Protokoll anzulasten, sondern behandeln eher eine Vielzahl an Implementierungen, die normalerweise im Einsatz sind. Somit werden weitere Schwächen verstärkt, was wieder zu einer Reduzierung der Security führt. Deswegen werden die Beschreibungen in zwei Gruppen unterteilt, um diese Trennung zu verdeutlichen.

Probleme des Protokolls

Key Management

Das größte Sicherheitsproblem von LoRaWAN liegt in den Schlüsseln. Die symmetrischen Keys sind fest auf einem Node und dem Join-Server verankert. Diese sind nicht änderbar, da sonst das gesamte System nicht mehr funktioniert. Wird der Schlüssel bekannt, so ist die jegliche Integritätsprüfung und Ende zu Ende Verschlüsselung hinfällig. Da die Endgeräte aber oftmals in ungeschützten Bereichen, wie zum Beispiel auf öffentlichen Ampelsystemen, installiert werden, muss ein gewisser Sicherheitsstandard in der Hardware, sowie auch der Software, vorhanden sein. In einem Bericht des Security Testing Unternehmens IOActive aus dem Jahre 2020 geht aber hervor, dass genau das nicht durchgeführt wird und oftmals Repositories offen im Internet auffindbar sind und einige Keys der Hersteller ident sind. Zusätzlich beschreiben sie, dass Session Keys auf vielen Servern im Netzwerk verteilt werden und somit die gesamte Verschlüsselung fragwürdig ist, da zahlreiche Teilnehmer dieses Schlüsselmaterial besitzen. Zu dem Problem gibt es aber noch andere Schlüsselverwaltungsprobleme, die die Sicherheit deutlich untergraben. Dadurch, dass bei der aktuellen Verwendung von LoRaWAN 1.0.3 keine räumliche Trennung zwischen Netzwerkserver und Join-Server vorgenommen wird, und die Verteilung durch den Networkserver stattfindet, hat dieser auch die volle Kontrolle des Verkehrs und kann die Nachrichten nach Belieben verändern oder sogar unterdrücken. Zwar wird in der Spezifikation von LoRaWAN beschrieben, dass diese Server als „trusted“ gelten, aber das Vertrauen auf externe Anbieter zu legen, stellt eine eindeutige Verletzung von Security Prinzipien dar. In dieser Beschreibung finden sich mehrere Schwachstellen vor, die getrennt behandelt werden müssen.

  • Repositories mit Quellcode und Schlüssel im Internet
  • Hard-coded Root – Keys


Integritätsschutz

In der derzeitigen Version findet sich die Berechnung eines MICs, der die Integrität der Nachrichten wahren soll. Diese wird mit dem NwkSKey durchgeführt. Der Schlüssel findet sich aber lediglich am Netzwerkserver, was somit bedeutet, dass die Integrität nur zwischen Node und Netzwerksserver gegeben ist. Danach wird das Paket an den zuständigen Application Server weitergeleitet. Hierbei ist das Frame aber nur verschlüsselt und unterliegt keinem Integritätsschutz mehr. Der Netzwerkserver kann also den vollständigen Inhalt nach Belieben ändern und auf Reaktionen des Application Servers warten. Daran kann er, auch ohne die Verschlüsselung zu brechen, Muster erkennen und so ein gültiges Paket bauen. Das Problem hierbei liegt somit in der fehlenden Integritätsprüfung zwischen dem Anwendungsserver und einem Endgerät. Folgende Angriffe sind somit möglich:

  • In dem Netzwerk vom Betreiber des Netzwerkservers sind Angreifer


Netzwerkverkehr Analyse

Die vollständige Kommunikation der Nodes muss von Gateways aufgenommen und weitergeleitet werden. An dieser Stelle sind die Daten aber durch den AppSKey verschlüsselt und durch den NwkSKey integritätsgeschützt. Einen direkten Blick auf die Pakete hat man somit nicht. Ein Angreifer hat aber nun die Möglichkeit ein Gateway zu betreiben und alle Frames abzufangen. Anhand der Menge und Häufigkeit der gesendeten Daten besteht dennoch die Gefahr, Rückschlüsse auf den Inhalt zu treffen. Sollte zum Beispiel die Menge von Personen in einem Gebäude gezählt werden, so wird bei steigender Datenmenge oder Länge der Frames auch eine erhöhte Anzahl von Personen anwesend sein. Ein Zitat aus einer Debatte zwischen zwei führenden Kräften von amerikanischen Geheimdiensten sagt: „We kill people based on metadata“. Das verdeutlich die Wichtigkeit dieses Problems, dass durch einen unzureichenden Schutz auftritt. Somit ist folgendes Problem ersichtlich:

  • Informationsgewinnung durch Analyse der Menge und Längen des Ciphertextes


Frequenzstörer

Nodes und Gateways kommunizieren drahtlos über ein offenes Frequenzband miteinander. Diese Kommunikation ist sehr anfällig auf Frequenzstörer. Wenn ein Angreifer Teile des Bandes überlagert, so kann ein Node nicht mehr mit einem Gateway kommunizieren. Das würde zu einem Ausfall der Services führt. Oftmals ist das auch unbemerkt möglich, da aufgrund der stromsparenden Bauweise Pings oder dergleichen unterlassen werden. Diese Angriffe sind in der Praxis sehr leicht durchzuführen, da man lediglich ein LoRa Radio Modul auf einem Microcontroller braucht. Nun muss nur die richtige Frequenz mit LoRa Nachrichten geflutet werden, um einen Ausfall zu provozieren. Folgende Schwachstelle kann somit gefunden werden:

  • Störung der Kommunikation zwischen Nodes und Gateways


Replay Angriffe

LoRaWAN bietet in seinem Design einen eingebauten Schutz, um Replay Angriffe zu verhindern. Doch trotz der Einbindung von Counter gibt es Methoden, um sie dennoch durchzuführen. Diese treffen aber nur bei der Activation By Personalization zu, da sich hierbei der Session Key nicht ändert. Die derzeitige Spezifikation beschreibt den Frame Counter (FCnt) als einen einfach inkrementierenden Wert, der bei jeder Join Prozedur wieder auf null gesetzt wird. Ein Angreifer kann alle Datenpakete über einen gewissen Zeitraum unbemerkt abfangen. Danach identifiziert er das Paket, welches zum Beispiel ein Alarmsystem deaktiviert und speichert dieses. Die Identifikation kann mithilfe der Länge der Nachricht, oder anderen Vorlagen durchgeführt werden. Nun muss er das Signal stören, oder den Node dazu zwingen, einen erneuten Join-Request zu schicken. Der Counter befindet sich jetzt wieder auf null und beginnt von vorne zu zählen. Das Paket, welches er nun bereit hat, ist somit gültig, da der Counter Wert sicherlich über den des derzeitigen Counters liegt. Um nun den Angriff zu, starten sendet er dieses Paket und schaltet die vorher erwähnte Alarmanlage ab. All das geschieht ohne das Wissen der Root-Keys. Folgendes Problem besteht:

  • Replay Angriffe unter gewissen Voraussetzungen möglich


Wormhole Angriffe

Diese Art des Angriffes zielt darauf ab, dass der Empfang der meisten Datenpakete in LoRaWAN vom Protokoll selbst nicht bestätigt wird und zusätzlich keine Zeitstempel verwendet werden. Dadurch besteht die Möglichkeit Pakete abzufangen und die weitere Zustellung, mithilfe eines Frequenzstörers, zu unterbinden. Der Angreifer selbst hat somit gültige Datenpakete, die an einem beliebigen Ort, zu beliebiger Zeit, wieder abgespielt werden können. Wichtige Frames können somit unterbunden werden, während das System davon ausgeht, dass alles wie gewohnt funktioniert und kein Problem besteht. Alles unter der Voraussetzung, dass entweder die Session noch nicht neu gestartet wurde oder die ABP in Verwendung ist. Es findet sich folgende Schwachstelle:

  • Pakete können zeitversetzt gesendet werden


Angriffe auf die Synchronisation von Class B Geräten

In Abschnitt 2.3.2 wird beschrieben, welche Klassen in LoRaWAN ihre Anwendung finden. Dabei wird auch auf die Synchronisation der Gateways und Nodes eingegangen. Demnach, werden alle Downlink Fenster vom Gateway an das Endgerät übermittelt. Dafür gibt es keinerlei Schutz und Verifikation der Nachricht. Somit kann ein Angreifer an dieser Stelle eingreifen und fehlerhafte Phasen an das Gerät übermitteln. Dieses ist dadurch nur in den verfügbaren Zeitfenstern empfangsbereit, was zu einer falschen Synchronisation der beiden Partner führt. Dadurch wäre die Kommunikation gestört und keine Downlink Phase kann mehr eintreten. Eine erneute Synchronisierung müsste stattfinden, um den Node wieder funktionstüchtig zu machen. Folgendes Problem besteht:

  • Angriffe auf die Synchronisierung der Nodes


Bit Flipping Angriffe

Aufgrund des fehlenden Integritätsschutzes zwischen dem Network Server und dem Application Server ist die Verbindung dazwischen angreifbar. Dadurch kann man auf diesen Bereich einen Bit Flipping Angriff durchführen. Dabei muss bekannt sein, was die Endgeräte für Daten senden und an welcher Position die zu verändernden Werte sind. Nun kann der zu ändernde Bereich an der richtigen Stelle geändert werden. Die Gefahr liegt somit darin, dass zum Beispiel einfache Temperaturdaten verändert werden können, ohne die Kenntnis der Schlüssel. Dieser Angriff fällt nur auf, wenn ein Angreifer in der Veränderung der Werte deutlich übertreibt und somit Temperaturen anstrebt, die nicht erreichbar sind. Bei kleinen Änderungen ist das kaum erkennbar. Durch dieses Verhalten ist folgende Schwachstelle ableitbar:

  • Änderung der Daten durch Bit Flipping


Probleme von Implementierungen

Dieser Abschnitt beschreibt Sicherheitsprobleme, die durch eine fehlerhafte Implementierung auftreten können und somit nicht vollständig dem Protokoll angelastet werden können.


Physische Sicherheit

Im Punkt „Key Management“ oberhalb wurde schon auf die Wichtigkeit der Sicherheit der Root-Keys eingegangen. Dieser Abschnitt soll nun verdeutlichen, wie gefährlich es ist, wenn auf die physische Sicherheit der Nodes keine Rücksicht genommen wird. Endgeräte müssen sehr oft in Bereichen installiert werden, wo es keine Überwachung oder andere Sicherungsmaßnahmen gibt. Der Zugang zu den Geräten ist dadurch leichter möglich. Sollten nun Angreifer das Gerät physisch erreichen, so können sie die Root-Keys auslesen und sich selbst in das Netzwerk einbringen indem z.B. falsche Messdaten vorgetäuscht werden. Es ist somit sehr wichtig einen Node vor Seitenkanalangriffen wie einer Simple Power Analysis oder Angriffen der gleichen Art zu schützen, die eine Auslesen der Schlüssel ermöglichen. Das Protokoll muss für diesen Punkt so angepasst werden, dass es nicht erforderlich ist Root Keys fest auf einen Node zu speichern. Dafür könnte eine asymmetrische Verschlüsselung eingesetzt werden. Folgende Problematik erscheint in diesem Punkt:

  • Unzureichende physische Sicherheit der Hardware

Aktivierung der Nodes

LoRaWAN bietet die Möglichekeit die Nodes auf zwei Arten zu aktivieren. Die erste Variante (ABP) wird oft in Unternehmen eingesetzt, da sie eine schnelle Einbindung in das lokale LoRaWAN Netz ermöglicht und kein Datenaustausch erforderlich ist. Das bietet einen entscheidenden Vorteil gegenüber der OTAA. Dieser Vorteil ist zugleich auch ein Nachteil, denn dadurch ändern sich die Session Keys niemals, sofern sie nicht manuell umgeschrieben werden. Somit sind alle Schlüssel über die volle Lebensdauer persistent. Wenn einer davon bekannt wird, ist nicht nur ein Gerät gefährdet, sondern das gesamte Netzwerk. Da eine Kompromittierung in der Regel nicht so schnell auffällt, stellt das ein erhebliches Sicherheitsproblem dar. In den FAQ der LoRa-Alliance zum Thema Security wird deswegen die OTAA empfohlen, sofern ein größeres Sicherheitsbedürfnis besteht. Doch dieses muss immer bestehen, weswegen die Funktion ABP ein Problem darstellt und nie eine Anwendung finden sollte. Sowie auch im Punkt Key Management ist auch hier eine ähnliche Schwachstelle erkennbar:

  • Hard-coded Session Keys


Datenverwendung

Da Nodes in der Regel nur eingebunden werden, wenn sie zum Betreiber selbst gehören, werden diese Geräte immer als vertrauenswürdig eingestuft. Das wirkt sich oftmals auch auf das Design des Backends aus. So werden Daten von Nodes einfach akzeptiert und weiterverarbeitet. Wie schon im Punkt „Physische Sicherheit“ oberhalb erwähnt, befinden sich die Endgeräte oftmals an leicht zugänglichen Orten, was dem nun zum Verhängnis werden könnte. Denn sollte ein Angreifer die volle Kontrolle über so ein Gerät haben, so könnte er mit Schwachstellen im Design des Backends wie SQL Injections oder dergleichen, ein ungewolltes Verhalten hervorrufen. Das Protokoll kann diese Schwachstelle nicht lösen. Es besteht folgende Schwachstelle:

  • Oftmals keine Datenfilterung der Eingabewerte durch Nodes


Network- und Application Server Implementierung

Die Netzwerk- und Anwendungsserver stellen einen wichtigen Bestandteil des LoRaWAN Netzwerkes dar. Die Kommunikation untereinander wird in der Spezifikation aber nicht definiert und festgelegt. Es gibt lediglich Empfehlungen, die aber nicht zwangsweise umgesetzt werden müssen. Das lässt bei den Serverbetreibern viel Interpretationsspielraum, was nicht passieren sollte. Angefangen von unsicheren Implementierungen eines Network Servers bis zu einem fehlerhaften Schlüsselaustausch mit den Application Server ist alles möglich.Ein Man-in-the-Middle kann sich dabei deutlich auf die Sicherheit des Protokolls oder der Implementierung auswirken. Durch Abfangen des Application Session Keys kann die Verschlüsselung gebrochen und nach Belieben eine Veränderung vorgenommen werden. Das funktioniert aber erst nach dem Network Server. Mehr dazu im Abschnitt „Integritätsschutz“. Folgende Schwachstellen finden sich in dieser Beschreibung:

  • Unsichere Implementierung der Server
  • Ungesicherte Verbindung zwischen Application Server, Join Server und Network Server


Gateway Probleme

MWR Labs beschreibt in ihrem Whitepaper einen wesentlichen Punkt. Gateways haben die Aufgabe den Verkehr blind an den Netzwerkserver weiterzuleiten. Dafür sind diese direkt mit dem Internet verbunden. Da es aber eine Vielzahl, in Relation zu einem Network Server, geben muss, werden diese oftmals ferngewartet. Diese Fernwartung kann nun mittels SSH, VPN oder dergleichen stattfinden. In einem perfekten Szenario werden diese Services immer aktuell gehalten und mit langen Passwörtern oder guten Zertifikaten abgesichert. Die Realität beweist aber, dass dies nicht der Fall ist und somit Angreifer ein Gateway übernehmen können, sobald die Firma vergisst, ein Update einzuspielen. Das Kontrollieren eines Gateways stellt im Prinzip kein Problem für LoRaWAN dar, da hierbei die Confidentiality und Integrity noch immer gewahrt sind, aber für andere Angriffsszenarien kann dieser Teil des Netzwerkes eine Rolle spielen. Beispielsweise untergräbt man die Verfügbarkeit deutlich, indem ein Gateway deaktiviert wird und keine Pakete mehr weiterleitet. Aufgrund der großen Abdeckung, fallen dann Nodes aus. Es finden sich somit folgende Schwachstellen vor:

  • Kontrolle eines Gateways durch ungesicherte Fernwartungssoftware

Sicherheitsprobleme in LoRaWAN 1.1

LoRaWAN 1.1 wurde in vielen Punkten überarbeitet und verbessert. Vorallem das Schlüsselmanagement hat sich vollständig geändert und kaum mehr Ähnlichkeiten mit der vorherigen Version 1.0.3. Dennoch gibt es auch hierbei noch einige Sicherheitsrelevante Probleme, die aber zu einem sehr großen Teil schon davor vorhanden waren und nicht behoben wurden. Nachfolgend werden nur neue Angriffsmethoden beschrieben.


Downgrade Attacken

LoRaWAN 1.1 bietet ebenfalls für die am weitesten verbreitete Version 1.0.3 eine Unterstützung an. Das bedeutet, dass ein Endgerät, das für die aktuellste Version ausgelegt ist auch im alten Netz arbeiten kann. Beim Verwenden dieses werden die zusätzlichen Schlüssel aber entfernt und der Node, der eigentlich für die Version 1.1 gebaut wurde, arbeitet rein mit v1.0.3. Somit bestehen auch bei einem neuen Node alle Sicherheitsprobleme. Ein Angreifer kann nun dieses Verhalten ausnutzen und dem Node dieses Verhalten aufzwingen. Dieser fällt daraufhin in das alte Schema, wo die bekannten Probleme ausgenützt werden können. Dadurch werden alle Verbesserung der Security, die in v1.1 eingebaut wurden hinfällig. Somit besteht folgendes Problem:

  • Downgrade Attacke auf die alte Protokollversion


Dauer einer OTAA Session

Die LoRaWAN 1.1 Spezifikation bietet keine genaue Definition wie lange eine Over The Air Activation Session maximal dauert. Das führt zu dem Sicherheitsproblem, dass Schlüssel bei einigen Geräten schneller erneuert werden und bei anderen Endgeräten viel langsamer oder sogar gar nicht. Die Sessions sind somit auf manchen Endgeräten sicherer, während das andere nicht bieten. Folgendes Sicherheitsproblem besteht:

  • Ungewisse Gültigkeitsdauer der Session Keys


Security Verbesserungen in LoRaWAN 1.1

Die Security in LoRaWAN 1.1 hat sich deutlich verändert und löst dadurch einige Sicherheitsprobleme. Unter der Voraussetzung, dass Downgrade Attacken nicht mehr möglich sind, gibt es einige Verbesserungen in der Schlüsselverwaltung. Es sind nun zwei Root-Keys vorhanden. Da dadurch nicht ein einziger Schlüssel für alle Operationen verantwortlich ist, kennt nicht jede Komponente alle Keys. Dadurch wird das nötige Vertrauen vom Netzwerkserver reduziert und reduziert die Gefahr auf deren Seite. Ein Schutz der Integrität ist dadurch noch immer nicht gegeben. Zusätzlich dazu wurden Frame Counter erhöht, was die Gefahr verringert, dass dieser Bereich zu klein ist und irgendwann endet. Zusätzlich dürfen diese Counter in der selben Session nicht mehr verwendet werden.

Sicherheitslösungen für LoRaWAN

LoRaWAN ist aus technischer Sicht noch ein neues Thema. Das spiegelt auch in den Quellen wider, die maximal 4 Jahre, also bis 2016, zurückreichen. Nach einer ausführlichen Recherche konnten nur zwei sinnvolle Bibliotheken gefunden werden, die in einem Netz eingesetzt werden sollen, da andere Repositories nicht den gewünschten technischen Stand hatten. Zusätzlich waren kaum andere Addons auffindbar. Die erste Bibliothek dient der Security Analyse eines LoRaWAN Netzwerkes (LoRaWAN Auditing Framework), während die Andere die Sicherheit in der Kommunikation verbessert und einige Integritäts- und Vertraulichkeitsprobleme behebt (TLS over LoRaWAN). Durch die Vielzahl an gefundenen Lücken ist dargelegt, dass es ratsam ist solch einen zusätzlichen Schutz einzubauen und sich nicht allein auf die standardmäßige Sicherheit zu verlassen. Eine Evaluierung dieser Bibliotheken folgt im nachfolgenden Kapitel.

LoRaWAN Auditing Framework

Das LoRaWAN Auditing Framework von IOActive bietet eine Fülle an Tools, um ein LoRaWAN Netzwerk auf Herz und Nieren zu testen. Das Erstellen, Analysieren, Abfangen und Cracken von Verbindungen stellt kein Problem dar und kann mithilfe dieser Zusammenstellung durchgeführt werden. Nachfolgend werden nur die Programme beschrieben, die für diese Arbeit maßgebend sind. Dafür wurden jene ausgewählt, die die Security testen können und Konfigurationsprobleme im eigenen LoRaWAN Netzwerk aufdecken.


LoRaWAN BruteForcer

Ein effektives, sowie mächtiges, Tool ist der LoRaWAN BruteForcer innerhalb des Auditing Frameworks. Mithilfe dessen kann man versuchen den verwendeten AppKey zu ermitteln. Das kann diese Software mithilfe eines vordefinierten Sets von oftmals verwendeten AppKeys bzw. währenddessen eine Berechnung neuer Schlüssel durchführen. Die Funktionsweise ist simpel und nutzt die MIC Berechnung bei Join Request und Join Accept Nachrichten aus. Denn beide werden in der Version 1.0.3 mit dem AppKey berechnet. In v1.1 wird der NwkKey dafür verwendet. Zu Beginn wird der MIC mit dem zu testenden AppKey über die Join Request Nachricht berechnet. Danach erfolgt ein Vergleich der zwei MICs. Sind sie identisch so wird dieser vorerst zwischengespeichert. Dieser Vorgang wird nun mit allen Appkeys durchgeführt, die man testen möchte. Dafür wird empfohlen die beigefügte Liste der Software zu verwenden, da sie feste Schlüssel von einigen Anbietern enthält. Danach kann mit der eigenen Berechnung begonnen werden. Die gefundenen Schlüssel sind potenzielle Root-Keys. Man ist sich zu dem Zeitpunkt noch nicht sicher, da Kollisionen entstehen können, denn der MIC ist ein berechneter Hash, der auf die ersten vier Bytes gekürzt wird. Nachdem eine Menge an Root Keys gefunden hat, wird die Join Accept Nachricht herangezogen. Wieviele er findet ist unklar, da dies von Fall zu Fall unterschiedlich ist. Über diese wird erneut ein MIC berechnet. Dafür wird der potenzielle AppKey verwendet. Sollte der MIC in dem Fall auch stimmen, so ist die Wahrscheinlichkeit sehr hoch, dass das der richtige Schlüssel ist. Man kann nun mit der Entschlüsselung einer Nachricht beginnen. Ergibt sie einen Sinn, so hat man einen validen AppKey. In Version 1.1 kann mit dieser Methode die Integrität des Systems gestört werden und Bit Flipping Angriffe ausgeführt werden, da hier eine Trennung zwischen Applikation Server und Netzwerk Server stattfindet. Mit dieser Methode wird gezeigt, dass offline Angriffe möglich sind und ein Errechnen der Schlüssel auch ohne eine Verbindung zum Node passieren kann. Wie anwendbar dieser Angriff ist, ist aber fraglich. Denn geht man von dem besten Supercomputer im Jahr 2017 aus, der eine Leistung von rund 93 Petaflops hat, so benötigt die Berechnung aller AES128 Keys 885 Quadrillionen Jahre. Somit ist die Sicherheit einzig und allein von einem sicher gewählten Schlüssel abhängig und verdeutlicht nochmals, dass die Verwendung von fixen Schlüssel unsicher ist. Mithilfe dieses Programms hat man somit die Möglichkeit auf bekannte Keys zu testen und zu prüfen, ob es einer der Root Keys ist oder nicht.


LoRaWAN Datensammler

Um einen Angriff zu starten, oder deren Sicherheit grundsätzlich zu testen, benötigt der Angreifer oder Tester einzelne Frames. Dafür bietet diese Bibliothek ein Script an, welches sich mit einem Netzwerkserver (https://www.chirpstack.io/) verbindet und deren Daten bezieht. Diese werden dann in eine Datenbank geschrieben. Um es zu verwenden, muss somit ein Zugriff auf diesen Server möglich sein. Ein Angreifer muss anderweitig an diese Daten kommen. Das könnte er zum Beispiel erreichen indem er auf die unverschlüsselte Verbindung zwischen Gateway und Server einen MITM Angriff startet oder die Pakete mit einem eigenen Gateway abgreift. Durch die sternförmige Anordnung des Netzwerkes empfangen schließlich alle Gateways die Pakete und leiten sie weiter. Das kann ausgenutzt werden.


LoRaWAN Paket Ersteller

Ein wesentliches Problem im LoRaWAN stellt ein DOS Angriff dar. Dieser ist durch Frequenzstörer und physische Einwirkung auf Gateways am einfachsten erzielbar und schwer zu erkennen. Dennoch gibt es andere Möglichkeiten eine derartige Attacke durchzuführen ohne, dass zusätzliche Hardware benötigt wird. Das GitHub Repository bietet dafür zwar kein eigenständiges Tool an, aber man kann den „UdpSender“ dafür zweckentfremden. Eigentlich ist es dafür gebaut worden mithilfe eines AppKeys valide Uplink Pakete zu erstellen. Das kann man sich zu Nutze machen. Vorausgesetzt ein Angreifer hat Zugriff auf den AppKey, so kann er gültige Join Request Pakete senden indem er die DevEUI vortäuscht. Der Join-Server reagiert darauf mit einem Join Accept und setzt die derzeit gültigen Session Keys zurück. Somit kann der Node nicht mehr mit dem Netz kommunizieren. Eine weitere Möglichkeit ist, eine gültige Nachricht zu senden und den FCnt derartig hoch zu setzen, sodass alle Werte darunter ungültig sind. Das Endgerät bekommt diese Nachricht aber nicht mit und übermittelt weiterhin geringere Counter Werte. Alle Nachrichten werden somit ungültig, da es als Replay Angriff gewertet wird und ein DOS findet statt. Alle beschriebenen Vorgänge setzen voraus, dass der AppKey bekannt ist.


LoRaCrack

LoRaCrack ist ein eigenes Tool, das von Sipke Melleman entwickelt wurde. Dennoch findet sich dieses auch in dem Auditing Framwork vor. Mithilfe dieses Programmes kann versucht werden eine LoRaWAN Session zu cracken und so auf die derzeitigen Session Schlüssel zu kommen, sofern der AppKey bekannt ist. Dafür nutzt es die Art der Generierung der Session Keys aus. Es erfolgt die Erzeugung mithilfe von drei Werten:

  • AppNonce
  • NetId
  • DevNonce

Addiert man die maximalen Bit Werte der Feldgrößen, so kommt man auf eine Entropie von 57 Bit. Das ist in der heutigen Zeit deutlich zu wenig. Durch eine fehlerhafte Implementierung der Nodes oder Server kann dieser Wert noch deutlich sinken. LoRaCrack nutzt das nun aus und kann mithilfe eines einzelnen Pakets und des Plain Textes errechnen, was der derzeitige Session Key ist. Durch die geringe Anzahl an Entropie und der hohen Geschwindigkeit des AES-CMAC ist das in wenigen Tagen erreichbar und hat keine Dauer von mehreren hunderten Jahren.


LoRaWAN Auditing Framework Zusammenfassung

Das Framework von IOActive deckt eine große Breite von Anwendungsmöglichkeiten ab, indem sie eine gute Auswahl von verwendbaren Tools erstellt haben. Es werden teilweise bereits bekannte Tools wie LoRaCrack verwendet, liefern aber auch selbst eine Vielzahl an empfohlenen Inhalt dazu. Vorallem die Verwendung des Tools für den Angriff auf den AppKey ist nützlich und gibt eine einfache Übersicht, ob schwache oder bekannte Schlüssel im Netzwerk eingesetzt werden. Auch für Angreifer ist es von Wert, weswegen ein Test durchaus Sinn macht. Kombiniert man das mit LoRaCrack, so kann man bei einem schlechten Root Key schnell auf die Session Schlüssel schließen und die weitere Kommunikation des gesamten Netzwerkes überwachen oder sogar eingreifen. Dafür ist dann der erwähnte Paketersteller relevant. Ein klassischer Penetrationstest des Netzwerkes kann folgende Schritte haben:

  • Datenpakete durch Kompromittierung des Netzwerkservers oder Erstellung eines Gateways abfangen.
  • AppKey mithilfe des BruteForcer Tools testen.
  • Sofern der Schlüssel schwach ist und sich dieser in der bereits erstellten Liste vorfindet, wird LoRaCrack angewendet, um die derzeitigen Session Keys zu übernehmen.
  • Mithilfe des Paket Erstellers gültige Pakete erzeugen und den Beweis liefern, dass die vollständige Übernahme des Verkehrs geschehen ist.
  • Prüfen, ob auch andere Nodes die selben Session Keys verwendet. Das kann bei der Activation by Personalisation vorkommen.

Durch diese Prüfung ist leicht erkennbar, ob die gespeicherten AppKeys eine Schwäche aufweisen und vielleicht sogar die Nodes getauscht werden sollen, da die Root-Keys in der Regel nicht änderbar sind. Abschließend kann zu diesem gesagt werden, dass es sinnvoll ist das Netzwerk und die Schlüssel zu prüfen. Dennoch lässt es auf die gesamte Security des Systems keinen eindeutigen Rückschluss zu. Um weiterhin zur Sicherheit beizutragen muss deutlich mehr umgesetzt werden, wie zum Beispiel das Hinzufügen von TLS over LoRaWAN, als diese Zusammenstellung anbietet.


TLS over LoRaWAN

TLS over LoRaWAN ist eine Erweiterung des LoRaWAN Standards, der angibt die Sicherheit deutlich zu steigern, indem Ende zu Ende Verschlüsselung eingesetzt wird. Zwar verspricht die LoRa-Alliance genau das Gleiche, doch wie in den oben beschriebenen Punkten ist dieser Schutz nicht ausreichend. Die Erweiterung wurde in einer Kooperation zwischen der Herstellerfirma PHYSEC und der Ruhr Universität Bochum entwickelt. Bis zum heutigen Tag ist es nun patentiert und marktreif. Aufgrund der eigenen Angaben, dass eine Ende zu Ende Verschlüsselung stattfindet und eine TLS ähnliche Technologie eingesetzt wird, wurde diese Bibliothek, zur Verbesserung des Standards, gewählt, obwohl diese nicht Open Source ist.


Einführung

Die Grundidee hinter dieser Technik ist es, TLS auf eine herkömmliche LoRaWAN Payload zu setzen und so die Sicherheit, unabhängig vom Standard selbst zu machen. Dadurch werden auch zukünftige Änderungen, wie sie zwischen der Version 1.1 und 1.0.3 geschehen, unberührt gelassen und das System kann unabhängig davon weiterarbeiten, auch, wenn sich die Struktur dahinter ändert. Es wird somit ein bestehendes, etabliertes und sicheres Protokoll verwendet, um kryptographische Bedenken zu zerstreuen. Durch die gesicherte Verbindung wird eine echte Ende zu Ende Verschlüsselung erzielt, die die Integrität nun auch zwischen Applikationsserver und Netzwerkserver wahren kann und weitere Sicherheitsvorteile bietet, die im weiteren Verlauf dieses Kapitels erklärt werden. TLS bietet vollständige Sicherheit zum Übertragen von Daten im Netz, doch dafür wird zum Transport TCP, ein verbindungsorientiertes Protokoll, verwendet. Das ist mit LoRaWAN nicht möglich, da keine Three-Way Handshakes gemacht werden, um die Last auf das Netzwerk so gering wie möglich zu halten und dadurch die Lebensdauer der Batterien zu erhöhen. Somit kann eigentlich auch keine Transport Layer Security verwendet werden, denn die Pakete werden im schlimmsten Fall nicht ankommen oder sogar die Reihenfolge ändern. Je nachdem welches Gateway die Nachrichten zuerst auffängt und weitersendet. PHYSEC hat sich dafür eine Lösung gesucht und nimmt statt TLS nun DTLS.


Datagram Transport Layer Security

DTLS ist im Prinzip ähnlich zu TLS indem es deren Grundgerüst übernimmt und mit weiteren Nachrichten erweitert, sowie weitere Felder hinzufügt. Dadurch kann es auch mit einem unzuverlässigen Protokoll, wie LoRaWAN, eingesetzt werden. So kommt es zu keinen Kollisionen und die Pakete werden in der richtigen Reihenfolge verwendet oder ein erneutes Senden wird durchgeführt. Die Erweiterung TLS over LoRaWAN nützt in Ihrer Implementierung das RFC 6347, welches DTLS 1.2 beschreibt. Dadurch wird eine aktuelle Version verwendet, welche heute als sicher gilt. Der größte Unterschied zu TLS ist der Handshake. Während dieser normalerweise auf der Ebene des Transportprotokolls durchgeführt wird, übernimmt in diesem Fall DTLS diese Aufgabe und stellt sicher, dass die Kommunikation richtig abläuft.Zusätzlich wurden drei weitere Nachrichten hinzugefügt:

  • Client Hello
  • HelloVerifyRequest
  • Client Hello

Diese wurden eingeführt, da DTLS in der Regel mit UDP arbeitet und diese Protokollart auf DOS Angriffe sehr anfällig ist. Das kommt daher, dass die IP-Adresse des Absenders in UDP, einfach abgeändert werden kann und so nicht verfolgbar ist woher eine Anfrage kommt. Ein Blockieren der gefälschten Adresse würde somit nichts nützen und keinen Erfolg erzielen, wie das bei TCP der Fall ist. Client Hello beinhaltet den Start der Kommunikation und liefert alle unterstützen Cipher, sowie Erweiterungen und Kompressionsfunktionen. Die zweite Nachricht liefert einen Cookie zurück, der daraufhin vom Client wieder zurückgesendet werden muss. Sofern die vermeintliche Adresse des Absenders gültig ist, kann er auch darauf Antworten und das oben beschriebene DOS Problem besteht nichtmehr.

Während des Nachrichtenaustausches wird übermittelt, welche Cipher Suites vom Server und Client unterstützt werden. Im weiteren Verlauf muss aber eine Auswahl dieser stattfinden. TLS over LoRaWAN fokussiert auf eine ganz bestimmte Zusammenstellung, um schnelle Geschwindigkeiten zu erzielen und eine Downgrade Attacke zu verhindern. Folgendes Set wird für TLS over LoRaWAN verwendet:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

Durch die fixe Definition einer einzigen Cipher Suite werden zusätzlich eine Menge an Daten eingespart, die im Laufe der Kommunikation übertragen werden.


Änderungen im Aufbau eines LoRaWAN Netzwerkes

Durch das Hinzufügen eines zusätzlichen Protokolls steht man vor neuen Herausforderungen. Insofern muss sich die Nachrichtenverarbeitung umstellen, denn durch das Ändern der Payload kann der Applikationsserver keine Nachricht mehr lesen und weiterverarbeiten. Dafür kommt nun auf die Seite des Clients ein DTLS Client bzw. auf die Seite des Applikationsservers ein DTLS Server. Der Netzwerkserver, das Gateway und der Join Server bemerken keinen Unterschied, da rein die Payload geändert wird. Die ist für diese Teile des Netzes aber sowieso nicht einsehbar. Deswegen ist es irrelevant, was in diesem Feld gesendet wird. Dadurch wird das eigentliche LoRaWAN Protokoll nicht berührt und weitere Geräte haben keine Kenntnis davon. Sollte nun die Topologie während des Einsatzes geändert werden, so stellt das auch kein Problem dar. Die Sicherheitsmechanismen von LoRaWAN bleiben alle aufrecht und werden nicht übergangen oder deaktiviert. Die Arbeit der Ruhr-Universität Bochum beschreibt die Implementierung des DTLS Servers auf der Seite des Netzwerkservers, was aber keinen Sicherheitsvorteil bietet. Der Grund hierfür ist, dass es in der realen Umgebung keinen Unterschied macht, wenn stattdessen der Applikationsserver genutzt wird. Ein Test hingegen wird durch die Verwendung des Applikationsservers deutliche erschwert, da diese Seite oftmals keine API zur Verwaltung der empfangenen Datenpakete zur Verfügung stellt. Das Unternehmen PHYSEC hat das erkannt und nachgebessert indem nun der Applikationsserver für die Implementierung des DTLS-Servers genutzt wird. Dadurch sind etwaige Integritätsverletzungen durch den Netzwerkserver unterbunden. Die Implementierung des Netzwerkes der Arbeit baut rein auf Open-Source Anwendungen auf. Ob PHYSEC diese genauso übernommen hat, ist nicht bekannt, dennoch scheint es auch mit den Bibliotheken möglich zu sein, eine DTLS gesicherte Verbindung zu erzeugen. DTLS arbeitet in der Regel mithilfe von UDP Paketen, was in diesem Fall aber nicht geschieht, da die Kommunikation über LoRaWAN stattfinden soll. Da diese Sprache aber nicht Standardmäßig von einem DTLS Client unterstützt wird, findet sich ein sogenanntes „Translator Interface“ zwischen dem Client und dem Host Controller Interface Prozessor. Der HCI Prozessor übernimmt die Übersetzung zwischen dem LoRa Modul und dem Translator Interface. Das Modul wird in der Arbeit mit iM880B beschrieben und ist ein LoRa Alliance zertifiziertes Bauteil mit großer Reichweite und geringem Stromverbrauch. Es wird von der Firma IMST hergestellt. Eine Nachricht wird vom DTLS Client generiert, an den Übersetzer weitergegeben und dann mithilfe des HCI Prozessors für das LoRa Modul aufbereitet. Danach wird das Paket zum Gateway übertragen. Dieses geht nun den normalen Weg und übermittelt die Nachricht via Internet an den Netzwerkserver. In diesem Fall wurde der Server des Anbieters „The Things Network“ gewählt, da er eine gute API anbietet. Beim Netzwerkserver angekommen geht das Paket nun genau die gegengleiche Richtung und wird über die API an die vordefinierte Bibliothek weitergegeben. Der Translator übersetzt diese LoRaWAN Pakete nun wieder in eine Sprache, die der DTLS Server versteht. Dieser übernimmt und verarbeitet sie weiter .


Handshake Dauer

LoRa arbeitet mit sogenannten „Spreading Factors (SF)“, die die Frequenz und Bitrate eines Chirps angeben. Ein Chirp ist das jeweilige Signal, dass durch die LoRa Platine am Node abgesendet wird und das Gateway auffängt. Dafür gibt es fünf Faktoren, die von 7 bis 12 reichen. Dabei variieren die Bandbreite und Datenrate. Dadurch ist es möglich bei verschiedenen Spreizfaktoren auch unterschiedliche Payload Größen zu erreichen.

Man sieht einen deutlichen Unterschied der maximalen Payload Größen, bei verschiedener Wahl der SF. Das stellt das die Verwendung von DTLS vor neue Herausforderungen, denn ein einfacher Handshake benötigt bei der Übertragung vom Server zum Client 1920 Byte und in die andere Richtung 673 Byte. Das ist bei der höchsten Daten Rate (DR) von 7 zwar schnell abgearbeitet, doch bei einer DR von 0, dauert dies sehr lange. Dies setzt voraus, dass nie ein Paket verloren geht und direkt den vorgesehenen Empfänger erreicht. Sofern ein erneutes Senden notwendig wird, steigt die Byte Anzahl der übermittelten Daten erheblich. Es kommt daher deutlich auf den Aufbau des Netzwerkes an und wie groß die Durchdringung der Signale sein muss. Denn mit der unterschiedlichen Wahl der Frequenz und Bit Rate wird auch die Reichweite und Oberflächendurchdringung variieren. Bei einer optimalen erhöhten Position und direkter Sicht auf das Gateway kann eine größere Datenrate erzielt werden, während das bei einer Platzierung des Nodes in einem Keller auf große Distanz nicht möglich ist. Zusätzlich zu den Limitierungen durch die Payload Größe, gibt es ebenfalls zu bedenken, dass durch die unterschiedlichen Klassen der einzelnen Nodes auch Zeitslots vergeben werden, an jenen auf Downlink Nachrichten gewartet wird und diese auch verarbeitet werden können. Somit kommt es auch auf die Klasse des Nodes an, wie lange ein Handshake dauert. Summiert man alle Erkenntnisse, so fand die Ruhr-Universität heraus, dass man insgesamt auf eine Dauer von mindestens 15 Minuten und maximal 3 Stunden, für einen DTLS Handshake, benötigt werden. Erst ab diesem Zeitpunkt ist es möglich normale Daten über die gesicherte Verbindung zu übermitteln.


Zusammenfassung

TLS over LoRaWAN bietet vollständigen Integritätsschutz mit Ende zu Ende Verschlüsselung und behebt viele Sicherheitsprobleme, indem dem Netzwerkserver das Vertrauen genommen wird, was bis jetzt notwendig war. Somit läuft man nicht Gefahr, dass der Betreiber einen Fehler in der Konfiguration macht. Wie die endgültige Implementierung genau aussieht, kann leider nicht festgestellt werden. Dennoch wurde von dem Unternehmen mitgeteilt, dass die endgültige Version zu einem Großteil aus Open Source Bibliotheken besteht und weitere dezidierte Komponenten hinzugefügt wurden. Diese Arbeit bezieht sich dennoch immer auf die Thesis der Ruhr-Universität und deren Ansätze, die zum großen Teil von PHYSEC in ihr endgültiges Produkt übernommen wurden. Eines der größten Mankos dieser Erweiterung ist die Dauer, die benötigt wird, um einen DTLS Handshake durchzuführen. Zwar muss dieser nur einmal abgearbeitet werden, da immer zwei DTLS Instanzen ausgeführt werden und dadurch währenddessen ein erneuter Handshake parallel zur Payload durchgeführt wird, aber das ist dennoch ein deutlicher Nachteil gegenüber der Standardsicherheit in LoRaWAN. Vergleicht man den Einsatz dieser Technik mit der Standardsicherheit in LoRaWAN, so verringern sich die Auswirkungen der Sicherheitslücken deutlich.

IoT-Protokoll Security Testing Guide

Im Zuge dieser Ausarbeitung wurde eine Security Testing Guide für IoT-Protokolle erstellt. Dadurch ist es möglich anhand einfacher Kriterien in der Designphase einer Implementierung Sicherheitsprobleme zu erkennen und schon davor Lösungen zu suchen. Im Anhang findet sich eine Übersicht des Mandl IoT Security Testing Guides.

File:MIST-Guide Zusammenfassung.pdf

References

Retrieved from "https://wiki.elvis.science/index.php?title=LoRaWAN_Security_Assessment&oldid=3682"