News Patchday für Windows 11: Microsoft verteilt neue Secure-Boot-Zertifikate

[Pirol]

Hallo alle zusammen, kann man denn prüfen, ob man schon das neue

Secure-Boot-Zertifikate bekommen hat ?​

 

[kellyfornia]

nur liest? ich habe hier 2 laptops von verwandten gehabt wo die pin abfrage obwohl der richtige pin eingegeben wurde nicht mehr ging, ich musste beide laptops komplett neu installieren!!! drecks win11..

Da saß das Problem ganz sicher vor dem PC und war nicht Windows 11.

 

[prayhe]

@Pirol Folgendes in Admin Powershell eingeben

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'

True = Passt, False = fehlt

 

[Tuetensuppe]

Bis jetzt bei 3 Systemen nicht

Positive Nachrichten möchte hier keiner lesen 😁

 

[cmdr_nemesis]

nur liest? ich habe hier 2 laptops von verwandten gehabt wo die pin abfrage obwohl der richtige pin eingegeben wurde nicht mehr ging, ich musste beide laptops komplett neu installieren!!! drecks win11..

Ja ja, das sagte mir die Dozentin auch, "ich habe ganz sicher das richtige Kennwort eingegeben", bis ich ihr bewiesen hatte, dass sie nicht das richtige Kennwort bei der Windows 11 Anmeldung eingegeben hat. Sie hatte nämlich eine Zahl vergessen... als es dann soweit war, hat sie zugegeben, dass sie sich vertan hat. Ich möchte nicht wissen, wie oft es sich hier um ein Layer-8-Problem handelt.

 

[areiland]

nur liest? ich habe hier 2 laptops von verwandten gehabt wo die pin abfrage obwohl der richtige pin eingegeben wurde nicht mehr ging, ich musste beide laptops komplett neu installieren!!! drecks win11..

So ist das nun mal wenn man sich nicht mal in der Lage sieht, von der Pin Eingabe einfach zur Passworteingabe zu wechseln und dann das Passwort einzugeben. Das kann man aber sehr schlecht Windows anlasten, denn das ist eindeutig ein Benutzerproblem.

 

[Pirol]

@prayhe
Danke, aber bei der Eingabe erhalte ich eine Fehlermeldung

 

[MaverickM]

Und wofür ist es sonst da?

Wie der Name schon sagt: Es stellt sicher, dass nur signierte Bootloader geladen werden können. Mit dem Kernel hat das gar nichts zu tun.

 

[fdsonne]

Solange Secure-Boot per Default Betriebssysteme mit Lücken bootet und M$ root-kits (vulgo Anti-Cheat) per Default zulässt bringt das keinen Nutzen.

Unabhängig welchen Wert es hat, wenn es überwunden wurde - es ist und bleibt immer noch ein Mehrwert ggü. gar keiner Verifizierung der am Boot Prozess beteiligten Komponenten.

Du musst Secure Boot ja nicht nutzen. Der Witz bei deinem Argument ist nur, Kritik über das Verfahren gut und schön - aber ohne hat es gar keine Absicherung dieses Teils des Boot Prozesses. Die Kiste bootet was ihr vorgesetzt wird. Komplett alle "Betriebssysteme" mit wie ohne Lücken und auch inkl. aller "M$ root-kits (vulgo Anti-Cheat)" per default. Erst ein Verfahren wie Secure Boot erlaubt dir als Nutzer doch überhaupt derartige Dinge zu unterbinden. Man MUSS! sich ja nicht Microsoft unterwerfen in dem Fall. Das ganze lässt sich zur aller größten Not mit Aufwand auch selbst betreiben. Selbst signierter PK und eigene PKI bspw.

Dann kann man sich das ja komplett schenken wenn man mit secure Boot noch nicht mal die Integrität des Kernels sicherstellen kann.

Es geht dabei gar nicht wirklich um die letzten Komponenten in der Bootkette, sondern viel eher um die ersten. Das System soll gar nicht soweit starten, dass du in der Lage bist, modifizierte Kernel Komponenten zu laden.

Ich denke es ist vom Gedanken her relativ wichtig sich davon zu lösen, dass hier der Nutzer aktiv das System aushebeln kann, weil er die Rechte hat. Der ganze Kram erschlägt vor allem eher Themen wo der Nutzer keine Möglichkeit (mehr) hat zu verhindern, dass das System andere Komponenten bootet als es vorgesehen sind - weil bspw. der Kram entwendet wurde.

Wenn du mir mein Notebook mopst und da ein UEFI PW verhindert, dass die Settings gedreht werden, TPM verwendet wird um Keys zu speichern, der TPM Tresor via Password nicht im Klartext lesbar ist und gleichzeitig die Boot Order hart auf die interne Disk bzw. den Bootmanager gedreht ist, ohne Boot von externen Medien ala USB, LAN, ... -> dann ist die Kiste nicht von extern auf machbar. Natürlich ist das nur eine Frage der Zeit, weil irgendwann in Jahren, Jahrzehnten oder Jahrhunderten die Technik so weit sein wird, dass via Bruteforce die Disk Encryption ausgehebelt werden kann. Aber bis dahin lässt einen das durchaus sicher schlafen.

Wie der Name schon sagt: Es stellt sicher, dass nur signierte Bootloader geladen werden können. Mit dem Kernel hat das gar nichts zu tun.

Secure Boot ist keine Single Stage Prüfung. Sondern eine Multi-Stage "chain of trust" Architektur. Sprich das läuft nicht mit einer einzelnen Prüfung während des Boot Prozesses und wenn das durch geht, dann läuft der Kram.
Es gibt mehrere verschiedene Ebenen, von Firmware über Bootloader bis Kernel und Treiber. Und ja, auch die Kernel Signaturen werden dabei geprüft. Das Ding dabei ist viel eher, dass es in der Kette relativ weit hinten passiert und eben über das Hinzufügen von entsprechenden Keys möglich ist, auch selbst signierte Kernel oder Kernel Module zu laden. Das "Problem" dabei ist, dem Admin der Kiste wird hier eben die Möglichkeit gegeben, dass selbst zu signieren.

Das kann man gut oder schlecht finden. Egal wie man es dreht, es hat zumindest Vor- wie auch Nachteile.

In gängigen (vor allem Enduser) Geräten ist Microsoft mit einem KEK und mehreren CA Keys vertreten, sodass ein großer Teil dieser Hardware eben durch das Wohlwollen von Microsoft abgehandelt wird. Das muss man halt so akzeptieren oder man nimmt es selbst in die Hand -> PK Austausch und eigene PKI. Das geht zumindest via Linux natürlich. Bei Windows als OS aber wird das nix.

 

[MaverickM]

Secure Boot ist keine Single Stage Prüfung. Sondern eine Multi-Stage "chain of trust" Architektur.

Alles schön und gut, aber darum ging es ja in der ursprünglichen Aussage gar nicht. Dort wurde attestiert, dass Secure Boot für Kernel-Level-Anti-Cheats notwendig bzw. gleichbedeutend wäre. Das hat gar nichts miteinander zu tun.

 

[fdsonne]

Dort wurde attestiert, dass Secure Boot für Kernel-Level-Anti-Cheats notwendig bzw. gleichbedeutend wäre. Das hat gar nichts miteinander zu tun.

Das steht doch dort aber gar nicht?

Da oben steht dass "Secure-Boot per Default Betriebssysteme mit Lücken bootet und M$ root-kits (vulgo Anti-Cheat) per Default zulässt". Das wurde kritisiert...

Darauf hin antwortetest du, dass das gar nix miteinander zu tun hat. Doch, hat es. Der Prozess des Secure Boots sieht auch vor, die Kernel Signaturen sowie Kernel Treiber Signaturen zu prüfen. Aber eben erst in einer späten Phase. Das heißt aber nicht, dass sowas pauschal immer erlaubt ist - der Knackpunkt ist hier, dass Microsoft es zulässt und in der Kette wird eben "vertraut" dass Windows hier korrekt agiert. Wie lang die Kette ist, definiert letztlich die Kette selbst. Technisch wäre es möglich mit einem validen first stage Boot Loader einfach aufzuhören und dann einfach alles danach zu booten. Das ergibt Sicherheitstechnisch aber absolut keinen Sinn. Insofern ist das technisch zwar möglich, praktisch aber so aktuell meines Wissens nach nicht ohne eigenen PK mit eigener PKI möglich.

Versuch doch mal unsignierte Treiber in Windows mit aktivem Secure Boot zu laden Das wird nicht funktionieren. Es gibt Möglichkeiten diese Sicherheitschecks zu deaktivieren. In aller Regel ist die Kette aber eben aufeinander aufbauend und mit aktiven Secure Boot kommst du eben nicht weit.

Man sollte sich aber eben wie ich oben auch schon angedeutet habe, davon lösen, dass das Thema nur aus der Nutzerbrille zu betrachten ist. Am Ende definieren hier externe Parteien eine Trust Kette - und der Nutzer kann dem entweder zustimmen oder eben nicht. Im Fall von Anti-Cheat Treibern im Windows ist das zumindest fragwürdig, ob das so funktionieren sollte. Denn es untergräbt aus Nutzersicht die Sicherheit des Systems definitiv.

 

[foofoobar]

Wenn du mir mein Notebook mopst und da ein UEFI PW verhindert, dass die Settings gedreht werden, TPM verwendet wird um Keys zu speichern, der TPM Tresor via Password nicht im Klartext lesbar ist und gleichzeitig die Boot Order hart auf die interne Disk bzw. den Bootmanager gedreht ist, ohne Boot von externen Medien ala USB, LAN, ... -> dann ist die Kiste nicht von extern auf machbar.

Dieses Szenario kann man mit LUKS abdecken, ohne secure-foo und TPM.

Natürlich ist das nur eine Frage der Zeit, weil irgendwann in Jahren, Jahrzehnten oder Jahrhunderten die Technik so weit sein wird, dass via Bruteforce die Disk Encryption ausgehebelt werden kann. Aber bis dahin lässt einen das durchaus sicher schlafen.

Gibt es für Brute-Force genügend Energie im Universum?

https://www.google.com/search?q=anzahl+elektronen+im+universum

 

[Black Phoenix]

@Andy

Eventuell ne Erwähnung wert Andy.

Dies betrifft ALLE seit dem optionalen Update KB5074105 im Januar, was ja im Sicherheitsupdate Februar integriert ist.

Nebenbei noch die Erwähnung, da es in den letzten Tagen zu verschiedenen Meldungen kam. Diejenigen, die alte Drucker mit V3- und V4-Druckertreiber nutzen, können diese Drucker auch nach Januar 2026 nutzen. Es werden ab Juli 2027 zwar keine Treiber mehr über Windows Update verteilt. Die Treiber von den OEM-Seiten können aber weiterhin installiert werden, damit diese alten Drucker funktionieren.

Betrifft nur "legacy Drucker".

Quelle: Deskmodder confirmed durch hier Borns IT

 

[MaverickM]

Da oben steht dass "Secure-Boot per Default Betriebssysteme mit Lücken bootet und M$ root-kits (vulgo Anti-Cheat) per Default zulässt". Das wurde kritisiert...

Exakt, und das stimmt ja auch nicht.

Doch, hat es.

Nein, weder muss Software, die auf den Kernel zugreift Secure Boot voraussetzen, noch greift jede Software, die Secure Boot voraussetzt, zwingend auf den Kernel zu.

 

[Nuclear]

Secure Boot ist das erste was ich bei JEDEM PC, den ich in meine Griffel kriege, deaktiviere. Nur Probleme hat man damit, man kann sein USB Boot - Laufwerk nicht problemlos booten (meine diversen Rettungs ISOs usw), man kann nicht so ohne weiteres Linux installieren ohne ein "Enrollment" zu machen, usw.....

Die Mär von der zusätzlichen Sicherheit können die jemand anderem erzählen.

 

[andy_m4]

man kann sein USB Boot - Laufwerk nicht problemlos booten

Wobei genau das ja der Sinn von Secure-Boot ist.
Ist also kein Bug, sondern ein Feature :-)

Die Mär von der zusätzlichen Sicherheit können die jemand anderem erzählen.

Sagen wir mal so:
Windows hat an genug Stellen Sicherheitsprobleme. Da ist ein abgesicherter Boot-Vorgang oftmals nicht die größte Priorität. :-)

Was gerne mal als Beispiel genannt wird ist das Evil-Maid-Szenario. Also das quasi jemand zugriff auf Deine Hardware bekommt (also die "evil maid" auf Deinem Laptop im Hotelzimmer während Du beim Frühstück sitzt) und dann nicht einfach ein Stick booten kann, um Malware unterzujubeln etc.

Allerdings hat ein Angreifer der direkten Zugang zur Hardware hat, natürlich trotzdem eine Menge Angriffsmöglichkeiten.
Und Secure-Boot alleine hilft ohnehin nicht. Wenn man nicht gleichzeitig auch die "Platte" verschlüsselt, kann man sich Secure-Boot auch schon fast sparen.

Man kann aber auch generell mal die Frage stellen, wie gut UEFI ist. Das ist nämlich relativ komplex und damit auch allein durch die Komplexität potentiell fehleranfällig/problematisch.

Da stellt sich die Frage, ob sowas wie CoreBoot nicht besser wäre (was ja teilweise auch verwendet wird wie beispielsweise in Chromebooks).

 

[3!93D]

Was ich nicht verstehe ist warum diese Zertifikate getasucht werden müssen auch wenn älter.
Jede Webseite ändert Ihr SSL/TLS zertifikat einmal im Jahr oder aber auch bald öfters.

Eigentlich ist doch so ein Zertifikat sicher, denn es gibt einen Privaten Schlüssel und eben den öffentlichen Schlüssel. Dieses MS UEFI Zertifikat Update rollt doch nur den Öffentlichen Schlüssel aus, der dann irgendwo im MS Universum mit dem Privaten Schlüssel verglichen wird und matcht.

Das ein neues Zertifikat eingesetzt werden muss, bedeutet doch im Umkehrschluss die alten Private Keys sind geleakt, oder? Sonst ist es doch nicht notwendig die Zertifikate zu tauschen.
Wenn ein privater Schlüssel offen liegt, kann jeder der diesen Schlüssel hat, sich offiziel als Inhaber outen und Mist damit betreiben. Dann ist der Wechsel Sinvoll sonst ist es doch nicht notwendig auch wenn das Zertifikat älter ist. Oder gibt es eine maximale Zeitgrenze im Standard der Zertifikate, Haltbarkeitsdatum nicht älter als 15 Jahre?

 

[xexex]

Jede Webseite ändert Ihr SSL/TLS zertifikat einmal im Jahr oder aber auch bald öfters.

Richtig! Aber wer bestätigt die Gültigkeit dieses Zertifikats? Eine Authentifizierungsstelle (CA). Das Zertifikat läuft aber irgendwann aus und muss getauscht/verlängert werden.

Bei einem Windows-PC kommen aktualisierte Zertifikate regelmäßig über die Update Funktion, manche Browser verwalten sogar eigene Zertifikatsketten. Nun aber das CA Zertifikat im UEFI ergänzt werden, weil das 2011er nach 15 Jahren Gültigkeit abläuft.

 

[andy_m4]

Was ich nicht verstehe ist warum diese Zertifikate getasucht werden müssen auch wenn älter.

Weil Zertifikate üblicherweise ein Ablaufdatum.

Warum haben Zertifikate ein Ablaufdatum?

Na wie Du so schön sagst: Ein Private-Key kann auch mal geleakt werden. In dem Falle muss das Zertifikat widerrufen werden. Das passt aber nicht irgendwie automatisch, weil Du ja dann auf dem entsprechenden Endgerät aktiv das Zertifikat entfernen bzw. invalidieren musst.
Sprich: Der Prozess des Widerrufens ist fehleranfällig. Um möglichen Schaden zu minimieren begrenzt man die Gültigkeit. Dann verhinderst Du, das auf "ewig" kompromittierte Keys benutzbar bleiben.

 

[foofoobar]

Bei einem Windows-PC kommen aktualisierte Zertifikate regelmäßig über die Update Funktion, manche Browser verwalten sogar eigene Zertifikatsketten.

Das bestimmte Browser eigene Root-CAs mitbringen ist unter anderem der Zertifikatspolitik von M$ geschuldet welche sich primär am Shareholdervalue orientiert.

Auch hier kann man gut sehen das es primär um Shareholdervalue geht und nicht um Sicherheit:

Hinzu kommt: Entwickler, die keine Ressourcen für die Code-Signierung aufbringen können oder wollen, werden faktisch von einem breiten Teil der Windows-Nutzerbasis ausgeschlossen. Besonders hart trifft das Open-Source-Projekte und Entwickler, die sich teure Code-Signing-Zertifikate von Microsoft nicht leisten können oder wollen.

https://www.heise.de/meinung/Kommen...uch-bei-Windows-der-falsche-Weg-11173252.html