Safe Boot: Ist es eine empfohlene Wahl oder nicht?

Secure Boot versprach seit 2012 einen „sauberen“ Bootvorgang. Der Ablauf des Microsoft-Zertifikats im September 2025 hat jedoch dazu geführt, dass mehr als ein Rechner vom Stromnetz getrennt wurde. Angesichts echter Sicherheitsgewinne und kommerzieller Hürden ist die Frage nicht länger technischer Natur: Sollen wir die Option aktiviert lassen oder sie bedenkenlos deaktivieren?

Secure Boot: Unverzichtbar oder Freiheitsbehinderung?

Das Konzept ist einfach: Das Motherboard prüft die Signatur jedes beim Booten geladenen Bricks. Ist der Schlüssel gültig, läuft das System weiter, andernfalls erscheint ein schwarzer Bildschirm. Diese Idee schränkt Rootkits effektiv ein, stellt aber Microsoft für fast alle PCs in den Mittelpunkt der Kette.

Im Jahr 2025 lief das berüchtigte Zertifikat von 2011 aus; ohne einen neuen Schlüssel in der Firmware booten Fedora, Ubuntu oder OpenSUSE nicht mehr. Lenovo-, Dell-, Asus-, HP- und Acer-Rechner, die vor 2020 ausgeliefert wurden, sind am stärksten gefährdet: Ohne ein UEFI-Update bleiben sie auf dem alten signierten Shim hängen. Es gibt einen Workaround: Ein neuer KEK überträgt den Schlüssel 2023 und startet die Vertrauenskette neu. Der Schlüssel wird über den Linux Vendor Firmware Service übertragen, der Hersteller muss den Mikrocode jedoch noch veröffentlichen. Bei einigen Gigabyte- oder ASRock-Modellen gibt das Tool fwupd lediglich die Meldung „Keine Updates verfügbar“ zurück, sodass der Benutzer entscheiden kann, ob er die Funktion deaktivieren möchte.

Direkte Auswirkungen auf Linux-Distributionen nach September 2025

Red Hat und Canonical kompilieren ihre Shims bereits mit dem Schlüssel 2023 und warten auf die Veröffentlichung der neuen Firmware durch die OEMs. In der Praxis wimmelt es in den Arch-Foren von Meldungen wie „Fehler beim Schreiben von efivarfs“ nach einem einfachen Pacman-Syu. Der Fehler wird oft durch einen BIOS-Reset behoben, ein Beweis dafür, dass die Zuverlässigkeit nicht gegeben ist.

Die Bedrohung ist nicht theoretischer Natur: Ein Computer, der im laufenden Betrieb nicht mehr bootet, ist teuer, insbesondere in einer heterogenen Flotte aus Intel- und AMD-Prozessoren. Der von mehreren Teams gewählte Kompromiss ist klar: Secure Boot ist deaktiviert, aber LUKS-Verschlüsselung und TPM sind aktiviert, um eine solide Barriere aufrechtzuerhalten.

Warum bestehen die Hersteller dennoch darauf?

Offiziell soll der Mechanismus Raubkopien blockieren und Windows 11 schützen. Inoffiziell schränkt der Mechanismus die Installation nicht signierter Systeme ein und festigt so den Marktanteil des in Redmond ansässigen Softwareunternehmens. In ihren Büros in Taipeh räumen die Teams von Asus und Gigabyte hinter vorgehaltener Hand ein, dass von Secure Boot ausgenommene Firmware den Support für sie vereinfachen würde, doch Marketingvereinbarungen haben erhebliches Gewicht.

Auf Unternehmensseite sehen die IT-Abteilungen von Dell und HP den Mechanismus positiv: eine standardisierte Flotte, ein eindeutiger Hash, vereinfachte Audits. Die Entdeckung von OEM-Plattformen, die ihre privaten UEFI-Schlüssel verloren haben, erinnert jedoch daran, dass zentralisierte Sicherheit einen Single Point of Failure schafft. Intel, AMD und das UEFI-Schlüsselspiel

Seit Tiger Lake bietet Intel ein BootGuard-Modul an, das Secure Boot ersetzen kann, während AMD PSP für die Verschlüsselung der Boot-Sequenz anpreist. Beide Hersteller wollen beweisen, dass sie nicht auf einen externen Schlüssel angewiesen sind, doch der Einsatz außerhalb von Rechenzentren bleibt marginal.

Gigabyte experimentiert mit einer lokalen Schlüsselbasis, die mit jedem BIOS-Update aktualisiert wird; ASRock bevorzugt einen Hybridmodus, bei dem die Microsoft-Signatur nur akzeptiert wird, wenn der OEM-Schlüssel abgelaufen ist. Beide wollen das Szenario 2025 vermeiden: eine plötzliche Abschaltung durch eine Drittbehörde.

Die Frage wird daher politisch: Wer kontrolliert die Vertrauensbasis?

Deaktivierung von Secure Boot ohne Sicherheitseinbußen

Das Deaktivieren der Option entlastet das System: Benutzerdefinierter Kernel, DKMS-Module, Virt-Manager und proprietäre Treiber werden ohne Signaturen geladen. Ein doppelter Vorteil für Entwickler, aber auch für Gamer, die nicht mehr mit Schlüsseln jonglieren möchten, wenn ein Nvidia-Patch erscheint.

Der Kompromiss ist nicht unüberwindbar: eine verschlüsselte Festplatte, eine Integritätsmaßnahme über systemd-verity und ein gut gewähltes BIOS-Passwort. Im Falle eines physischen Angriffs hält die Verschlüsselung, und aus der Ferne schließen schnelle Updates Schwachstellen effektiver als schlecht gepflegtes Secure Boot.Letztendlich ist Secure Boot ein Gürtel, der reißt, wenn die Schnalle jemand anderem gehört.

Wer seine Boot-Kette kontrolliert, kann darauf verzichten; regulierte Umgebungen hingegen müssen mit ihren Lieferanten verhandeln, um ein erneutes Auftreten des Fehlers mit abgelaufenen Zertifikaten zu vermeiden. Quelle: