MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

UEFI-Boot Kurzfassung

Auf der Seite UEFI Secure Boot/BlackLotus/PKFail habe ich umfangreich die Zusammenhänge und Vorgehensweisen erklärt..

Mittlerweile hat Microsoft aber mit Eventlogs und Registrierungsschlüsseln nachgebessert und diese Informationen wollte ich nicht in die große Seite einbauen, wo wir doch alle so wenig Zeit zum Lesen haben.

Worum geht es? (vereinfacht)

Damit Betriebssysteme nicht schon vor dem Boot und damit der Aktivierung von Schutzprogrammen kompromittiert werden, hat Microsoft schon vor vielen Jahren das "Secure Boot"-Konzept aufgesetzt. Dabei sind alle Komponenten digital signiert und das UEFI-Bios prüft beim Start sich selbst, aber auch weitere beim Startprozess aktive Firmware, z.B. PXE-Boot, Raid-Controller, Grafikkarten etc., dass diese nicht verändert wurden. Zudem Zeitpunkt hat der Computer natürlich noch kein "Internet" und kann z.B. nicht prüfen, ob Zertifikate noch gültig sind. Daher gibt es folgende Bausteine:

  • DB im UEFI-Speicher
    In der DB liegen Zertifikate, mit denen Programme signiert werden können, z.B. von Microsoft aber auch anderen Herstellern.
  • DBX im UEFI-Speicher
    Hier landen die Hashwerte von zurückgezogenen Komponenten, weil diese z.B. nachweislich kompromittiert wurden.
  • KEK-Schlüssel  im UEFI-Speicher
    Die Einträge in der DB/DBX-Tabelle müssen aktualisiert werden. Damit das nicht jede Malware auf dem Computer kann, müssen diese Updates durch einen KEK-Schlüssel signiert sein. Den hat z.B. Microsoft und dieses Zertifikat ist natürlich auch wieder signiert worden.
  • PK-Schlüssel in der Computer-Firmware
    Der Plattform-Key wird vom Hersteller des Computers (Lenovo, Dell, HP, etc.) oder des BIOS, z.B. AMI. über ein Firmware Update bereitgestellt. Das ist quasi das Root-Zertifikat.

Auf den meisten Computern, die ein UEFI-Bios nach 2011 haben, sollte im KEK-Speicher ein Zertifikate mit dem Namen "Microsoft Corporation KEK CA 2011" liegen, welches mit 15 Jahren Gültigkeit im Juni 2026 ausläuft. Daher hat Microsoft schon im Jahr 2023 ein neues KEK-Zertifikat erstellt und von den Herstellern mit deren Plattform-Key signieren lassen. Allerdings gibt es auch einige Plattform-Keys, die bald ablaufen. Das ist aber ein Problem der Hersteller.

Zwei weitere Probleme werden gerne übersehen. Eine Microsoft UEFI-Zertifikat wurde im Jahr 2023 kompromittiert und sollte schon lange zurückgezogen werden und Kunden der Firma AMI haben wohl ein "Test-PK-Key" auf produktive Maschinen installiert, dessen Geheimnis auch nicht geheim ist. Ein Firmware-Update stopft diese Lücke, sofern der Hersteller dies bereitstellt.

Die Aufgabe ist nun also, dass alle Computer durch ein Microsoft Update zuerst einen neuen KEK-Schlüssel bekommen müssen, mit dem dann über ein damit signiertes DB/DBX-Update die Einträge in diesen Datenbanken aktualisiert werden und erst dann ein Update des Windows Bootloader durch einen Version ersetzt der mit den neuen Schlüsseln signiert wurde.

Wenn Sie ihr System nicht aktualisieren, dann wird es aber auch nach Ablauf der Zertifikate weiter booten. Allerdings kann Windows Updates dann keine neuen Bootloader installieren, da dieser nicht mehr durch die dann abgelaufenen Zertifikate signiert werden kann. Da zu der Zeit der Computer keinerlei Verbindung zum Internet hat, kann er sich nur auf die Zertifikatsketten verlassen, die im Bios und UEFI-Speicher hinterlegt sind.

Windows Updateprozess

Microsoft hat im Januar 2026 damit angefangen, die neuen Zertifikate über Windows Updates auf die Computer zu verteilen. Sie sollten auf ihrem Computer im Ordner "C:\Windows\system32\SecureBootUpdates" ein paar Dateien finden:

Sie werden aber nicht sofort installiert, denn es kann dabei ja auch etwas schief gehen und Voraussetzungen müssen erfüllt sein. Daher scheint Microsoft erst langsam ein paar Computer in der Welt zu aktualisieren und sammelt über die Windows Telemetrie die Ergebnisse ein. Entsprechend werden dann weitere Computer mit Updates versorgt. Nach meinen Wissen (Stand März 26) müssen dazu zwei Bedingungen erfüllt sein:

  • Windows 11 Clients
  • mit aktivierter Telemetrie

Im Umkehrschluss bedeutet dies, dass die Updates nicht automatische installiert werden, wenn Sie:

  • Telemetrie abgeschaltet haben
    Was aber nicht ganz stimmt. Im Update-Paket gibt es eine "BucketConfidenceData.cab", in der wohl Systeme aufgeführt werde, die problemlos aktualisiert werden können.
  • Windows 10 Clients
    Die bekommen schon länger keine Updates mehr und ich habe noch nicht geschaut, wie es Windows 100 Clients mit ESU-Support handhaben.
  • Windows Server
    Hier wird Microsoft wohl den Administrator in die Pflicht nehmen, die Updates zu begleiten.
  • Virtuelle Maschinen
    Ein klassisches "Firmware-Update" würde hier nicht funktionieren, da das alle virtuell ist.
  • Linux-Systeme
    Da gibt es kein Windows Update aber ich habe schon gesehen, dass einige Distributionen sich auch darum kümmern.

Status erkennen

Sie sollten also zuerst prüfen, ob ihre Server und Clients schon "aktuell" sind. Auf UEFI Secure Boot/BlackLotus/PKFail habe ich ein paar Skripte bereitgelegt, die als Administrator die Speicher aus dem UEFI-Bios auslesen und prüfen. Das war aber noch Stand Sommer 2023 und 2025. Im Update vom 11. Nov 2025 (KB5068202) erledigt Microsoft dies über Meldungen im Eventlog und Registrierungsschlüssel. Hier ist insbesondere der folgende Ort interessant:

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing

Der Wert von "UEFICA2023Status" zeigt den aktuellen Stand an. Dieser PC hier ist wohl schon komplett aktualisiert. Auf einem Lenovo Thinkpad Yoga (2013) mit Windows 10 aus dem Jahre 2017 habe ich nach Aktivierung von ESU über ein Microsoft Konto, folgende Einträge gesehen:

Ich bin mal gespannt, ob der noch ein Update bekommt. Der Wert in "UEFICA2023Status" kann einen von drei Werten annehmen:

Bedeutung von UEFICA2023Status:
NotStarted: Das Update wurde noch nicht gestartet
InProgress: Das Update wird aktuell durchgeführt. Es kann einige Neustarts bedeuten
Updated   : Die Aktualisierung ist erfolgreich gewesen.

Wenn das Update auf einen Fehler läuft dann gibt es einen Code im Schlüssel "UEFICA2023Error". Weitere Felder sind:

Bedeutung von WindowsUEFICA2023Capable:
0 oder fehlt: Das “Windows UEFI CA 2023” Zertifikat ist nicht in der DB
1           : Das “Windows UEFI CA 2023” Zertifikat ist in der DB
2           : Das “Windows UEFI CA 2023” Zertifikat ist in der DB und der Bootmanager ist damit signiert​​​​​​​

Damit wissen Sie nun, wie Sie mit einer Inventarsoftware auf ihren Clients und Servern den aktuellen Status abfragen können. Das dürfte für die meisten Firmen viel einfacher sein, als eine Suche im Eventlog.

Wer natürlich heute schon seine Eventlogs z.B. in ein zentrales Logging führt, kann auch dort nachschauen:

Eventlog: System
Source  : TPM-WMI
EventID : 1799  
Level   : Information
Text    : Boot Manager signed with Windows UEFI CA 2023 was installed successfully 

Es gibt natürlich noch viele weitere EventIDs, die den Fortschritt der Installation begleiten und Fehler melden. Microsoft hat die alle in einem Artikel beschrieben.

Update mit "AvailableUpdates" antriggern (einmalig)

Normalerweise bekommt ihr PC die Updates über Windows Update alleine aber sie können das Update auch manuell anstoßen. Allerdings brauchen Sie dazu natürlich Berechtigungen und für einige Aktionen ist auch "LocalAdmin" nicht ausreichend. Microsoft hat daher einen "geplanten Task" auf ihrem Computer installiert, der alle 12 Stunden gestartet wird und Updates einspielt. Dieser Task wertet einen Registrierungsschlüssel aus, welcher über verschiedene Bits den aktuellen Prozess steuern. Sie setzen einfach den Schlüssel z.B. durch Import der REG-Datei:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot]
"AvailableUpdates"=dword:00005944

Das geht natürlich auch per PowerShell.

Set-ItemProperty `
   -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" `
   -Name "AvailableUpdates" `
   -Value 0x00005944

Die Aktualisierung wird beim Neustart oder alle 12 Stunden durch einen geplanten Task ausgeführt:

Es kann also etwas dauern, bis der Wert die folgenden Stationen durchläuft und das zur Aktion zugeordnete Bit gelöscht wird:

Start: 0x5944
0x0040 → 0x5904 (Applied the Windows UEFI CA 2023 successfully)
0x0800 → 0x5104 (Applied the Microsoft Option ROM UEFI CA 2023 if needed)
0x1000 → 0x4104 (Applied the Microsoft UEFI CA 2023 if needed)
0x0004 → 0x4100 (Applied the Microsoft Corporation KEK 2K CA 2023)
0x0100 → 0x4000 (Applied the Windows UEFI CA 2023 signed boot manager)

Wenn bei ihnen andere Werte stehen, dann sollten Sie im Eventlog sehr schnell die Ursache finden. Bei mir was z.B.: 0x00005800" der Fehler, wenn meine Test-VM nicht mit SecureBoot konfiguriert war.

Am Ende sind alle Schritte durchgeführt worden und der Wert landet bei 0x4000.

Gruppenrichtlinie mit AvailableUpdatesPolicy

Neben dem Schlüssel "AvailableUpdates" gibt es noch "AvailableUpdatesPolicy". Dieser Schlüssel sollte laut Microsoft nicht per REGEDIT oder PowerShell gesetzt werden:

For reference only – do not update this key through the registry. This key is used by Group Policy and Intune to communicate Secure Boot related actions to Windows. It represents the policy set by Intune or Group Policy.
Quelle: https://support.Microsoft.com/en-us/topic/registry-key-updates-for-secure-boot-windows-devices-with-it-managed-updates-a7be69c9-4634-42e1-9ca1-df06f43f360d

Damit können Sie aber per Gruppenrichtlinie die Einstellung vorgeben, die dann ebenfalls angewendet wird. Allerdings wird der Wert dann nicht wieder zurückgesetzt.

Weitere Links