Secure Boot unter Linux: Was der Zertifikatswechsel bedeutet und wie Du Dein System prüfst

Dein Linux startet mit Secure Boot weiter, auch nach dem Ablauf von Microsofts alten Secure-Boot-Zertifikaten. Kritisch wird erst das nächste Update des kleinen Bootloaders Shim. Neue Shim-Versionen tragen die Signatur der „Microsoft UEFI CA 2023“. Kennt die Firmware Deines Rechners diese Zertifizierungsstelle nicht, verweigert sie den Start. Prüfe deshalb mit mokutil, ob die neue CA eingetragen ist. Fehlt sie, spielst Du sie per fwupd oder per Firmware-Update des Herstellers ein.

Betroffen bist Du nur, wenn Secure Boot eingeschaltet ist. Das gilt für reine Linux-Rechner, für Dual-Boot mit Windows und für Live-Sticks und Rettungsmedien. Windows ist hier nur der Auslöser. Microsoft verwaltet die Schlüssel, mit denen fast jede Distribution auf normaler PC-Hardware startet.

Was Secure Boot beim Start prüft

Secure Boot ist eine Funktion der UEFI-Firmware. Sie startet nur Programme, deren Signatur sie kennt. Dafür hält die Firmware laut der Dokumentation von fwupd vier Listen bereit:

• PK (Platform Key): ein einzelner Schlüssel des Geräteherstellers. Er legt fest, wer die KEK-Liste ändern darf.
• KEK (Key Exchange Key): Schlüssel von Microsoft und vom Hersteller. Nur damit signierte Änderungen an db und dbx nimmt die Firmware an.
• db: die Erlaubnisliste. Hier stehen die Zertifizierungsstellen, deren Signaturen gelten.
• dbx: die Sperrliste. Sie enthält widerrufene Zertifikate und Prüfsummen unsicherer Bootloader.

Linux-Distributionen lassen nicht jede GRUB- und Kernel-Version von Microsoft signieren. Microsoft signiert stattdessen ein kleines Vorprogramm namens Shim. Shim enthält den Schlüssel der Distribution und prüft damit GRUB und den Kernel. Das Prinzip ist alt: Schon 2012 war der erste nutzbare Shim für Distributionen ein Thema. Wie hitzig damals über Secure Boot gestritten wurde, zeigt ein Archivbeitrag zu den Mythen über UEFI und Secure Boot.

Dazu kommt eine eigene Ebene: MOK, der Machine Owner Key. Das sind Schlüssel, die Shim verwaltet. Sie stehen nicht in der db der Firmware. Ubuntu erzeugt bei der Installation zum Beispiel einen MOK, mit dem es selbst gebaute Kernelmodule signiert. Beim Eintragen fragt der MokManager nach dem Neustart nach einem Passwort. Welche MOKs eingetragen sind, zeigt mokutil --list-enrolled. Der Zertifikatswechsel ändert an Deinen MOKs nichts. Sie hängen aber am Shim: Startet er nicht, nützt Dir auch der MOK nichts.

Welche Zertifikate ablaufen und was an ihre Stelle tritt

Microsoft hat 2011 drei Zertifikate ausgestellt, die in fast jeder PC-Firmware stecken. Alle drei haben ihr Ablaufdatum im Jahr 2026 und bekommen Nachfolger aus dem Jahr 2023. Die Daten stammen aus dem Support-Artikel von Microsoft und decken sich mit der Übersicht von cert.at.

Für Linux zählt vor allem die Microsoft UEFI CA. Mit ihr signiert Microsoft den Shim. Die neue Generation teilt diese Aufgabe auf: Die „Microsoft UEFI CA 2023“ signiert Bootloader, die „Microsoft Option ROM UEFI CA 2023“ die Firmware mancher Steckkarten. Die Windows Production PCA betrifft nur den Windows-Bootmanager und damit Dual-Boot-Rechner.

Abgelaufen heißt dabei nicht gesperrt. Red Hat erklärt, dass der Ablauf nur das Signieren neuer Dateien beendet. Bereits signierte Bootloader startet die Firmware weiter. Voraussetzung ist, dass ihr Zertifikat in der db bleibt und nicht in der dbx landet.

Was passiert, wenn Du nichts tust

Kurzfristig passiert nichts. Laut Microsoft starten Geräte ohne die neuen Zertifikate normal und installieren weiter Updates. Drei Folgen summieren sich aber mit der Zeit:

1. Keine neuen Shim-Versionen. Die Distributionen signieren künftige Shims nur mit der CA von 2023. Fehlt sie in der db, startet der neue Shim nicht. Debian und Red Hat bauen deshalb Prüfungen ein, die ein unpassendes Shim-Update vor der Installation erkennen sollen.
2. Keine neuen Sperren. Ohne die neue KEK kann Microsoft keine signierten Updates für db und dbx liefern. Neu entdeckte Bootkits blockiert Deine Firmware dann nicht, schreibt cert.at.
3. Ärger mit neuen Medien. Künftige Installations-ISOs können die CA von 2023 voraussetzen. Canonical kündigt das für kommende Ubuntu-Medien an.

Prüfliste: So checkst Du Dein Linux

Die folgenden Befehle stammen aus den Anleitungen von Canonical, Red Hat und Fedora. Bis auf fwupdmgr update lesen sie nur Informationen aus. Du kannst sie also gefahrlos ausprobieren.

1. UEFI-Modus prüfen (Befehl aus dem Fedora Magazine). Erscheint „BIOS“, startet Dein System im alten BIOS-Modus. Dann spielt Secure Boot keine Rolle.

   [[ -d /sys/firmware/efi ]] || echo BIOS

2. Secure Boot prüfen (Befehl aus der Anleitung von Red Hat). Die Ausgabe „SecureBoot enabled“ heißt: Die Firmware prüft Signaturen.

   mokutil --sb-state

3. Zertifikate in db und KEK auflisten (Befehle aus der Ubuntu-Anleitung von Canonical). Suche in der ersten Ausgabe nach „Microsoft UEFI CA 2023“. In der zweiten sollte „Microsoft Corporation KEK 2K CA 2023“ stehen.

   mokutil --db | grep 'Subject:'
   mokutil --kek | grep 'Subject:'

4. fwupd-Version prüfen (Canonical). Für die Zertifikatsupdates nennt Canonical mindestens Version 2.0.

   fwupdmgr --version

5. Updates holen und einspielen (Canonical). fwupd zeigt die Zertifikate als eigene Einträge, etwa „UEFI CA“, „KEK CA“ und „UEFI dbx“. Nach der Installation startest Du neu und wiederholst Schritt 3.

   sudo fwupdmgr refresh
   sudo fwupdmgr update

6. Signatur des Shims ansehen (optional, Befehl aus dem Fedora Magazine). Dafür brauchst Du das Paket pesign. Bei anderen Distributionen ersetzt Du „fedora“ durch den passenden Ordner unter /boot/efi/EFI/.

   sudo pesign -S -i /boot/efi/EFI/fedora/shimx64.efi

Was das Ergebnis von Schritt 3 bedeutet, zeigt die Tabelle:

Was die Distributionen ausliefern

Wie viel Du selbst tun musst, hängt an Deiner Distribution. Die Tabelle fasst zusammen, was die Projekte veröffentlicht haben. Die Daten stehen dabei, weil sich die Angaben schnell ändern.

Dual-Boot mit Windows und BitLocker

Auf einem Dual-Boot-Rechner teilen sich Windows und Linux dieselbe Firmware. Windows Update spielt die neuen Zertifikate in db und KEK ein. Davon profitiert auch Linux. Das Debian-Wiki weist darauf hin, dass Dual-Boot-Rechner die Updates womöglich schon über Windows erhalten haben. Prüfe das mit Schritt 3 der Prüfliste, bevor Du fwupd startest.

Die Windows Production PCA betrifft den Windows-Bootmanager. Windows braucht die „Windows UEFI CA 2023“, um nach dem Ablauf weiter Sicherheitsupdates für den Start zu bekommen. Für Linux spielt sie keine Rolle. Sperrt Microsoft die alte PCA später per dbx, starten laut cert.at aber alte Windows-Installations- und Rettungsmedien nicht mehr. Erstelle Deine Windows-Rettungsmedien deshalb neu, sobald Windows die neuen Zertifikate nutzt.

BitLocker: Änderungen an db oder KEK verändern die Messwerte, die das TPM beim Start prüft. Windows fragt dann womöglich einmal nach dem Wiederherstellungsschlüssel. Das beschreiben Microsoft und die Entwickler von fwupd. Canonical hat die Verteilung der fwupd-Updates sogar kurz angehalten, weil es auf Dual-Boot-Rechnern mit BitLocker Probleme gab. Lege den Schlüssel deshalb bereit, bevor Du unter Linux fwupdmgr update ausführst. Du findest ihn im Microsoft-Konto oder bei der IT Deiner Firma.

LUKS mit TPM: Entsperrst Du ein verschlüsseltes Linux automatisch per TPM, gilt das Gleiche. Red Hat rät, die Bindung vor dem Neustart auf Register zu legen, die sich nicht ändern, oder sie kurz abzuschalten. Nach dem Neustart bindest Du den Schlüssel neu. Wer LUKS mit einer Passphrase entsperrt, muss nichts beachten.

Startet nach einem Windows-Update plötzlich nur Windows, oder meldet der Shim „SBAT self-check failed“, hilft die Anleitung GRUB nach einem Windows-Update reparieren. Die Reihenfolge im Bootmenü änderst Du bequem mit dem GRUB Customizer.

Live-Sticks und Rettungsmedien erneuern

Ein bootfähiger Stick bringt seinen eigenen Shim mit. Er stammt aus dem ISO, das Du auf den Stick geschrieben hast. Ein alter Stick kann deshalb an zwei Stellen scheitern:

• Sein Shim trägt nur die Signatur von 2011. Auf Rechnern, die ab Werk nur die Zertifikate von 2023 kennen, startet er nicht. Solche Geräte liefern laut fwupd-Dokumentation einige Hersteller aus.
• Sein Shim steht wegen bekannter Lücken auf einer Sperrliste, also in der dbx oder in der SBAT-Liste. Dann blockiert ihn jeder aktuell gehaltene Rechner.

Umgekehrt gilt: Ein neues ISO, dessen Shim nur die Signatur von 2023 trägt, startet nicht auf Firmware ohne die neue CA. Aktualisiere deshalb zuerst die Firmware und schreibe danach Deine Sticks neu. So gehst Du vor:

1. Lade das aktuelle ISO Deiner Distribution und Deines Rettungssystems herunter.
2. Schreibe es mit Rufus oder balenaEtcher auf den Stick. Rufus prüft beim Schreiben, ob der Bootloader des Abbilds gesperrt ist, und warnt dann. Das steht in den Versionshinweisen von Rufus. balenaEtcher kopiert das Abbild unverändert und prüft danach nur, ob die Kopie stimmt. Wie das geht, zeigt eine ältere Anleitung zu Abbildern mit Etcher.
3. Starte den Stick einmal mit eingeschaltetem Secure Boot auf dem Rechner, den Du im Notfall retten willst.
4. Beschrifte den Stick mit Distribution und Version.

Multiboot-Sticks mit Ventoy funktionieren anders. Ventoy startet die ISOs über einen eigenen Bootloader und trägt dafür beim ersten Start einen eigenen Schlüssel als MOK ein. Hier zählt vor allem die Version von Ventoy. Aktualisiere den Stick deshalb mit dem neuesten Ventoy-Release.

Typische Meldungen und was dahintersteckt

Secure Boot einfach ausschalten?

Das geht, und Linux startet danach ohne Prüfung der Signaturen. Du verlierst damit aber den Schutz vor manipulierten Bootloadern. Auf Dual-Boot-Rechnern hängt außerdem die BitLocker-Härtung von Windows an Secure Boot. Als Dauerlösung taugt das Abschalten deshalb nur für Altgeräte, für die der Hersteller kein Firmware-Update liefert und fwupd nichts anbietet. Auf allen anderen Rechnern bleibt Secure Boot an, und Du spielst die neuen Zertifikate ein.

Dein nächster Schritt

Öffne ein Terminal und führe mokutil --sb-state und mokutil --db | grep 'Subject:' aus. Steht dort „Microsoft UEFI CA 2023“, bist Du vorbereitet und hältst Dein System wie gewohnt aktuell. Fehlt der Eintrag, sicherst Du zuerst den BitLocker-Schlüssel, falls Windows mit auf der Platte liegt. Danach spielst Du die Zertifikate per fwupd oder BIOS-Update ein und schreibst Deinen Rettungsstick neu.