Achtung: Linux Secure Boot steht vor einem Schlüssel-Problem

Wer Linux mit aktiviertem Secure Boot nutzt – und viele merken gar nicht, dass sie diese Funktion aktiviert haben – sollte aufhorchen. Da kommt ein Ablaufdatum auf uns zu, das die nächste Systeminstallation ordentlich verhageln kann.

Der Hintergrund

Das Problem sitzt im bootloader: genauer gesagt im shim, jenem wichtigen ersten Baustein, der Linux den Umgang mit UEFI Secure Boot beibringt. Dieser shim ist mit einem Microsoft-Schlüssel signiert. Und genau dieser Schlüssel aus dem Jahr 2011 wird am 11. September seine Gültigkeit verlieren.

Klingt dramatisch? Ist es zum Teil auch. Denn obwohl ein Ersatzschlüssel bereits seit 2023 bereitsteht, haben Millionen von Systemen ihn schlicht noch nicht installiert. Bei manchen Maschinen wäre dafür ein Firmware-Update vom Hardware-Hersteller nötig – und manche Hersteller kümmern das schlicht nicht mehr.

Wen trifft es wirklich?

Gute Nachricht zuerst: Bestehende Linux-Installationen machen wahrscheinlich keine Probleme. Der bootloader eurer Distribution ist mit eigenen Schlüsseln signiert und läuft weiter wie gewohnt.

Schwierig wird es eher hier:

• Frische Linux-Installationen auf Secure-Boot-Systemen
• Booten von Installationsmedien auf Maschinen mit veralteten Firmware-Datenbanken
• Randfälle, in denen Hersteller Updates schlicht nicht ausgeliefert haben

Richard Hughes, der Entwickler hinter LVFS (Linux Vendor Firmware Service), fasst es trocken zusammen: Die KEK-Updates schlagen mit etwa 98 Prozent Erfolg durch, die db-Updates mit ungefähr 99 Prozent. Klingt erstmal gut. Aber Hughes fügt hinzu: Selbst ein Prozent, multipliziert mit Millionen betroffener Nutzer, ergibt eine ordentliche Menge an Fehlschlägen. Kein Grund zur Panik – aber auch nichts, worauf man sich ausruhen sollte.

Wo liegt eigentlich das Problem?

Die Schlüssel selbst machen nicht schlapp. Das eigentliche Übel ist der begrenzte Speicherplatz. Ältere UEFI-Firmwares haben nur wenig Platz für EFI-Variablen. Manchmal muss man diesen Platz regelrecht „defragmentieren" – sprich: das BIOS auf Werkseinstellungen zurücksetzen.

Hughes bemerkt dazu: Je älter eure BIOS-Version, desto wahrscheinlicher tretet ihr auf dieses Problem.

Für die betroffenen ein bis zwei Prozent sieht der Lösungsweg oft so aus:

1. Neustart
2. BIOS auf Werkseinstellungen zurücksetzen
3. Update erneut versuchen

Die Community schafft Abhilfe

Positiv: Die Open-Source-Gemeinde hat vorgesorgt. LVFS und fwupd – Tools für Firmware-Updates direkt unter Linux – wurden fit gemacht für solche Zertifikatswechsel. Die meisten großen Distributionen liefern aktualisierte shim-Binaries mit dem neuen Microsoft-Schlüssel aus. Eure nächste OS-Installation sollte also glatt über die Bühne gehen.

Hersteller verteilen gerade fleißig KEK-Updates (Key Exchange Key), die fwupd ermöglichen, den neuen Microsoft-Zertifikate sicher in die Firmware-Datenbank einzutragen.

Und für diejenigen, deren Hersteller seit Jahren nichts mehr von sich hören lassen? Nun, dann bleibt als letzte Option: Secure Boot komplett deaktivieren.

Was solltest du jetzt tun?

Falls du Linux-Systeme mit Secure Boot verwaltest:

1. Überprüfe dein aktuelles Setup, bevor der September kommt
2. Spiele Firmware-Updates ein, falls verfügbar
3. Halte Backup-Bootoptionen bereit – nur für alle Fälle
4. Bei Neuinstallationen ab September: Stell sicher, dass dein Installationsmedium den aktualisierten shim nutzt

Die Open-Source-Welt hat solche Zertifikatsabläufe schon öfter überstanden. In den meisten Fällen wird das hier auch glimpflich ausgehen. Aber wenn du eine ganze Flotte von Maschinen betreust oder in den nächsten Monaten eine Frischinstallation planst, solltest du jetzt aktiv werden. Ein paar Minuten Vorbereitung können dich später vor frantic debugging sessions bewahren.

Für Entwickler und Startups, die Linux produktiv einsetzen: Ab auf die Maintenance-Checklist mit diesem Thema.

Bleibt secure – am besten mit Schlüsseln, die noch gültig sind.