Hacker im Luftverkehr

Integrität der Firmware für Flugsicherheit sicherstellen

| Autor / Redakteur: David Kleidermacher * / Franz Graser

Sicheres Booten und Integritätsüberprüfung

Bild 1: Sichere Boot-Sequenz
Bild 1: Sichere Boot-Sequenz (Bild: Green Hills Software)

Sicheres Booten ist der einfachste und effektivste Weg, um Permanent Roots zu verhindern oder zumindest zu erkennen. Beim sicheren Booten soll gewährleistet werden, dass die gesamte Plattform einschließlich Hardware, Bootloader, Betriebssystem und kritische Anwendungen – also alles, was zu einem bekannten, vertrauenswürdigen Systemstatus beiträgt – überprüft und für authentisch befunden wird.

Verfügen die Hardware und der Bootloader über die Möglichkeit, die System-Firmware (Betriebssystem, Hypervisor, gesamte Trusted Computing Base – TCB) von einer anderen Einrichtung aus zu laden (etwa über USB) anstelle des beabsichtigten, vertrauenswürdigen Device (etwa Flash), kann ein Angreifer mit Zugriff auf das System ein böswilliges Betriebssystem booten. Dieses kann wie das vertrauenswürdige Betriebssystem agieren, allerdings mit böswilligem Verhalten. So können Netzwerkauthentifizierungsdienste deaktiviert oder Backdoor-Logins hinzugefügt werden.

Dies ist aber nur eine Möglichkeit, Systeme ohne sicheres Booten zu untergraben. Statt eines bösartigen Bootloaders oder Betriebssystems kann auch ein böswilliger Hypervisor gebootet werden. Dieser kann dann das vertrauenswürdige Betriebssystem innerhalb einer virtuellen Maschine starten. Der böswillige Hypervisor hat vollen Zugriff auf das RAM und kann so die vertrauenswürdige Umgebung im Verborgenen ausspionieren, Kryptografie-Schlüssel stehlen oder die Sicherheitsvorkehrungen des Systems verändern. In einem Beitrag von King u.a. wird ein Beispiel dieser Attacke beschrieben: mit SubVirt, einem Malware-Hypervisor. Ein weiterer berüchtigter Angriff, genannt BluePill, erweiterte den SubVirt-Ansatz: Ein permanentes Rootkit wird erstellt, das sich einfach während des Betriebs starten lässt und die Schwächen des ab Werk installierten Windows-Betriebssystems ausnutzt .

Die typische sichere Boot-Methode überprüft die Authentizität jeder Komponente innerhalb der Boot-Kette. Ist ein Glied in dieser Kette unterbrochen, wird der sichere Ausgangszustand beeinträchtigt. Der ROM-Loader in der ersten Stufe muss auch über einen hardwaregeschützten Kryptografie-Schlüssel verfügen, um die digitale Signatur des Bootloaders auf der nächsten Stufe zu überprüfen. Dieser Schlüssel kann in das ROM-Loader-Image selbst integriert werden – entweder über eine OTP-Sicherung (One-Time Programmable) oder er ist in einem lokalen TPM (Trusted Platform Module) gespeichert, das zusätzlichen Manipulationsschutz bietet.

Der Signaturschlüssel dient zur Authentizitätsüberprüfung der Komponenten in der zweiten Stufe der Boot-Kette. Der Entwickler hat die Möglichkeit, jedes authentische Image oder eine Reihe von bekannten (Known-Good) Images zu erlauben. Dabei müssen die Known-Good-Signaturen ebenfalls in der hardwaregeschützten Umgebung gespeichert werden. Die Überprüfung der Komponenten auf der zweiten Ebene deckt deren ausführbares Image als auch die Known-Good-Signatur und den Signatur-Verifikationsschlüssel der dritten Stufe ab (falls diese vorhanden ist). Die Überprüfungskette kann unendlich lang sein. Einige anspruchsvolle Computersysteme haben ausgesprochen lange Ketten oder sogar Bäume überprüfter Komponenten, die die TCB ausmachen. Bild 1 zeigt ein Beispiel einer sicheren Boot-Sequenz über drei Ebenen.

Der Vorteil beim sicheren Booten ist, dass die meisten universellen Mikroprozessoren einen integrierten Speicher für den Kryptografie-Schlüssel für diesen Root-of-Trust-Ansatz enthalten, ohne dafür weitere spezielle Hardware zu benötigen.

Sicheres Booten allein verhindert keine böswilligen Identitätswechsel. So kann ein Smart Meter durch ein gleich aussehendes, böswilliges Gerät ersetzt werden, das aber heimlich private Informationen über den Energieverbrauch an eine böswillige Webseite sendet. Anwender und Versorger müssen sich also sicher sein, dass ein im Einsatz befindliches Produkt als Known-Good-TCB arbeitet.

Werden Embedded-Systeme mit Verwaltungsnetzwerken verbunden, kann die Identitätsüberprüfung (Remote Attestation) eine wichtige Sicherheitsfunktion übernehmen. Ein einfacher, hardware-unabhängiger Ansatz kann für jedes Computersystem verwendet werden, wenn eine gegenseitig authentifizierte Verbindung (etwa über IKE/IPsec oder Transport Layer Security – TLS) eingesetzt wird. Solange der statische private Schlüssel und die sichere Verbindungsprotokoll-Software des Systems in die TCB integriert sind, die während des sicheren Bootens überprüft wird, hat die Beglaubigungsinstanz die Gewissheit, dass das System unter Known-Good-Firmware läuft. Eine Verbesserung dieses Ansatzes wäre, wenn der Client den kompletten Satz an digitalen Signaturen entsprechend der TCB-Kette an die Beglaubigungsinstanz sendet, die den Known-Good-Satz an Signaturen lokal speichert.

Inhalt des Artikels:

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 42251896 / Embedded Betriebssysteme)