Isolation als Schutzschild Sicherheit für IoT-Geräte durch Software-Isolation

Anbieter zum Thema

Arvato Systems

TXOne Networks

Keeper Security EMEA Ltd.

Maxim Integrated Products GmbH

Geräte für das Internet of Things müssen klein, kostengünstig und einfach sein. Gleichzeitig sind IoT-Devices für Cyberkriminelle von zunehmend größerem Interesse, denn ein erfolgreicher Angriff öffnet oft einen direkten Weg ist ungeschützte Firmennetzwerk. Mit dem Prinzip der Software-Isolation lassen sich IoT-Geräte aber wirksam vor Angriffen schützen.

Internet-of-Things-(IoT)-Geräte übernehmen viele Aufgaben: Sie können zum Tracken von Assets dienen; als Zugriffskontrollen; aber auch für die vorausschauende Wartung von Maschinen. Dabei erfassen sie Daten und verarbeiten, speichern und versenden diese. Die gewonnen Informationen sind in vielen Fällen wertvoll und sollten nicht in falsche Hände geraten. Daher ist Sicherheit eine der wichtigsten Anforderungen an IoT-Applikationen.

Die Kommunikation zwischen den beteiligten Geräten muss abgesichert und zuverlässig erfolgen, Assets müssen sicher gespeichert und verarbeitet werden und die Integration der Devices muss sicherheitstechnisch konsistent sein. Dieser Artikel untersucht, wie sich Sicherheit als integraler Bestandteil von IoT-Geräten implementieren lässt. Betrachten wir zuerst die Bestandteile eines IoT-Geräts: Architektur, Kommunikation, Integration und Assets.

Bildergalerie

Ein IoT-Gerät ist ein Glied in einer Kette von Prozessschritten – vom Erfassen über das Auswerten bis zum Aufbereiten von Daten. Häufig müssen die vernetzten Objekte selbst viele Funktionen beherrschen – dazu zählt auch die Kommunikation mit Backend-Einheiten wie Gateways, Servern oder der Cloud. All diese Funktionen sollen in das kleinstmögliche, günstigste und einfachste Embedded-System-Design integriert werden.

Im IoT ist zudem eine lange Standzeit batteriebetriebener Geräte essenziell. Um die Zahl aktiver Komponenten zu minimieren, übernimmt oft ein Mikrocontroller gleich mehrere Anwendungen. Nach gängiger Praxis kommt ein Betriebssystem zum Einsatz, das unterschiedliche Speicherbereiche isoliert adressieren kann. Dies erfordert jedoch leistungsfähige CPUs zum Beispiel auf Arm-Cortex-A-Basis, die mit ausreichend Arbeits- und Flash-Speicher ausgestattet sind – ein Widerspruch zu den Vorgaben, dass das Design möglichst klein, einfach und günstig sein soll. Das Bündeln der vielen Funktionen macht die Geräte zudem leichter angreifbar. Hinzu kommt: Ein IoT-Device braucht Schnittstellen für die Datenkommunikation sowie Firmware- und Service-Updates. Diese Interfaces können Hackern als Einfallstore dienen. Doch das Mechanismen zu ihrem Schutz zu implementieren erhöht die Komplexität des IoT-Knotens, was ebenfalls den Vorgaben zuwider läuft.

Zugriffskontrolle: Kritisch bei parallel laufenden Programmen

Betrachten wir als Beispiel ein Embedded-Gerät, das mit einem Computer verbunden ist. Es kann Fingerabdrücke erfassen und verarbeiten, im bidirektionalen Modus drahtlos per Bluetooth oder Li-fi kommunizieren, die Verifizierungsinformationen der Fingerabdrücke und einen geheimen Schlüssel speichern und Anwendungen ausführen (Bild 1). In erster Linie dient dieses Gerät dazu, den Nutzerzugriff auf einen hochwertigen Dienst zu kontrollieren, der sich auf einem Remote-Server befindet und über einen Client-Computer zugänglich ist.

Dabei kommt die Zwei-Faktor-Authentifizierungsmethode zum Einsatz. Wenn ein Nutzer Zugriff auf den Dienst anfordert, wird eine Zufallszahl (Challenge) generiert und vom Server über den Computer an das Embedded-Gerät gesendet. Nur wenn der Fingerabdruck des Anwenders mit den gespeicherten Informationen übereinstimmt, wird die Challenge kryptographisch mit dem geheimen Schlüssel verknüpft (verschlüsselt oder signiert) und schließlich zur Authentifizierung an den Remote-Server zurückgeschickt.

Die Nutzungsdauer des Geräts lässt sich durch das Hinzufügen neuer Anwendungen erhöhen, die Zugriffskontrollen für andere Dienste bereitstellen. Unter Sicherheitsaspekten ist es jedoch ein Nachteil, wenn sich mehrere Anbieter, Anwendungen und Schlüssel die gleiche Hardwareplattform teilen. Die Komplexität und Leistungsfähigkeit der Geräte ist in der Regel durch Preis und Formfaktor limitiert. Oft bestimmen Kriterien wie der kleinstmögliche Embedded-Speicher und eine möglichst einfache Architektur die Wahl des Mikrocontrollers.

Aktuell kommen häufig Cortex-M-Prozessor von Arm zum Einsatz. Unabhängig vom Software-Entwicklungsmodell, ob internes Team oder Subunternehmer, wird die Komplexität des Embedded-Codes enorm steigen, wenn mehrere Anwendungen bedient werden sollen. Da der Cortex-M nur über eine Speicherschutzeinheit (Memory Protection Unit, MPU) verfügt, ist die Wahrscheinlichkeit hoch, dass die Software des Geräts eine einfache Architektur („Flat Model“) verwendet, bei dem alle Anwendungen die gleichen Rechte und Ressourcen haben (Bild 2).

Attacken breiten sich über das schwächste Glied aus

Für Anwender sind solche flachen Architekturen ein Risiko. Da sich die Anwendungen die Ressourcen unkontrolliert teilen und die gleichen Ausführungsrechte besitzen, kann jede Schwachstelle, jeder Fehler in einem Programm alle anderen Anwendungen beeinträchtigen. Damit ist die Funktion des gesamten Geräts gefährdet. Bevorzugter Angriffskanal ist die externe Kommunikationsschnittstelle. Per Definition ist sie von außen zugänglich, idealerweise über ein Netzwerk.

Der Software-Stack, der die Kommunikation handhabt, ist immer funktional validiert, aber nur selten sicherheitstechnisch verifiziert. Ein Angriffspfad, der auf eine Schwachstelle in einem Kommunikations-Stack abzielt, nutzt in der Regel einen Speicherüberlauf oder eine fehlende Überprüfung der Eingangsdaten: Ein Angreifer kann über die ungenau geprüften Kommunikations-Buffer bösartigen Code in den internen RAM des Mikrocontrollers einschleusen.

Sobald sich dieser Code innerhalb der Plattform befindet und ausgeführt wird, kann der Angreifer die volle Kontrolle über die auf dem Gerät laufende Software übernehmen (Bild 3). Das eröffnet dem Angreifer vielfältige Möglichkeiten: Diebstahl biometrischer Informationen, Durchführung von Relay-Angriffen und jedes andere Szenario, das auf den Embedded-Anwendungen basiert.

Bildergalerie

Isolation der Applikationen sorgt für mehr Sicherheit

Um dieser Bedrohung zu begegnen, werden in der Regel Softwarelösungen eingesetzt, die Hardware-Sicherheitsmechanismen wie eine Speicherverwaltungseinheit (Memory Management Unit, MMU) oder Arm TrustZone nutzen. Dabei handelt es sich um „Isolationssoftware“, auch Hypervisoren oder virtuelle Maschinen genannt. Sie verwenden Hardware-Mechanismen zum Definieren separater Software-Container, in denen jeweils eine Anwendung läuft. Die Hauptaufgabe eines Hypervisors ist es, diesen Containern Ressourcen zuzuweisen, deren Nutzung zu überwachen und die Kommunikation zwischen den Boxen zu steuern. Viele Anwender denken, dass ein solcher Ansatz bei Arm Cortex-M-basierten Mikrocontrollern nicht möglich ist, da sie keine MMU, sondern nur eine MPU verwenden.

Doch auch ohne MMU ist ein hohes Maß an Sicherheit möglich – etwa mithilfe des DeepCover Security Framework (DSF). Diese Software-Isolationslösung von Maxim garantiert eine weitreichende Isolation zwischen den auf Cortex-M-basierten Mikrocontrollern laufenden Software-Containern. Kernstück dieser Lösung ist ein Hypervisor, der Container, erlaubte Ressourcen und Interaktionen sehr strikt per Software definiert. Anwendungen können über Gateways miteinander interagieren.

Der Hypervisor überwacht die Konfiguration jedes Containers. Er stellt auch sicher, dass die Ausführung mit der jeweiligen Container-Konfiguration übereinstimmt. Unterschiede zur beabsichtigten Konfiguration erkennt er sofort, z.B. Zugriffsversuche außerhalb erlaubter Speicherbereiche, Versuche, mit einem anderen Container außerhalb eines erlaubten Gateways zu interagieren oder ein direkter Zugriff auf unzulässige Ressourcen. Während dieser Verwaltungsaufgaben behält der Hypervisor seine eigenen Rechte und Ressourcen bei.

Ein Sicherheitslabor hat das Framework als konform mit den sehr anspruchsvollen PCI-PTS-POI-Sicherheitsanforderungen für Software-Isolation eingestuft. Diese gelten als Grundlage für sichere Bezahlprozesse und sind daher auch für das IoT geeignet. Der Fingerabdrucksensor zeigt exemplarisch, dass das DSF ein einfaches, aber effizientes Architekturdesign ermöglicht (Bild 4). Das Framework weist einen speziellen Container exklusiv der Verwaltung der biometrischen Merkmale zu, einschließlich des Zugriffs auf den Fingerabdrucksensor und der Extraktion der Daten. Das Framework verhindert Zugriffe auf diesen Sensor aus anderen Containern heraus. Jeder Versuch, den Sensor unerlaubt zu lesen, wird erkannt. Dies löst eine Ausnahmebedingung aus, die zu einem betriebssicheren Fehlerfall (safe failure) führt.

Vollständige Kontrolle durch den Hypervisor

Das Framework kann fehlerhafte Software zwar nicht in fehlerfreie Applikationen verwandeln, aber Angriffsmöglichkeiten stark einschränken. Eine Schwachstelle in einer Anwendung kann zum Beispiel nicht länger die Firmware preisgeben. Fehler bleiben im jeweiligen Container isoliert – dies verringert den Wert für einen Angreifer drastisch. Das DSF bietet den Vorteil, dass mehrere Anwendungen von verschiedenen Anbietern mit unterschiedlichen Sicherheitsniveaus und unterschiedlicher Robustheit auf einem einzigen Gerät gehostet werden können.

Der Anbieter der anspruchsvollsten Applikation kann nun auch andere Anwendungen auf demselben Hardwaregerät akzeptieren, ohne das Risiko einzugehen, seine eigene Anwendung zu schwächen und seine Assets freizulegen. Das hohe Maß an Kontrolle in Containerarchitektur und Ressourcenpartitionierung ermöglicht einfache und vertrauenswürdige Updates der Anwendungen. Der Hypervisor kontrolliert Anwendungen vollständig. Er kann sie durch einfache Schritte modifizieren, aktualisieren oder entfernen, ohne die Funktion anderer Applikationen zu beeinträchtigen.

Darüber ermöglicht dies sichere Updates für zusätzliche Dienste, etwa eine Verschlüsselung, ohne dabei die Schlüssel einem anderen Container preiszugeben. Ein weiterer wichtiger Vorteil besteht darin, dass Container sich während der Ausführung nicht gegenseitig behindern. Zertifikate eines Containers können so nicht durch Änderungen eines anderen beeinträchtigt werden: Das Zertifikat bleibt gültig. Wir sind somit von einer einzigen monolithischen Software, bei der jede Änderung einen Einfluss auf ihre Stabilität insgesamt hat und der Zertifizierung einiger Teile davon zu einer Reihe von unabhängigen, isolierten Images übergegangen, die ihre eigenen Eigenschaften und Fehler isoliert behalten.

Dieser Artikel stammt von unserem Partnerportal ElektronikPraxis. Verantwortlicher Redakteur: Michael Eckstein.

* Yann Loisel ist Director Software in der Micros, Security and Software Business Unit von Maxim Integrated.

* Stéphane Di Vito ist Senior Principal Member of Technical Staff, Software, in der Micros, Security and Software Business Unit von Maxim Integrated.

* Emmanuel Puerto ist Principal Member of Technical Staff, Applications, in der Micros, Security and Software Business Unit von Maxim Integrated.

(ID:45468925)