LoRaWAN Security Assessment - Revision history

NKirnbauer: expired links changed with links from wayback machine

2024-09-23T14:59:35Z

expired links changed with links from wayback machine

← Older revision		Revision as of 14:59, 23 September 2024
Line 214:		Line 214:
	== References ==		== References ==

	* https://lora-alliance.org/sites/default/files/2018-04/what-is-lorawan.pdf		* http://web.archive.org/web/20200925193738/https://lora-alliance.org/sites/default/files/2018-04/what-is-lorawan.pdf
	* https://lora-developers.semtech.com/library/tech-papers-and-guides/lora-and-lorawan/		* http://web.archive.org/web/20201028121324/https://lora-developers.semtech.com/library/tech-papers-and-guides/lora-and-lorawan/
	* https://lora-alliance.org/sites/default/files/2018-07/lorawan1.0.3.pdf		* http://web.archive.org/web/20201018130111/https://lora-alliance.org/sites/default/files/2018-07/lorawan1.0.3.pdf
	* https://tools.ietf.org/html/rfc8376		* https://tools.ietf.org/html/rfc8376
	* https://lora-alliance.org/sites/default/files/2019-05/lorawan_security_whitepaper.pdf		* https://lora-alliance.org/sites/default/files/2019-05/lorawan_security_whitepaper.pdf
Line 222:		Line 222:
	* https://github.com/IOActive/laf/		* https://github.com/IOActive/laf/
	* https://github.com/cyberms/Loracrack		* https://github.com/cyberms/Loracrack
	* https://~~www~~.~~physec~~.de/~~lora~~-~~tls~~-~~extension~~-~~for~~-~~iotree~~/		* http://web.archive.org/web/20201028121324/https://lora-developers.semtech.com/library/tech-papers-and-guides/lora-and-lorawan/

	[[Category:Documentation]]		[[Category:Documentation]]

PMandl: /* IoT-Protokoll Security Testing Guide */

2020-05-13T09:46:04Z

IoT-Protokoll Security Testing Guide

← Older revision		Revision as of 09:46, 13 May 2020
Line 208:		Line 208:
	== IoT-Protokoll Security Testing Guide ==		== 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		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]]		[[File:MIST-Guide_Zusammenfassung.pdf]]

PMandl: /* IoT-Protokoll Security Testing Guide */

2020-05-13T09:44:14Z

IoT-Protokoll Security Testing Guide

← Older revision		Revision as of 09:44, 13 May 2020
Line 209:		Line 209:

	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		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
	[MIST-Guide_Zusammenfassung.pdf]
			[[File:MIST-Guide_Zusammenfassung.pdf]]

	== References ==		== References ==

PMandl at 09:43, 13 May 2020

2020-05-13T09:43:59Z

← Older revision		Revision as of 09:43, 13 May 2020
Line 205:		Line 205:
	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.		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.		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
			[MIST-Guide_Zusammenfassung.pdf]

	== References ==		== References ==

PMandl: /* Sicherheitsprobleme in LoRaWAN 1.1 */

2020-05-13T09:26:37Z

Sicherheitsprobleme in LoRaWAN 1.1

← Older revision		Revision as of 09:26, 13 May 2020
Line 98:		Line 98:

	'''Downgrade Attacken'''		'''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:		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		* Downgrade Attacke auf die alte Protokollversion
Line 103:		Line 104:

	'''Dauer einer OTAA Session'''		'''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:		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		* Ungewisse Gültigkeitsdauer der Session Keys

PMandl at 09:26, 13 May 2020

2020-05-13T09:26:00Z

← Older revision		Revision as of 09:26, 13 May 2020
Line 138:		Line 138:
	'''LoRaCrack'''		'''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. ~~Denn, wie in Punkt 2.3.5 beschrieben,~~ erfolgt die Erzeugung mithilfe von drei Werten:		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		* AppNonce
	* NetId		* NetId
Line 148:		Line 148:
	'''LoRaWAN Auditing Framework Zusammenfassung'''		'''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 ~~in Punkt 3.1.3.~~ relevant. Ein klassischer Penetrationstest des Netzwerkes kann folgende Schritte haben:		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.		* Datenpakete durch Kompromittierung des Netzwerkservers oder Erstellung eines Gateways abfangen.
	* AppKey mithilfe des BruteForcer Tools testen.		* AppKey mithilfe des BruteForcer Tools testen.

PMandl: /* TLS over LoRaWAN */

2020-05-13T09:25:04Z

TLS over LoRaWAN

← Older revision		Revision as of 09:25, 13 May 2020
Line 194:		Line 194:
	'''Handshake Dauer'''		'''Handshake Dauer'''

	LoRa arbeitet mit sogenannten „Spreading Factors (SF)“, die die Frequenz und Bitrate eines Chirps angeben~~. In Punkt 2.2 wurde das bereits angesprochen~~. 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.		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 ~~(Punkt 2.3.2.)~~, 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.		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.

PMandl: /* TLS over LoRaWAN */

2020-05-13T09:24:32Z

TLS over LoRaWAN

← Older revision		Revision as of 09:24, 13 May 2020
Line 188:		Line 188:

	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.		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. Abbildung 12 beschreibt nun das Setup, wie die Implementierung der Server und des Clients mit der Hardware zusammenarbeiten kann. Dafür wird auf die Testumgebung in der Arbeit der Ruhr-Universität Bochum eingegangen. Ob die Pakete aber weitergeleitet werden und die DTLS-Server auf der Applikationsseite sind, macht in der Praxis keinen Unterschied zum Testsetup.		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 .		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 .

PMandl: /* TLS over LoRaWAN */

2020-05-13T09:21:39Z

TLS over LoRaWAN

← Older revision		Revision as of 09:21, 13 May 2020
Line 164:		Line 164:

	'''Einführung'''		'''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.		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.		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.
Line 185:		Line 186:

	'''Änderungen im Aufbau eines LoRaWAN Netzwerkes'''		'''Ä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.		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. Abbildung 12 beschreibt nun das Setup, wie die Implementierung der Server und des Clients mit der Hardware zusammenarbeiten kann. Dafür wird auf die Testumgebung in der Arbeit der Ruhr-Universität Bochum eingegangen. Ob die Pakete aber weitergeleitet werden und die DTLS-Server auf der Applikationsseite sind, macht in der Praxis keinen Unterschied zum Testsetup.		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. Abbildung 12 beschreibt nun das Setup, wie die Implementierung der Server und des Clients mit der Hardware zusammenarbeiten kann. Dafür wird auf die Testumgebung in der Arbeit der Ruhr-Universität Bochum eingegangen. Ob die Pakete aber weitergeleitet werden und die DTLS-Server auf der Applikationsseite sind, macht in der Praxis keinen Unterschied zum Testsetup.


	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 .		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'''		'''Handshake Dauer'''

	LoRa arbeitet mit sogenannten „Spreading Factors (SF)“, die die Frequenz und Bitrate eines Chirps angeben. In Punkt 2.2 wurde das bereits angesprochen. 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.		LoRa arbeitet mit sogenannten „Spreading Factors (SF)“, die die Frequenz und Bitrate eines Chirps angeben. In Punkt 2.2 wurde das bereits angesprochen. 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.

Line 199:		Line 200:

	'''Zusammenfassung'''		'''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.		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.		Vergleicht man den Einsatz dieser Technik mit der Standardsicherheit in LoRaWAN, so verringern sich die Auswirkungen der Sicherheitslücken deutlich.

PMandl: /* Sicherheitslösungen für LoRaWAN */

2020-05-13T09:21:01Z

Sicherheitslösungen für LoRaWAN

@@ Line 156: / Line 156: @@
 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.
 == References ==