Secure Boot ist seit 2011 Teil des PC-Ökosystems, aber 2023–2025 rückte es schließlich ins Rampenlicht, und zwar nicht in einer Weise, die sich Microsoft, OEMs oder Firmware-Anbieter gewünscht hätten. Was einst ein stiller Sicherheitsbeitrag hinter den Kulissen war, wurde plötzlich zu einer Titelgeschichte. Tatsächlich wurden bei der Einführung des CA-2023-Zertifikats seit langem bestehende Inkonsistenzen bei der Firmware-Implementierung, der Zertifikatsverarbeitung und den Update-Pipelines in der gesamten PC-Branche aufgedeckt. Um es kurz und brutal zu fassen: Es war weder schön noch lustig.
Für Windows-Benutzer war das Ergebnis eine verwirrende Mischung beunruhigender Dinge. Dazu gehörten Boot-Warnungen, defekte Boot-Ketten und inkonsistente oder inkohärente Herstelleranweisungen. Die vorherrschende allgemeine Meinung war, dass Secure Boot, das eingeführt wurde, um Vertrauen und Zuverlässigkeit zu erhöhen, stattdessen zu einer Quelle der Unsicherheit und Verwirrung geworden war.
In diesem Artikel erfahren Sie, was Secure Boot ist, wie es funktioniert, warum CA-2023 wichtig ist, wie Anbieter ins Stolpern geraten sind und was Benutzer tun können, wenn Secure Boot-Updates fehlschlagen. Unterwegs erkläre ich jedes Akronym, gehe Schritt für Schritt durch die Vertrauenskette und biete praktische Anleitungen an, die auf der Fehlerbehebung in der Praxis basieren. Ich habe gerade eine anstrengende, wenn nicht sogar epische Reise hinter mir, um meine kleine PC-Flotte (Größe zwischen 10 und 15) vollständig sicher und bootfähig zu machen und mit den CA 2023-Bootzertifikaten zu betreiben. Es war eine ziemliche Reise und ich habe mehr gelernt, als ich jemals wissen wollte.
Was ist Secure Boot und warum ist es wichtig?
Secure Boot ist eine Funktion, die durch das Unified Extensible Firmware Interface (UEFI) definiert wird, Intels modernen Ersatz für das Legacy-BIOS. Sein Zweck besteht darin, sicherzustellen, dass beim Systemstart nur vertrauenswürdige, signierte Bootloader und Betriebssystemkomponenten ausgeführt werden können.
Um dies zu erreichen, stützt sich Secure Boot auf einen Satz kryptografischer Schlüssel, die in der Firmware gespeichert sind. Diese Schlüssel definieren, was vertrauenswürdig ist, was erlaubt ist und was ausdrücklich verboten ist.
Hier sind die Schlüsselkomponenten:
Plattformschlüssel (PK)
Der Plattformschlüssel legt den Systembesitzer fest. Wer auch immer die PK kontrolliert, kontrolliert die Secure Boot-Konfiguration. Typischerweise installieren OEMs ihr eigenes PK im Werk.
Schlüsselaustauschschlüssel (KEK)
Der Key Exchange Key autorisiert Aktualisierungen der Secure Boot-Datenbanken. Microsoft, OEMs und manchmal auch Unternehmensadministratoren verwalten KEKs. Ein gültiger KEK ist ein Ticket, das es einem Dritten ermöglicht, Aktualisierungen auf in UEFI verwaltete Zertifikate und Datenbanken anzuwenden.
Zulässige Signaturdatenbank (DB)
Diese Datenbank enthält Hashes und Zertifikate für vertrauenswürdige Bootloader und Betriebssystemkomponenten. Wenn etwas eine in der Datenbank vorhandene Signatur aufruft, lässt die Firmware die Ausführung zu.
Datenbank für verbotene Signaturen (DBX)
Dies ist die „Widerrufsliste“. Alles im DBX wird explizit blockiert – auch wenn es einmal vertrauenswürdig war. Mit DBX-Updates entzieht die Branche kompromittierte Bootloader. Mit dem ursprünglichen CA-2011 wurde die ganze Secure-Boot-Sache ins Leben gerufen; MS plant, dies später im Jahr 2026 zu widerrufen. CA-2023 wird es ersetzen und wird langsam aber sicher über Windows Update und OEM-UEFI-Updates eingeführt.
Warum ist Secure Boot wichtig?
Secure Boot wurde entwickelt, um Rootkits, Bootkits und andere Pre-OS-Malware zu stoppen. Wenn es Angreifern gelingt, die Boot-Kette zu kompromittieren, können sie sich vor dem Betriebssystem verstecken, der Erkennung entgehen und auf unbestimmte Zeit bestehen bleiben. Sie werden immer wieder zurückkommen, weil sie außerhalb und unabhängig vom Betriebssystem arbeiten. Secure Boot macht solchen Spielereien ein Ende.
Theoretisch ist Secure Boot eine saubere, elegante Lösung. In der Praxis ist das Secure Boot-Ökosystem chaotisch, fragmentiert und voller Grenzfälle.
Secure Boot ist jedoch wichtiger und binärer denn je. Das Positive daran ist, dass es gut funktioniert, wenn es funktioniert. Der Nachteil besteht darin, dass auftretende Probleme herausfordernd, nervig und zeitaufwändig sein können.
Der Secure Boot-Kompromiss, der CA-2023 auslöste
Anfang 2023 kündigte Microsoft ein großes Sicherheitsproblem an, bei dem ältere Windows-Boot-Manager-Binärdateien auf eine Weise kompromittiert wurden, die eine Umgehung von Secure Boot ermöglichen könnte. Um dies zu mildern, hat das Unternehmen ein neues DBX-Update namens CA-2023-Widerruf herausgegeben. Durch dieses Update wurden anfällige Bootloader zur Verbotsliste hinzugefügt und ein neuer, signierter Bootloader mit einem passenden Zertifikat bereitgestellt, der gegen solche Angriffe und Probleme immun war.
Warum war das notwendig?
Angreifer hatten Möglichkeiten entdeckt, ältere Bootloader auszunutzen, um den Secure Boot-Schutz zu deaktivieren. Der Widerruf dieser Binärdateien erwies sich als wesentlich für die Aufrechterhaltung der Integrität des Ökosystems.
Warum hat das die Systeme kaputt gemacht?
Viele OEMs hatten:
- veraltete Firmware
- Inkonsistente DB/DBX-Verarbeitung
- Defekte Update-Pipelines
- Nicht standardmäßige Secure Boot-Implementierungen
- unvollständige oder falsche Schlüsselsätze
- Firmware, die DBX-Updates stillschweigend ignorierte
- Firmware, die Systeme blockierte, als DBX-Updates angewendet wurden
Mit anderen Worten: Durch den Widerruf wurden jahrelange technische Schulden offengelegt. In vielen Fällen reichte der Versuch einer Aktualisierung aus, um Auswirkungen auf den PC zu haben. Im besten Fall können betroffene PCs möglicherweise nicht neu gestartet werden (Warmstart über die Auswahl „Ein/Aus“ > „Neustart“ im Startmenü). Im schlimmsten Fall können betroffene PCs nach dem Einschalten möglicherweise nicht booten oder gar nicht auf UEFI zugreifen. Schlechte Nachrichten!
Ergebnisse nach CA-2023
Millionen von Systemen landeten in einem dieser Staaten:
- Secure Boot ist aktiviert, erzwingt jedoch keine Widerrufe
- Secure Boot deaktiviert, da Aktualisierungen fehlgeschlagen sind
- Secure Boot bleibt im „Benutzermodus“ mit nicht übereinstimmenden Schlüsseln hängen
- Systeme können nach DBX-Updates nicht gestartet werden
- Firmware, die sich weigerte, das CA-2023-Update überhaupt anzuwenden
Dies war kein reines Microsoft-Problem. Es war ein ökosystemweites Versagen. Offensichtlich wurde Secure Boot dadurch zu einer Qual für Benutzer mit Systemen, die eines oder mehrere dieser Probleme aufwiesen. Einer meiner ASRock B550 Extreme4-basierten Ryzen 5-PCs wies die meisten, wenn nicht sogar alle dieser Mängel auf. Schließlich musste ich das Motherboard austauschen, um an ihnen vorbeizukommen.
Wie funktioniert die „Secure Boot Chain“?
Um zu verstehen, warum CA-2023 so viel Ärger verursacht hat, hilft es, die Vertrauenskette Schritt für Schritt durchzugehen.
Schritt 1: Firmware validiert den PK
Wenn der PK gültig ist, weiß das System, wem die Plattform „besitzt“.
Schritt 2: Firmware validiert KEKs
Diese Schlüssel autorisieren Aktualisierungen von DB und DBX.
Schritt 3: Firmware lädt DB und DBX
Diese legen fest, was erlaubt und was verboten ist.
Schritt 4: Firmware validiert den Bootloader
Wenn die Signatur des Bootloaders mit einem Eintrag in DB übereinstimmt und nicht in DBX vorhanden ist, wird er ausgeführt.
Schritt 5: Der Bootloader validiert Betriebssystemkomponenten
Der Windows-Boot-Manager überprüft Signaturen auf winload.efi, Treibern und anderen Early-Boot-Komponenten.
Schritt 6: Das Betriebssystem startet mit intaktem Vertrauen
Wenn alles funktioniert, wird Windows normal geladen.
Leider bieten viele Stufen reichlich Gelegenheit, dass die Dinge schiefgehen. Das macht diesen Ansatz etwas fragil und gelegentlich anfällig für Blockaden oder völlige Misserfolge. Wenn einer der folgenden Fälle auftritt, können Dinge kaputt gehen oder ausfallen:
- DB fehlt eine erforderliche Signatur
- KEKs sind veraltet
- PK ist falsch
- Firmware führt Aktualisierungen falsch aus
- Bootloader stimmen nicht überein (Windows verwaltet eine separate Kopie in der C:\Windows-Ordnerhierarchie, während eine andere Instanz von der EFI-Partition verwendet wird)
Wenn ein solches Element angezeigt wird, schlägt Secure Boot möglicherweise fehl oder fällt zurück. Es könnte auch stillschweigend versäumen, sein Sicherheitsregime durchzusetzen. So befand ich mich beispielsweise in einer Situation, in der bei jedem Start eine Meldung angezeigt wurde, die (fälschlicherweise) eine „CPU-Änderung“ meldete und dazu aufforderte, die aktuellen TPM-Sicherheitseinstellungen zu bestätigen oder auf die vorherigen TPM-Sicherheitseinstellungen zurückzusetzen. So sah das aus:
Es ist eine bekannte Eigenart des ASRock B550 Extreme4 UEFI, dass es einen Prozessorwechsel meldet, selbst wenn Secure Boot-Änderungen oder -Updates vorgenommen werden. Tatsächlich musste ich etwa zwei Wochen lang jedes Mal, wenn ich mein System neu startete, auf diesem Bildschirm „N“ eingeben, um zum Windows-Desktop zu gelangen. Dadurch dauerte jeder Neustart mindestens 2-3 Minuten und störte mich unendlich.
Häufige Secure Boot-Probleme bei verschiedenen Motherboard-Anbietern
Bei der Einführung von CA-2023 wurde deutlich, dass die Firmware-Disziplin verschiedener Anbieter völlig unterschiedlich ausfiel. Einige Desktop- und Laptop-PCs liefen ohne Probleme durch; andere erlebten alles von kleinen Rückschlägen über größere Probleme bis hin zu nicht mehr bootfähigen Systemen. Werfen wir einen Blick darauf, wie sich verschiedene Anbieter in dieser Situation geschlagen haben.
ASUS
Einige ASUS-Mainboards weigerten sich, DBX-Updates anzuwenden, es sei denn, Secure Boot wurde vorübergehend deaktiviert – eine paradoxe Anforderung. Andere führten Aktualisierungen durch, beließen die Systeme jedoch im Zustand „halb widerrufen“. Das CA-2011-Zertifikat könnte auch dann noch verwendet werden (oder nicht), wenn das CA-2023-Zertifikat vorhanden wäre.
MSI
- Einige (aber nicht alle) MSI-Boards waren berüchtigt für:
- Inkonsistente DBX-Verarbeitung
- Firmware, die Updates stillschweigend ignorierte
- Secure Boot-Modi, die nicht mit den UI-Bezeichnungen übereinstimmten
- Systeme, die unerwartet auf die Werksschlüssel zurückgesetzt wurden
ASRock
ASRock-Boards erforderten oft manuelle Eingriffe für folgende Dinge:
- Löschschlüssel
- Neuinstallation der Werkseinstellungen
- Microsoft-Schlüssel erneut registrieren
- Manuelles Anwenden von DBX-Updates
Ihre Dokumentation war spärlich und viele Benutzer blieben im Unklaren. In meinem Fall hatte ich zwei angeblich identische Motherboards, beide B550 Extreme4-Modelle. Einer von ihnen übergab sich dem Handbuch, und Microsoft WU lieferte Updates. Der andere konnte die ausstehenden Aktualisierungen des Betriebssystems (sowohl WU als auch manuell durchgeführte) nie mit den Inhalten der verschiedenen Firmware-Datenbanken in Einklang bringen. Dies war in der Tat der Auslöser der fortlaufenden Serie von „CPU-Änderungs“-Warnungen, die im vorherigen Abschnitt dieser Geschichte beschrieben wurden.
Dell, HP, Lenovo (und andere OEMs…)
Unternehmens- und verbraucherorientierte PC- und Laptop-Anbieter (darunter auch Acer, ASUS, Dynabook usw.) schnitten im Allgemeinen besser ab, aber selbst sie hatten:
- gestaffelte Rollouts
- Inkonsistentes BIOS/UEFI-Update-Timing
- Einige Systeme erforderten mehrere Neustarts, um DBX-Änderungen anzuwenden
Als ich mir die gelesenen Forenbeiträge auf Answers.microsoft.com, TenForums.com, ElevenForum.com und TechPowerUp.com ansah, sah ich Hunderte und Aberhunderte von Forenthreads, die Hilfe bei der Bewältigung von Secure Boot-Problemen suchten. Bei vielen handelte es sich um Laptops und bei vielen weiteren um Desktops, insbesondere um Eigenbauten oder solche von Boutique-Herstellern, die erstklassige kommerzielle Teile zusammenbauen, um maßgeschneiderte PCs für wohlhabende Käufer zu bauen (siehe nächster Abschnitt).
Maßgeschneiderte PCs
Motherboards desselben Herstellers verhalten sich möglicherweise unterschiedlich, abhängig von:
- Tatsächlich installierte Chipsätze
- Firmware-Zweig
- Erscheinungsjahr
- OEM vs. Einzelhandels-SKU
Insgesamt war der Mangel an Standardisierung offensichtlich. Die Secure Boot-Probleme, auf die Benutzer gestoßen sind, sind allgegenwärtig. Einige haben letztendlich Windows Update oder manuellen Änderungen nachgegeben. Andere haben sich hartnäckig allen Reparatur- oder Korrekturversuchen widersetzt. Ich selbst habe mich schon überall in diesem Problemfeld befunden, wobei Misserfolge in letzter Zeit von Erfolgen (aber nichtsdestotrotz Misserfolgen) überholt wurden.
Was Benutzer tun können, wenn Secure Boot-Updates fehlschlagen
Es gibt viele Möglichkeiten, wie Secure Boot fehlschlagen kann. Das Windows-Update meldet möglicherweise einen Erfolg, aber die DBX (Sperrliste) ändert sich nie. Die Firmware meldet möglicherweise, dass Secure Boot „aktiviert“ ist, es wird jedoch nicht erzwungen (das PowerShell-Bestätigungs-SecureBootUEFI meldet in diesem Fall „false“).
Systeme booten möglicherweise, bestehen jedoch keine Konformitätsprüfungen (weitere Einzelheiten finden Sie im Abschnitt „Garlin-Skripte“ weiter unten in dieser Geschichte). Bootloader stimmen möglicherweise nicht mit DB-Einträgen überein, oder Systeme starten nach Updates möglicherweise nur zögerlich oder überhaupt nicht (wie es bei meinem ASRock B550 Extreme4-System der Fall war). Hier ist viel los, also gibt es viele Dinge, die man ausprobieren kann, falls man sie reparieren muss. Lassen Sie uns eine Liste möglicherweise schwerwiegender Ursachen und damit verbundener Lösungen durchgehen.
Nicht übereinstimmende Schlüssel (PK/KEK/DB/DBX)
Wenn der PK oder KEK veraltet ist, lehnt die Firmware möglicherweise Datenbankaktualisierungen in der Liste der gültigen Anmeldeinformationen und Werte (DB) oder der Liste der widerrufenen Elemente (DBX) ab. In diesem Fall lohnt es sich, eine oder alle dieser Korrekturen auszuprobieren:
- Auf Werks- oder Standardschlüssel zurücksetzen (normalerweise als auswählbare Aktion in UEFI verfügbar, wenn sich Secure Boot im benutzerdefinierten Modus befindet)
- Registrieren Sie Microsoft-Schlüssel erneut (erfordert normalerweise die erneute Anwendung eines Microsoft-Updates, was eine Deinstallation/Neuinstallation mit sich bringt, möglicherweise über DISM – WU bietet ein zeitlich begrenztes Rollback)
Firmware ignoriert DB- oder DBX-Updates
Auf einigen PCs und Laptops wendet UEFI außer unter bestimmten Bedingungen keine DB- oder DBX-Updates an. Möglicherweise muss Secure Boot deaktiviert werden. Das Compatibility Support Module (CSM, das „Dual Boot“ entweder im BIOS-oder UEFI-Modus ermöglicht; moderne PCs unterstützen nur UEFI, ältere Modelle funktionieren jedoch oft in beide Richtungen) muss ausgeschaltet sein. Manchmal müssen Secure Boot-Schlüssel gelöscht werden (eine weitere UEFI-Option), bevor Updates durchgeführt werden. Möglicherweise sind Experimente erforderlich, um herauszufinden, was was ist. Wenn Sie Glück haben, finden Sie Informationen von anderen unerschrockenen Entdeckern, die Ihr spezielles Problem bereits gesehen und gelöst haben.
Veraltete Bootloader
Ältere Windows-Installationsmedien oder Reparatur-/Wiederherstellungsdisketten enthalten möglicherweise Bootloader, die zu alt sind, um mit Secure Boot zu funktionieren. Tatsächlich wird sich diese Diskrepanz später im Jahr 2026 verstärken, nachdem Microsoft sich intensiver mit der Aufhebung von CA-2011 befasst (was die meisten älteren Bootloader beinhalten). Wenn ein Bootloader zu alt ist, blockiert DBX ihn möglicherweise. Korrekturen sind recht einfach, da Bootloader nicht mit der Firmware (UEFI) interagieren. Versuchen Sie in diesem Fall eine der folgenden Reparaturen:
- Führen Sie Windows Update aus: Möglicherweise wird ein veralteter Bootloader durch einen aktuellen ersetzt
- Erstellen Sie die Startdateien mit dem Dienstprogramm bcdboot neu
- Stellen Sie sicher, dass die EFI-Partition fehlerfrei ist (und erstellen Sie sie neu, wenn dies nicht der Fall ist).
Firmware-Fehler oder Kuriositäten
Insbesondere auf älteren PCs ist es eine gute Idee, das UEFI zu aktualisieren (zu flashen), bevor Sie mit Secure Boot beginnen. Für PCs, die alt genug sind, gibt es jedoch möglicherweise einfach keine Updates für 2023 und neuere Versionen. Aber für Systeme, die mehrere Neustarts, bestimmte Firmware-Versionen oder manuelle Importe der Secure Boot-Datenbank (DB, DBX) erfordern, sind einige Techniken hilfreich:
- Aktualisieren Sie die Firmware auf die neueste stabile Version (Betaversionen nur dann in Betracht ziehen, wenn alle anderen Optionen fehlgeschlagen sind: Sie möchten nicht eine Ursache der Instabilität gegen eine andere eintauschen)
- Wo immer verfügbar, verwenden Sie vom Hersteller bereitgestellte Kapseln oder Updates, um Änderungen an der Secure Boot-Datenbank anzuwenden (z. B. funktionierte mein MSI MAG Tomahawk nicht richtig, bis ich sein UEFI geflasht hatte, das Secure Boot und CA-2023-Elemente direkt integriert enthielt).
- Lassen Sie Windows Update seine Arbeit erst ausführen, NACHDEM die Firmware aktuell ist: Neue Updates und alte Firmware sorgen für eine volatile und problemanfällige Umgebung, wie ich beim ASRock B550 Extreme4-Build erfahren habe
Alles in allem ist die Wahrscheinlichkeit, dass Benutzer auf diesem Weg in einem Schlagloch stecken bleiben, weitaus geringer, wenn sie sich an der Einhaltung von Secure Boot-Vorgängen von Firmware-Updates bis hin zu Windows-Updates versuchen und nur bei Bedarf manuelle UEFI-Vorgänge durchführen.
Wie die Skripte dabei helfen, Probleme mit Secure Boot-Updates zu lösen
Zu den interessantesten Entwicklungen während der Einführung von CA-2023 gehörte das Aufkommen von Community-gesteuerten Tools und Diagnosen. Insbesondere der Eleven-Forum-VIP und Guru-Benutzer Garlin hat einen über 50-seitigen Thread mit nützlichen PowerShell-Skripten bereitgestellt und diese mit unglaublich nützlicher Unterstützung und Diskussion untermauert. Seine Skripte bewirken Folgendes:
- Secure Boot-Schlüssel aufzählen
- Validieren Sie DB/DBX-Einträge
- Nichtübereinstimmungen erkennen
- Identifizieren Sie veraltete Bootloader
- Überprüfen Sie den Durchsetzungsstatus
- detaillierte Berichte erstellen
Für viele Benutzer waren Garlins Skripte der erste klare Einblick in die tatsächliche Funktion ihrer Firmware. Zur Veranschaulichung dessen, was die Garlin-Skripte beleuchten, zeigt Abbildung 1 die Ausgabe seines Skripts mit dem Namen Check_UEFI-CA2023.ps1, aufgenommen von meinem kürzlich umgebauten MSI MAG Tomahawk B550-Desktop:
Eine sorgfältige Prüfung des obigen Screenshots zeigt, dass auf dem PC sowohl CA 2011 als auch CA 2023 Key Exchange Keys (KEKs) installiert sind, mit DB-Zertifikaten für UEFI CA 2011, Windows PCA 2011 und drei Varianten von CA 2023. Die Liste der DBX-Zertifikate ist leer (unten sehen Sie, dass CA 2011 noch nicht widerrufen wurde; sobald das passiert, sollten diese Einträge verschoben werden hier).
EFI-Dateien zeigen, dass der Boot-Manager UEFI CA 2023 zulässt, ebenso wie die Registrierung, und dass die neueste Secure Boot-Code-Integritätsrichtlinie vorhanden ist. MS verwendet diese Richtlinie, um anfällige oder Rollback-anfällige bootkritische Binärdateien zu blockieren, insbesondere für Virtualization Based Security (VBS, wie im zweiten Punkt in der Gesamtausgabe des Skripts erwähnt).
Schließlich zeigt die Skriptausgabe, dass die ältere CA-2011-Zertifizierung noch nicht widerrufen wurde. Das ist Absicht: Ich warte ab, wie und wann Microsoft dies über Windows Update in den Griff bekommt, wie sie es irgendwann in der zweiten Hälfte des Jahres 2026 versprochen haben. Wir werden sehen, wie sich das entwickelt …
Warum diese Skripte wichtig sind
Anbieter legen selten den vollständigen Secure-Boot-Status eines PCs offen. Die Fensteroberfläche ist nur ein Teil dieses Bildes. Firmware-Benutzeroberflächen sind inkonsistent und bezeichnen dieselben Dinge oft mit unterschiedlichen Namen. Garlins Skripte zeigen uns, was im Secure-Boot-Bereich vor sich geht, und sagen uns, welche Maßnahmen möglicherweise ergriffen werden müssen, um den gesamten Aktualisierungs- und Aufholprozess abzuschließen.
Was tun, wenn Secure Boot keine Updates anwendet?
Hier ist ein praktischer, schrittweiser Wiederherstellungsworkflow.
Schritt 1: Überprüfen Sie den aktuellen Status
Verwenden Sie PowerShell oder Garlins Skripte, um Folgendes zu überprüfen:
- PK
- KEK
- DB
- DBX
- Durchsetzungsstatus
- Bootloader-Versionen
Schritt 2: Firmware aktualisieren
Installieren Sie das neueste BIOS/UEFI-Update.
Schritt 3: Setzen Sie die Tasten auf die Werkseinstellungen zurück
Deaktivieren Sie Secure Boot, stellen Sie den Modus auf „Benutzerdefiniert“ ein und setzen Sie dann die werkseitigen Standardschlüssel zurück oder installieren Sie sie (verschiedene UEFIs verwenden unterschiedliche Terminologie). Wie auch immer sie es nennen, dadurch werden oft Unstimmigkeiten beseitigt.
Schritt 4: Aktivieren Sie Secure Boot erneut
Stellen Sie sicher, dass CSM deaktiviert ist (es wird häufig aktiviert, wenn UEFI aktualisiert wird; es muss deaktiviert werden, damit Secure Boot aktiviert werden kann).
Schritt 5: DBX-Update(s) anwenden
Verwenden Sie Windows Update oder die Kapsel(n) des Herstellers, sofern verfügbar. Suchen Sie auf den Support-Seiten des System- (oder Motherboard-)Anbieters nach UEFI und zugehörigen Updates. Das hat bei meinem MSI MAG Tomahawk B550 Motherboard geholfen.
Schritt 6: Bootdateien neu erstellen (falls erforderlich)
Sie können integrierte Befehle verwenden, um Ihre Startdateien neu zu erstellen, indem Sie den UEFI-Befehl bcdboot C:\Windows/f ausführen. Manchmal kann es erforderlich sein, von einer Reparatur- oder Rettungsdiskette zu booten und diese in der Windows-Wiederherstellungsumgebung (WinRE) auszuführen. Es ist immer sicherer, diesen Ansatz zu wählen, und er wird Sie über Boot-Probleme oder sichere Boot-Richtlinienblockaden hinwegkommen lassen, falls diese auftauchen sollten.
Schritt 7: Überprüfen Sie den Status erneut
Bestätigen Sie, dass DBX CA 2023-Einträge enthält. Tatsächlich wäre dies ein guter Zeitpunkt, Garlins Check_UEFI-CA2023.ps1-Skript auszuführen. (Hinweis: Wenn Sie in das Eigenschaftenfenster der Datei schauen und die Option „Blockierung aufheben“ aktivieren, können Sie dieses Skript in PowerShell ausführen, ohne die lokale Ausführungsrichtlinie zu ändern oder zu umgehen. Dies ist im folgenden Screenshot dargestellt.)
Meiner Meinung nach muss das Secure Boot Ecosystem reformiert werden
Interessant waren die schrittweise Einführung von CA 2023 und die jüngsten Bemühungen, Systeme auf die aktuelle Secure Boot-Konformität zu bringen. Aber es hat auch ein breites Spektrum systemischer Probleme und Probleme aufgedeckt. Zum einen mangelt es den Firmware-Anbietern an einheitlichen Implementierungen und Terminologien, so dass es die Aufgabe von IT-Profis und anderen Installateuren ist, dafür zu sorgen, dass alles funktioniert. Erschwerend kommt hinzu, dass die Dokumentation oft mangelhaft ist und keine Abhilfemaßnahmen vorsieht, wenn etwas kaputt geht oder nicht richtig funktioniert.
Derzeit sind Update-Pipelines fragil. Ein Fehltritt (z. B. das Versäumnis, Secure Boot auf den benutzerdefinierten Modus zu setzen, bevor versucht wird, die Standardschlüssel neu zu installieren) kann dazu führen, dass der Update-Vorgang hängen bleibt und das normale Startverhalten beeinträchtigt. Auf einem meiner ASRock-Desktops konnte ich den PC nicht normal neu starten und konnte nur einen tiefen Kaltstart durchführen, um in UEFI zu gelangen oder den Startzyklus durchzuführen (dies dauerte zwei Wochen, bevor ich das Motherboard wechselte, damit alles wieder normal funktionierte). Dies treibt auch meine Beobachtung voran, dass OEMs und Motherboard-Anbieter hinsichtlich der Qualität der Secure Boot-Implementierung und -Handhabung große Unterschiede aufweisen. Während mich das ASRock-Mobo in den Wahnsinn trieb, hatte ich mit keinem meiner Lenovo-Systeme (einige aus dem Jahr 2018) Probleme, auch nicht mit meinem Dell-Mini-PC oder einem ASUS-Snapdragon-Laptop.
Bei diesem Prozess habe ich gelernt, dass Secure Boot nur so stark ist wie sein schwächstes Glied. Leider weisen einige Systeme Schwachstellen auf. Viele dieser Schwachstellen machen aus einem eigentlich routinemäßigen Update einen Kampf. Einige davon können sogar noch drastischere Maßnahmen erfordern, wie z. B. einen Systemaustausch oder einen Motherboard-Austausch.
Was Microsoft, OEMs und Benutzer tun müssen
Alle Kinder auf diesem Spielplatz müssen bestimmte Dinge tun, um den aktuellen Secure Boot-Sumpf zu verbessern. Meiner Meinung nach wirkt sich dies bei Microsoft, OEMs und der Benutzergemeinschaft wie folgt aus. Zunächst sollte Microsoft eine strengere Zertifizierung durchsetzen, mit verbesserter Diagnose und besseren Tools (Garlins Skripte sind im Nachhinein ziemlich einfach; es gibt keinen Grund, warum MS nicht ausgefeiltere Implementierungen anbieten kann, um die Dinge voranzubringen).
Als nächstes könnten die OEMs viel tun, um das Firmware-Verhalten zu standardisieren und eine einheitliche Terminologie einzuführen. Sie können ihr DB-Update immer gründlicher testen und bieten mehr Einblick und Klarheit in den Secure Boot-Status und die Werte in ihren UEFI-Schnittstellen. Ein robustes, automatisiertes Rollback-Tool würde auch dabei helfen, falsche oder schlechte Entscheidungen rückgängig zu machen.
Und schließlich sollten Benutzer die Sicherheit ernster nehmen. Dies bedeutet, die Firmware zu aktualisieren, sobald neue Updates verfügbar sind, und sich dafür zu entscheiden, Secure Boot zu verwenden (nicht zu deaktivieren), es sei denn, Installationen, Konfigurationsänderungen oder Updates erfordern eine (vorübergehende) Deaktivierung. Benutzer sollten außerdem regelmäßig ihre Secure Boot-Datenbanken überprüfen, um sicherzustellen, dass sie aktuell und korrekt sind, und sicherstellen, dass ihre EFI-Partitionen fehlerfrei und aktuell sind.
Wenn jeder seinen Beitrag leistet, kann Secure Boot seine Aufgabe erfüllen und Systeme vor Kompromittierungen und Angriffen auf Boot- und Root-Ebene schützen. Das ist ziemlich wichtig, also denke ich, dass es sich lohnt, es zu tun.
Secure Boot ist immer noch wichtig, aber es muss noch daran gearbeitet werden
Secure Boot bleibt ein wichtiger Abwehrmechanismus im Windows-Sicherheitsmodell. Aber die CA 2023-Saga zeigt, dass dieses Ökosystem fragil, inkonsistent und eine Modernisierung überfällig ist. Die gute Nachricht ist, dass die Branche lernt. Firmware-Anbieter verbessern sich. Microsoft verschärft die Anforderungen. Community-Tools schließen Lücken. Aber die Lektion ist klar: Vertrauen ist kein Selbstläufer. Vertrauen muss aufrechterhalten, überprüft und gelegentlich repariert werden. Secure Boot ist keine Ausnahme.
Abschließend möchte ich Ihnen raten, darauf zu achten, wie die Zeit vergeht, während Sie an der Lösung von Secure Boot-Problemen arbeiten, falls diese auftreten. Wenn die Behebung eines Problems einen halben Tag dauert, ist das tolerierbar. Wenn es länger dauert, ist es an der Zeit, über Alternativen, Problemumgehungen und Ersatz nachzudenken. Während Sie nachdenken, können Sie Secure Boot ausschalten: Windows funktioniert auch ohne es. Aber vielleicht entscheiden Sie sich, wie ich, dafür, widerspenstige, festsitzende Hardwarekomponenten auszutauschen, anstatt weiter zu kämpfen, ohne dass eine sichere Lösung in Sicht ist. Es liegt an Ihnen!
Zuhause
Teilen
Newsletter
WL-Newsletter
WL-Newsletter!
Bleiben Sie mit den neuesten Windows-, IT- und KI-Updates auf dem Laufenden. Mehr als 50.000 Abonnenten vertrauen darauf.
Name
Kostenlos beitreten
*️⃣ Quelllink:
Einführung des CA-2023-Zertifikats, Thread mit mehr als 50 Seiten, Home , Newsletter ,