Nahe am Verfallsdatum

von Evgenij Smirnov

Secure Boot ist die erste Verteidigungslinie gegenüber Rootkits und anderen böswilligen Veränderungen, die innerhalb oder sogar unterhalb des Betriebssystem-Kernels agieren und somit jeglichen Endpunktschutz aushebeln. Doch die drei wichtigsten Zertifikate dieses Schutzmechanismus laufen in diesem Jahr ab – die ersten bereits im Juni. Admins müssen diese unter Windows Server händisch und für Clients automatisiert ersetzen. Andernfalls droht ein Verlust der Secure-Boot-Vertrauenskette.

Antimalware-Technologien existieren fast so lange wie Computerviren. Bereits im Jahr 1972 wurde der Reaper-Wurm im ARPANET freigesetzt, um den Creeper-Wurm von 1971 zu stoppen. Beide Programme enthielten keine destruktiven Payloads, beanspruchten jedoch Systemressourcen.

Die heute dominierende x86-/x64-Architektur wurde erstmals 1986 vom BRAIN-Virus befallen. Dessen Analyse beeinflusste die Karriere des IT-Sicherheitsexperten Mikko Hypponen nachhaltig. Bis heute sind über 10.000 Virenstämme mit über 100.000 Varianten bekannt. Besonders Rootkits bereiten IT-Verantwortlichen erhebliche Schwierigkeiten.

Diese Malwaregattung nistet sich in Systemkomponenten ein, die das System vor dem Betriebssystem-Kernel aktiviert, etwa im Bootloader. Dadurch kann ein Rootkit Hardwareaufrufe modifizieren, sodass der Rootkit selbst unentdeckt bleibt. Diese Methode ist weiterhin aktuell: Im Jahr 2021 leitete das Produkt FiveSys HTTP-Aufrufe infizierter Systeme auf fremde Ziele um.

Secure-Boot-Standard als Schutzmaßnahme

Um Rootkits zu bekämpfen, entwickelte das UEFI-Forum unter Federführung von Microsoft nach der Jahrtausendwende den "Secure Boot"-Standard. Er soll das Einschleusen von Malware in Firmware, Bootloader oder Kernel verhindern. Alle Programme im Boot-Prozess sind dafür digital signiert. Jede Komponente prüft die Signatur der folgenden, bevor sie die Steuerung übergibt. Schlägt die Validierung fehl, bricht der Boot-Prozess ab.

Manche Hardwarehersteller ergänzen ihre UEFI-Implementierungen um einen Selbstheilungsversuch, der die Firmware bei Fehlern auf Werkseinstellungen zurücksetzt. Microsoft führte Secure Boot mit Windows 8 als Kompatibilitätsvoraussetzung ein. Zunächst mussten Hersteller die Funktion nur bereitstellen, aber nicht zwingend aktivieren. Seit Windows 11 fordert Microsoft UEFI Secure Boot zwingend für die Installation des Betriebssystems [1].

Ein Windows-PC mit Secure Boot erfordert die Kooperation mehrerer Akteure. CPU- und Chipsatz-Hersteller liefern den "Hardware Root of Trust" (HWRoT) und sichern den Prozess gegen Umgehung ab. Der Mainboard-Hersteller stellt das UEFI-Subsystem bereit und speichert den "Platform Key" (PK) so, dass der Schlüssel an die Hardware gebunden bleibt. Es obliegt dem Hersteller, PKs für Baureihen oder Einzelgeräte zu generieren. Manche Anbieter verwenden jedoch unsichere Testschlüssel der BIOS-Hersteller. Systeme nehmen den PK in der Regel als gültig an; eine Validierung der Laufzeit oder der Ausstellerinstanz erfolgt meist nicht. Das Zertifikat in der Hardware dient als Container für den Public Key. Das private Gegenstück verbleibt beim Hersteller zum Signieren des UEFI-Firmware-Image.

In der Ladesequenz steuern verschiedene Parteien Code bei. Neben Betriebssystem-Herstellern betrifft dies Anbieter von Peripherie wie Grafikkarten oder Entwickler von Festplattenverschlüsselungen. Deren Boot-ROMs oder EFI-Anwendungen unterliegen ebenfalls der Prüfung durch Secure Boot. Die UEFI-Spezifikation nutzt dafür einen zweistufigen Mechanismus: Die UEFI-Variable "DB" enthält eine Liste erlaubter Zertifikate für Bootloader, Option-ROMs und Betriebssystem-Images. Dies können Endpunkt-Zertifikate oder Zertifizierungsstellen (CA) sein. Auch SHA-256-Hashes von Software-Images sind möglich. Die mit dem PK signierte Datenbank der "Key Enrollment Keys" (KEK) enthält Zertifikate, die Updates der DB autorisieren. In der KEK befinden sich meist Schlüssel des Hardwareherstellers und die KEK-CA von Microsoft. Drittanbieter müssen ihre Zertifikate von Microsoft oder den Plattform-Herstellern signieren lassen, um eigene Firmware-Updates durchzuführen.

Widerruf und Aktualisierung von Signaturen

Das Verfahren erlaubt einen Widerruf kompromittierter Schlüssel über die UEFI-Variable "DBX". Sie enthält gesperrte Zertifikate oder Image-Hashes. Aktualisierungen der DBX erfordern eine Signatur mit einem gültigen KEK-Schlüssel. Zudem führen UEFI-Subsysteme oft eine "Default KEK" und "Default DB", um beschädigte Variablen wiederherzustellen. Microsoft baute 2011 eine PKI-Hie- rarchie mit drei CAs auf, die 15 Jahre gültig sind:

- Microsoft Corporation KEK CA 2011 (bis 24.06.2026)

- Microsoft Corporation UEFI CA 2011 (bis 27.06.2026)

- Microsoft Windows Production PCA 2011 (bis 19.10.2026)

Diese CAs laufen 2026 ab. Microsoft nutzt den Wechsel für eine stärkere Trennung der Zuständigkeiten. Die bisherige UEFI-CA wird durch zwei spezialisierte Stellen ersetzt: Eine für Bootloader der Systemhersteller und eine für Option-ROMs der Peripherie-Anbieter. Die neuen CAs wurden im Jahr 2023 signiert. Die Preboot-CAs sind bis 2038 gültig, während die Windows-CA 2035 abläuft.

Folgen abgelaufener Zertifizierungsstellen

Laut offizieller Microsoft-Kommunikation booten Geräte, die den 2023er CAs noch nicht vertrauen, weiterhin problemlos, sofern die UEFI-Firmware der Spezifikation entspricht. Die Signaturprüfung untersucht die zeitliche Gültigkeit der CA-Zertifikate nicht. Vor dem Bootvorgang steht eine verlässliche Systemzeit nicht zwingend zur Verfügung. Anders verhält es sich beim Signiervorgang selbst: Eine gültige Signatur lässt sich mit einem abgelaufenen Zertifikat nicht mehr erzeugen. Damit können Updates der UEFI-Komponenten und Bootloader nicht mehr mithilfe von Microsoft signierter Pakete durchgeführt werden, da Microsoft diese mit Zertifikaten aus der 2011er PKI nicht mehr signieren kann. Dies setzt das Sicherheitsniveau und die Wartbarkeit herab.

Updatepakete, die vor Ablauf der Zertifikate signiert wurden, lassen sich voraussichtlich auch danach einspielen, sodass IT-Profis versäumte Systeme auch 2027 noch nachpflegen können. Auch hier gilt die Voraussetzung der Kompatibilität der Firmware mit der UEFI-Spezifikation.

Der Zertifikatsablauf bleibt nicht ohne Folgen: Sobald Microsoft Sicherheitslücken im Bootloader durch Patches behebt, werden diese nur mit einem 2023er Schlüssel signiert sein. Systeme ohne diese Zertifikate können den Patch nicht validieren. Das gleiche Problem tritt auf, wenn Peripherie wie Grafikkarten oder RAID-Controller nach November 2026 hergestellt wurden. Deren Boot-ROM ist nur durch 2023er Schlüssel signiert.

Besondere Vorsicht ist geboten, wenn Administratoren nach dem CA-Update die alten Zertifikate über die DBX sperren. Damit wird der Einsatz von Komponenten unmöglich, deren Boot-ROM ausschließlich mit den 2011er Schlüsseln signiert wurde. Dennoch ist das Sperren der alten PKI sinnvoll, da damit in der Vergangenheit zahlreiche Images signiert wurden, von denen einige als Malware identifiziert sind. Die aktuelle Sperrliste von Microsoft umfasst über 400 Image-Hashes.

Der Updateprozess im Überblick

Der Aufbau der Chain of Trust im Secure Boot ermöglicht es Hardwareanbietern, den Zertifikatsupdate-Prozess über ein Firmware-Update durchzuführen. Windows kann anschließend den Bootloader austauschen. Einige Notebook-Hersteller liefern seit Ende 2023 Firmware aus, die die neuen und alten Microsoft-CAs parallel enthält. Für andere Systeme hat Microsoft das Update der UEFI-Zertifikatsspeicher in Windows integriert.

Der geplante Task "Secure-Boot-Update" im Ordner "\Microsoft\Windows\PI" übernimmt die Durchführung. Dieser Task existiert auf allen Secure-Boot-fähigen Windows-Versionen und läuft ab Systemstart alle 12 Stunden. Dabei gelten zwei Einschränkungen:

1. Der schreibende Zugriff von Windows auf UEFI-Variablen erfordert, dass Secure Boot im nativen UEFI-Modus aktiv ist. Admins können dies in der PowerShell mit Confirm-SecureBootUefi prüfen. "True" bestätigt den Start durch Secure Boot, "False" signalisiert ein aktives UEFI bei deaktiviertem Secure Boot. Im BIOS-Modus liefert das Cmdlet eine Fehlermeldung.

2. Der Firmwarehersteller muss ein Updatepaket bereitstellen, dass den 2023er Microsoft-KEK-Key mit dem gültigen Platform Key signiert. Microsoft hat die OEMs dazu aufgefordert [2].

Damit der Task aktiv wird, müssen Sie im Registrierungsschlüssel "HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ SecureBoot" den DWORD-Wert "AvailableUpdates" setzen [3]. Ein komplettes Update der Zertifikate erreichen Sie mit dem Wert "0x5944". Danach können Sie den Task manuell starten oder den nächsten Durchlauf abwarten. Der Wert "0x5944" setzt sich bitweise zusammen:

- 0x4000: Die beiden 2023er UEFI-CAs nur anwenden, wenn die 2011er UEFI-CA vorhanden ist

- 0x1000: UEFI 2023 CA nutzen

- 0x0800: Option ROM UEFI 2023 CA aktiv

- 0x0100: Windows UEFI 2023 CA signierten Boot-Manager anwenden

- 0x0040: Windows UEFI 2023 CA einsetzen

- 0x0004: Microsoft KEK 2K 2023 CA anwenden

Aufgrund der KEK- und DB-Hierarchie muss der Vorgang zweimal wiederholt und das System dazwischen neu gestartet werden. Nach erfolgreichem Einspielen wird das jeweilige Bit auf 0 gesetzt. Die Ergebnisse finden Sie im System-Ereignisprotokoll unter der Quelle "TPM-WMI" mit den Event-IDs 1801 (Fehler) oder 1808 (Erfolg) [4]. Die Zertifikate sind in aktuellen Windows-Patchständen bereits enthalten.

Zertifikate der Clients automatisch erneuern

Bei Geräten mit Windows 10 oder 11 mit Berechtigung für Extended Security Updates (ESU) führt Microsoft den Prozess automatisch durch, sofern Telemetrie-Daten geliefert werden. Administratoren können den Prozess über ADMX-Vorlagen unter "Administrative Vorlagen \ Windows-Komponenten \Sicherer Start" steuern:

- Enable Secure Boot certificate deployment

- Automatic certificate deployment via Updates (Aktiviert bedeutet hier: nicht automatisch aktualisieren)

- Certificate deployment via Controlled Feature Rollout

Da es sich um Legacy-Richtlinien handelt, werden diese nicht automatisch auf Standardwerte zurückgesetzt. Es empfiehlt sich, jedes Modell einzeln zu testen und die Richtlinie per WMI-Filter, Group Policy Preferences oder Intune-Policys auszurollen [5].

Die Vorabprüfung ist bei aktivem Bit- Locker besonders wichtig. Veränderungen an der UEFI-Firmware lösen den Recovery-Modus aus, was die Eingabe des 48-stelligen Wiederherstellungsschlüssels erfordert. Falls das Firmwarewerkzeug des Herstellers die BitLocker-Verwaltung nicht automatisiert, müssen Sie den Festplattenschutz vor dem Update aufheben:

Manuelles Erneuern auf Servern

Für Server hat Microsoft kein automatisches Updateverfahren vorgesehen. Die manuelle Aktualisierung führen Sie jedoch genauso durch wie oben beschrieben:

- Aktualisieren Sie die Firmware – der Stand muss neuer als März 2023 sein.

- Stellen Sie sicher, dass Sie Secure Boot tatsächlich einsetzen.

- Setzen Sie den Registrierungswert für "AvailableUpdates" auf 0x5944.

- Triggern Sie den geplanten Task oder warten Sie den nächsten Lauf ab.

- Kontrollieren Sie das Ergebnis.

- Starten Sie das System neu und wiederholen Sie den Vorgang.

Bei Servern müssen Sie genau abwägen, ob Sie die 2011er PKI nach erfolgreichen Updates durch einen Eintrag in der DBX sperren. Einerseits haben Zertifikate aus dieser PKI sehr viele Images und Treiber signiert, was den Sicherheitsstandard absenkt, solange Sie dieser PKI noch vertrauen. Andererseits verbauen Sie sich durch das Sperren der alten Zertifikate den Einbau von Karten mit Boot-ROM, die noch keine 2023er Signatur tragen. Je nachdem, wie Sie den Lifecycle der Serverhardware in Ihrer Organisation handhaben, kann die Entscheidung hier unterschiedlich ausfallen.

Bei Systemen, auf denen kein Windows- Betriebssystem installiert ist, variiert das Handling von UEFI-Updates zwischen den Linux-Distributionen erheblich. Hier sind Administratoren meist auf Updates der Anbieter angewiesen. Linux-Server unter Secure Boot bringen in der Regel keinen eigenen signierten Bootloader oder KEK mit. Fast alle Distributionen nutzen den von Microsoft signierten First-Stage- Bootloader "Shim". Dieser prüft die Integrität des eigentlichen Linux-Bootloaders. Die standardkonforme Vertrauenskette endet somit faktisch beim Shim.

Zur Statusermittlung unter Linux dient der mokutil-Befehl. Auf einigen Plattformen lassen sich Aktualisierungen mit "fwupdmgr" vornehmen [6]. Für den ESXi-Hypervisor steht eine finale Vorgehensweise noch aus; Broadcom empfiehlt derzeit, Anweisungen der Hardwareproduzenten abzuwarten.

Testen des Zertifikat-Rollouts

Trotz automatisierter Rollouts ist eine Überwachung der Ergebnisse wichtig, um vor Ablauf der 2011er PKI manuell eingreifen zu können. Wenn ein Endpoint-Managementsystem Registrierungswerte erfasst, sind folgende Pfade unter "HKLM \ SYSTEM \ CurrentControlSet \ Control \ SecureBoot" relevant [3]:

- State\UEFISecureBootEnabled (0 oder 1)

- Servicing\WindowsUEFICA2023Capable (0, 1 oder 2)

- Servicing\UEFICA2023Status ("NotStarted”, "InProgress” oder "Updated”)

- Servicing\UEFICA2023Error (nur bei Fehlern vorhanden)

Zur Untersuchung einzelner Geräte dient das Get-SecureBootUEFI-Cmdlet. Da es Variablen in Rohform ausgibt, sind Skripte zur Dekodierung der Byte-Arrays in Image-Hashes oder X509-Zertifikate notwendig [7]. Eine Sammlung von Skripten des Nutzers "cjee21" fasst diese Ergebnisse lesbar zusammen [8]. Diese Werkzeuge können nach Prüfung als Basis für eigene Automatisierungen dienen.

VM-Zertifikate aktualisieren

Die Virtualisierung verlagert die Zertifikatsaktualisierung von der Hardware in die Software, erfordert jedoch oft Downtime. Damit das Update gelingt, muss die virtuelle Infrastruktur aktuell sein. Dies umfasst den Hypervisor und die Version der virtuellen Hardware jeder VM. Bei Hyper-V-Hosts unter Windows Server 2025 funktioniert das Update in Windows-VMs meist automatisch. Bei VMs mit anderen Gast-Betriebssystemen aktualisieren sich die Zertifikate in der VM-Firmware nicht selbstständig. Hier müssen Sie die VM herunterfahren und in den Einstellungen die ausgewählte CA für Secure Boot ändern, speichern und anschließend wieder zurücksetzen. Dieser Vorgang wirkt auf das Gastsystem wie ein Firmware-Update. Bei älteren Hostversionen wird das Einspielen des 2023er KEK derzeit oft mit der Fehlermeldung "Zugriff verweigert" (Event-ID 1795) abgelehnt [9].

Bei VMware enthalten neu angelegte VMs ab Hardwareversion 13 die 2023er Zertifikate, sofern die ESXi-Hosts mindestens Stand 8.0.2 aufweisen. Ältere VMs behalten die bisherige Konfiguration. Ein manuelles Löschen der nvram-Datei ist riskant, da dabei alle UEFI-Variablen verloren gehen. Da der Platform Key der UEFI-Firmware in vielen VMware-Konstellationen ungültig ist, schlägt die Aktualisierung des KEK oft fehl, was wiederum Updates der DB und DBX verhindert. Die Anleitung von Broad- com für ESXi erfordert Downtime und mehrere Neustarts [10].

Fazit

Die ursprüngliche Microsoft-PKI für Secure Boot läuft nach 15 Jahren aus. Wenn für Anfang 2027 ohnehin ein Hardware-Refresh geplant ist, können Sie das Thema vernachlässigen, da Neugeräte die 2023er Zertifikate bereits mitbringen. Für den sicheren Weiterbetrieb bestehender Systeme sollten IT-Teams Firmware-Updates unter Beachtung von BitLocker durchführen und die Windows-eigenen Updatefunktionen nutzen. Bei virtuellen Maschinen müssen Hypervisor und Hardwareversion auf den aktuellen Stand gebracht werden. Eine Sperrung der 2011er Zertifikate sollte erst erfolgen, wenn sichergestellt ist, dass alle Preboot-Komponenten bereits über neue Signaturen verfügen.

Ablauf der Microsoft-Zertifikate für Secure Boot