Systemdesign Viele vertrauenswürdige Umgebungen

Die Sicherheit von IoT-Geräten basiert auf komplexer Hardware-Mechanismen oder Containervirtualisierung. Mit TEE lassen sich verschiedene Teile des Systems einfach isolieren.
Die Sicherheit von IoT-Geräten basiert auf komplexen Hardware-Mechanismen oder Containervirtualisierung. Mit TEE lassen sich verschiedene Teile des Systems einfach isolieren.

Bisherige Ansätze zur Sicherung von IoT-Geräten basieren auf dem Einsatz komplexer Hardware-Mechanismen oder der Containervirtualisierung. Mit Trusted Execution Environments (TEE) dagegen lassen sich verschiedene Teile des Systems auf einfache Art sicher isolieren.

Das Anwendungsfeld Internet der Dinge (IoT) hat sich stark ausgeweitet, laut aktuellen Schätzungen auf elf Milliarden Geräte, wie ein Bericht der Development Bank of Singapore (DBS) [1] zeigt. Dem Bericht zufolge sind Datenschutz, Sicherheit und Interoperabilität die Haupthindernisse für eine noch breitere Akzeptanz. Während es mit Projekten wie EdgeX Foundry der Linux Foundation Versuche zur Interoperabilität und Standardisierung gibt, bleiben Datenschutz und Sicherheit noch weitgehend unangetastet.

IoT-Geräte arbeiten nicht isoliert, sie müssen typischerweise mit einem zentralen Manager kommunizieren, ihre Ergebnisse veröffentlichen und Befehle von diesem zentralen Manager annehmen. Typische Kommunikationsformen sind Protokolle wie Bluetooth Low Energy (BLE) und TCP/IP (Transmission Control Protocol/Internet Protocol). Diese Protokolle bringen komplexe Serialisierer und Deserialisierer mit, die oft anfällig für Pufferüberlauf-Exploits sind [2].

Gängige Schutzmethoden

Aktuelle Ansätze umfassen Prozess­isolierung, Sandboxing und Containerisierung, die das Betriebssystem (OS, Operating System) anbietet. Die Idee ist, die Fähigkeit des Angreifers zu begrenzen, sich zu bewegen, sobald eine Schwachstelle ausgenutzt wird. Embedded-Geräte sind jedoch in der Regel ressourcenbeschränkt und verfügen über einen begrenzten Speicher und eine begrenzte Rechenleistung. Geräte der Mikrocontroller-Klasse verfügen in der Regel nicht über eine MMU (Memory Management Unit), die benötigt wird, um ein umfangreiches Betriebssystem mit Containerisierung und Sandboxing wie Linux auszuführen.

Zwar bieten mikrokernbasierte Ansätze auch Sicherheit, erfordern aber für ihre minimal privilegierte Kernelcode- und Prozessisolation auch eine physische MMU – der Microkernel F9 ist die einzige von den Autoren identifizierte Ausnahme [3, 4]. Daher neigen Embedded-Betriebssysteme, die auf Hardware ohne MMU laufen, dazu, alle funktionalen Codeblöcke im gleichen Berechtigungsraum zu kombinieren, was dazu führt, dass Programme den gleichen Zugriff auf Code und Daten haben. Ohne Zugriffskontrolle kann eine kompromittierte Komponente des Software-Stacks das gesamte System zum Erliegen bringen.

Die Lösung des Problems ohne Privilegientrennung wird in der Regel über einen Schutz des Speichers durch verwaltete Sprachen oder Annotationen erreicht. Dies soll verhindern, dass Shared Memory Exploits wie Buffer Overflows, Underruns, Use After Free und ähnliches durchgeführt werden. Solche Methoden schützen nicht vor Post-Exploitation-Angriffen und erfordern einen ergänzenden neuen Sicherheitsansatz.

Eine neue radikale Idee: Multizonen

Im Folgenden wird der komplementäre Ansatz, der Struktur und Partitionierung des Gesamtsystems einschließt, betrachtet. Dabei wird versucht, das Prinzip der geringsten Privilegien für die Partitionen anzuwenden. Der Geist der Aussage »Jedes Programm und jeder privilegierte Benutzer des Systems sollte mit dem geringsten Maß an Pri­vilegien arbeiten, das notwendig ist, um die Aufgabe zu erledigen« [5] wird an die Partitionen angepasst.

Häufig wird in der Cloud-Welt das Sidecar-Muster [6] eingesetzt. Es ermöglicht, Funktionsblöcke in separaten Containern zu isolieren. Das Istio Service Mesh [7] geht mit diesem Modell noch einen Schritt weiter und nutzt Sidecars, um die Kommunikation zwischen Mikroservices mit Mutual Transport Layer Security (mTLS) zu ermöglichen – ohne dass sich die Entwickler um Zertifikate oder Methoden kümmern müssen. Ein wesent­licher Vorteil ist die Unabhängigkeit bei der  Zusammensetzung. So kann ein Entwickler lokal mit den ihm am besten vertrauten Frameworks arbeiten und sich für zusätzliche Sicherheit oder Funktionen zur Laufzeit entscheiden.

Diese Vorteile lassen sich mit dem für den Mikrokernel-Ansatz typischen Interprocess-Communications-Modell (IPC) kombinieren. Der Entwickler schreibt die Anwendung unter Berücksichtigung der UART-Logik (Universal Asynchronous Receiver Transmitter) und fügt mit minimalen Änderungen eine weitere Bereitstellungszone für mTLS hinzu.

Für den neuen Ansatz wurde auch untersucht, wie der FTP-Server für UNIX vsftpd [8] (Very Secure File Transfer Protocol Daemon) einen einzelnen Prozess in eine Menge unterteilt. Der Server vsftpd hat getrennte Prozesse, die verschiedene Aufgaben bearbeiten, wobei jeder dieser Prozesse mit den minimalen Privilegien läuft, die für die jeweilige Aufgabe benötigt werden.

Darauf aufbauend lässt sich ein System von mehreren Zonen zusätzlich zur Anwendungszone realisieren. Die Zonen kommunizieren miteinander über InterZone Communications (IZC), ähnlich wie Prozesse, die über IPC kommunizieren, ohne jedoch die für monolithische Kerne typische Angriffsfläche einzuführen. Eine Zone ist für die TLS-Terminierung und die sichere Verbindung mit dem System vorgesehen. Aus Sicht der Anwendungszone unterscheidet sich diese Zone nicht von einer Zone mit UART-Schnittstelle. Beide implementieren eine Kommunikationsverbindung. Die dritte Zone stellt die Wurzel der Sicherheitskette (Root of Trust) für die sichere Speicherung von Zertifikaten und Schlüsselmanagement zur Verfügung. In einem typischen Cloud-Szenario – z.B. AWS IoT Greengrass oder EdgeX – wird die Anwendungszone vom Gerätehersteller, die TLS-Zone vom Cloud-Dienstleister und die Root-of-Trust-Zone vom Unternehmen, das die Geräte fertigt, entwickelt.

Multizonen-Prototyp auf Open-Source-Basis

Für eine Machbarkeitsstudie des Multizonen-Ansatzes wurde MultiZone Security von Hex Five Secutity genutzt, eine offene, standardisierte und leicht anzuwendende TEE (Trusted Execution Environment), die auf GitHub unter der Apache-2.0-Lizenz frei verfügbar ist. MultiZone Security wurde für RISC-V entwickelt, eine freie und offene Befehlssatzarchitektur (ISA, Instruction Set Architecture). Implementiert wurde das Multizonen-Sicherheitskonzept auf dem Entwicklungssystem Freedom E300 von SiFive [9]. Der RTL-Code dieses SoC wurde für das FPGA-Entwicklungsmodul Arty [10] von Digilent entwickelt. Der SoC Freedom E300 enthält keine Ethernet-Funktion, ist aber Open-Source und ermöglicht es so, die Ethernet-Lite-Komponente von Xilinx hinzuzufügen, die für den Betrieb des Ethernet-Ports auf dem FPGA-Modul erforderlich ist.

Die Wahl fiel deshalb auf Ethernet Lite, da so die Komplexität des Direct Memory Access (DMA) vermieden werden kann. DMA wird in typischen IoT-Knoten oft nicht benötigt und würde über den Rahmen dieser Sicherheitsbetrachtung hinausgehen.
Die Schaltung des SiFive-SoCs wurde für die Machbarkeitsstudie modifiziert. So wurde ein einmalig programmierbarer (OTP, One Time Programmable) Speicher für die TLS-Zertifikate ergänzt. Die Daten der Zertifikate werden während der FPGA-Programmierung in den OTP-Speicher geschrieben und können erst danach gelesen werden. Weitere Änderungen sind: Hinzufügen von mehr RAM bis zu 64 KB, Erhöhen der CPU-Frequenz auf 65 MHz, Aktivieren des RISC-V-Benutzermodus und Hinzufügen der Unterstützung für Core Lokal Interrupts. Alle diese Verbesserungen sind als Open Source frei auf GitHub verfügbar [11].