Wer in letzter Zeit ein Dual-Boot-System zwischen Windows und Linux betreibt, kennt das Problem vielleicht bereits aus eigener Erfahrung: nach einem Windows-Update startet Linux plötzlich nicht mehr. Die Fehlermeldung lautet irgendwas mit Verification failed: (0x1A) Security Violation oder Invalid signature detected. Das ist kein Bug im klassischen Sinne — es ist die Auswirkung einer jahrelangen Übergangsperiode in Microsofts Secure-Boot-Zertifikatsinfrastruktur, die jetzt konkret wird.
Was ist Secure Boot überhaupt?
Secure Boot ist ein Standard der UEFI-Spezifikation, der sicherstellen soll, dass nur kryptographisch signierter Code beim Systemstart ausgeführt wird. Die Idee dahinter ist einfach: Schadsoftware, die sich vor dem Betriebssystem in den Boot-Prozess einnistet (sogenannte Bootkits), kann durch Secure Boot blockiert werden, da sie keine gültige Signatur vorweisen kann.
Vereinfacht gesagt: Dein UEFI-Firmware prüft vor dem Laden eines Bootloaders dessen digitale Signatur gegen eine hinterlegte Datenbank. Stimmt die Signatur nicht, wird der Startvorgang abgebrochen. Das klingt simpel, ist aber in der Praxis ein mehrschichtiges Zertifikatssystem mit mehreren Akteuren.
Das Zertifikatssystem: PK, KEK, db und dbx
Das Secure-Boot-Ökosystem kennt vier zentrale Konzepte:
PK (Platform Key): Der oberste Schlüssel in der Hierarchie, ausgestellt vom Gerätehersteller. Wer den PK kontrolliert, kontrolliert Secure Boot auf dem Gerät. Auf Consumer-Hardware ist das typischerweise Dell, Lenovo, HP oder der jeweilige Hersteller. Auf eigener Hardware (z.B. beim Aufbau eines eigenen UEFI-Systems) kann man hier seinen eigenen Schlüssel hinterlegen.
KEK (Key Exchange Key): Wird genutzt, um die Signatur-Datenbanken (db und dbx) zu aktualisieren. Auf den meisten Windows-Systemen trägt Microsoft hier seinen KEK ein, wodurch Microsoft in der Lage ist, die Datenbanken zu aktualisieren — ohne dass der Nutzer eingreifen muss. Das ist sowohl praktisch als auch eine Machtfrage.
db (Signature Database): Die Whitelist. Enthält Zertifikate und Hashes, denen vertraut wird. Ein Bootloader, der mit einem Zertifikat aus der db signiert ist, darf ausgeführt werden. Microsofts wichtigste Einträge hier waren historisch:
Microsoft Windows Production PCA 2011— zum Signieren des Windows-BootloadersMicrosoft Corporation UEFI CA 2011— zum Signieren von Drittanbieter-UEFI-Applikationen, darunter alle Linux-Shims
dbx (Forbidden Signature Database): Die Blacklist. Enthält widerrufene Zertifikate und Hashes von bekannt-verwundbaren oder kompromittierten Bootloadern. Sobald ein Hash oder ein Zertifikat in der dbx landet, wird der entsprechende Code nicht mehr ausgeführt — egal ob er formal noch gültig signiert ist.
Der Kern des Problems: Alte Zertifikate, neue Anforderungen
Das Zertifikat Microsoft Corporation UEFI CA 2011 ist, wie der Name andeutet, seit 2011 im Einsatz. Fast alle Linux-Distributionen, die Secure Boot unterstützen, nutzen einen sogenannten Shim — ein kleines, von Microsoft signiertes UEFI-Programm, das dann den eigentlichen Linux-Bootloader (GRUB, systemd-boot etc.) lädt und dessen Signatur gegen einen distributionseigenen Schlüssel prüft.
Dieses 2011er-Zertifikat läuft aus. Microsoft hat das Nachfolgezertifikat Microsoft UEFI CA 2023 eingeführt und beginnt schrittweise, neue Shim-Versionen nur noch mit dem neuen Zertifikat zu signieren. Gleichzeitig werden alte, mit Sicherheitslücken behaftete Shim-Versionen aktiv in die dbx aufgenommen — sie werden also als "verboten" markiert.
Das Ergebnis: Wer seine Linux-Distribution nicht aktuell hält, läuft Gefahr, dass nach einem Windows-Update, das die dbx aktualisiert, der Linux-Bootloader blockiert wird.
Die BlackLotus-Nachwirkungen und dbx-Updates
Der direkteste Auslöser für die aktuell rollenden dbx-Updates war die Entdeckung von BlackLotus — einem UEFI-Bootkit, das 2022/2023 in freier Wildbahn beobachtet wurde. BlackLotus war in der Lage, Secure Boot zu umgehen, indem es ältere, verwundbare Bootloader nutzte, die noch gültig signiert, aber bekannt unsicher waren.
Microsofts Reaktion: massenhafte Aufnahme alter Bootloader-Hashes in die dbx. Das ist technisch korrekt und sicherheitstechnisch geboten — hat aber Kollateralschäden. Viele Linux-Shims, die auf älteren Systemen oder in nicht-aktuell-gehaltenen Installationen noch im Einsatz sind, landeten plötzlich auf der Blacklist.
Dazu kommt: dbx-Updates werden auf Windows-Systemen automatisch durch Windows Update eingespielt. Ein Nutzer startet Windows, das Update läuft durch, er rebootet — und Linux bootet nicht mehr. Keine Vorwarnung, kein Dialog, kein einfacher Rollback.
Wie der Linux-Boot-Chain funktioniert (und wo es bricht)
Zum Verständnis lohnt sich ein kurzer Blick auf die vollständige Boot-Kette eines typischen Linux-Systems mit Secure Boot:
- UEFI Firmware prüft die Signatur von
/EFI/ubuntu/shimx64.efi(oder äquivalent) gegen die db. Das Shim ist mit dem Microsoft UEFI CA-Zertifikat signiert. ✓ - Shim lädt
grubx64.efiund prüft dessen Signatur gegen den eingebetteten distributionseigenen Schlüssel (z.B. Canonical's Key für Ubuntu). ✓ - GRUB lädt den Linux-Kernel und prüft (bei aktivierter Lockdown-Konfiguration) dessen Signatur. ✓
- Kernel startet, initrd wird geladen. ✓
Das Problem entsteht in Schritt 1: Wenn der Hash des installierten Shim in der dbx steht, verweigert die Firmware die Ausführung — und die gesamte Kette bricht im ersten Glied.
Wer ist konkret betroffen?
Dual-Boot-Systeme (Windows + Linux): Das höchste Risiko. Windows Update spielt dbx-Updates ein, ohne dass der Nutzer gefragt wird. Wenn der Linux-Shim danach auf der Blacklist steht, bootet Linux nicht mehr. Betroffen sind vor allem ältere Installationen, die seit Monaten oder Jahren nicht aktualisiert wurden.
Reine Linux-Systeme ohne Windows: Geringeres Risiko, da keine automatischen dbx-Updates durch Windows Update eingespielt werden. Die Firmware kann jedoch vom Hersteller über Updates dbx-Einträge hinzufügen. Wer regelmäßig Firmware-Updates einspielt (was man tun sollte), kann trotzdem betroffen sein.
Windows-only-Systeme: Kein praktisches Problem. Der Windows-Bootloader wird von Microsoft zeitnah mit neuen Zertifikaten signiert.
Server ohne Secure Boot: Auf vielen Servern ist Secure Boot deaktiviert. Dort ist das Thema irrelevant — solange das so bleibt.
Was du jetzt konkret tun solltest
1. Linux-System vollständig aktualisieren
Der wichtigste Schritt. Moderne Distributionen haben ihre Shims längst auf neue, nicht-widerrufene Versionen aktualisiert. Unter Debian/Ubuntu:
sudo apt update && sudo apt full-upgradeUnter Fedora/RHEL:
sudo dnf upgrade --refreshUnter Arch:
sudo pacman -SyuNach dem Update sollte das Paket shim-signed (Debian/Ubuntu) bzw. shim-x64 (Fedora) in einer aktuellen Version vorliegen, die mit dem neuen UEFI CA 2023 kompatibel ist.
2. Secure-Boot-Status prüfen
Unter Linux lässt sich der aktuelle Status mit folgendem Befehl prüfen:
mokutil --sb-stateUnd die aktuell vertrauenswürdigen Zertifikate:
mokutil --list-enrolledDie dbx-Einträge (Blacklist) lassen sich ebenfalls auslesen:
mokutil --dbx | grep -i "hash\|guid"3. UEFI/BIOS Firmware aktualisieren
Hersteller spielen neue db/dbx-Einträge auch über Firmware-Updates ein. fwupd vereinfacht das unter Linux erheblich:
sudo fwupdmgr refresh
sudo fwupdmgr updateDas ist besonders wichtig auf Systemen ohne Windows, die keine automatischen dbx-Updates über Windows Update erhalten.
4. MOK (Machine Owner Key) prüfen
Wer seinen Kernel selbst kompiliert oder Treiber aus dem DKMS-Framework nutzt (z.B. Nvidia-Treiber, VirtualBox), hat möglicherweise eigene Schlüssel im MOK-Speicher. Diese sind von den Microsoft-Zertifikaten unabhängig und nicht direkt betroffen — sollten aber trotzdem regelmäßig auf Gültigkeit geprüft werden:
mokutil --list-enrolled5. Notfallplan: Was tun wenn Linux nicht mehr bootet?
Wenn das Kind bereits in den Brunnen gefallen ist:
- UEFI-Setup öffnen (meist Entf, F2 oder F12 beim Start)
- Secure Boot temporär deaktivieren
- Linux booten und System vollständig updaten (
apt full-upgradeo.ä.) - Secure Boot wieder aktivieren
- Beim nächsten Boot sollte der neue Shim akzeptiert werden
Sollte nach dem Update Secure Boot weiterhin blockieren, liegt möglicherweise ein veralteter GRUB oder ein alter Kernel-Hash in der dbx. In diesem Fall:
sudo update-grub
sudo grub-install --target=x86_64-efi --efi-directory=/boot/efiAusblick: Eigene PKI für Secure Boot
Wer langfristig unabhängig von Microsofts Zertifikatspolitik sein möchte, kann Secure Boot mit vollständig eigenen Schlüsseln einrichten. Das bedeutet: eigener PK, KEK, und db — kein Microsoft-Zertifikat mehr in der Vertrauenskette. Dieser Ansatz wird in der Linux-Community zunehmend populärer, ist aber nur für erfahrene Nutzer geeignet, da ein Fehler das System unbootbar machen kann. Tools wie sbctl vereinfachen diesen Prozess erheblich.
Fazit
Die Ablösung der Secure-Boot-Zertifikate ist kein dramatisches Ereignis — es ist ein vorhersehbarer, notwendiger Übergang in einer alternden Public-Key-Infrastruktur. Wer sein System regelmäßig aktualisiert, wird kaum Probleme bemerken. Wer das nicht tut — insbesondere auf Dual-Boot-Systemen — riskiert, nach einem Windows-Update vor einem nicht bootenden Linux zu stehen.
Die wichtigste Maßnahme ist simpel: System aktuell halten. Shim, GRUB, Kernel, Firmware. Das löst 95% der Probleme, bevor sie entstehen.
Secure Boot vollständig verstehen: Der Vertrauensanker
Secure Boot basiert auf einem Schlüsselhierarchie-System mit drei Schlüsseltypen:
- Platform Key (PK): Der Schlüssel des Mainboard-Herstellers — wurzel der gesamten Vertrauenskette. Wer den PK besitzt kann alle anderen Schlüssel ändern
- Key Exchange Key (KEK): Signiert Updates der DB und DBX-Listen. Microsoft und der OEM-Hersteller haben normalerweise je einen KEK
- Signature Database (db): Liste der vertrauenswürdigen Signierschlüssel und Hashes
- Forbidden Signature Database (dbx): Liste der explizit gesperrten Schlüssel — hier landen kompromittierte Keys
Der SK15-Ablauf 2023 betraf spezifisch einen Schlüssel in der db-Datenbank: Das Microsoft UEFI CA 2011-Zertifikat, das zum Signieren von Boot-Loadern genutzt wurde. Nach Ablauf akzeptierten strikt konfigurierten UEFI-Implementierungen Dateien nicht mehr, die nur mit diesem Zertifikat signiert waren.
sbctl: Modernes Secure-Boot-Management unter Linux
Das modernste Tool für Secure Boot unter Linux ist sbctl. Es ermöglicht das Erstellen eigener Secure-Boot-Schlüssel und das Signieren des eigenen Kernels und Boot-Loaders — vollständige Kontrolle ohne Abhängigkeit von Microsoft-Zertifikaten:
# sbctl: Eigene Secure-Boot-Schlüssel erstellen
sbctl create-keys
# Schlüssel in UEFI einrollen (Secure Boot im Setup-Mode!)
sbctl enroll-keys --microsoft # Eigene Schlüssel + Microsoft-Schlüssel
# Status prüfen
sbctl status
# Zeigt: Setup Mode, Secure Boot Status, Signierte Dateien
# Kernel und Bootloader signieren
sbctl sign /boot/vmlinuz-linux
sbctl sign /boot/EFI/GRUB/grubx64.efi
sbctl sign /usr/lib/systemd/boot/efi/systemd-bootx64.efi
# Automatisch: Alle unsignierten Dateien finden und signieren
sbctl verify
sbctl sign-all # Alle verifizierten Pfade signierenMit eigenen Secure-Boot-Schlüsseln ist man vollständig unabhängig von Microsoft-Zertifikaten und deren Ablauf. Der Nachteil: Jeder neue Kernel, jedes Boot-Loader-Update muss neu signiert werden — sbctl kann das über Pacman/apt-Hooks automatisieren.
Dual-Boot: Secure Boot korrekt konfigurieren
Dual-Boot mit Windows und Linux ist die schwierigste Secure-Boot-Konfiguration. Windows benötigt Microsoft-Schlüssel in der db. Linux kann entweder mit Microsoft-signierten Shim-Bootloadern starten (Ubuntu, Fedora, openSUSE machen das so) oder mit eigenen Schlüsseln (sbctl-Ansatz).
Der Shim-Ansatz (Standard bei Ubuntu): Der Shim-Bootloader ist von Microsoft signiert. Shim lädt dann GRUB, das mit einem Distro-eigenen Schlüssel signiert ist. Windows und Linux teilen sich die Microsoft-Vertrauenskette. Nachteil: Abhängigkeit von Microsoft-Zertifikaten und Shim-Verwundbarkeiten (wie BootHole 2020).
Der sbctl-Ansatz: Eigene Schlüssel für Linux, Microsoft-Schlüssel für Windows parallel in der db. Beide koexistieren. Vorteil: Kontrolle. Nachteil: Mehr initiale Konfiguration.
# Secure Boot Status aus laufendem System prüfen
bootctl status | grep "Secure Boot"
mokutil --sb-state
# Zeigt: SecureBoot enabled/disabled
# Alle Secure-Boot-Variablen anzeigen
efi-readvar
# Gesperrte Schlüssel (dbx) anzeigen
sbctl list-enrolled-keysWas tun wenn Secure Boot nicht aktivierbar ist?
Bei manchen älteren Mainboards (besonders bei Consumer-Boards vor 2012) gibt es kein Secure Boot im UEFI — oder es ist derart eingeschränkt implementiert, dass es nicht sinnvoll nutzbar ist. In diesen Fällen:
- Secure Boot deaktiviert lassen und andere Boot-Sicherheitsmaßnahmen nutzen (dm-verity für Rootfs-Integrität)
- Full-Disk-Encryption (LUKS) als Schutz vor physischem Zugriff
- TPM-basiertes Key-Sealing als Alternative zu Secure-Boot-Verifikation
- Bei neuerer Hardware: BIOS-Update kann Secure-Boot-Unterstützung nachrüsten
Secure Boot ist kein Allheilmittel — es schützt den Boot-Prozess gegen Manipulation, aber nicht gegen Angriffe auf ein laufendes System. Es ist eine Schicht in einem mehrschichtigen Sicherheitskonzept, keine Komplettlösung.
Vorsorge: Wie man sich gegen zukünftige Ablaufe absichert
Der SK15-Vorfall hat eines deutlich gemacht: Secure Boot ist kein "Set and Forget"-Feature. Zertifikate laufen ab, Firmware-Updates können Konfigurationen ändern, und wer kein Monitoring hat, erfährt davon erst wenn das System nicht mehr bootet.
Praktische Vorsorge-Maßnahmen: BIOS-Updates regelmäßig einspielen — Hersteller aktualisieren die dbx-Listen und fügen neue Signierschlüssel in db hinzu. Für Linux-Nutzer mit Dual-Boot: Die Shim-Version aktuell halten (wird mit Distro-Updates mitgeliefert). Für Nutzer mit eigenen Secure-Boot-Schlüsseln (sbctl): Ein Monitoring aufsetzen, das die Ablaufdaten der eigenen Schlüssel überwacht.
Letztendlich ist Secure Boot ein mächtiges Sicherheitsfeature das Boot-Prozess-Integrität auf Hardware-Ebene garantiert — vorausgesetzt, es wird korrekt konfiguriert und gewartet. Der SK15-Ablauf hat die Komplexität dieser Wartung sichtbar gemacht. Wer das versteht und entsprechend handelt, profitiert von echtem Schutz gegen Boot-Kits und Rootkits ohne böse Überraschungen beim nächsten Systemstart.
Secure Boot bleibt eines der wenigen Sicherheitsfeatures das auf Hardware-Ebene angreift — bevor das Betriebssystem startet, bevor Antivirus läuft, bevor irgendein Software-Schutz aktiv ist. Die Investition in korrektes Setup und Wartung zahlt sich aus. Wer Dual-Boot mit Linux und Windows betreibt, sollte die Shim-Versionierung im Auge behalten und bei Problemen zuerst prüfen ob ein Secure-Boot-Zertifikat-Update die Ursache ist.
Für alle Dual-Boot-Nutzer die dieses Problem noch nicht hatten: Es ist eine Frage des Wann, nicht des Ob. Ein bootfähiges Linux-Live-System auf einem USB-Stick in der Schublade, zusammen mit Notizen zur eigenen Secure-Boot-Konfiguration, ist die pragmatischste Vorbereitung.