[English]Microsoft hat gerade ein neues PowerShell-Script für Windows 10 und Windows 11 veröffentlicht, welches die Boot-Medien aktualisiert. Dadurch soll sichergestellt werden, dass das Windows UEFI CA 2023 Zertifikat in naher Zukunft akzeptiert wird. Das Ganze steht im Kontext zur Black Lotus Secure Boot-Schwachstelle, die Microsoft schließen musste. Kurzer Rückblick, um was es geht.
Anzeige
Black Lotus und Windows UEFI CA 2023 Zertifikat
Im März 2024 wurde bekannt, dass das BlackLotus UEFI-Bootkit den Secure Boot in Windows 11 mittels der Schwachstelle CVE-2023-24932 überwinden könne. Microsoft hat zwar versucht, da etwas per Update zu patchen. Das ist aber ziemlich in die Hose gegangen. Ich hatte im Blog-Beitrag KB5025885: Secure Boot-Absicherung gegen Schwachstelle CVE-2023-24932 (Black Lotus) über die Schwachstelle berichtet.
Parallel dazu dräut beim Secure Boot not ein anderes Problem. Im Oktober 2026 läuft ein UEFI-Zertifikat ("Windows Production PCA 2011") Microsofts ab, welches beim Secure Boot benutzt wird. Das dürfte nicht nur Windows-Nutzer betreffen, sondern auch Linux-Administratoren sollten sich mit dem Thema befassen.
Es besteht die Befürchtung, dass Systeme ohne das alte Zertifikat ab dem genannten Datum nicht mehr mit Secure Boot starten können. Auch dieses Thema hatte ich im Beitrag Frage: BlackLotus-Schwachstelle und ablaufendes UEFI-Zertifikat – was droht uns? angesprochen. Und auf diesen Sachverhalt versucht Microsoft nun mit einem PowerShell-Script als Antwort zu reagieren.
KB5053484 für Windows 10/11
Zum 4. Februar 2025 hat Microsoft den Support-Beitrag KB5053484 (Updating Windows bootable media to use the PCA2023 signed boot manager) veröffentlicht – Bolko hatte im Diskussionsbereich darauf hinwiesen (danke), ich hatte es aber auch auf diversen Webseiten gesehen.
Anzeige
Im Support-Beitrag wird das PowerShell-Skript Make2023BootableMedia.ps1 zum Download angeboten. Das PowerShell-Skript lässt sich verwendet, um Windows-Bootmedien zu aktualisieren, damit die Medien auf Systemen verwendet werden können, die dem Zertifikat "Windows UEFI CA 2023" vertrauen, schreibt Microsoft. Als Ein- und Ausgabe können bootfähige Medien des folgenden Typs verwendet werden:
- ISO-CD/DVD-Image-Datei,
- USB-Flash-Laufwerk,
- ein lokaler Laufwerkspfad, oder
- ein Netzlaufwerkspfad.
Hinweise zum Aufrufen des PowerShell-Scripts finden sich im verlinkten Support-Beitrag. Damit dieses PowerShell-Skript ordnungsgemäß funktioniert, wird zudem die neueste Version des Windows Assessment and Deployment Kit (Windows ADK) benötigt. Dieses muss hier heruntergeladen und dann installiert werden.
Details zu diesem Zertifikat beschreibt Microsoft im Supportbeitrag KB5025885: How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932.
Ähnliche Artikel:
KB5025885: Secure Boot-Absicherung gegen Schwachstelle CVE-2023-24932 (Black Lotus)
Frage: BlackLotus-Schwachstelle und ablaufendes UEFI-Zertifikat – was droht uns?
Anzeige
Wieso liefert Microsoft nicht diese aktualisierten Bootmedien? Wieso muss man sich ADK antun? Warum kann MS nicht einfach das Powershell inkl. der Files liefern, die für den Tausch nötig wären?
Kleine 100 Personen Indie-Firma in Redmond, bitte habe verständnis! ;)
/s
Ernstgemeinte Frage: Was machen die ca. 1 Mrd. PC-Nutzer, die nicht zufällig diesen Blog lesen und ohnehin keine Ahnung haben, was ein "Boot-Medium", ein "UEFI", ein "Secure Boot" oder ein "Powershell" sein könnte?
Da heißt es dann: "Selber Schuld, wenn Sie einen privaten PC benutzen. Aber wir haben da das ideale Produkt für Sie: Den virtuellen Cloud PC. Da brauchen Sie sich um sowas nicht mehr kümmern." :)
Ganz ehrlich, Microsoft fährt gerade an einigen Ecken so eine Verzögerungsschiene um gefühlt alle in die Sch*** zu reiten. Das selbe auch bei Exchange und dem CU15 bzw. noch schlimmer bei der kommenden SE Version, bei der immer noch nichts in reinen Tüchern zu sein scheint. Nur ein Haufen Fragezeichen und am Ende muss dann alles ganz schnell gehen, damit möglichst viele On-Prem Kunden unter die Räder kommen.
Aber bestimmt wird es wieder ein tolles, neues Cloud Produkt geben, was alles viel besser macht ;)
Blöde Frage wieso verwendet der Kunde dann diese Produkte? Egal bei welchem Hersteller die Produkte werden immer unbrauchbarer, aber der Kundschaft ist das egal und sie kauft dennoch. Fällt in der Firma Cloudmail für ein paar Stunden oder Tage aus, na dann ist das eigentlich schon mal gegeben und ist halt so. Hingegen wäre das bei OnPrem früher so gewesen, hätte die Firmenleitung die Admins gelyncht.
hast es dir gerade selbst beantwortet, die Produktqualität sinkt bei allen Herstellern.
Und die Umstellung von etablierten Prozessen auf etwas Neues ist um ein vielfaches aufwändiger als die Maintenance. Bzw. ist Exchange nicht einfach "nur" ein Mail Server, verstehen aber viele nicht, dass da mehr dran hängt als einfach ein Postfix/Dovecot.
Hat jemand das SecureBoot Problem genau analysiert und kann das kurz zusammenfassen? Die Infos von Microsoft sind ja meistens wirklich absolut nichtssagend und man muss alles selbst zusammensuchen…
Was mir beim Überfliegen des Artikels auffällt:
– Das Windows UEFI CA 2023 ist ein Root Zertifikat von SecureBoot und muss in im BIOS gespeichert werden. Wie soll das auf bestehenden Geräten gemacht werden? Das muss ja vom Hersteller durchgeführt werden, was ist hier Microsofts Plan? Einfach hoffen und beten?
– Wann wird der live Bootloader von W10/W11 mit einem neuen Zertifikat ausgestattet welches von Windows UEFI CA 2023 ausgestellt ist? Bis dahin muss ja das BIOS Update durch sein sonst startet nichts mehr.
– Wieso ein Script für Boot-Medien? Einfach Boot-Medien mit dem selben Datum umstellen wie der live Bootloader…
– Und zum Schluss noch, wird das alte Root Zertifikat Windows Production PCA 2011 im BIOS belassen oder wäre der Plan da zu entfernen? Ich hoffe jetzt mal nur Windows Produkte hatten dieses alte Zertifikat benutzt und nicht auch Linux sonst findet die Party ja auch bei Linux statt.
Danke für schnelle Erleuchtung ohne 1h alle Infos einzeln zusammenzusuchen.
Gruss A20017
Ich finde so viele Fragen ja etwas unverschämt. Ich helfe Menschen wirklich gerne, aber ein wenig Lebenszeit zum einlesen sollte jeder selbst aufbringen, sonst wäre meine Lebenszeit um das zu erklären ja wertlos.
Seit langen lasse ich es Fragen zu beantworten die zu umfangreich sind.
habe das schon ausgearbeitet, weshalb ich das aus dem Stehgreif beantworten kann ;)
-durch einen REG Key wird eine Funktion in Windows getriggert die das neue Cert ins UEFI schreibt, du selbst brauchst da nicht extra irgendwas ins UEFI manuell kopieren.
Bin aber auch schon bei dem ein oder anderen Mainboard in ein Problem gelaufen, wo Windows meinte, dass SecureBoot nicht aktiviert ist, lt. BIOS aber schon. Trick war dann Secure Boot deaktivieren und wieder reaktivieren, danach haben auch die REG Keys greifen können.
– der Unsinn ist für mich auch unbegreiflich, genauso gut könnte man den Bootloader doppelt signieren für die Übergangszeit …verstehe nicht warum MS nicht einfach den neuen Bootloader bereits mitausliefert, evtl. gibt es Probleme mit der Doppeltsignierung. Zeitplan kann dir niemand nennen, nicht Mal die bei MS wissen das. So lange du aber das 2011er Cert nicht enfernst gehen beide Versionen.
– das 2011er Cert muss dann am Ende entfernt werden, weil das ja kompromittiert ist. Das ist allerdings ein Extra Schritt.
Als MS Referenz hier auch noch Mal die Quelle: https://support.microsoft.com/en-us/topic/how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d
Ich weiss nicht ob mein Verständnis richtig ist. Ich meine folgendes.
Damit Secureboot funktioniert, ist im UEFI ein Zertifikat von MS von 2011 hinterlegt. Der Bootloader muss mit dem privaten Teil dieses Zertifikates signiert sein sonst startet er nicht.
Problem 1
Black Lotus hat einen Weg gefunden, an den Bitlocker Schlüssel zu kommen ohne dass Secureboot dies verhindert hätte.
Somit war Secureboot mit Bitlocker gebrochen.
Eigentlich sollte ein UEFI die Möglichkeit haben, gebrochene Signaturen zu sperren. Die OEMs haben diese Liste z.T. zu kurz gemacht und es gibt mittlerweile viele Bootloader (auch aus der Linux Fraktion) die Lücken haben und in die Sperrliste gehören.
Somit kann MS Ihren gebrochenen Bootloader nicht mehr zuverlässig überall sperren.
Problem 2
Das Zertifikat von MS hat eine Gültigkeit bis 2026.
Danach kann MS keinen Bootloader mehr signieren, der von Secureboot akzeptiert wird.
MS Lösung:
Ein neues Root Zertifikat in alle UEFI verteilen (dazu gibt es eine definierte Schnittstelle) und neue Bootloader mit diesem Zertifikat signieren (Windows Update).
Leider wurde dies noch nie gemacht, sodass nicht bekannt ist, ob der eigene Computer diese Schnittstelle richtig implementiert.
-> Seriöse OEMs haben dies mit ihren Computern getestet und bei Fehlern ein neues UEFI bereitgestellt.
-> Immer zuerst das aktuelle UEFI installieren
-> Bei älteren Computern bzw. NoNames kann es sein, dass es keine getestetes UEFI gibt und somit ist diese Umstellung eigenes Risiko.
Ist das UEFI aktuell kann mit der Anleitung von MS das neue Root Zertifikat gespeichert werden.
Danach kann ein neuer Bootloader in Windows installiert und gestartet werden.
Nun sollten auch alle Boot Medien, parallel Installationen mit neuem BootLoader aktualisiert werden. Dazu ist obiges Script gedacht.
Sind alle Bootloader mit neuer Signatur, kann im UEFI das alte Zertifikat gesperrt
werden.
Als letzter Schritt muss im UEFI das Rückrollen obiger Schritte verhindert werden.
Erst danach hat BlackLotus keine Möglichkeit mehr unerlaubt auf BitLocker zuzugreifen.
Zusammenfassung
– UEFI aktualisieren
– Neues Zertifikat installieren, testen
– Neuer BootLoader installieren, testen
– Alle BootMedien aktualisieren, testen
– Altes Zertifikat sperren, testen
– Rückrollen von altem Zertifikat blockieren.
Dies alles kommt bis Ende 2026 automatisch.
Nur weisst Du dann nicht warum Dein Computer deswegen vielleicht nicht mehr startet.
Habe bei der Arbeite mittlerweile 50 Computer mit neuem Zertifikat und neu signiertem Bootloader ausgerüstet und getestet. Bisher ohne Probleme.
Das alte Zertifikat habe ich noch nicht geblockt, weil ich zuerst die Boot Medien aktualisieren muss.
Unikatäre Computer ohne Fallback habe ich noch nicht gemacht, Wie soll ich dem Chef den Ausfall erklären.
Im MS Artikel sind auch Hilfestellungen bei Problemen aufgeführt.
HTH
ReFe
Dass das je automatisch kommen soll, daran glaube ich nicht.
Die Sperre bzw. Aufnahme in die UEFI DBX mache ich jetzt schon, falls ich dann doch noch alte Bootmedien starten muss, kann man die in der UEFI DBX wieder manuell entfernen, dann booten die Computer auch wieder, aber das kommt so gut wie nicht vor.
Vielen Dank euch.
Also der Hauptpunkt meiner Fragen, wie das neue Zertifikat ins UEFI gepatcht werden soll, hat sich geklärt.
Wie MS das bei all den Herstellern automatisch machen will bleibt ein grosses Fragezeichen…
Wie soll man bei tausenden Computern von unterschiedlichen Herstellern die UEFI Aktualisierung überwachen und sicherstellen? Microsoft wird sich keine Sekunde darum kümmern. Das gibt eine 100% Stelle nur dafür. Cool, werden sich paar drüber freuen.
Gruss
A20017
Naja das lässt sich auch beantworten irgendwie. Windows 11 läuft nur auf neuerer Hardware (od. korrekter wird nur supported auf neuerer Hardware), die Schnittstelle zum UEFI ist standardisiert, nagel mich nicht fest in welcher Version, aber die ist definitiv in den aktuellen Versionen vom UEFI drin.
Läuft ohne TPM und Secureboot legal auf Windows 11 IoT und IoT LTSC. Welche man legal bei Firmen und MS zertifizierten resellern günstig erstehen kann.
Die Frage ist, warum will ich einen 11 Jahre alten PC damit ausstatten, wenn der Ideale Office PC (siehe Computerbase-Vorschläge im Forum) maximal 300-400€ komplett kostet.
Da ist jede IoT Lizenz um TPM/Secureboot-Zwang (ohne Tricks) nicht zu haben 25-33% von der Hardware rausgeworfenes Geld.
1.
Mit welchem Microsoft-Update wurden die neuen Schlüssel in das UEFI gepatcht?
Soweit ich weiß ist es das KB5036210 vom 13.Februar 2024 mit dem die Signatur-Datenbank (DB) im UEFI gepatcht wurde, damit das neue Bootloader-Zertifikat akzeptiert wird.
Ob Windows das neue Zertifikat integriert hat soll man an folgendem Registry-Schlüssel erkennen können (laut KB50362101-Support-Seite):
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\SecureBoot\\Servicing]
"WindowsUEFICA2023Capable"=dword:00000000
0 bedeutet nicht bereit (ist bei mir so).
support. microsoft. com/de-de/topic/kb5036210-bereitstellen-des-windows-uefi-ca-2023-zertifikats-f%C3%BCr-sicheres-starten-zugelassener-signaturdatenbanken-db-a68a3eae-292b-4224-9490-299e303b450b
2.
Ab welcher UEFI-Version sind die neuen Signaturen bereits ab Werk integriert, ohne das UEFI patchen zu müssen?
Im UEFI kann man selber nachschauen:
secure boot keys -> Authorized Signatures (db) -> search for "Windows UEFI CA 2023"
3.
Eine sehr lange Erklärung zu diesen UEFI-Signaturen findet man bei Microsoft, inklusive Downloads für das neue Zertifikat:
learn. microsoft. com/de-de/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11
Man braucht also je Mainboard-Hersteller einen signierten KEK-Schlüssel, um überhaupt diese neuen Signaturen ins UEFI integrieren zu dürfen.
Microsoft bezeichnet das neue Schlüsselaustausch-Zertifikat als "Microsoft Corporation KEK CA 2023-Zertifikat".
Alle Mainboard-Hersteller müssen dieses Microsoft-Zertifikat runterladen, signieren und wieder zurück zu Microsoft hochladen, damit Microsoft dann per Update aus Windows heraus ab dem Jahr 2026 neue DB und DBX-Signaturen ins UEFI schreiben darf. Ohne dieses neue signierte KEK würden die UEFIs die Updates der erlaubten Bootloader-Signatur-Datenbanken verweigern.
4.
Wie macht man so ein UEFI-Signatur-Update mit Linux?
Die Mainboard-Hersteller erhalten nämlich nur von Microsoft diese KEK-Schlüssel, aber nicht von "Linux" (wer wäre denn da zuständig).
Wird Microsoft auch die aktualisierten Signaturen der Linux-Bootloader in die Windows-Updates integrieren oder wird Microsoft die goldene Gelegenheit ausnutzen und auf diese Weise das unerwünschte Linux nachhaltig rauskicken?
Werden die UEFI-Hersteller ab dem Jahr 2026 überhaupt noch Secure-Boot abschaltbar machen oder ist es immer an, weil es eine Vorraussetzung für Windows 11 ist?
Man denke da etwa an die Aldi-PCs, die schon immer nur ein sehr abgespecktes BIOS bzw UEFI hatten, wo man viele Dinge nicht mehr umschalten kann.
>aber nicht von "Linux" (wer wäre denn da zuständig).
Du bist bei *NIX deine eigene CA und SecureBoot unter *NIX ist trivial. Man muss nur bei absolut jedem Kernel-Update neu signieren. Könnte schnell nervig werden.
Ohnehin weiss ich nicht was Menschen glauben mit dem Bootvorgang schützen zu wollen (außer Bitlocker/dmcrypt). 99% der Angriffe sind nach der Bootphase.
Secure Boot soll Schutz gegen Rootkits sein.
Oh das ist mir bekannt, aber das nützt einem gar nichts, wenn der Keylogger im laufenden OS unerkannt bleibt.
Hey, stell dir mal eine Welt vor, in der ein BIOS mit UEFI einen Schreibschutz hat, oder es zumindest ein Schreibgeschütztes BIOS gibt und eine flashback taste, mit der man ein Rootkit freies BIOS ohne SPI NAND flash programmer und programmer clip einspielen kann.
Krass oder? Würde bestimm 50cent mehr in der Herstellung kosten statt dieses Security Theater.
Könnte man Hardware ohne Programmierclips wirklich auf NULL löschen können wären Rootkits eine Legende am Lagerfeuer.
Ich hatte das Thema vor einigen Tagen hier schon einmal angesprochen.:
https://administrator.de/forum/uefi-ca-2023-wie-seht-ihr-es-670977.html
Leider kam nicht ein einziges Feedback.
Unserer Meinung nach funktioniert es aktuell recht gut; wird aber noch nicht automatisch durch Microsoft durchgeführt (Enforcemant Phase).
Wir haben ein paar simple Batchdateien, mit denen die Updates der Datenbanken und der Bootloader stets korrekt durchgeführt wurden.
Welche Batchdateien benutzt ihr?
Habt ihr die selber geschrieben?
Könnt ihr die hier veröffentlichen?
Sind eure Batchdateien auch auf das Windows ADK vom Dezember 2024 angewiesen?
Werdet ihr das neue Make2023BootableMedia.ps1 von Microsoft benutzen oder werdet ihr bei euren Batchdateien bleiben?
Was ist die Mindestversion der UEFIs, damit eure Batchdateien funktionieren und welcher Windows-Patchlevel wird mindestens benötigt?
Bei Administrator .de fragst du:
"Was ist mit dem KEK?"
Wie habt ihr denn die DB aktualisiert, wenn ihr nicht vorher das aktualisierte KEK benutzt habt?
Das war dann wohl bereits im UEFI vorher integriert oder wurde durch ein Windows-Update installiert.
Habt ihr die selber geschrieben? -> ja, überhaupt nicht kompliziert – vereinfachen nur etwas die von MS beschriebenen mannuellen Schritte.
Könnt ihr die hier veröffentlichen?- > schreib eine PN (administrator.de), dann packe ich dir etwas zum testen ein
Sind eure Batchdateien auch auf das Windows ADK vom Dezember 2024 angewiesen?->nein
Werdet ihr das neue Make2023BootableMedia.ps1 von Microsoft benutzen oder werdet ihr bei euren Batchdateien bleiben?->Das ist etwas anderes. Unsere Batches: zum vorzeitigen Aktualisieren der Maschinen. Make2023BootableMedia.ps1 ist zum Aktualisieren vorhandener Medien.
Was ist die Mindestversion der UEFIs->keine, hat auch mit alten Boards funktioniert
Getestet mit 24H2 und 23H2 (jeweils aktuell)
Wie habt ihr denn die DB aktualisiert, wenn ihr nicht vorher das aktualisierte KEK benutzt habt?->es funktioniert einfach
Das war dann wohl bereits im UEFI vorher integriert-> nein
…oder wurde durch ein Windows-Update installiert -> Das fragen wir uns auch. Aber wie gesagt, es funktioniert. Möglicherweise lief da schon einiges mit Microsoft und den Mainboardherstellern im Hintergrund?!
Zitat:
"Könnt ihr die hier veröffentlichen?- > schreib eine PN (administrator.de), dann packe ich dir etwas zum testen ein"
—
Ich habe dort eben Nachricht an dich geschickt.
Pastebin und das öffentlich und sinnvoll für alle Teilen ist zu kompliziert oder? Unglaublich!
Er wird seine Gründe haben – wenn es öffentlich werden soll, kann er mir die Info auch per Mail schicken und ich stelle es im Blog ein.
Ein Warnung das es auf eigene Gefahr ist reicht ja ;)
Ich finde diese Geheimklubmentalität in einem tollen Onlinemedium zum Informationstausch absolut schadhaft für die Leser.
Es sind 6 kurze einzeilige Batch-Dateien mit den Befehlen aus den 3 Schritten strikt nach Microsoft-Anleitung ab
"To deploy the update and apply the revocations, follow these steps:"
support. microsoft. com/en-us/topic/kb5025885-how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d
—
Schritt 1: 2023er Key in die BIOS-Datenbank (db) schreiben
– 1a -> Befehl als Batch
2 x Neustart
Überprüfung:
– 1b -> Befehl als Batch
Ergebnis true = ok
Schritt 2: Bootmanager updaten
– 2a -> Befehl als Batch
2 x Neustart
Überprüfung:
– 2c und 2d ii -> beide Befehle in einer Batch
Ergebnis true = ok
Schritt 3:
2011er Key in die Bios Datenbank (dbx) als verboten eintragen.
Wenn man das allerdings macht, dann wird das System mit 2011er-Boatloadern nicht mehr starten.
– 3a -> Befehl als Batch
2 x Neustart
Überprüfung:
– 3c -> Befehl als Batch
Ergebnis true = ok
Also neben der üblichen Registryfrickelei dieses Mal auch wilde Konsolenfrickelei.
Ich dachte immer, die Kommandozeile ist ein Ausschlusskriterium (siehe die ganzen Linuxbashereien hier) und mal muss alles per Mäuseschubserei erledigen können?!?
Im Endeffekt muss man gar nichts machen. Es kommt automatisch. Für laufende Systeme und für ISOs.
Das das Thema aufgekocht wurde war wohl ein Fehler, man sollte von der "Problematik" nur wissen, wenn sie zum "Problem" wird order werden könnte [Konjunktiv].
Wer jetzt nicht ganz viele Bootmedien zum Arbeiten in der Firma braucht, der kann ja wohl auf die offiziellen ISOs warten. Dann wenn es "kaputt" ist, dann werden Industrie und MS diese ISOs auf Druck auch flott anbieten.
Vielleicht gibt es dann mal ein Paar Wochen Wartezeit. Wer das ertragen kann, der muss sich hier nicht so einen Stress machen. Es ist alles OK und geht seinen natürlich geordneten Gang.
Das sehe ich mittlerweile exakt genauso.
Handlungsbedarf nur:
– Wenn man vorab sicherstellen möchte, dass die Maßnahmen auf einer Maschine funktionieren werden.
– Wenn ein Bios (DB) einer aktualisierten Maschine zurückgesetzt wurde und dann nicht mehr die CA 2023 enthält.
– Bei "älteren" Bootmedien, die man für aktualisierte Systeme vorhält.
Na, dann hoffe ich mal, dass Ihr recht habt, und dass das auch für Linux- bzw. Dual-Boot-Systeme gilt — ich selbst bin da zu weit weg von, um das alles im Detail nachvollziehen zu können.
Als Fallback bleibt ja immer noch die Option, Secure Boot auszuschalten — obwohl es ja wohl kaum die Idee sein dürfte, durch ein Secure-Boot-Sicherheitsupdate quasi das Abschalten zu erzwingen…
Ich will mit meinen Meinungen nicht nerven, aber es gibt stressfreie Lösungen:
2 SSD, dann zerschießen sich die OS auch nicht gegenseitig /boot
Ein MSI-Mainboard welches 3 zustände für Secureboot kennt (aus/optional/strikt).
Dann bootet windows mit SecureBoot und Linux ohne, automatisch. Die boot partitionen werden bei Distr upgrades nicht von MS geschrottet und man kann sehr viel Spaß haben.
Eine zweite SSD wären vllt 30€ wenn nur für OS und eine schwache 240GB.
Vielleicht bin *ICH* auch total bescheuert, aber es geht.
Überhaupt kein Ausschlusskriterium, PowerShell ist ein geiles Tool für Windows und echt ein Segen, bin froh, dass die eingeführt wurde und ohne würde einiges bei mir nicht funktionieren.
Desktop-/Laptophersteller liefern heutzutage in ihrer Firmware die erforderlichen Zertifikate für Secure Boot beim mitgekauften Windows11-Betriebsystem gleich mit und pflegen diese über Firmwareupdates. Diese sollte man als User machen. Das ist wahrscheinlich aber für viele Nicht-Power-User neu. Wenn man die erforderlichen Firmware-Updates zusammen mit den Microsoft Security Updates eingespielt bekommt, merkt man wohl wenig, und das ist wohl das, was angestrebt ist.
Ob das Entfernen des alten Root Zertifikat Windows Production PCA 2011 bei bestehender Hardware gemacht wird, glaube ich nicht, sonst kann man den beim Kauf erworbenen Betriebsystem-Oiginalzustand nicht mehr starten. Bei Linux als einzig mitgeliefertes Betriebsystem stellt sich die Frage für das alte Root Zertifikat Windows Production PCA 2011 nicht.
Wer sein System sicher machen möchte, muss das wohl händisch machen. Dies gilt auch für das Aktualisieren der Recovery Drive.
Es gibt weitere Fälle, die wohl ebenfalls händisch sicher gemacht werden müssen:
1) Offline-Systeme
2) Die Festplatte wurde geklont oder Verändern der EFI System Partition
3) Nachträglicher Umbau zweite Festplatte und/oder TPM2.0-Chip
4) Dual-Boot Windows/Linux
5) Type-1 oder Type-2 Hypervisor auf Desktop/Laptop
6) Eigene Zertifikate
7) UEFI SBAT revocations aktivieren
Vielleicht gibt es noch weitere im Regressionsbaum?
Bei Linux gäbe es die Varianten über systemd-ukify und über sbctl, zumindest mein Stand.
Das Linux-Verschlüsseln/Entschlüsseln/Umschlüsseln einer Festplatte unter UEFI in den 7 Fällen hat die ähnliche Herausforderungen wie das Closed-Source Windows.
Oder man wartet die Fristen ab, an denen MS das Update von allein einspielt.
Das es nicht automatisch erfolgte sollte es Firmenkunden einfach machen. Privatpersonen werden davon gar nichts merken. Vielleicht mal eine aktuelle ISO ziehen müssen, wenn sie durch zufall feststellen die alte geht nach dem Update nicht.
Es wird einfach alles von alleine geschehen und man muss mal einen neuen Stick mit Rufus machen. Warum tut jeder so als wäre das Thema sooooo kritisch?
Habe das Update vorab eingespielt inkl löschen und an meinen abläufen hat sich nichts geändert.
Wo kann ich unter Windows wie aufrufen bzw. abfragen, welche Windows UEFI Zertifikate hinterlegt sind?
In Powershell liesse sich das bewerkstelligen mit:
Get-SecureBootUEFI -Name PK # Platform Key
Get-SecureBootUEFI -Name KEK # Key Exchange Key
Get-SecureBootUEFI -Name db # Signature Database
Get-SecureBootUEFI -Name dbx # Revoked Signatures Database
Die Arrayinhalte sind jedoch in einer EFI_SIGNATURE_LIST Struktur.
Das Github-Repository https://github.com/cjee21/Check-UEFISecureBootVariables mit dem Skript Get-UEFIDatabaseSignatures.ps1 liest die Struktur korrekt ein.
import-module Get-UEFIDatabaseSignatures.ps1
(Get-SecureBootUEFI -Name db | Get-UEFIDatabaseSignatures).SignatureList.SignatureData | select-object {$_.Issuer +" : "+ $_.Subject}
CN=Microsoft Root Certificate Authority 2010, O=Microsoft Corporation, L=Redmond, S=Washington, C=US : CN=Microsoft Windows Production PCA 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
CN=Microsoft Corporation Third Party Marketplace Root, O=Microsoft Corporation, L=Redmond, S=Washington, C=US : CN=Microsoft Corporation UEFI CA 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
CN=[Hersteller-spezifisch] : CN=[Hersteller-spezifisch]
CN=Microsoft Root Certificate Authority 2010, O=Microsoft Corporation, L=Redmond, S=Washington, C=US : CN=Windows UEFI CA 2023, O=Microsoft Corporation, C=US
Vielleicht geht es aber auch einfacher?
Hier ggf. eine wichtige Info (Quelle: Bleepingcomputers, Kommentar von BrechtMO):
I think it's important to know that boot images generated by recent ADK versions already contain this fix
For information on applying the BlackLotus UEFI bootkit vulnerability security updates to boot images from the ADKs before the ADK 10.1.26100.1 (May 2024, Dec 2024) (10.1.26100.1), see Customize Windows PE boot images. Boot images from the ADK 10.1.26100.1 (May 2024, Dec 2024) (10.1.26100.1) and newer already have the BlackLotus UEFI bootkit vulnerability security update applied to them. For this reason, it's recommended to use boot images from the ADK 10.1.26100.1 (May 2024, Dec 2024) (10.1.26100.X) or newer.
https://learn.microsoft.com/en-us/mem/configmgr/core/plan-design/configs/support-for-windows-adk
(however my MDT boot image generated with 10.1.26100.1 has a bootmgr.efi with signature signed by "Microsoft Windows Production PCA 2011" which is not right, I suppose)