Software::Security
Garrett stellt Fakten über EFI Secure Boot klar
Kernel-Entwickler Matthew Garrett hat in seinem Blog das Thema EFI Secure Boot erneut aufgegriffen. Dieses Mal stellt er häufig zu hörende Behauptungen zusammen, die falsch oder irreführend sind.
Microsoft fordert von Herstellern, die die Hardware-Zertifizierung für Windows 8 erhalten wollen, die Unterstützung des EFI-BIOS und Secure Boot. Daraus ergeben sich potentielle Probleme, die Garrett in mehreren Blog-Einträgen bereits beleuchtete; auch die Linux Foundation veröffentlichte eine Übersicht in einem Whitepaper, bei dem Garrett Koautor war.
Laut Garrett ist die Spezifikation von Secure Boot eigentlich nicht besonders kompliziert. Aber einige ihrer Konsequenzen seien nicht offensichtlich und offenbarten sich erst nach einigem Nachdenken.
Als erstes stellt Garrett klar, dass Secure Boot tatsächlich zusätzliche Sicherheit bewirken kann, auch wenn manchmal anderes behauptet wird. Denn es macht Modifikationen des Master Boot Records unmöglich. Secure Boot muss außerdem klar von Trusted Boot unterschieden werden. Letzteres benötigt eine TPM-Hardware und kann sicherstellen, dass alles, was vor dem Start eines Betriebssystems lief, vertrauenswürdig war. Ein System, das über Secure Boot gestartet wurde, muss sich dagegen blind darauf verlassen, dass die Firmware vertrauenswürdig ist.
Secure Boot kann weder zur Implementierung von DRM genutzt werden noch die physische Sicherheit von Rechnern garantieren. Für diese Anforderungen ist es nicht gedacht. Für dem Zweck, für den es gedacht ist, ist es jedoch erforderlich, dass jede Komponente, die direkt auf die Hardware zugreifen kann, signiert ist. Hier liegt ein großes Problem, denn jede Komponente kann nur eine Signatur haben. Hätte nun jeder Hersteller einen eigenen Schlüssel, mit dem er seine Treiber signiert, müsste das BIOS sie alle kennen, was nicht skalierbar ist. Daher werden nahezu alle Treiber mit einer Signatur kommen, die auf einen der im BIOS hinterlegten Schlüssel zurückzuführen ist - fast immer wird dies der von Microsoft sein.
Microsoft könnte sein bestehendes Monopol also nutzen, um ein weiteres Monopol zu schaffen, eine Gefahr, die nach Ansicht von Kommentatoren für eine Beschwerde bei der Kartellbehörde ausreichen sollte. Zumal Microsoft nicht einfach nur die Anforderungen der UEFI-Spezifikation übernimmt, sondern von den Herstellern weitere Einschränkungen verlangt. Auf der ARM-Architektur, wo Microsoft keine Rücksicht auf ältere Windows-Versionen nehmen muss, fordert es sogar, dass es keine Umgehungsmöglichkeit für Secure Boot geben darf.
Falsch ist laut Garrett auch die Annahme, dass Secure Boot von der NIST vorgeschrieben ist. Vielmehr sind die NIST-Richtlinien für die Sicherheit von Firmware effektiv ein notwendiger Bestandteil von Secure Boot. Abschließend ist es für Garrett keineswegs klar, dass Linux-Anbieter mit Secure Boot problemlos fahren können. Einer der Vorteile für Linux-Anwender lag bisher darin, ihr System genau an ihre Anforderungen anpassen zu können, und vor allem, solche Anpassungen auch selbst machen zu können, ohne auf externe Hilfe zurückzugreifen. Secure Boot könnte dies erheblich schwieriger machen.
