Matthew Garret: Mythen über UEFI / Secure Boot – und es bleibt ein Problem für Linux

Das Thema UEFI / Secure Boot scheint Red Hats Matthew Garret richtige Kopfschmerzen zu bereiten. Wieder einmal hat er sich in einem Blog-Eintrag dazu geäußert und möchte die Mythen um das sichere Starten des Computers erklären. Das Problem sei zum größten Teil, dass die Spezifikationen dafür zwar öffentlich sind, das Endresultat aber auch nach langem Nachdenken nicht vorhersehbar ist. Deswegen möchte er ein paar Dinge ins rechte Licht rücken. Ich versuch mal, das so gut wie möglich auf Deutsch wiederzugeben:

Durch Secure Boot gibt es keine zusätzliche Sicherheit

Unwahr: Angriffe gegen die Umgebung vor dem Start sind real und nicht ungewöhnlich. Sobald etwas im MBR (Master Boot Record) landet, ist es um das System geschehen. Schadcode kann dann den Bootloader oder den Kernel modifizieren. Der einzige Weg das zu identifizieren ist, die Festplatte in ein anderes System zu hängen und dort zu überprüfen. Ein Kaltstart von einem sicheren Medium ist auch denkbar. Secure Boot unterbindet ein solches Szenario durch digitale Unterschriften und stelle desewegen zusätzliche Sicherheit zur Verfügung.

Secure Boot ist nur ein anderer Namen für Trusted Boot

Unwahr: Trusted Boot muss die Möglichkeit haben, den gesamten Boot-Prozess zu überwachen. Somit hat das Betriebssystem die Möglichkeit herauszufinden, was vor dem Betriebssystemstart vor sich ging. Die Wurzel des Vertrauens ist hier die Hardware und ein TPM ist Voraussetzung. Secure Boot hingegen limitiert die Applikationen, die vor dem Start des Betriebssystems laufen können. Sobald das OS läuft, gibt es keine Möglichkeit mehr herauszufinden, was vor dem Start abgelaufen ist oder ob ds System tatsächlich sicher gestartet wurde.

Microsoft verlangt von den Hardware-Herstellern nur, die Spezifikation zu implementieren

Unwahr: In den Windows 8 Hardware Certification Requirements unter Sektion 27.7.3.3 der Version 2.3.1A der UEFI-Spezifikationen ist niedergeschrieben, dass ein Anwender Secure Boot nicht überstimmen/überschreiben/temporär umgehen kann. Möchte ein Anwender ein unsigniertes Abbild starten, muss er Secure Boot auf dem Zielsystem komplett deaktivieren.

MANDATORY: No in-line mechanism is provided whereby a user can bypass Secure Boot failures and boot anyway Signature verification override during boot when Secure Boot is enabled is not allowed. A physically present user override is not permitted for UEFI images that fail signature verification during boot. If a user wants to boot an image that does not pass signature verification, they must explicitly disable Secure Boot on the target system.

Secure Boot lässt sich benutzen, um DRM zu implementieren

Unwahr: Secure Boot lässt sich nicht dazu benutzen, bestimmte Applikationen nicht mehr laufen zu lassen – ein aktiver Schutz gegen raubkopierte Software ist es also nicht. Der einzige Kommunikations-Kanal zwischen UEFI und dem Betriebssystem ist die UEFI-Variable SecureBoot, die entweder 1 oder 0 ist.

So lange es Maschinen gibt, auf denen sich Secure Boot deaktivieren lässt, ist Secure Boot kein DRM.

Secure Boot bietet physikalischen Schutz

Unwahr: Secure Boot bietet keinen Schutz gegen Angreifer, die physikalischen Zugriff auf das System haben. Das Betriebssystem könne nicht überprüfen, ob die Firmware modifiziert wurde – zum Beispiel ein manuelles Deaktivieren von Secure Boot.

Secure Boot definiert lediglich die Interaktion zwischen der Firmware und dem Bootloader

Irreführend: Es ist wahr, dass Secure Boot nur die Authentifizierung des Pre-OS-Code spezifiziert. Secure Boot soll also sicherstellen, dass nur digital unterschriebener Code ausgeführt wird. Sollte unsignierter Code die Hardware berühren bevor das Betriebssystem startet, ist das System ausgehebelt. Man könnte zum Beispiel einen signierten Linux-Kernel starten, der dann einen unsignierten Treiber lädt. Dieser setzt wiederum eine gefälschte UEFI-Umgebung auf und lädt dann Windows. Das Microsoft-Betriebssystem würde nun denken, dass es sicher gestartet wurde.

Wenn dieser digital unterschriebene Linux-Kernel für jedermann verfügbar wäre, ist das ganze System in Frage gestellt. Die logische Antwort von Microsoft wäre, diesen Kernel auf eine schwarze Liste zu setzen. Secure Boot ist nunmal dafür gemacht, sämtliche Software zu verifizieren, die mit der Hardware interagiert. Ansonten würde es keine zusätzliche Sicherheit mit sich bringen.

Nur Rechner die Windows starten möchte brauchen die Microsoft-Schlüssel

Irreführend: Microsoft braucht nur einen einzigen Schlüssel und der Windows-Bootloader unterzeichnet damit auch alle anderen Komponenten. Der Bootloader ist nicht die einzige Komponente, die unterzeichnet werden muss. Jegliche Treiber, die auf ROMs oder Plugin-Karten sind, müssen ebenfalls signiert werden. Ein Ansatz wäre, dass alle Hardware-Hersteller ihre eigenen Schlüssel haben. In der Praxis aber kaum umsetzbar, da jeder Rechner dann alle Schlüssel von jedem PCI-Karten-Ersteller mit sich bringen müsste.

Wenn ein Rechner als Schlüssel von NVIDIA mit sich bringt, aber keine von AMD, könnte der Anwender nicht einfach eine eine GeForce durch eine Radeon ersetzen. Der Grafiktreiber lädt sich nämlich nicht mehr. Stattdessen stellt Microsoft einen Unterschriften-Dienst bereit. Hersteller können sich für eine WHQL-Mitgliedschaft bewerben und ihre UEFI-Treiber werden von Microsoft abgesegnet.

Das Problem ist ganz einfach, dass ein Treiber der von Microsoft angezeichnet ist, von niemandem anderen eine Unterschrift tragen kann. Wenn ein Hardware-Hersteller also PCI-Karten mit Microsoft-zertifizierten Treibern anbieten möchte, muss das System den Microsoft-Schlüssel beinhalten.

Das ist nur ein Problem für Clients und nicht Server

Nicht zwingend wahr: Für Server-Hardware trifft Microsofts Regel bezüglich ein Vorhandenseins von Secure Boot derzeit nicht ein. Sollte es aber implemtiert sein, muss es wie bei einem Client behandelt werden – aktiviert.

Secure Boot wird von NIST gebraucht

Total unwahr: Garret hat von einigen Leuten gehört, dass Secure Boot in direktem Zusammenhang mit NIST SP800-147 steht. Das Dokument befasst sich mit Firmware-Sicherheit, also was unternommen werden muss, damit sich Firmware selbst sicher ist. Dazu gehört auch, dass das Betriebssystem die Firmware nicht überschreiben kann und Firmware-Updates digital unterzeichnet sein müssen. Dass die Firmware nur signierte Software laufen lassen darf, dieser Paragraph ist in diesem Dokument weit und breit nicht zu finden. Secure Boot muss sich zwar darauf verlassen können, dass die Firmware sicher ist, hat aber nichts mit NIST SP800-147 zu tun.

In Linux kann man Secure Boot ganz einfach implementieren

Irreführend: Aus technischer Sicht, ja. Eine praktikable Lösung fehlt aber auf ganzer Linie. Garret hat sich zu diesem Thema bereits früher geäußert.

Das Problem betrifft nur den Hobby-Linuxer und nicht den wirklichen Markt

Unwahr: Derzeit ist es noch unklar, ob selbst die großen Linux-Distributoren Secure Boot so einbauen können, dass es die Bedürfnisse ihrer Kunden befriedigt. Eine native Implementierung kürzt ganz einfach viele der Vorzüge von Linux für Enterprise-Kunden. Als Beispiel nennt Garret die Möglichkeit bestimmter Anpassungen, um Systeme für bestimmte Arbeitsabläufe zu tunen. Was Linux so interessant macht ist eben die Möglichkeit, es nach Lust und Laune anpassen zu können. Secure Boot erschwert dies.

Fazit

Viele der Geschichten um Secure Boot sind einfach ungenau und irreführend über die Vor- und Nachteile. Man kann laut Garret nur eine vernüftige Diskussion um dieses Thema führen, wenn als Basis das technische Verständnis der Spezifikation vorhanden ist und nicht irgendwelche Aussagen von Analysten, die keine Ahnung vom Linux-Markt und / oder -Sicherheit haben, als Grundlage dienen.

Aber das ist ja alles halb so wild, weil schließlich hat Microsoft seinen Liebesbeweis zu Open-Source am Valentinstag zu Ausdruck gebracht, oder?