WireGuard für tief eingebettete Systeme

Eine sichere und effiziente Netzwerkkommunikation in tief eingebetteten Systemen stellt eine Herausforderung dar. Das liegt an den begrenzten Ressourcen wie Speicher und Rechenleistung von solchen Systemen. Aus diesem Grund habe ich in meiner Bachelorarbeit die Eignung von WireGuard für tief eingebettete Systeme untersucht. Da WireGuard als hochperformantes VPN-Protokoll bekannt ist und einen schmalen Quellcode vorweist, bin ich von folgender Hypothese ausgegangen: WireGuard ist für die Integration in tief eingebettete Systeme geeignet.

Die Herausforderung: Eignet sich WireGuard für die Integration in tief eingebettete Systeme?

Ziel meiner Bachelorarbeit war es zu evaluieren, ob sich das VPN-Protokoll WireGuard für die Vernetzung von leichtgewichtigen, mit einem RTOS betriebenen IoT-Geräten eignet. Hierfür wurde ein passend ausgewählter Mikrocontroller mit einem Echtzeitbetriebssystem mit dem LwIP-Stack um eine WireGuard-Komponente erweitert. Weiterhin wurde in einem Testnetzwerk eine WireGuard-Verbindung zwischen dem entwickelten tief eingebetteten System und einem Linux-Server aufgebaut. Anschließend wurde der Netzwerkdatendurchsatz der WireGuard-Verbindung gemessen und der Ressourcenverbrauch auf dem Mikrocontroller ermittelt. Im Anschluss wurde die VPN-Verbindung mit einer DTLS-Verbindung verglichen. Hierbei wurde ebenfalls der Netzwerkdatendurchsatz gemessen und der Ressourcenverbrauch auf dem Mikrocontroller ermittelt. Die Messergebnisse beider Verbindungen werden in dieser Arbeit gegenübergestellt und diskutiert.

Meine Arbeit beschäftigt sich hauptsächlich mit verschlüsselten Netzwerkverbindungen. Das bedeutet, dass der Mikrocontroller eine relativ hohe Rechenleistung bieten sollte und mit einer Taktfrequenz von bis zu 216 MHz erfüllt der STM32f767zi diese Anforderung. Des weiteren enthält dieser Mikrocontroller eingebettete Hochgeschwindigkeitsspeicher mit einem Flash-Speicher von 2 MB und 512 KB SRAM. Somit weist der verwendete Mikrocontroller einen vergleichsweise hohen Speicher auf und ermöglicht es dem Anwender komplexe Anwendungen auszuführen.

Hardwaregrundlage: Der Mikrocontroller STM32f767zi

Die STM32-Familie von 32-Bit-Mikrocontrollern von STMicroelectronics basiert auf den von ARM entwickelten Cortex-M-Prozessoren und bieten eine hohe Performance, Echtzeitfähigkeit, digitale Signalverarbeitung, Konnektivität und einen Betrieb mit geringem Stromverbrauch. Ich habe bei meiner Bachelorarbeit den Mikrocontroller STM32f767zi als tief eingebettetes System verwendet. Dieser Mikrocontroller stellt eine Vielzahl von Peripheriegeräten, einschließlich einer integrierten Ethernet-Schnittstelle zur Verfügung, die es ermöglicht, Daten über ein Netzwerk zu übertragen.

STM32CubeIDE als Entwicklungsumgebung

Als Entwicklungsumgebung habe ich die STM32CubeIDE verwendet. Diese C/C++-Entwicklungsplattform basiert auf dem Eclipse-Framework und beinhaltet Konfigurations- und Codegenerierungsfunktionen.

Um die Programmierung zu erleichtern, wurde die von ST erstellte und freigegebene Hardware Abstraction Layer (HAL)-Bibliothek verwendet. Die HAL-Bibliothek gewährleistet eine gute Portabilität über die STM32-Mikrocontroller. Die Bibliothek abstrahiert die Hardware des Mikrocontrollers und stellt eine einheitliche Schnittstelle für die Programmierung von Peripheriegeräten wie z. B. GPIO, UART oder Timer zur Verfügung. Dies erleichtert die Entwicklung erheblich, da es nicht notwendig ist, spezielle Hardware-Kenntnisse zu haben, um die Peripheriegeräte anzusteuern. Mit der graphischen Oberfläche der CubeIDE wurden die jeweiligen Peripheriegeräte konfiguriert und anschließend der entsprechende Initialisierungscode generiert.

FreeRTOS als Echtzeitbetriebssystem und LwIP als IP-Stack

Ich habe FreeRTOS als Echtzeitbetriebssystem ausgewählt, da es ein marktführendes RTOS für Mikrocontroller und kleine Mikroprozessoren ist und somit eine umfangreiche Dokumentation besitzt, welche die Implementierung erleichtert. FreeRTOS wird unter einer MIT-Open-Source-Lizenz vertrieben und kann somit in jeder Applikation, ob privat oder kommerziell ohne Einschränkung eingesetzt werden. Des weiteren hat dieses Echtzeitbetriebssystem einen minimalen ROM-, RAM- und Verarbeitungsaufwand mit einem Kernel-Platzbedarf, der typischerweise zwischen 6 KB und 12 KB liegt und eignet sich somit gut für eingebettete Systeme, die in der Regel einen geringen Speicherplatz bereitstellen.

Da die ausgewählte WireGuard-Implementierung, die als Basis zur Integration von WireGuard verwendet wird, auf LwIP basiert, wurde LwIP als IP-Stack ausgewählt. Das lightweight IP (LwIP) ist ein kostenloser und leichtgewichtiger TCP/IP-Protokollstack, der sich für den Einsatz in eingebetteten Systemen eignet. Das Hauptaugenmerk bei der Umsetzung von LwIP liegt darauf, die RAM-Nutzung zu reduzieren, während immer noch ein vollständiger TCP/IP-Stack bereitgestellt wird.

Das Prinzip meiner Arbeit

In meiner Arbeit wurde eine VPN-Verbindung mit WireGuard zwischen dem tief eingebetteten System und dem Raspberry Pi, der als Linux-Server fungiert, hergestellt. WireGuard funktioniert durch Hinzufügung einer Netzwerkschnittstelle. Die virtuelle WireGuard-Netzwerkschnittstelle wird im Rahmen dieser Arbeit als wg0 bzw. wg0-Schnittstelle bezeichnet.

System
System

Abbildung 1 zeigt die Struktur des Testnetzwerks sowie verwendete Protokolle. Das Testnetzwerk besteht aus dem STM32-Mikrocontroller, einem Windows10-Rechner und einem Raspberry Pi 3 B. Diese drei Netzwerkkomponenten sind per Ethernet-Kabel über einen Netgear GS105 GE GS105GE Netzwerkswitch miteinander verbunden und bilden ein Local Area Network (LAN). Der Raspberry Pi dient als Netzwerk-Server und hat ein 64-Bit Linux-Betriebssystem. Weiterhin dient der Raspberry als DHCP-Server, mit einem DHCPAdressbereich von 192.168.1.101 bis 192.168.1.200 und hat selbst die feste, statische eth0-IP-Adresse 192.168.1.100.

Das tief eingebettete System dient als Netzwerk-Client. Dank des LwIP-Stacks fungiert der STM32 als DHCP-Client und bezieht über den Switch vom DHCPServer die eth0-IP-Adresse 192.168.1.102. Der Windows10-Rechner ist per USB mit dem Mikrocontroller verbunden und dient hauptsächlich zur Programmierung des STM32 mit der CubeIDE. Weiterhin bekommt der Windows10-Rechner vom DHCP-Server die eth0-IP-Adresse 192.168.1.101. Dadurch kann der Windows10-Rechner per SSH auf den Raspberry Pi zugreifen.

Die WireGuard-Verbindung ist in der Abbildung 1 rot gekennzeichnet und wird mit einem virtuellen, verschlüsselten VPN-Tunnel illustriert. Weiterhin sind in rot die jeweiligen Tunnel-IP-Adressen bzw. wg0-IP-Adressen sowie deren listening-Ports angegeben. Der STM32-Mikrocontroller dient als WireGuard-Client und der Raspberry Pi als WireGuard-Server.

Nach der Implementierung von WireGuard wurden Messungen durchgeführt, um den Netzwerkdatendurchsatz und den Ressourcenverbrauch auf dem Mikrocontroller zu ermitteln.

System
System

Um den Netzwerkdatendurchsatz zwischen WireGuard-Client und Server zu bestimmen, wird das OpenSource Tool iperf verwendet. Iperf basiert auf dem Client- Server-Modell und misst die maximale TCP und UDP Netzwerk Bandbreite zwischen Client und Server. Für einen Testaufbau (Abb. 2) wird jeweils ein iperf-Client und ein iperf-Server benötigt. Dabei wird in der Regel der Netzwerkdurchsatz vom Client zum Server gemessen. In Abb. 2 ist der STM32 links und der Raspberry Pi rechts eingezeichnet. Die Farbe blau deutet die iperf-Messung an. Der iperf-Server führt die Messung anhand der Anzahl der empfangenen Pakete pro Zeiteinheit durch.

System
System

Zum Vergleich wurde der Netzwerkdatendurchsatz einer DTLS-Verbindung ermittelt. Abbildung 3 illustriert die Messung des Netzwerkdatendurchsatzes der DTLS-Verbindung mit iperf zwischen dem STM32 (DTLS-Client, links) und dem Raspberry Pi (DTLS-Server, rechts). Die Farbe blau deutet die iperf-Messung an. Hierbei ist der Weg eines UDP-Pakets durch das Testnetzwerk (Abb. 1) gezeigt. Zu Beginn wird das Paket vom DTLS-Client verschlüsselt (1) und über das eth0-Interface an den DTLS-Server (Goldy) gesendet (2). Goldy entschlüsselt das empfangene Paket (3) und leitet das Paket weiter an den iperf-Port (4), auf dem der iperf- Server lauscht.

Ergebnis: WireGuard ist im Vergleich zu DTLS performanter

Das Kernergebnis dieser Arbeit besagt in der Tat, dass WireGuard im Vergleich zu DTLS performanter ist und weniger Ressourcen benötigt und sich somit für tief eingebettete Systeme eignet (Abb. 4, 5 und 6).

System
System

Im Vergleich zum DTLS-Protokoll, das für Echtzeit-Anwendungen mit geringer Latenz und datenintensiven Anforderungen bekannt ist, zeigt WireGuard eine bessere Leistung. Insbesondere die Messungen zeigen, dass WireGuard im Vergleich zur DTLS-Verbindung niedrigere Jitter-Werte (Abb. 4) und eine höhere Bandbreite (Abb. 5) aufweist. Dadurch ermöglicht WireGuard einen effizienteren Datendurchsatz (Abb. 6) und weist außerdem einen geringeren Ressourcenverbrauch auf dem STM32 auf.

System
System

System
System

Dies bestätigt die Hypothese der Eignung von WireGuard für die Integration in tief eingebettete Systeme. Die Kombination aus geringem Ressourcenverbrauch und besserer Performance macht WireGuard zu einer geeigneten und für viele Zwecke sogar besseren Lösung als DTLS für tief eingebettete Systeme.

Wie könnte es weitergehen?

Es ist wichtig anzumerken, dass die Messungen in dieser Arbeit WireGuard nur mit dem DTLS-Protokoll vergleichen. Weitere Vergleiche mit anderen VPNLösungen wie OpenVPN oder IPsec könnten zusätzliche Einblicke liefern und eine umfassendere Beurteilung der Eignung von WireGuard für tief eingebettete Systeme ermöglichen. Weiterhin gilt es für eine umfassendere Beurteilung zu erforschen, wie sich das WireGuard-Protokoll auf verschiedenen Mikrocontrollern mit unterschiedlichen Ausstattungen verhält. Eine Untersuchung der Optimierungsmöglichkeiten der gemessenen Parameter wie Speicherverbrauch und Datendurchsatz auf anderen Mikrocontrollern wäre von Interesse. Dadurch könnte ein vertieftes Verständnis dafür gewonnen werden, wie WireGuard in Bezug auf Leistung und Ressourcenverbrauch auf verschiedenen Mikrocontrollern funktioniert.

Zusammenfassend habe ich meine Bachelorarbeit mit großer Freude verfasst und war besonders am gewählten Thema sehr interessiert. Der Weg zum Ergebnis war, wie bei jeder wissenschaftlichen Arbeit, herausfordernd, aber dank der ausgezeichneten Betreuung und Unterstützung meiner Arbeitskollegen konnte ich mein Ziel erfolgreich erreichen.

Veröffentlichung als Fachartikel

Diese Arbeit stieß beim Fachverlag WEKA auf großes Interesse und wurde in der Zeitschrift Elektronik, Heft 21 - 2023 unter dem Titel WireGuard oder DTLS – ein Vergleich veröffentlicht.