Login
Login-Name Passwort


 
Newsletter
Werbung

Do, 19. Januar 2012, 09:03

Hardware

»Secure Boot« in UEFI-Firmware macht weiter Probleme

Der Kernel-Entwickler Matthew Garrett hat in einem neuen Artikel verschiedene Implikationen von »UEFI Secure Boot« beleuchtet, die für Linux zu Problemen werden könnten.

Technisch ist die Implementierung von »UEFI Secure Boot« kein Problem. Dies hatte Garrett in früheren Artikeln festgestellt, nachdem er sich eingehend mit der Spezifikation beschäftigt hatte. Seine Erkenntnisse führten zu einem gemeinsamen Whitepaper von Canonical und Red Hat, das die Fakten zu »Secure Boot« in UEFI-Firmware zusammenstellt und die Hersteller auffordert, eine einfache Möglichkeit zum Ein- und Ausschalten der Sicherheitsfunktion vorzusehen.

Ist »UEFI Secure Boot« eingeschaltet, so lädt das BIOS nur Komponenten, die eine gültige kryptografische Signatur tragen. Dazu müssen im BIOS Schlüssel hinterlegt sein. Mit entscheidend ist dabei, wer die Kontrolle über diese Schlüssel besitzt.

In seinem neuen Beitrag geht Garrett besonders auf die Aspekte der Lizenzierung und Schlüsselverteilung ein. Eine erste Konsequenz aus Secure Boot ist, dass sämtlicher Code, der die Hardware betrifft, vertrauenswürdig sein muss. Garrett zeigt einen Mechanismus auf, wie das System auszuhebeln ist. Beispielsweise könnte zunächst ein signierter Linux-Kernel gebootet werden, der von einem Angreifer manipuliert ist. Er würde eine simulierte UEFI-Umgebung starten und dann Windows booten. Obwohl Windows nichts Verdächtiges bemerken würde, könnte das System kompromittiert sein. Es wäre nur erforderlich, einen solchen manipulierten Kernel ins System einzuschleusen, über Windows-Trojaner oder Viren beispielsweise.

Somit sind signierte Kernel allein nicht ausreichend. Signierte Kernel dürften nur signierte Module laden. VirtualBox, proprietäre Nvidia-Treiber und andere Treiber außerhalb des Kernels wären nicht mehr nutzbar.

Garrett sieht auch Probleme mit der Lizenzierung, wenn Code unter der GPLv3 zum Einsatz kommt. Ein weiteres Problem ist die Schlüsselverteilung, die von der Spezifikation nicht weiter beschrieben wird. Microsoft verlangt von allen Herstellern, den Microsoft-Schlüssel einzubauen. Linux könnte einen eigenen Schlüssel erzeugen, hätte aber weniger Macht über die Hersteller, diesen einzubauen. Zudem könnte der private Teil des Schlüssels nicht an Linux-Distributoren weitergegeben werden. Alle Distributionen wären gezwungen, einen eigenen Schlüssel zu erzeugen. Doch das wäre wahrscheinlich teuer und das Ende der nichtkommerziellen Distributionen.

Der vorgesehene »Custom Mode«, der es ermöglicht, eigene Schlüssel zu installieren, ist zwar eine Lösung dafür, doch er würde den Benutzern die zusätzliche Last aufbürden, den Schlüssel einzutragen. Das ist ein Schritt, der laut Spezifikation nur durch manuellen Eintrag am Rechner vorgenommen werden darf. Die Oberfläche dafür würde bei jedem Gerät anders aussehen, was es schwierig machen würde, gute Anleitungen zu schreiben. Automatische Installationen wären viel aufwendiger, da zunächst der Schlüssel manuell einzutragen wäre.

Es ist durchaus möglich, dass Garrett die Lage etwas zu pessimistisch sieht, da auf normalen PC-Systemen »Secure Boot« wahrscheinlich nur eine Option sein wird, die im Idealfall standardmäßig ausgeschaltet ist. Auf spezialisierteren Systemen wie im Smartphone-Bereich ist die Situation jedoch eine andere. Hier hat Microsoft jüngst eine Anforderung herausgegeben, dass Windows-Geräte »Secure Boot« nicht abschaltbar machen dürfen. Für Linux-Anwender sind solche Geräte uninteressant, dennoch zeigt es laut dem Software Freedom Law Center den Zynismus von Microsoft.

Werbung
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung