WireGuard über LoRaWAN
Ende-zu-Ende-Sicherheit für schmalbandige IoT-Netze
Eine robuste, Ende-zu-Ende-verschlüsselte Kommunikation mit WireGuard über LoRaWAN im Rahmen von Industrie 4.0 und Smart Cities ist technisch machbar. Doch wie funktioniert sie im Einzelnen, und stößt sie an technische Grenzen? Der Autor dieses Beitrags ist diesen Fragen nachgegangen.
Die fortschreitende Digitalisierung im Rahmen von Industrie 4.0 und Smart Cities beruht zunehmend auf der Vernetzung einer großen Anzahl von IoT-Geräten, die oft über weite Distanzen und mit begrenzten Energieressourcen kommunizieren müssen. Für solche Anwendungsfälle haben sich Low Power Wide Area Networks (LPWANs) etabliert, unter denen LoRaWAN eine führende Rolle einnimmt. Diese Netzwerke sind jedoch für geringe Datenmengen mit kleinen Paketgrößen optimiert, was die Nutzung von Standard-Sicherheitsprotokollen wie IP-basierten VPNs vor erhebliche Herausforderungen stellt. Der durch sie verursachte Protokoll-Overhead ist für die schmalbandige Übertragung zu hoch [1].
Während die native LoRaWAN-Sicherheit die Kommunikation zwischen Endgerät und LoRaWAN-Netzwerkserver schützt, fehlt eine standardmäßige Ende-zu-Ende-Verschlüsselung bis zur finalen Zielanwendung. Diese Sicherheitslücke ist für sicherheitskritische IoT-Anwendungen inakzeptabel. Auf Basis der Erkenntnis, dass sich das als hochperformant bekannte VPN-Protokoll WireGuard grundsätzlich für ressourcenbeschränkte, mit einem RTOS betriebene Systeme eignet, evaluiert diese Arbeit die Realisierung einer Ende-zu-Ende-sicheren Kommunikation mit WireGuard über die stark limitierten Rahmenbedingungen eines LoRaWAN-Netzwerks. Die zentrale Herausforderung liegt darin, das ursprünglich für breitbandige Kommunikation konzipierte WireGuard-Protokoll auf LoRaWAN zu übertragen. Als schmalbandiges IoT-Protokoll bringt LoRaWAN Einschränkungen wie eine geringe Datenrate und stark begrenzte Nutzlastgrößen mit sich, die es zu überwinden galt.
Die technische Grundlage für dieses Vorhaben bildet die Standardisierung der IP-Übertragung über LPWANs durch die IETF. Der Standard RFC 8724 ermöglicht mittels Static Context Header Compression (SCHC) eine effiziente Komprimierung von UDP/IPv6-Headern, sodass IP-basierte Kommunikation über LoRaWAN praktikabel wird [3], [4]. Ziel dieser Arbeit ist es daher, die Implementierung von WireGuard in einem LoRaWAN-Netzwerk zu realisieren und diesen Ansatz hinsichtlich seiner Effizienz, des Datenoverheads und der Eignung für ressourcenbeschränkte Geräte zu bewerten.
Realisierung, Integration und Untersuchung
Abbildung 1 zeigt den konkreten Versuchsaufbau des LoRaWAN-Testnetzwerks. Die Rolle des Endgeräts übernimmt ein STM32F767ZI-Mikrocontroller in Verbindung mit einem RFM95W-LoRa-Modul. Dieser wurde gewählt, weil er mit ausreichend Rechenleistung sowie Speicherressourcen ausgestattet ist und vom Echtzeitbetriebssystem Zephyr vollständig unterstützt wird.
Abbildung 1: Versuchsaufbau des LoRaWAN-Testnetzwerks (Erläuterung siehe Text).
Auf der Gegenseite wird die gesamte Infrastruktur des Ziel-Geräts in einem Raspberry Pi 5 realisiert. Dort fungiert das WM1302-Modul als LoRa-Konzentrator, dessen Daten vom Semtech UDP Packet Forwarder verarbeitet und an den LoRaWAN-Server – implementiert durch die ChirpStack-Software – weitergeleitet werden. Die Kommunikation zwischen den einzelnen Software-Komponenten im Server erfolgt über UDP und MQTT. Dieser Versuchsaufbau bildete die Grundlage für die Implementierung und die anschließenden Messungen.
Um eine stabile Basis für die Machbarkeitsanalyse zu schaffen, wurden im Vorfeld zwei wesentliche Rahmenbedingungen für den Versuchsaufbau festgelegt. Erstens wurde durchgehend die LoRaWAN-Datenrate mit dem Spreading Factor 7 (DR5) verwendet. Diese Einstellung bietet die größtmögliche Payloadgröße (222 Bytes), was entscheidend war, um eine Fragmentierung der großen WireGuard-Pakete zu vermeiden. Die damit einhergehende geringe Sendezeit (Airtime) pro Paket schont zudem den gesetzlich limitierten LoRaWAN-Duty-Cycle und beugt so Übertragungsengpässen vor.
Zweitens wurde das Endgerät als LoRaWAN-Klasse-C-Gerät betrieben. Obwohl dieser Modus energieintensiver ist, gewährleistet er durch ein dauerhaft geöffnetes Empfangsfenster die für das WireGuard-Protokoll notwendige, ständige Erreichbarkeit. Dies stellt sicher, dass der Client auf serverseitig initiierte Anfragen, wie einen neuen Handshake, unmittelbar reagieren kann [7].
Nach der erfolgreichen Integration und Stabilisierung des WireGuard-Protokolls im Zephyr RTOS, was die Lösung spezifischer Handshake- und Zeitstempel-Probleme erforderte, lag der Fokus auf der Übertragung der verschlüsselten Pakete über LoRaWAN.
Abbildung 2: Uplink-Architektur für WireGuard (WG) über LoRaWAN.
Um die Ende-zu-Ende-Sicherheit zu realisieren, wurde die in Abbildung 2 dargestellte Uplink-Architektur implementiert. Der entscheidende Prozessschritt findet im Endgerät (STM32) statt: Ein ausgehendes IP-Paket wird zuerst durch WireGuard verschlüsselt, und erst danach wird der äußere UDP/IPv6-Header des resultierenden Tunnel-Pakets mittels SCHC komprimiert.
Diese Reihenfolge ist zwingend erforderlich, damit auf der Zielseite ein Standard-WireGuard-Server ohne Anpassungen verwendet werden kann. Eine umgekehrte Vorgehensweise würde dazu führen, dass der Server nach dem Entschlüsseln ein für ihn unlesbares, komprimiertes Paket verwirft. Die Implementierung fängt dazu das fertige WireGuard-Paket – samt Header und Verschlüsselung – direkt innerhalb des Sendeprozesses des WG-Moduls ab, bevor es an eine physische Netzwerkschnittstelle übergeben wird. Stattdessen wird es für die Komprimierung und den Versand via LoRaWAN umgeleitet.
Auf der Serverseite (Raspberry Pi) empfängt eine C-Anwendung das komprimierte Paket via MQTT, stellt mittels SCHC-Dekomprimierung das ursprüngliche WireGuard-Paket wieder her und leitet dieses über einen lokalen Socket an den WG-Server weiter. Dieser übernimmt die finale WG-Entschlüsselung und reicht die Nutzdaten an die Ziel-Anwendung weiter.
Abbildung 3: Downlink-Architektur für WireGuard über LoRaWAN.
Der in Abbildung 3 dargestellte Downlink-Prozess beginnt im Raspberry Pi. Ein von der Ziel-Anwendung gesendetes Paket wird zunächst vom lokalen WireGuard-Server verschlüsselt. Anstatt es über das Netzwerk zu versenden, wird dieses verschlüsselte Paket jedoch mittels NetfilterQueue im Server selbst abgefangen, mit SCHC komprimiert und anschließend via LoRaWAN an das Endgerät gesendet.
Im STM32 wird das empfangene Paket nach der LoRaWAN-Verarbeitung durch die SCHC-Bibliothek dekomprimiert. Das Ergebnis ist das wiederhergestellte, aber immer noch WireGuard-verschlüsselte Paket. Die zentrale Herausforderung besteht darin, dieses Paket zur finalen Entschlüsselung an die lokale wg0-Schnittstelle weiterzuleiten. Die Lösung ist eine manuelle Paket-Injektion: Der Ziel-Header des Pakets wird so manipuliert, dass er auf die lokale wg0-Schnittstelle zeigt. Anschließend wird das Paket in den Zephyr-Netzwerkstack injiziert, als wäre es von außen empfangen worden, was die finale Entschlüsselung durch WireGuard anstößt.
Evaluierung der Messergebnisse
Im Folgenden wird ein Anwendungs-Szenario untersucht, um die theoretische Sendekapazität von WireGuard über LoRaWAN zu untersuchen, sowohl mit als auch ohne SCHC-Header-Komprimierung. Bei der verwendeten WG-Implementierung wird alle drei Minuten ein Handshake zur Schlüsselerneuerung stattfinden. Zusätzlich wird für dieses Szenario festgelegt, dass Transport-Pakete mit einer Nutzlast von 10 Bytes vom Endgerät gesendet werden, worauf der Server mit einem Keepalive-Paket antwortet. Die Airtime-Werte für die relevanten WG-Paketgrößen sind in Tabelle 1 zusammengefasst.
Pakettyp | Größe (ohne SCHC) | Airtime (ohne SCHC) | Größe (mit SCHC) | Airtime (mit SCHC) |
Handshake Initiation | 196 Bytes | 331,1 ms | 155 Bytes | 271,6 ms |
Handshake Response | 140 Bytes | 251,1 ms | 99 Bytes | 189,7 ms |
Keepalive-Paket | 80 Bytes | 164,1 ms | 39 Bytes | 102,7 ms |
Transport-Paket (10 Bytes Payloadgröße) | 144 Bytes | 256,3 ms | 103 Bytes | 194,8 ms |
Auf Basis des in Europa geltenden LoRaWAN-Duty-Cycle von 1 Prozent, der die maximale Sendezeit auf 36 Sekunden pro Stunde limitiert, lässt sich aus diesen Werten die theoretisch mögliche Paketanzahl berechnen. Das Ergebnis dieser Berechnung zeigt den signifikanten Vorteil der SCHC-Header-Kompression: Die Anzahl der möglichen Transport-Pakete pro Stunde steigt von 50 auf 83. Dies entspricht einer Steigerung der Sendekapazität um 66 Prozent und unterstreicht die Notwendigkeit von Komprimierungsverfahren für die Nutzung IP-basierter Protokolle wie WireGuard über schmalbandige Netzwerke.
Die nachfolgenden Abschnitte präsentieren die Messergebnisse und vergleichen die drei untersuchten Szenarien – reine LoRaWAN-Kommunikation, UDP/IPv6 über LoRaWAN und WireGuard über LoRaWAN – hinsichtlich Latenz, Datenoverhead und Ressourcenverbrauch.
Abbildung 4: Gegenüberstellung der Mittelwerte der Uplink-Latenzen der drei Kommunikationsszenarien.
Abbildung 4 fasst die Ergebnisse der Uplink-Latenzen in einem Balkendiagramm zusammen und verdeutlicht die Latenzunterschiede zwischen den drei Szenarien. Es ist ein klarer, stufenweiser Anstieg der mittleren Latenz zu erkennen. Die Einführung von UDP/IPv6 mit SCHC führt zu einem signifikanten Mehraufwand gegenüber der reinen LoRaWAN-Übertragung. Der größte Latenzsprung wird durch die zusätzliche Integration von WireGuard verursacht, was primär auf den zusätzlichen Rechenaufwand der kryptographischen Operationen sowie den deutlich höheren Paketgrößen zurückzuführen ist. Innerhalb der Szenarien zeigt sich zudem der erwartete Anstieg der Latenz bei Zunahme der Payloadgröße.
Die Latenz des initialen WG-Handshakes ist eine entscheidende Metrik für den Verbindungsaufbau. Die Messung wurde die Dauer für die ersten drei Schritte des Handshake-Prozesses in 50 Messzyklen erfasst. Die Auswertung dieser Messungen ist in Tabelle 2 und Abbildung 5 zusammengefasst.
Messung | Mittelwert | Median | Standardabweichung | Min. | Max. |
WG-Handshake | 1934,37 | 1931,91 | 9,13 | 1925,16 | 1968,47 |
Die Ergebnisse zeigen zwei zentrale Eigenschaften. Erstens ist die durchschnittliche Latenz für einen vollständigen Handshake mit etwa 1,93 Sekunden relativ hoch. Dieser Wert ist plausibel, weil der Prozess aus drei aufeinanderfolgenden Übertragungen (Uplink, Downlink, Uplink) besteht, die sich summieren. Zudem weisen die Handshake-Pakete selbst einen erheblichen Datenoverhead auf, was ihre Übertragungszeit (Airtime) weiter verlängert und zur Gesamtverzögerung beiträgt. Die extrem geringe Standardabweichung von nur 9,13 ms und die enge Spanne von etwa 43 ms zwischen dem Minimal- und Maximalwert belegen eine hohe Konsistenz und Wiederholbarkeit des Handshake-Prozesses.
Abbildung 5: Box-Plot der Verteilung der WG-Handshake-Latenz aus 50 Messungen. Dargestellt sind der Median (rote Linie), der Interquartilsabstand (blaue Box), die Spannweite (Whisker) sowie die statistischen Ausreißer (Punkte).
Der zentrale, hellblaue Kasten des Box-Plots (Abbildung 5) ist sehr schmal und verdeutlicht, dass die mittleren 50 Prozent der Messwerte in einem extrem engen Bereich zwischen dem unteren Quartil (1930,83 ms) und dem oberen Quartil (1934,66 ms) liegen. Die rote Linie innerhalb der Box markiert den Median bei 1931,91 ms. Die vom Kasten ausgehenden, schwarzen Linien (die Whisker) zeigen die Spannweite der Datenpunkte, die nicht als Ausreißer gelten. Der obere Whisker erstreckt sich bis zum höchsten Wert innerhalb dieses Toleranzbereichs (1936,69 ms).
Die vier einzelnen Kreise oberhalb des Whiskers stellen die statistischen Ausreißer dar.
Zusammenfassend zeigt sich, dass der Handshake-Prozess überwiegend stabil und konsistent ist, was durch den sehr kurzen Interquartilsabstand von nur 3,83 ms belegt wird. Gleichzeitig deuten die wenigen Ausreißer darauf hin, dass seltene, vereinzelte Ereignisse zu leichten Verzögerungen führen können.
Der Ressourcenverbrauch im STM32-Mikrocontroller (Abbildung 6) belegt die Machbarkeit der Implementierung in ressourcenbeschränkten Systemen. Die finale Anwendung inklusive LoRaWAN, Zephyr und WireGuard belegt rund 192,4 KB Flash-Speicher und 89 KB RAM.
Abbildung 6: Gegenüberstellung des Flash- und RAM-Verbrauchs im STM32-Mikrocontroller für LoRaWAN, UDP/IPv6 und WireGuard.
Der Großteil dieses Bedarfs wird durch den vollständigen IP-Stack von Zepyhr und die zusätzlichen Bibliotheken verursacht. Das eigentliche WireGuard-Modul erhöht den RAM-Bedarf nur moderat um etwa 12,3 KB für kryptographische Operationen und Puffer.
Ein interessanter, wenn auch nur eingeschränkt möglicher Vergleich lässt sich zu den Ergebnissen der Bachelorarbeit des Verfassers ziehen. Darin wurde eine WG-Implementierung in demselben Mikrocontroller realisiert, jedoch auf Basis von FreeRTOS und dem LwIP-Stack, die etwa 171 KB Flash und 110 KB RAM beanspruchte [1].
Um den zusätzlichen Datenoverhead der einzelnen Protokollschichten zu bestimmen, wird eine beispielhafte Übertragung einer 10-Byte-Anwendungsnutzlast betrachtet. Als Referenz dient eine reine LoRaWAN-Übertragung, bei der kein zusätzlicher Overhead entsteht. Tabelle 3 fasst den zusätzlichen Protokoll-Overhead für die beiden darüber liegenden Szenarien zusammen.
Szenario | Berechnung des Overheads | Zusätzlicher Overhead |
UDP/IPv6 (mit SCHC) | 48 Bytes (IPv6+UDP) – 41 Bytes (SCHC-Einsparung) | 7 Bytes |
WireGuard (mit SCHC) | 134 Bytes (Gesamt-Overhead) – 41 Bytes (SCHC-Einsparung) | 93 Bytes |
Dieser große Overhead von 93 Bytes bei WireGuard ist protokollbedingt, weil das WG-Paket nicht nur den eigenen Protokoll-Overhead enthält, sondern zusätzlich ein vollständiges, unkomprimiertes UDP/IPv6-Paket kapselt (Abbildung 2 und 3). Obwohl der äußere Header komprimiert wird, muss der innere Header für die Verarbeitung im Zielnetzwerk intakt bleiben, was 48 Bytes dieses Overheads ausmacht.
Der WG-Handshake besteht aus vier Schritten. Der Overhead des WG-Handshakes setzt sich aus den Größen der ausgetauschten Pakete zusammen. Für die Berechnung des Overheads werden die ersten drei Schritte herangezogen. Der vierte Schritt wird, wie bereits bei der Handshake-Latenz-Messung, für die Overhead-Betrachtung vernachlässigt. Der Grund dafür ist, dass dieser Schritt nicht zwingend unmittelbar erfolgen muss.
Auf Basis von Tabelle 1 ergibt sich der Gesamt-Overhead des betrachteten WG-Handshakes aus der Summe der ersten drei Pakete zu 293 Bytes. Um diesen Wert einzuordnen, wird er mit den Ergebnissen bestehender Forschung zu anderen Sicherheitsprotokollen über LoRaWAN verglichen.
Untersuchungen zum Einsatz von Standard-TLS/DTLS zeigen einen Handshake-Overhead im Bereich von 3000 bis 6000 Bytes. Der Overhead des hier vorgestellten Ansatzes ist somit um mehr als einen Faktor 10 geringer [5].
Eine weitere Analyse liefert Vergleichswerte für leichtgewichtige DTLS-Varianten. Dort wird ein Overhead von 198 Bytes für eine auf Pre-Shared Keys basierende Methode (DTLS-PSK) und 746 Bytes für eine zertifikatbasierte Methode (DTLS-ECC) ermittelt. Der in dieser Arbeit gemessene Wert von 293 Bytes für den WireGuard-Handshake positioniert sich somit zwischen dem von DTLS-PSK und DTLS-ECC [6].
Fazit und Ausblick
Die Arbeit demonstriert erfolgreich die technische Machbarkeit einer robusten Ende-zu-Ende-verschlüsselten Kommunikation mit WireGuard über LoRaWAN. Die Implementierung überzeugt durch einen hochgradig stabilen Uplink und einen konsistenten, wiederholbaren Handshake-Prozess.
Die wesentliche Grenze der vorgestellten Lösung ist der signifikante Datenoverhead, der primär durch das unkomprimierte, von WireGuard gekapselte innere IP-Paket verursacht wird. Dieser Overhead stellt zwar einen messbaren Effizienzverlust dar, die Verbindung bleibt jedoch praktikabel.
Zukünftige Forschungsansätze sollten hier ansetzen. Das größte Potenzial liegt in der Implementierung einer zweifachen SCHC-Komprimierung: Würde das innere IP-Paket bereits vor der WireGuard-Verschlüsselung komprimiert, ließe sich die Sendezeit (Airtime) drastisch reduzieren. Ein solcher optimierter Ansatz könnte die Effizienz des leichtgewichtigen WireGuard-Protokolls in schmalbandigen IoT-Netzen entscheidend voranbringen und die Technologie für ein noch breiteres Spektrum sicherheitskritischer Anwendungen nutzbar machen.
Der Autor
Ruien Karimi ist Embedded-Softwareentwickler mit Fokus auf Embedded Systems und IoT-Sicherheit. Sein Studium der Elektro- und Informationstechnik schloss er mit den Vertiefungen Technische Informatik (B.Eng.) und Kommunikationstechnologie (M.Sc.) ab. Seit September 2025 ist er bei Softing Industrial Automation tätig. Die in diesem Beitrag vorgestellte Arbeit entstand in Kooperation mit der Ingenics Digital GmbH.
Literatur
[1] Ben Van der Ross, »Was ist LPWAN? Stromsparende Wide Area Netzwerke erklärt.« Zugriff am: 14.08.2025. (2022), Adresse: https://www.emnify.com/de/blog/was-ist-lpwan?utm_term=&utm_campaign=sea-de-dachdsa-nb-dsa_pilot.
[2] R. Karimi, WireGuard für tief eingebettete Systeme: Bachelorarbeit an der Hochschule München, Fakultät für Elektrotechnik und Informationstechnik. Hochschule München, 2023. Adresse: https://books.google.de/books?id=0OGx0AEACAAJ.
[3] A. Minaburo, L. Toutain, C. Gomez, D. Barthel und J. Zuniga, »SCHC: Generic Framework for Static Context Header Compression and Fragmentation«, Internet Engineering Task Force (IETF), Techn. Ber. 8724, 2020, Zugriff am 06.07.2025. Adresse: https://www.rfc-editor.org/rfc/rfc8724.html.
[4] O. Gimenez und I. Petrov, »Static Context Header Compression and Fragmentation (SCHC) over LoRaWAN«, Internet Engineering Task Force (IETF), Request for Comments 9011, 2021, Zugriff am 06.07.2025. Adresse: https://www.rfc-editor.org/rfc/rfc9011.html.
[5] M. Rademacher, H. Linka, J. Konrad, T. Horstmann und K. Jonas, »Bounds for the Scalability of TLS over LoRaWAN«, Techn. Ber., 2022, Zugriff am 12.08.2025. Adresse: https://www.researchgate.net/publication/360779154_Bounds_for_the_Scalability_of_TLS_over_LoRaWAN.
[6] I. You, S. Kwon, G. Choudhary, V. Sharma und J. T. Seo, »An Enhanced LoRaWAN Security Protocol for Privacy Preservation in IoT with a Case Study on a Smart Factory-Enabled Parking System«, Sensors, Jg. 18, Nr. 6, 2018, issn: 1424-8220. doi: 10.3390/s18061888. Adresse: https://www.mdpi.com/1424-8220/18/6/1888.
[7] L. A. T. C. R. P. Workgroup, »RP002-1.0.0 LoRaWAN Regional Parameters«, LoRa Alliance, Techn. Ber. RP002-1.0.0, 2019, Zugriff am 12.04.2025. Adresse: https://resources.lora-alliance.org/technical-specifications/rp002-1-0-0-lorawan-regional-parameters.