LoRaWAN Security Assessment
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 [BIP19]. 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.
Description
Step 1
Enter these commands in the shell
echo foo echo bar
Step 2
Make sure to read
- War and Peace
- Lord of the Rings
- The Baroque Cycle
Used Hardware
Device to be used with this documentation Maybe another device to be used with this documentation
Courses
- A course where this documentation was used (2017, 2018)
- Another one (2018)