Safety und Security von Embedded Systemen Sicherheitstrends für vernetzte Geräte (2)

Funktionen wie M2M-Kommunikation, Multimedia, Internet-Anbindung und Finanztransaktionen sind ein attraktives Ziel für Netzwerk-Attacken durch Hacker. Neue Sicherheitseinrichtungen sind also erforderlich, deren Ansätze und Wirkungsweise im Bereich der Software wir im zweiten Teil dieses Beitrags vorstellen.

Thema dieses ausführlichen, zweiteiligen Beitrags (Teil 1 ist in der letzten Ausgabe Nr. 10/2012 der DESIGN&ELEKTRONIK erschienen) sind die Beschreibung wichtiger Sicherheitsanforderungen sowie praktische Anleitungen zu deren Umsetzung. Während der erste Teil unter anderem die Herausforderungen nannte und zuverlässige Hardware-Lösungen abdeckte, behandelt dieser zweite Teil wichtige Aspekte sicherer Software, die Virtualisierung, den Schutz gespeicherter Daten und eine sichere Netzwerkverbindung.

Vertrauen in die Software

Natürlich ist der im ersten Teil beschriebene Hardware-Vertrauensanker nutzlos, wenn fehlerhafte Software überprüft und gestartet wird. Wir wollen hier nicht näher auf die sichere Softwareentwicklung eingehen (die Literatur »Embedded Systems Security« bietet mehr Informationen dazu), aber wir können erörtern, was am Anfang entscheidend ist: Elektronikentwickler brauchen einen Software-Vertrauensanker - ein zuverlässiges Betriebssystem -, auf dem sich vertrauenswürdige Anwendungen entwickeln und betreiben lassen.

Monolithische Betriebssysteme können Systemsoftware wie Netzwerk-Stacks, Dateisysteme oder Gerätetreiber enthalten, die sich den gleichen Speicherbereich teilen und im privilegierten Modus ablaufen. Dies führt zu einer sehr breiten TCB (Trusted Computer Base) und bietet zahlreiche Angriffsmöglichkeiten für Hacker. Beispiele monolithischer Betriebssysteme sind Windows, Linux und VxWorks.

Im Unterschied dazu betreibt ein Microkernel-Betriebssystem nur eine minimale Anzahl kritischer Dienste im Supervisor-Modus (z.B. Thread-Management, Exception-Handling oder die prozessinterne Kommunikation) und hostet andere Systemkomponenten im User-Modus. Dort können sie nur auf Ressourcen zugreifen, die der Entwickler zuvor als zulässig eingestuft hat. Ein Fehler in einer Komponente kann also andere Komponenten, die unabhängige Ressourcen verwalten, nicht gefährden. Da der Microkernel einfach aufgebaut ist, lässt sich seine Sicherheit einfach verifizieren und sicherstellen.

Bild 1 zeigt den Unterschied zwischen Microkernel- und monolithischem Ansatz. Die meisten universellen Betriebssysteme sind monolithisch, da sie vor mehr als 20 Jahren entstanden - die damals begrenzte Mikroprozessorleistung erforderte diesen Ansatz. Benutzeranwendungen können hier auf die meisten Dienste über einen effizienten Kernel-Systemaufruf zugreifen.

Ein Microkernel hingegen implementiert diese Dienste mit kommunizierenden Prozessen.

So kann eine Anwendung, die über ein Network-File-System (NFS) auf eine Datei zugreifen möchte, eine Kommunikation zwischen der Anwendung, einem TCP/IP-Prozess, einem Gerätetreiber und einem NFS-Prozess erfordern.

Diese Vorgänge geschehen im Hintergrund: Eine Anwendung ruft die gängigen read()- oder write()-Schnittstellen auf, und der Microkernel routet die Daten zwischen den Systemprozessen.

Virtualisierung bringt Sicherheit

Bei den heutigen Mikroprozessor-Geschwindigkeiten ist der Rechen- beziehungsweise Messaging-Overhead des Microkernels nicht mehr relevant. Alle neueren Betriebssysteme sind mit Microkernels ausgestattet und bilden die Basis praktisch jedes elektronischen Geräts, vom Smartphone über Avionik bis hin zu Netzwerktechnik und Prozessleitsystemen.

Beispiele für Betriebssysteme auf Microkernel-Basis sind »Integrity«, »LynxSecure«, »Neutrino« und »PikeOS«. Es ist unwahrscheinlich, dass Linux monolithisch wäre, wenn es heute entwickelt würde. Linus Torvalds sagt selbst, Linux sei monolithisch und nennt Mikrokernels »netter«. Aus theoretischer (und ästhetischer) Sicht verliere Linux hier.

Trotzdem verzeichnet Linux eine immer weiter wachsende Anwendungs- und Programmiererbasis, die Entwickler nutzen wollen. Die Entscheidung, einen Microkernel oder ein monolithisches Betriebssystem einzusetzen, muss sich nicht gegenseitig ausschließen; Virtualisierung bietet die Möglichkeit, beides zu betreiben. Die Gründe für eine System-Virtualisierung in Datenzentren sind hinlänglich bekannt: optimierte Ressourcen und verbesserte Systemverfügbarkeit.

In der Elektronikwelt bietet die Virtualisierungstechnik aber ein wesentlich breiteres Anwendungsfeld und ist entscheidend für die Sicherheit. Bereits im Jahr 2005 stellte Intel seine »Virtualization Technology« (Intel VT) vor, mit der sich die Virtualisierung vereinfachen und beschleunigen lässt. Vor kurzem wurde Intel VT für die »Embedded Intel Atom«-Prozessoren verfügbar.

Ähnliche Hardware-Assistenten, die eine effiziente Virtualisierung in einer Vielzahl von Elektronikgeräten ermöglichen, wurden auch für andere CPU-Architekturen entwickelt, da-runter für ARM (ARM Virtualization Extensions).

Bild 2 zeigt eine Hypervisor-Architektur, in der die Computer-Virtualisierung als Dienst auf einem vertrauenswürdigen Microkernel enthalten ist.

Microkernel-Hypervisoren sind zum Beispiel der »Integrity Multivisor« von Green Hills Software und einige Varianten des L4-Microkernel. Sie bieten Microkernel-Robustheit und ermöglichen die Wiederverwendung universeller Betriebssysteme wie Linux.

Elektronikentwickler können damit die Systemsicherheit erheblich verbessern, indem eine kleine Anzahl kritischer Sicherheitsfunktionen außerhalb der ursprünglichen Umgebung angesiedelt und direkt auf der Microkernel-TCB gehostet wird.

Sichere Netzwerkanbindung

Im Jahr 2010 wurde eine weit verbreitete Remote-Management-Schwachstelle beim Betriebssystem VxWorks entdeckt: Über einen offenen Systemdiagnose-Port konnten Hacker Schadsoftware installieren und sogar das Betriebssystem rooten oder ersetzen. Eine grundlegende Strategie dagegen ist die Überwachung des Management-Ports durch gegenseitige Authentifizierung über ein Netzwerk-Sicherheitsprotokoll wie »SSL«. Allerdings ist eine SSL-Verbindung nur die Spitze eines Eisbergs von Maßnahmen, um wirklich gesicherte Verbindungen zu gewährleisten.

Aber wie können sie sich gegen Schwachstellen in Betriebssystemen von Drittanbietern schützen, von denen viele in Binärform und ohne Sicherheitszertifikat ausgeliefert werden?

Die Systemvirtualisierung ermöglicht hier eine gesicherte Netzanbindung für elektronische Systeme:

Das ursprüngliche Betriebssystem wird in eine virtuelle Maschine eingebracht und ist somit sicher von kritischen Funktionen isoliert, zum Beispiel von der Verbindungsauthentifizierung und dem Konfigurationsmanagement, das ein vertrauenswürdiger Hypervisor bereitstellt.

Dabei lässt sich Device-Management-Software auch zur Überwachung, Konfiguration und zum Updaten des ursprünglichen Betriebssystems einsetzen (Bild 3).

Schutz von Datenspeichern

Im Jahr 2010 zeigte eine Sendung des US-Fernsehsenders CBS, dass ausrangierte Büro-Kopiergeräte eine ergiebige Quelle für private Informationen sind, die sich einfach von den internen Festplatten der Kopierer auslesen lassen. Während diese Systeme keinerlei Schutz der gespeicherten Daten aufwiesen, verfügen viele moderne elektronische Systeme vor dem Hintergrund von IP-Schutz (Intellectual Property), DRM (Digital Rights Management) etc. über verschlüsselte Speicher.

Mit »Full Disk Encryption« (FDE) wird das gesamte Speichermedium verschlüsselt. Dies stellt sicher, dass versteckte Dateien wie Auslagerungsdateien des Betriebssystems nicht sichtbar sind. Erfolgt FDE innerhalb der Speicherperipherie, wird das Medium als »Self-Encrypting Drive« (SED) bezeichnet. Leider können viele elektronische Systeme aufgrund ihres Formfaktors keine eigenständigen SED-Produkte aufnehmen. Doch die Verschlüsselung kann auch auf der nächsthöheren Ebene, dem »Device Management Layer«, stattfinden, der in der Regel ein blockorientierter Treiber ist.

Der Schutz auf dieser Ebene kann dann immer noch das gesamte Gerät umfassen (FDE). Dabei darf der »Storage Encryption Key« niemals im Klartext auf dem Medium gespeichert sein. Dennoch ist es oft erforderlich, eine verschlüsselte Kopie dieses Schlüssels zu speichern. Der Schlüssel wird zur aktiven Nutzung freigegeben, während das System in einem autorisierten Betriebsmodus läuft.

Bei interaktiven Systemen wie Smartphones oder von einem Mitarbeiter bedienten Point-of-Sale-Einrichtungen wird die Freigabe durch die erfolgreiche Authentifizierung des Anwenders ausgelöst. In unbeaufsichtigten Systemen kann der symmetrische Schlüssel dagegen über eine sichere Netzwerkverbindung zu einem entfernten Server abgerufen werden, der eine Datenbank der bereitgestellten Datenschlüssel beinhaltet. Hier initiiert das elektronische System das Laden des Schlüssels - und zwar immer dann, wenn ein Datenschlüssel entriegelt werden muss (z.B. beim Booten).

Virtuelle Selbstverschlüsselung

Ohne passende Rückversicherung, zu der Tests auf Binärebene, die sichere Auslieferung und andere Kontrollen zählen, können Hacker mit verschiedenen Techniken weiterhin Zugriff erlangen. Entwickler können einen Hochsicherheits-Entwicklungsprozess für ihre eigene Software anwenden. Datenschutz ist eine weitere Anwendung für die Systemvirtualisierung in vernetzten Einrichtungen.

Ein Hypervisor startet das Hauptbetriebssystem in einer virtuellen Maschine und führt die Speicherverschlüsselungskomponenten außerhalb der virtuellen Maschine durch. Dadurch entsteht ein virtuelles Self-Encrypting-Drive (vSED). Alle sicherheitskritischen Aspekte des Schutzes ruhender Daten - die Authentifizierung zum Entsperren des SED, das Ver-/Entschlüsselungsprotokoll und das Schlüsselmanagement - laufen außerhalb der primären Betriebssystemumgebung ab und schützen die gespeicherten Daten vor externen Angriffen.

Bild 4 zeigt eine beispielhafte vSED-Architektur. Der Hypervisor virtualisiert den physikalischen Speicher. Wenn das Betriebssystem einen Datenblock schreibt, verschlüsselt eine vertrauenswürdige Anwendung den Block und speichert ihn in einem passenden Block der physikalischen Einrichtung. Da die Verschlüsselung in einer sicher partitionierten Anwendung abläuft, kann keine andere, nicht vertrauenswürdige Software auf der Plattform auf den Schlüssel zugreifen oder verschlüsselungstechnische Attacken durchführen.

Um die Effizienz zu erhöhen, sollten wann immer möglich integrierte Verschlüsselungs-beschleuniger zum Einsatz kommen. Alternativ zu einem eigenständigen Verschlüsselungs-Coprozessor lässt sich die Verschlüsselung auf einen Core eines Multicore-Prozessors auslagern, dessen Kerne nur selten vollständig ausgelastet sind.

Erfolgt das Entsperren des Speichers mittels Passwort, müssen sich Entwickler auch über Schadsoftware-Attacken wie »Key-Logging« und »Screen-Scraping« in der primären Betriebssystemumgebung bewusst sein. In der vSED-Umgebung läuft die Passwort-Eingabe und das dazugehörige Bildschirmmanagement (wenn vorhanden) in nativen Anwendungen ab, die gegen solche Angriffe zu schützen sind.

Über den Autor:

David Kleidermacher ist Chief Technical Officer (CTO) bei Green Hills Software.