Der heutige Safer Internet Day wurde 1999 in mehreren Ländern Europas ins Leben gerufen, um die Nutzer für das Thema Sicherheit im Internet zu sensibilisieren. Das Thema Sicherheit hat aber in fast allen Bereichen des Internet eine sehr hohe Relevanz. Das Internet der Dinge (engl.: Internet of Things, IoT) ist hier keine Ausnahme.
Dieser Artikel widmet sich dem Thema Sicherheit im Bereich LoRaWAN. Einiges davon kann auch auf andere LPWAN-Technologien übertragen werden.
Das Phänomen des Internet der Dinge zeichnet sich durch eine wachsende Vorherrschaft von Objekten und Instanzen aus, die zu automatischem Datentransfer imstande sind und jeweils einzigartige Kennungen besitzen. Die erhöhte Dichte der IoT-Infrastruktur entsteht hauptsächlich durch Machine-to-Machine (M2M)-Kommunikation, also durch Sensorensysteme, wie man sie in Smart Homes oder Smart Cities, industriellen Automatisierungsprozessen, tragbaren, sog. Mobile-Computing-Geräten, Fahrzeug-zu-Fahrzeug-Kommunikation usw. findet.
Bei einer Analyse sollte nicht isoliert ein einzelnes Geräte im Feld betrachtet werden. Vielmehr gilt es systemisch alle Schnittstellen zu Gateways, Anwendungen und Datenspeicher, in denen große Datenmengen verarbeitet und abgelegt werden, zu berücksichtigen.
Sicherheitsherausforderungen bestehen in allen schichten der IoT-Architekturen. Der Aufwand, um Datenschutz und die Anforderungen von Unternehmen und Gesellschaften in Einklang zu bringen ist erheblich.
Eine wichtige Instanz in diesem Bereich ist der zusammenschluss wichtiger Branchenführer, die Internet of Things Security Foundation (IoTSF). Die IoTSF ist eine gemeinschaftliche, nicht kommerzielle, internationale Antwort auf die komplexen Herausforderungen, die durch die expansive immer stärker miteinander verbundene Welt entstehen. Ihr Ziel erreicht sie durch die Koordination von Zusammenarbeit zwischen den Unternehmen und indem Hersteller dazu angeregt werden, die Sicherheit von Geräten und Systemen von Grund auf zu berücksichtigen. Einige wichtige Vertreter der IoTSF sind Intel, Huawei, IBM, Thales, Secure-IC, BT, Vodafone, Imagination Technologies, Royal Holloway University of London, Glasgow Caledonian University, NMI und PenTest Partners.
Die Herausforderung
Ein großer Teil der Risiken ist vor allem der Tatsache geschuldet, dass IoT-Geräte nach der Inbetriebnahme immer in Bereitschaft sind. Dies ist unabhängig davon, ob sie wirklich immer mit dem Netzwerk verbunden sind oder sich im Standby-Modus befinden. Sie durchlaufen nur am Anfang ihres Lebenszyklus im System einen Authentifizierungsprozess. Dies macht sie aus sicherheitstechnischer Sicht sehr anfällig.
Bei der Produktentwicklung werden Sicherheitsaspekte nicht immer berücksichtigt. Das stellt ein großes Problem dar, welches im gleichen Maße angegangen werden sollte, wie Konnektivität selbst. Einige IoT-Produkte verfügen über veraltete eingebettete Betriebssysteme. Nicht nur deswegen stellt die Installation von System- oder Sicherheits-Updates auf IoT-Geräten eine große Herausforderung dar. Netzknoten werden meist außerhalb oder beim Kunden installiert, daher kommt es nicht selten zu einer großen Anzahl verstreuter Netzknoten, die sehr schwer zu überwachen und zu verwalten sind.
Einstellungen oder Konfigurationen – einschließlich Sicherheitskonfigurationen – für jeden einzelnen Netzknoten individuell vorzunehmen, stellt keine repräsentative technische Lösung dar. Die automatische Initiierung dieser Netzwerkknoten durch den Hersteller ist ebenfalls keine besonders zuverlässige Lösung. Angemessene und erprobte Verfahren müssen verhindern, dass Updates selbst zu Sicherheitslücken werden.
Einige Sicherheitsfirmen bieten spezielle IoT-Sicherheitslösungen an, wie Festplattenverschlüsselung oder die Implementierung manipulationssicherer Komponenten. Diese Lösungen ermöglichen sowohl fortschrittliche, digitale Sicherheit und Lifecycle-Management über Verschlüsselung als auch Zugriffsbeschränkungen auf sensible Daten.
Über den hohen Stellenwert von Sicherheitsaspekten herrscht im IoT-Markt weitgehend Einigkeit. Die gesamten Vorteile neuer Technologien sollten ausschließlich in sicheren Umgebungen erschlossen werden.
Welche Sicherheitsfunktionen umfasst der LoRaWAN-Standard?
Der LoRaWAN-Protokollstack wird in Abbildung 1 dargestellt. Er besteht aus einer Anwendungsebene, einer MAC-Ebene und einer PHY-Ebene. Die Daten aus der Anwendungsebene werden in die MAC-Nutzdaten übertragen. Die MAC-Ebene erstellt aus den MAC-Nutzdaten den MAC-Frame. Die MAC-Nutzdaten enthalten einen Frame-Header (mit den Quell- und Zieladressen sowie einem Frame Counter), einen Frame-Port und die Frame-Nutzdaten (mit den Anwendungsdaten). Mithilfe des Frame-Ports wird festgestellt, ob der Frame ausschließlich MAC-Befehle (wenn er auf 0 gesetzt ist) oder anwendungsspezifische Daten enthält. Schließlich verwendet die PHY-Ebene den MAC-Frame als PHY-Nutzdaten und erstellt so den PHY-Frame, nachdem Präambel, PHY-Header und CRC eingefügt wurden.
Abbildung 1: LoRaWAN-Protokollstack
Die RF-Parameter umfassen Frequenzen, Leistungsstufen, Modulation und die grundlegenden RF-Protokolle. Diese sind alle im LoRaWAN-RF oder der physikalischen Ebene enthalten.
Da die Sicherheitsintegration für jedes drahtlose Netzwerk äußerst wichtig ist, verwendet das LoRaWAN zwei Sicherheitsebenen, wie in Abbildung 2 zu erkennen ist: eine für die Netzwerkebene und eine für die Anwendungsebene. Die Netzwerkebenensicherheit stellt die Authentizität des Geräts im Netzwerk sicher. Die Anwendungsebenensicherheit stellt sicher, dass der Netzwerkbetreiber keinen Zugang zu den Anwendungsdaten des Endnutzers hat.
Abbildung 2: Die zweifachen Sicherheitsebenen des LoRaWAN
Ein Endgerät (Netzknoten) muss aktiviert werden, bevor es über das LoRaWAN-Netzwerk kommunizieren kann. In LoRaWAN-Netzwerken sind zwei Aktivierungsmethoden verfügbar: OTAA und ABP.
Over-the-Air-Aktivierung (OTAA)
Diese OTAA-Methode basiert auf der Zusammenarbeit zwischen Over-the-Air-Nachrichten für Join Requests und Join Accepts. Für jedes Endgerät (Netzknoten) wird ein 64-Bit-DevEUI, ein 64-Bit-AppEUI und ein 128-Bit-AppKey bereitgestellt. Der DevEUI ist eine eindeutige, globale Kennung für das Gerät, die vergleichbar ist mit der MAC-Adresse eines TCP/IP-Geräts. Der AppKey wird zur kryptografischen Zeichnung des Join Request verwendet. Der AppKey wird verwendet wenn der Netzknoten, wie in Abbildung 3 dargestellt, eine Join-Request-Nachricht versendet. Der Netzknoten sendet eine Join-Request-Nachricht bestehend aus seinem AppEUI und DevEUI. Er sendet außerdem eine DevNonce – einen einmaligen, zufällig generierten 2-Byte-Wert, der zur Vermeidung von Replay-Angriffen verwendet wird.
Abbildung 3: Die OTAA-Methode im LoRaWAN
Diese drei Werte werden über den AppKey des Geräts mit einem 4-Byte langen MIC (Message Integrity Code) gekennzeichnet. Der Server akzeptiert Join Requests ausschließlich von Geräten mit bekannten DevEUI- und AppEUI-Werten und überprüft dabei den MIC durch Abgleich mit dem AppKey.
Abbildung 4: Die Elemente einer LoRaWAN-Nachricht
Wenn der Server den Join Request akzeptiert, antwortet er dem Gerät mit einer Join-Accept-Nachricht. Die Anwendungs- und Netzwerkserver berechnen die zwei 128-Bit-Keys des Netzknotens: den Application Session Key (AppSKey) bzw. den Network Session Key (NwkSKey). Diese werden auf Basis von Werten berechnet, die vom Netzknoten in der Join Request Nachricht gesendet wurden.
Zusätzlich generiert der Anwendungsserver seinen eigenen Nonce-Wert: AppNonce. Dabei handelt es sich um einen weiterer einmaligen, zufällig generierter Wert.
Die Join-Accept-Antwort enthält die AppNonce, eine NetID und eine Adresse des Endgeräts- (DevAddr) zusammen mit Konfigurationsdaten für RF-Delays (RxDelay) und den zu verwendenden Kanälen (CFList). Die NetID ist bei LoRaWAN-Geräten der Klasse B wichtig. Sie ist ein 3-Byte-Wert, mit dem die Netzknoten identifizieren können, dass eine Nachrichte von einem netzinternen Gateway gesendet wurde. Daher muss sie eine eindeutig Kennung für das entsprechende LoRaWAN aufweisen. Die Adresse des Endgeräts (DevAddr) in der Join-Accept-Antwort ist eine 32-Bit-Kennung, die innerhalb des Netzwerks einmalig ist.
Die Unterscheidung von Endgeräten, die dem Netzwerk bereits beigetreten sind, ist über die Geräteadresse möglich. So können die Netzwerk- und Anwendungsserver die richtigen Verschlüsselungen verwenden und die Daten richtig interpretieren.
Beim Rückempfang von Daten werden diese mit dem AppKey verschlüsselt. Der Netzknoten verwendet dann den AppKey, um die Daten zu entschlüsseln und leitet mit dem AppNonce-Wert aus der Join-Accept-Nachricht den AppSKey sowie den NwkSKey ab.
Activation by Personalization (ABP)
Diese ABP-Methode unterscheidet sich von der OTAA, da die Netzknoten zusammen mit der DevAddr und den beiden für den Netzknoten eindeutigen Session Keys (NwkSKey und AppSKey) versendet werden. Da die Netzknoten bereits über die benötigten Informationen und Keys verfügen, können sie die Kommunikation mit dem Netzwerkserver beginnen, ohne vorab Join-Nachrichten austauschen zu müssen.
Sobald ein Netzknoten einem LoRaWAN beigetreten ist – entweder über OTAA oder ABP – werden alle zukünftigen Nachrichten mit einer Kombination aus verschiedenen Keys verschlüsselt (siehe dazu auch Security in LoRaWAN):
- Network Session Key (NwkSKey) – ein Sicherheitsmechanismus der Netzwerkebene. Dieser Key ist für jedes Endgerät einzigartig und wird zwischen dem Endgerät und dem Netzwerkserver geteilt. Der Network Session Key sorgt für die Nachrichtenintegrität während der Kommunikation und sichert die Kommunikation von Endgeräten zum Netzwerkserver.
- Application Session Key (AppSKey) – Dieser Key ist für die End-to-End (Gerät-zu-Gerät)-Verschlüsselung der Nutzdaten verantwortlich. Er ist ebenfalls ein AES-128-Bit-Key, der für jedes Endgerät eindeutig ist und wird zwischen dem Endgerät und dem Anwendungsserver geteilt. Der Application Session Key verschlüsselt und entschlüsselt Anwendungsdatennachrichten und sichert Anwendungsnutzdaten.
Diese beiden Session Keys (NwkSKey und AppSKey) sind für jedes Endgerät und jede Session einmalig. Wird das Gerät dynamisch aktiviert (OTAA), werden diese Keys bei jeder Aktivierung erneut generiert. Wird das Gerät statisch aktiviert (ABP), bleiben diese Keys bestehen bis sie manuell geändert werden.
Advanced Encryption Standard (AES)
Die AES-Verschlüsselung mit dem im LoRaWAN implementierten Key-Austausch entsprechend den Sicherheitsmaßnahmen für drahtlose Netzwerke nach IEEE 802.15.4 (dargestellt in Abbildung 5).
Abbildung 5: Gesicherte Anwendungsdatenübertragung im LoRaWAN
Der im LoRaWAN-Standard implementierte Verschlüsselungsmechanismus, der interoperabel zwischen Herstellern und Netzwerkanbietern ist, schafft damit Vertraulichkeit und Integrität bei End-to-End-Datenübertragung.
Die Stärken der Sicherheitsfunktionen des LoRaWAN-Standards
Die Systemsicherheit in LoRaWANs wird durch eine Kombination aus technischen und operativen Maßnahmen realisiert. An dieser Stelle sollte darauf hingewiesen werden, dass das LoRaWAN ursprünglich für Geräte entwickelt wurde, die auf Hardware beschränkt sind. Außerdem empfangen die meisten Anwendungen im LoRaWAN Daten von verteilten Sensoren. Für typische Anwendungen ist das LoRaWAN eine einfache, kosteneffiziente und sichere Lösung.
Die Stärken der Sicherheitsfunktionen im LoRaWAN bestehen aus einigen bewährten Verfahren:
- OTAA-Bereitstellung: Wenn Keys und Zertifikate für jede Session dynamisch zwischen einem Gerät und den Netzwerk- und Anwendungsservern übertragen werden. Durch den erneuten Beitritt zu Netzwerken werden die Session Keys der Geräte regelmäßig geändert. Das ist wichtig für die Vermeidung potentieller Risiken wie Spoofing, Tempering usw.
- Dynamisch aktivierte Geräte (OTAA) verwenden während des Aktivierungsvorgangs den Application Key (AppKey) zur Ableitung der beiden Session Keys. Im Netzwerk wird deren Wert auf den Default-AppKey eingestellt, der dann zur Aktivierung aller Geräte verwendet wird. Die Implementierung eines individuellen AppKeys für jedes Gerät wird empfohlen. Ausschlaggebend ist, dass im gesamten Sicherheitsprozess Keys niemals mit der Over-the-Air-Methode gesendet werden. Es werden ausschließlich die fehlenden Teile einer Berechnung von beiden Seiten ausgetauscht. Die Generierung von Keys durch das Abfangen von Over-the-Air-Traffic ist daher äußerst komplex.
- Das Vorhandensein eines Hardware-Elements zur Speicherung von Sicherheitsanmeldeinformationen im Gerät kann von Vorteil sein. Die Extraktion von Keys durch Reverse-Engineering oder das Scannen von Gerätespeichern ist dadurch deutlich erschwert. Zusätzlich sollte eine sichere Boot-Nutzung die Integrität der Geräte-Firmware sicherstellen.
- Eine zusätzliche Verschlüsselungsebene auf Anwendungsebene wird immer empfohlen und sollte gegebenenfalls umgesetzt werden.
- Zur Vermeidung von Replay-Angriffen ist es wichtig, die Überprüfung von Uplink-/Downlink-Nachrichtenzählern im Netzwerk zu aktivieren. Durch die drahtlose Netzwerkverbindung bleibt die Möglichkeit böswilliger Erfassung und Speicherung von Nachrichten noch bestehen. Durch die Verschlüsselung der Nachrichten ist es jedoch nicht möglich, diese ohne den AppSKey zu lesen. Auch der Austausch von Nachrichten auf der Netzwerkebene ist ohne den NwkSKey nicht möglich, da dabei die MIC-Überprüfung nicht erfolgreich wäre. Die erneute Übertragung von Nachrichten ist möglich. Diese so genannten „Replay-Angriffe“ können durch Frame Counter erkannt und blockiert werden. Wird ein Gerät aktiviert, werden beide Frame Counter (FCntUp und FCntDown) auf 0 gesetzt. Jedes Mal, wenn das Gerät eine Uplink-Nachricht überträgt, wird der FCntUp erhöht. Jedes Mal, wenn der Netzwerkserver eine Downlink-Nachricht überträgt, wird der FCntDown erhöht. Empfängt das Gerät oder das Netzwerk eine Nachricht, deren Frame Count niedriger ist als in der letzten Aufzeichnung, wird die Nachricht ignoriert.
- Anders als beim TCP, ist die Quittierung von LoRaWAN-Daten-Frames optional. Der Empfänger würde diesen Frame dann mit einem Daten-Frame bestätigen, dessen ACK-Bit auf 1 gesetzt wurde. Diese optionale Frame-Quittierung ist für das LoRaWAN ideal, da die Sendezeit von Geräten beschränkt ist. Daher könnte ein gewisser Verlust von Datenpaketen irrelevant sein. Zur Überprüfung wird jedem Frame ein MIC angefügt. Das ist im Grunde eine Signatur, die mithilfe eines Network Session Keys über den Frame berechnet wird. Selbst wenn dieselben Nutzdaten mehrmals übertragen werden, erhält jeder Frame eine einzigartige Signatur, da der Frame Counter für jede Übertragung erhöht wird.
Die Schwächen der Sicherheitsfunktionen des LoRaWAN-Standards
Den Entwicklern von LoRaWAN-Lösungen sollte klar sein, dass die Benutzung des LoRaWAN keine Garantie für 100%-igen Schutz in jeglichen Sicherheitsbereichen ist. Diese Tatsache kann auch auf alle anderen drahtlosen Technologiesysteme übertragen werden. LoRaWAN-Lösungen sollten stattdessen mit dem Bewusstsein für mögliche Sicherheitsrisiken entwickelt werden.
Da LoRaWAN-Lösungen in einem breiten Umfang von Systemen eingesetzt werden – von Sicherheitslösungen für den Haushalt bis zu Ressourcen für Fernsteuerungs- und Überwachungsinfrastrukturen – sind Angriffe und nicht autorisierte Benutzung durchaus möglich.
Einige der wichtigsten Schwächen der Sicherheitsfunktionen im LoRaWAN sind:
- Verschlüsselte Nachrichten haben dieselbe Länge wie der Key.
- Die ABP-Methode legt beide Session Keys dauerhaft fest, was zu Schwachstellen führt.
- Die Speicherung von LoRaWAN-Keys (AppKey, NwkSKey und AppSKey) stellt ein grundlegendes Problem dar. Bei der Entwicklung von Lösujeder Phase von Entwicklung und Ausschöpfung die Netzsicherheit berücksichtigt werden. Mehrere Schwachstellen bestehen in Bezug auf Key-Lifecycle-Management, Session-Key-Generierung, Speicherung und Transport, die eine sorgfältige Entwicklung und Implementierung notwendig machen. Kunden Zugriff auf Geräte-Keys zu gewähren, ist für den Vertrieb nicht von Vorteil. Mit bekannten Seitenkanalattacken können Keys aus dem Gerätespeicher wiedergewonnen werden. Alle Geräte-Keys sollten, z. B. durch Verschlüsselung mit Master-Keys, entsprechend gesichert werden, um das Risiko Ihrer Offenlegung zu verringern. Die Speicherung von LoRaWAN-Netzwerkserver-Keys ist eine Prouuml;r die eine komplette Systemlösung bereitgestellt werden muss.
- Eine weitere Schwäche besteht in den Identifikations- und Verbindungsprozessen. Jedes Gateway sendet regelmäßig Beacons (seine individuelle ID) an den Server. Diese ID kann von Angreifern leicht abgerufen werden. Ist die ID bekannt, kann das Gateway werden, beispielsweise mit einem bösartigen Gateway, das seine ID häufiger sendet als das echte.
Einige Hersteller verfolgen einen anderen Ansatz: die Nachrüstung vorhandener Sicherheitselemente. Dieser Prozess ist nicht optimal wenn ein System viele verteilte Komponenten hat. Die Umsetzung ist empfindlich, komplex, anspruchsvoll und kann häufig nicht auf sichere, zeitnahe und kosteneffiziente Weise durchgeführt werden.
Fazit und Ausblick
Der aktuelle LoRaWAN-Standard 1.0.x beinhaltet bereits ein verhältnismäßig hohes Maß an Sicherheit. Die oben gelisteten Risiken und Angriffsszenarien haben durchaus ihre Berechtigung und sollten bei jedem Anwendungsfall individuell bewertet werden. Lösungsansätze wurden oben schon diskutiert.
Um den gestiegenen Sicherheitsanforderungen in IoT-Netzwerken Rechnung zu tragen, wird innerhalb der LoRa Alliance stetig an der Verbesserung des Standards gearbeitet. Die LoRa Alliance ist ein Non-Profit Zusammenschluss von Organisationen die bei der Standardisierung von LPWAN Netzwerken zusammen arbeiten.
Die neue LoRaWAN 1.1 Spezifikation wurde am 17.Oktober 2017 veröffentlicht. Da die neue Spezifikation maßgebliche Änderungen an den bestehenden Netzwerkprotokollen und der LoRaWAN Kommunikation mit sich bringt, werden erste Endgeräte nach der neuen Spezifikation frühestens im Laufe von 2018 erwartet. Geräte nach LoRaWAN 1.1 Standard sind rückwärts kompatibel mit LoRaWAN 1.0.x Geräten und können auch mit 1.0.2 Netzwerk Servern zusammen arbeiten.
Die Änderungen der LoRaWAN 1.1 Spezifikation betreffen sowohl die Endgeräte als auch die Gateways und Server. Die wichtigsten Neuerungen befinden sich in der Kommunikation zwischen Endgerät und Gateways sowie in der Kommunikation zwischen den Servern.
Insbesondere wird den in der aktuellen Spezifikation 1.0.2. noch möglichen Join Replay Angriffe und den Downlink ACK Angriffe Rechnung getragen.
Hierfür wurde z.B. der Uplink Frame Counter (FCntUp) verschlüsselt in Bestätigungsnachrichten (ACK Downlinks) mit aufgenommen. Mit Hilfe dieser Neuerung kann das Endgerät erkennen, welche seiner Nachrichten vom Netzwerkserver bestätigt wurde.
Weitere Sicherheitsverbesserungen betreffen die klare Trennung zwischen Netzwerkserver, Joinserver und Applikationsserver und die Einführung von zusätzlichen Schlüsseln wie NwkKey, NwkSEncKey, SNwkSIntKey, FNwkSIntKey und AppSKey. Diese neuen Schlüssel sind insbesondere für das neue Handover Roaming wichtig, das es ermöglicht, Nachrichten von Endgeräten über fremde LoRaWAN Netzwerke hinweg aktiv bis zu dem Heimatnetzwerk des Endgerätes weiter zu leiten.
Besonderes Augenmerk wurde auch auf die nach der Spezifikation 1.1 möglichen “third party Join Server” gelegt. Diese Join Server werden nun nicht mehr von den Betreibern der Netzwerk Server verwaltet, sondern von einer vertrauenswürdigen dritten Instanz bereitgestellt. Auf den Join Servern werden alle sicherheitsrelevanten Schlüssel der Endgeräte verwaltet und entweder den für den Transport der Nachrichten zuständigen Netzwerk Server oder den für die Verarbeitung der Nachrichten zuständigen Applikation Server bereitgestellt. Eine klare Trennung dieser Zuständigkeiten verhindert, dass der Netzwerkbetreiber (Operator) den Inhalt (Paypload) der LoRaWAN Nachrichten mitlesen kann.
Falls Sie weiterhin über das Thema Sicherheit bei LPWAN auf dem Laufenden gehalten werden wollen, tragen Sie sich einfach auf unserer Mailing-Liste ein.
