LoRaWAN Security Assessment
Summary
Dieses Wiki bietet eine Übersicht zu der Sicherheit in LoRaWAN 1.0.3. 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.
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 [TLF20]. 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 [IDY20]. 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 [BPG18]. Ein Zitat aus einer Debatte zwischen zwei führenden Kräften von amerikanischen Geheimdiensten sagt: „We kill people based on metadata“ [NWK14]. 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 [MRL19]. 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 [AER17]. 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 [AER17]. 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 [AER17]. 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 [BPG18]. 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 [YXL17] [MRL19]. Durch dieses Verhalten ist folgende Schwachstelle ableitbar:
- Änderung der Daten durch Bit Flipping
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)