Secure Boot Zertifikate: Was sind DB, DBX, KEK und PK?

Secure Boot · Zertifikate · Windows Update

Secure Boot Zertifikate: Was sind DB, DBX, KEK und PK?

Alle fünf Microsoft-Dateien aus dem Secure Boot Update erklärt — Zweck, Inhalt und warum sie bis Juni 2026 eingespielt sein müssen.

📅 April 2026  ·  ⏱ 8 Min. Lesezeit  ·  IT-Service Walter

Mit dem kumulativen Update vom März 2026 (KB5053606) stößt Microsoft den lang angekündigten Wechsel der Secure Boot-Zertifikate an. Fünf separate Binärdateien spielen dabei verschiedene Rollen — doch was steckt konkret in DBUpdate2024.bin, DBXUpdate2024.bin, DBXUpdateSVN.bin, DBUpdate3P2023.bin und DBUpdateOROM2023.bin? Dieser Artikel erklärt jede Datei im Detail.

⚠ Deadline: 27. Juni 2026
Systeme ohne die neuen 2023-Zertifikate können nach diesem Datum keine Secure Boot-Sicherheitsupdates mehr empfangen und bleiben anfällig für Boot-Level-Angriffe wie BlackLotus.

Grundlagen: Die Secure Boot-Hierarchie

Secure Boot ist ein UEFI-Sicherheitsmechanismus der verhindert, dass nicht autorisierte oder kompromittierte Bootloader beim Systemstart ausgeführt werden. Die Grundlage bilden vier UEFI-Variablen die in einem klaren Vertrauenshierarchie-Modell organisiert sind:

PK — Platform Key
KEK — Key Enrollment Key
db — Signature Database
dbx — Forbidden Signatures

Jede Ebene wird von der darüberliegenden signiert und autorisiert

Variable Vollname Ausgestellt von Zweck
PK Platform Key Gerätehersteller (OEM) Oberste Vertrauensebene. Signiert den KEK.
KEK Key Enrollment Key Microsoft Corporation Autorisiert Änderungen an db und dbx.
db Signature Database Microsoft / OEM Liste vertrauenswürdiger Zertifikate. Bootloader müssen hier gelistet sein.
dbx Forbidden Signatures Microsoft Sperrliste. Bootloader hier sind verboten — auch mit gültiger Signatur.

Die fünf Update-Dateien im Detail

Das GitHub-Repository microsoft/secureboot_objects liefert im Release v1.6.4-signed fünf signierte Binärdateien — drei für die db-Variable (vertrauenswürdige Zertifikate hinzufügen) und zwei für die dbx-Variable (Revocation List erweitern).

db

DBUpdate2024.bin

≈ 4,8 KB

UEFI-Variable
db (Signature Database)
Priorität
🔴 Kritisch — das Hauptzertifikat

Was ist enthalten?

Diese Datei fügt das Windows UEFI CA 2023-Zertifikat zur vertrauenswürdigen Signature Database (db) hinzu. Das ist das zentrale neue Zertifikat das alle Windows-Bootloader ab 2023 signiert.

Enthaltenes Zertifikat:
CN=Windows UEFI CA 2023, O=Microsoft Corporation, C=US
Aussteller: Microsoft Root Certificate Authority 2010
Ablauf: 2035 (gültig bis weit nach der Deadline)

Warum ist diese Datei entscheidend?

Ohne dieses Zertifikat in der db-Variable kann ein System keine Bootloader mehr starten die mit der neuen CA 2023 signiert sind. Nach dem Ablauf der alten Production PCA 2011 im Herbst 2026 wäre das System nicht mehr bootfähig mit aktuellen Windows-Versionen.

db

DBUpdate3P2023.bin

≈ 4,8 KB

UEFI-Variable
db (Signature Database)
Priorität
🟡 Hoch — Drittanbieter-Bootloader

Was ist enthalten?

Das 3rd Party UEFI CA 2023-Zertifikat von Microsoft. Dieses Zertifikat ist für Drittanbieter-Bootloader zuständig — z.B. Linux-Distributionen (Ubuntu, RHEL, Debian), Shim-Bootloader und andere nicht-Microsoft UEFI-Anwendungen.

Enthaltenes Zertifikat:
CN=Microsoft UEFI CA 2023, O=Microsoft Corporation, C=US
Signiert Bootloader von Drittanbietern (Linux, alternative OS)

Für wen relevant?

Besonders wichtig für Dual-Boot-Systeme und Unternehmensumgebungen mit Linux-VMs oder alternativen Betriebssystemen. Ohne diese Datei können nach dem Zertifikatswechsel bestimmte Linux-Distributionen auf Systemen mit aktivem Secure Boot nicht mehr booten.

db

DBUpdateOROM2023.bin

≈ 4,8 KB

UEFI-Variable
db (Signature Database)
Priorität
🔵 Mittel — Hardware-ROMs

Was ist OROM und warum gibt es diese Datei?

OROM steht für Option ROM — das sind kleine Firmware-Programme die auf Erweiterungskarten wie Grafikkarten, RAID-Controllern und Netzwerkkarten gespeichert sind und beim UEFI-Start geladen werden. Mit aktivem Secure Boot müssen auch diese ROMs signiert und in der db-Variable vertrauenswürdig sein.

Enthaltenes Zertifikat:
CN=Microsoft Option ROM UEFI CA 2023
Signiert Option ROMs für PCIe-Geräte (Grafik, NIC, RAID)

Praktische Bedeutung

Für Desktop-Systeme und Server mit Erweiterungskarten. Ohne dieses Zertifikat könnten nach dem Zertifikatswechsel bestimmte PXE-Boot-Adapter (Netzwerk-Boot), RAID-Controller oder ältere GPU-ROMs beim Start blockiert werden.

⬇ Ab hier: DBX-Dateien — Sperrliste (Revocation List)
Die folgenden Dateien enthalten keine neuen Zertifikate, sondern widerrufen kompromittierte Bootloader-Versionen

dbx

DBXUpdate2024.bin

≈ 5,0 KB

UEFI-Variable
dbx (Forbidden Signature Database)
Priorität
🔴 Kritisch — Sicherheitsrelevant

Was wird gesperrt?

Diese Datei sperrt das Windows Production PCA 2011-Zertifikat in der dbx-Sperrliste. Das ist das Zertifikat das bisher alle Windows-Bootloader signiert hat — und das ab Herbst 2026 ausläuft.

Gesperrtes Element:
CN=Microsoft Windows Production PCA 2011
Fingerabdruck: 580A6F4CC4E4B669B9EBDC1B2B3E087B80D0678D
⚠ Wird nach dem Zertifikatswechsel aus der db entfernt und in die dbx übertragen

Warum wird das alte Zertifikat gesperrt?

Durch das Sperren des alten Zertifikats wird verhindert, dass Angreifer ältere, kompromittierte Windows-Bootloader nutzen — selbst wenn diese mit dem (noch gültigen) Production PCA 2011 signiert sind. Das ist die technische Umsetzung der BlackLotus-Gegenmaßnahme.

Zusammen mit DBUpdate2024.bin: Das System vertraut ab dem Update nur noch Bootloadern mit der neuen CA 2023-Signatur (db) und blockiert aktiv alle alten PCA-2011-signierten Bootloader (dbx). Das schließt bekannte Angriffsvektoren.

dbx

DBXUpdateSVN.bin

≈ 3,5 KB

UEFI-Variable
dbx (Forbidden Signature Database)
Priorität
🟡 Hoch — Versionskontrolle

Was sind Security Version Numbers (SVN)?

SVN (Security Version Numbers) sind ein Mechanismus der verhindert, dass ältere, bekannt verwundbare Versionen des Windows Boot Managers gestartet werden — selbst wenn diese korrekt signiert sind.

Statt einzelner Hash-Werte kompromittierter Binärdateien (die Liste würde endlos wachsen) definiert SVN eine Mindest-Versionsnummer. Jeder Boot Manager der eine niedrigere SVN hat, wird von der UEFI-Firmware blockiert.

Enthaltene SVN-Einträge:
bootmgfw.efi: major_svn=7 (ersetzt major_svn=2)
bootmgr.efi: major_svn=3 (ersetzt major_svn=2)
Boot Manager-Versionen unterhalb dieser Werte werden blockiert

Warum ist das wichtiger als Hash-Sperren?

Hash-basierte Sperren (wie in DBXUpdate2024.bin) müssen für jede einzelne kompromittierte Datei separat eingetragen werden. SVN-Sperren blockieren automatisch alle Versionen unterhalb der Mindestanforderung — damit werden auch zukünftige Exploits gegen alte Versionen verhindert, ohne dass ein neues DBX-Update nötig wäre.

Schnellübersicht: Alle fünf Dateien

Datei Variable Aktion Ohne diese Datei
DBUpdate2024.bin db Windows UEFI CA 2023 hinzufügen Neue Windows-Bootloader nicht vertrauenswürdig
DBUpdate3P2023.bin db 3rd Party UEFI CA 2023 hinzufügen Linux / Drittanbieter-Bootloader blockiert
DBUpdateOROM2023.bin db Option ROM CA 2023 hinzufügen PCIe-Option-ROMs möglicherweise blockiert
DBXUpdate2024.bin dbx Production PCA 2011 sperren Alte kompromittierte Bootloader weiter bootbar
DBXUpdateSVN.bin dbx SVN-Mindestversion erhöhen Verwundbare Boot-Manager-Versionen nicht geblockt

Download: Wo die Dateien beziehen

Die Dateien sind ausschließlich im offiziellen Microsoft GitHub-Repository verfügbar:

📦 microsoft/secureboot_objects
https://github.com/microsoft/secureboot_objects/releases/tag/v1.6.4-signed
Aktuelles Release: v1.6.4-signed (März 2026) — signiert mit Microsoft Corporation KEK CA 2011

PowerShell-Download (TLS 1.2 erforderlich):

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
$base  = "https://github.com/microsoft/secureboot_objects/releases/download/v1.6.4-signed"
$sbbin = "C:\Tools\SBBIN"

# amd64 (x64 Systeme)
Invoke-WebRequest "$base/dbxupdate_x64.bin" -OutFile "$sbbin\amd64\DBXUpdate2024.bin" -UseBasicParsing
# (Alle fünf Dateien je Architektur aus dem Release herunterladen)

✓ Fazit: Warum alle fünf Dateien wichtig sind

Die drei DB-Dateien fügen neue Vertrauensanker hinzu — ohne sie kennt die UEFI-Firmware die neuen 2023-Zertifikate nicht. Die zwei DBX-Dateien schließen gleichzeitig bekannte Sicherheitslücken — sie sperren kompromittierte Bootloader und erhöhen die Mindest-SVN. Erst der Einsatz aller fünf Dateien zusammen schließt den Sicherheitskreis vollständig.

ISW Secure Boot Analyzer
Prüfen Sie den Secure Boot-Status aller Windows-Systeme in Ihrer Domäne — inklusive automatischem Offline-Update aller fünf Dateien.
Mehr erfahren → isw-adtools.de

© 2026 IT-Service Walter · isw-adtools.de · Dieser Artikel gibt den Stand April 2026 wieder.