Ich habe viel darüber gehört, wie Microsoft UEFI Secure Boot in Windows 8 implementiert. Anscheinend verhindert es, dass „nicht autorisierte“ Bootloader auf dem Computer ausgeführt werden, um Malware vorzubeugen. Es gibt eine Kampagne der Free Software Foundation gegen Secure Boot, und viele Leute haben online gesagt, dass es sich dabei um einen „Machtgriff“ von Microsoft handelt, um „freie Betriebssysteme zu eliminieren“.
Wenn ich einen Computer bekomme, auf dem Windows 8 und Secure Boot vorinstalliert sind, kann ich dann später trotzdem Linux (oder ein anderes Betriebssystem) installieren? Oder funktioniert ein Computer mit Secure Boot immer nur mit Windows?
Antwort1
Zunächst die einfache Antwort auf Ihre Frage:
Wenn Sie ein ARM-Tablet habenmit Windows RT (wie das Surface RT oder das Asus Vivo RT), dannSie können Secure Boot nicht deaktivieren oder andere Betriebssysteme installieren. Wie viele andere ARM-Tablets werden diese GerätenurFühren Sie das mitgelieferte Betriebssystem aus.
Wenn Sie einen Nicht-ARM-Computer habenmit Windows 8 (wie das Surface Pro oder eines der unzähligen Ultrabooks, Desktops und Tablets mit einem x86-64-Prozessor), dannSie können Secure Boot vollständig deaktivieren, oder Sie können Ihre eigenen Schlüssel installieren und Ihren eigenen Bootloader signieren. So oder so,Sie können ein Betriebssystem eines Drittanbieters wie eine Linux-Distribution installierenoder FreeBSD oder DOS oder was auch immer Ihnen gefällt.
Nun zu den Einzelheiten, wie diese ganze Secure Boot-Sache eigentlich funktioniert: Es gibt viele Fehlinformationen über Secure Boot, insbesondere von der Free Software Foundation und ähnlichen Gruppen. Dies hat es schwierig gemacht, Informationen darüber zu finden, was Secure Boot eigentlich macht, also werde ich mein Bestes geben, es zu erklären. Beachten Sie, dass ich keine persönliche Erfahrung mit der Entwicklung von Secure Boot-Systemen oder ähnlichem habe; dies ist nur das, was ich durch Online-Lektüre gelernt habe.
Erstens,Secure Boot istnichtetwas, das Microsoft sich ausgedacht hat.Sie sind die ersten, die es in großem Umfang umsetzen, aber sie haben es nicht erfunden. Es istTeil der UEFI-Spezifikation, was im Grunde ein neuerer Ersatz für das alte BIOS ist, an das Sie wahrscheinlich gewöhnt sind. UEFI ist im Grunde die Software, die zwischen dem Betriebssystem und der Hardware kommuniziert. UEFI-Standards werden von einer Gruppe namens „UEFI Forum", das sich aus Vertretern der Computerindustrie zusammensetzt, darunter Microsoft, Apple, Intel, AMD und einer Handvoll Computerhersteller.
Zweitwichtigster Punkt,Die Aktivierung von Secure Boot auf einem Computernichtbedeutet, dass der Computer nie ein anderes Betriebssystem starten kann. Tatsächlich besagen Microsofts eigene Windows-Hardwarezertifizierungsanforderungen, dass Sie bei Nicht-ARM-Systemen sowohl Secure Boot deaktivieren als auch die Schlüssel ändern können müssen (um andere Betriebssysteme zuzulassen). Dazu aber später mehr.
Was macht Secure Boot?
Im Wesentlichen verhindert es, dass Malware Ihren Computer während der Startreihenfolge angreift. Malware, die über den Bootloader eindringt, kann sehr schwer zu erkennen und zu stoppen sein, da sie in Low-Level-Funktionen des Betriebssystems eindringen kann und so für Antivirensoftware unsichtbar bleibt. Secure Boot überprüft lediglich, ob der Bootloader von einer vertrauenswürdigen Quelle stammt und nicht manipuliert wurde. Stellen Sie es sich wie die aufklappbaren Verschlüsse von Flaschen vor, auf denen steht: „Nicht öffnen, wenn der Deckel aufgeklappt ist oder das Siegel manipuliert wurde.“
Auf der obersten Schutzebene befindet sich der Plattformschlüssel (PK). Auf jedem System gibt es nur einen PK, der vom OEM während der Herstellung installiert wird. Dieser Schlüssel dient zum Schutz der KEK-Datenbank. Die KEK-Datenbank enthält Schlüsselaustauschschlüssel, die zum Ändern der anderen sicheren Startdatenbanken verwendet werden. Es kann mehrere KEKs geben. Dann gibt es noch eine dritte Ebene: die autorisierte Datenbank (db) und die verbotene Datenbank (dbx). Diese enthalten Informationen über Zertifizierungsstellen, zusätzliche kryptografische Schlüssel und UEFI-Geräteabbilder, die jeweils zugelassen oder blockiert werden sollen. Damit ein Bootloader ausgeführt werden darf, muss er kryptografisch mit einem Schlüssel signiert sein, derIstin der Datenbank undist nichtin der dbx.
Bild vonErstellen von Windows 8: Schützen der Pre-OS-Umgebung mit UEFI
Wie dies auf einem realen Windows 8-zertifizierten System funktioniert
Der OEM generiert seinen eigenen PK und Microsoft stellt einen KEK bereit, den der OEM vorab in die KEK-Datenbank laden muss. Microsoft signiert dann den Windows 8-Bootloader und verwendet seinen KEK, um diese Signatur in die autorisierte Datenbank einzutragen. Wenn UEFI den Computer bootet, überprüft es den PK, überprüft den KEK von Microsoft und überprüft dann den Bootloader. Wenn alles gut aussieht, kann das Betriebssystem booten.
Bild vonErstellen von Windows 8: Schützen der Pre-OS-Umgebung mit UEFI
Wo kommen Betriebssysteme von Drittanbietern wie Linux ins Spiel?
Erstens könnte jede Linux-Distribution einen KEK generieren und OEMs bitten, ihn standardmäßig in die KEK-Datenbank aufzunehmen. Sie hätten dann genauso viel Kontrolle über den Startvorgang wie Microsoft. Die damit verbundenen Probleme, wieerklärt von Matthew Garrett von Fedora, sind, dass a) es schwierig wäre, alle PC-Hersteller dazu zu bringen, den Schlüssel von Fedora zu integrieren, und dass b) es anderen Linux-Distributionen gegenüber unfair wäre, da deren Schlüssel nicht enthalten wäre und kleinere Distributionen nicht so viele OEM-Partnerschaften haben.
Fedora hat sich entschieden (und andere Distributionen ziehen nach), Microsofts Signaturdienste zu verwenden. Dieses Szenario erfordert die Zahlung von 99 US-Dollar an Verisign (die von Microsoft verwendete Zertifizierungsstelle) und gibt Entwicklern die Möglichkeit, ihren Bootloader mit Microsofts KEK zu signieren. Da Microsofts KEK bereits auf den meisten Computern vorhanden ist, können sie ihren Bootloader so signieren, dass er Secure Boot verwendet, ohne dass ein eigener KEK erforderlich ist. Dies ist letztendlich mit mehr Computern kompatibel und insgesamt kostengünstiger, als sich mit der Einrichtung eines eigenen Schlüsselsignatur- und -verteilungssystems zu befassen. Weitere Einzelheiten dazu, wie dies funktioniert (unter Verwendung von GRUB, signierten Kernelmodulen und anderen technischen Informationen), finden Sie im oben genannten Blog-Beitrag, den ich Ihnen empfehle, zu lesen, wenn Sie sich für solche Dinge interessieren.
Angenommen, Sie möchten sich nicht mit der lästigen Anmeldung bei Microsofts System herumschlagen, keine 99 $ bezahlen oder einfach einen Groll gegen große Unternehmen hegen, deren Namen mit einem M beginnen. In diesem Fall besteht die Möglichkeit, Secure Boot trotzdem zu verwenden und ein anderes Betriebssystem als Windows auszuführen.Microsofts Hardware-Zertifizierung erfordertdass OEMs es Benutzern ermöglichen, ihr System in den „benutzerdefinierten“ UEFI-Modus zu versetzen, in dem sie die Secure Boot-Datenbanken und den PK manuell ändern können. Das System kann in den UEFI-Setup-Modus versetzt werden, in dem der Benutzer sogar seinen eigenen PK angeben und Bootloader selbst signieren kann.
Darüber hinaus machen Microsofts eigene Zertifizierungsanforderungen es für OEMs zwingend erforderlich, eine Methode zum Deaktivieren des sicheren Bootens auf Nicht-ARM-Systemen zu integrieren.Sie können Secure Boot deaktivieren!Die einzigen Systeme, bei denen Sie Secure Boot nicht deaktivieren können, sind ARM-Systeme mit Windows RT, die ähnlicher wie das iPad funktionieren, auf dem Sie keine benutzerdefinierten Betriebssysteme laden können. Obwohl ich mir wünschen würde, dass es möglich wäre, das Betriebssystem auf ARM-Geräten zu ändern, kann man mit Fug und Recht sagen, dass Microsoft hier dem Industriestandard für Tablets folgt.
Also ist Secure Boot nicht grundsätzlich schlecht?
Wie Sie hoffentlich sehen, ist Secure Boot nicht böse und nicht nur auf die Verwendung mit Windows beschränkt. Der Grund, warum die FSF und andere so verärgert darüber sind, ist, dass es zusätzliche Schritte zur Verwendung eines Betriebssystems eines Drittanbieters mit sich bringt. Linux-Distributionen zahlen vielleicht nicht gern für die Verwendung des Microsoft-Schlüssels, aber es ist die einfachste und kostengünstigste Möglichkeit, Secure Boot für Linux zum Laufen zu bringen. Glücklicherweise ist es einfach, Secure Boot auszuschalten und verschiedene Schlüssel hinzuzufügen, wodurch der Umgang mit Microsoft vermieden wird.
Angesichts der Menge an immer ausgefeilterer Malware scheint Secure Boot eine vernünftige Idee zu sein. Es handelt sich dabei nicht um einen bösen Plan zur Übernahme der Welt und es ist weit weniger beängstigend, als einige Experten für kostenlose Software glauben machen wollen.
Weiterführende Literatur:
- Microsoft-Hardware-Zertifizierungsanforderungen
- Erstellen von Windows 8: Schützen der Pre-OS-Umgebung mit UEFI
- Microsoft-Präsentation zur Secure Boot-Bereitstellung und Schlüsselverwaltung
- Implementierung von UEFI Secure Boot in Fedora
- TechNet Secure Boot-Übersicht
- Wikipedia-Artikel zu UEFI
Kurz zusammengefasst:Secure Boot verhindert, dass Malware Ihr System während des Bootvorgangs auf niedriger, nicht erkennbarer Ebene infiziert. Jeder kann die notwendigen Schlüssel erstellen, damit es funktioniert, aber es ist schwer, Computerhersteller davon zu überzeugen, diese zu verteilen.deinDer Schlüssel steht jedem zur Verfügung, Sie können also alternativ Verisign bezahlen, um den Schlüssel von Microsoft zum Signieren Ihrer Bootloader zu verwenden und sie funktionsfähig zu machen.Sie können Secure Boot auch deaktivieren aufbeliebigNicht-ARM-Computer.
Letzter Gedanke zur FSF-Kampagne gegen Secure Boot: Einige ihrer Bedenken (d. h. es macht esSchwererzur Installation freier Betriebssysteme) sind gültigbis zu einem Punkt. Die Aussage, dass die Einschränkungen „jemanden daran hindern werden, etwas anderes als Windows zu booten“, ist aus den oben genannten Gründen nachweislich falsch. Eine Kampagne gegen UEFI/Secure Boot als Technologie ist kurzsichtig, fehlgeleitet und ohnehin nicht effektiv. Es ist wichtiger sicherzustellen, dass die Hersteller tatsächlich die Anforderungen von Microsoft befolgen und den Benutzern ermöglichen, Secure Boot zu deaktivieren oder die Schlüssel zu ändern, wenn sie dies wünschen.