Ab 2026 sollen ja die Zertifikate abgelaufen sein, und Rechner mit Secure Boot nicht mehr hochfahren. Jetzt habe ich im UEFI-Bios nachgesehen und stelle fest, dass dort noch die "alten" Zertifikate mit Angabe "2011" sind. Die Prozedur zur Aktualisierung ist für mich derart undurchschaubar, dass ich hier einmal nachfragen möchte, was wohl das Beste wäre. Also: Microsoft schlägt vor: Erst einmal BIOS UEFI updaten. Möchte ich machen, aber dann verlangt die Herstellerseiteninfo ein vollständiges Motherboard Firmware Update. Geht da irgendetwas durch Fehleingabe schief, läßt sich das Motherboard nicht mehr ansprechen -> Schrott. Dann heißt es bei Microsoft: Updates für das BIOS und die Zertifikate werden schrittweise mit den monatlichen Updates und Patches ausgerollt. Man müsse nur ein Update von Februar 2024 schon besitzen, dann würde die BIOS-Updatefunktion automatisch laufen. Letzte Möglichkeit wäre natürlich Secure boot zu disablen. Microsoft sagt: Dann bekommt man keine Sicherheitsupdates mehr. Also. Was soll man tun? Abwarten und Tee trinken ist wohl keine Option. ciao gustav P.S.: Momentan steht in Ereignisanzeige zwar noch "...Der Softwareschutzdienst hat die Überprüfung des Lizenzierungsstatus abgeschlossen..." Aber spätestens ab 2026 kommt der große Crash, dem ich meinerseits vorbeugen möchte.
:
Bearbeitet durch User
Karl B. schrieb: > Aber spätestens ab 2026 kommt der große Crash, dem ich meinerseits > vorbeugen möchte. Ich kenne mich damit zwar nicht aus, aber für dich könnte Linux eine Alternative sein.
Mein Win10 sagt, dein Zeug ist zu alt für Win11! Ich nutze weiter meinen Verbrenner ;-)
Karl B. schrieb: > Man müsse nur ein Update von > Februar 2024 schon besitzen, dann würde die BIOS-Updatefunktion > automatisch laufen. Hast Du das gemacht?
Christian M. schrieb: > Mein Win10 sagt, dein Zeug ist zu alt für Win11! Ich nutze weiter meinen > Verbrenner ;-) Klar. Neues Motherboard Pro Z690-A DDR4 AMI BIOS 1.10.13.12.2021 viel zu alt, klar. Win 11 24H2 Build:26100.4946 Update: (KB5063878) (26100.4946) Alles in den Müll. https://learn.microsoft.com/de-de/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11 ciao gustav
Angehängte Dateien:
-
Secure_boot_Certs.jpg
79 KB -
Auf_Aus_Setzen.jpg
20 KB
Und weg mit dem neumodischen Schickschnack. ciao gustav
:
Bearbeitet durch User
Also, die Angst vor einem Bios-Update-Fehlschlag ist ein Risiko, das man eingehen kann. Wenn es einen gibt sollte man den einspielen, alleine schon für Sicherheitslückenaktualität und Microcodeupdates bzgl. Energieverbrauch und teilweise auch Brandgefahr. Das geht normal nicht schief, außer man hat Stromausfall in dem Moment, und moderne Boards haben eh ein Reservebios, das im Fehlerfall einspringt. Den Secureboot abzuschalten ist die beste Wahl wenn man Angst vor dem Fail des Signaturupdates hat, der ist dann nämlich egal. Allerdings gibt es mittlerweile Software die nur auf Securebootgeräten läuft... Das solche PCs allerdings keine Updates mehr bekämen wäre mir neu. Ich hab das auf allen Rechnern deaktiviert (schließlich soll auch Windows nicht am PC oder BIOS rumpfuschen) und habe die aktuellste Variante laufen.
Karl B. schrieb: > Ab 2026 sollen ja die Zertifikate abgelaufen sein, und Rechner mit > Secure Boot nicht mehr hochfahren. Hast Du dafür eine Quelle?
https://www.borncity.com/blog/2025/06/30/microsofts-uefi-secure-boot-zertifikat-laeuft-im-juni-2026-ab/ "... der Versuch Microsofts, das im Oktober 2026 auslaufende Zertifikat über Windows Update zu aktualisieren, ist gründlich schief gegangen" https://support.microsoft.com/en-us/topic/windows-secure-boot-certificate-expiration-and-ca-updates-7ff40d33-95dc-4c3c-8725-a9b95457578e
:
Bearbeitet durch User
Karl B. schrieb: > Letzte Möglichkeit wäre natürlich Secure boot zu disablen. > Microsoft sagt: Dann bekommt man keine Sicherheitsupdates mehr. Da bin ich mal gespannt. Ob Microsoft wohl vorhat, die digitale Autonomie weltweit zu fördern, indem unzählige Ämter völlig überraschend die Fähigkeit zu Windows-Updates verlieren? :)
:
Bearbeitet durch User
(prx) A. K. schrieb: > https://www.borncity.com/blog/2025/06/30/microsofts-uefi-secure-boot-zertifikat-laeuft-im-juni-2026-ab/ > > "... der Versuch Microsofts, das im Oktober 2026 auslaufende Zertifikat > über Windows Update zu aktualisieren, ist gründlich schief gegangen" Danke Dir! Naja, bis Oktober 2026 fließt noch sehr viel Wasser den Rhein herunter. Kein Grund, schon jetzt paranoid zu werden.
Jens M. schrieb: > Den Secureboot abzuschalten ist die beste Wahl wenn man Angst vor dem > Fail des Signaturupdates hat. der ist dann nämlich egal. Zweimal nein. Das Update kommt (bzw. kam schon) automatisch, und dann funktioniert es eben oder nicht. Das Abschalten von Secure Boot hat überhaupt keinen Einfluss auf irgendwelche Updates. Und nein, es ist nicht egal, wenn der BIOS-Inhalt wg. einem schiefgegangenem Update fehlerhaft ist.
:
Bearbeitet durch User
Rainer Z. schrieb: > Kein Grund, schon jetzt paranoid zu werden. Du erinnerst dich, wie überraschend für Ämter, Bundestage und wohl auch einige Unternehmen das sehr lange angekündigte Ende von Windows 7 kam? Mit heftigen Zusatzkosten für Verlängerung des Supports.
Rolf schrieb: > Das Abschalten von Secure Boot hat > überhaupt keinen Einfluss auf irgendwelche Updates. Das ist korrekt. Aber Windows schert sich nicht um das abgelaufene Zert wenn SB aus ist. Rolf schrieb: > Das Update kommt (bzw. kam schon) automatisch, und dann > funktioniert es eben oder nicht. Da war ja auch noch was mit "es ist kein Platz mehr im Flash, ach scheiß drauf, dann hat jeder Rechner halt zufällig andere Schlüssel drin, was solls". Ja, da gings um zurückgezogene/gesperrte Bootloader, aber das Windows einfach so die Schlüssel tauscht wird nicht überall funktionieren. Wäre das erste Mal das MS Software schreibt, die überall 100% klappt.
(prx) A. K. schrieb: > dann würde die BIOS-Updatefunktion > automatisch laufen. Ich würd niemals irgend einer Software erlauben, an meinem Bios rum zu pfuschen... Oder haftet Microsoft, wenn der Rechner im Anschluss daran nicht mehr hoch fährt?
Kurt schrieb: > Ich würd niemals irgend einer Software erlauben, an meinem Bios rum zu > pfuschen... Windows bittet nicht um Erlaubnis
Kurt schrieb: > (prx) A. K. schrieb: >> dann würde die BIOS-Updatefunktion >> automatisch laufen. Der Text stammt nicht von mir.
Kurt schrieb: > Oder haftet Microsoft, wenn der Rechner im Anschluss daran nicht mehr > hoch fährt? Durch Updates gebrickte Rechner kommen gelegentlich vor. Mir spukt in diesem Zusammenhang Fujitsu im Kopf herum. Kann vorkommen, dass der Hersteller oder Händler konziliant wird, wenn nicht Oma Müller vor der Tür steht, sondern ein grösseres Unternehmen. Wie Händler, Hersteller und Microsoft das dann untereinander klären, kriegt man üblicherweise nicht mit.
:
Bearbeitet durch User
Kurt schrieb: > Oder haftet Microsoft, wenn der Rechner im Anschluss daran nicht mehr > hoch fährt? Könnte schwierig sein, sich aus der Haftung rauszuwinden, wenn man den Update selbst erzwungen hat. Wie es bei Microsoft ja mittlerweile Usus ist.
:
Bearbeitet durch User
Jens M. schrieb: > Das geht normal nicht schief, außer man hat Stromausfall in dem Moment, > und moderne Boards haben eh ein Reservebios, das im Fehlerfall > einspringt. Ist das so? Auch wenn ich nicht mehr die Hand am Puls habe, so lese ich doch immer noch, aber dass die Rechner quasi ein "Basis-Bios" haben, ist mir neu.
Frank O. schrieb: > Ist das so? Wie verbreitet das ist weiss ich nicht, aber es gibt Geräte - mit 2 Banks für das Zeug, alternierend, - oder einem reduzierten Notfallsystem, das im Boot quasi blind auf bestimmte USB-Sticks reagiert.
:
Bearbeitet durch User
Würde, falls irgendwas wegen abgelaufenem Zertifikat nicht mehr funktioniert, helfen, die Uhrzeit (RTC) vorübergehend zur Reparatur zurückzustellen?
F. P. schrieb: > Würde, falls irgendwas wegen abgelaufenem Zertifikat nicht mehr > funktioniert, helfen, die Uhrzeit (RTC) vorübergehend zur Reparatur > zurückzustellen? Theoretisch vielleicht, nur darf die Kiste dann natürlich kein Netzwerk sehen.
(prx) A. K. schrieb: > das im Boot quasi blind auf > bestimmte USB-Sticks reagiert. Das wäre heute sinnvoll. Immerhin kannst du den Käfer nicht mehr ausbauen und in einen Programmer stopfen. Danke für diesen Hinweis!
(prx) A. K. schrieb: > Frank O. schrieb: >> Ist das so? > > Wie verbreitet das ist weiss ich nicht, aber es gibt Geräte > - mit 2 Banks für das Zeug, alternierend, > - oder einem reduzierten Notfallsystem, das im Boot quasi blind auf > bestimmte USB-Sticks reagiert. Es gibt auch welche mit Flash-Taste an der Rückseite, womit das Flashen von USB-Laufwerk gestartet wird (der Code dafür wird nicht überschrieben).
(prx) A. K. schrieb: > Rainer Z. schrieb: >> Kein Grund, schon jetzt paranoid zu werden. > > Du erinnerst dich, wie überraschend für Ämter, Bundestage und wohl auch > einige Unternehmen das sehr lange angekündigte Ende von Windows 7 kam? > Mit heftigen Zusatzkosten für Verlängerung des Supports. Aber ja. Und ich verstand auch nicht, weshalb "Ämter, Bundestage und wohl auch einige Unternehmen" es nicht geschafft haben, rechtzeitig auf eine neue Version umzusteigen. Tja, wer weiß, vielleicht ist der verlängerte Support sogar ökonomischer als eine Neuanschaffung und Aktualisierung des Systems? Aber um eine veraltete Windows-Version geht es hier nicht.
Rainer Z. schrieb: > Aber um eine veraltete Windows-Version geht es hier nicht. Sondern um Termine, die so lange ignoriert werden, bis dies akut in den Hintern kneift. Ob es dabei um die Version von Windows geht, oder die Version der Boot-Zertifikate, ist sekundär. Und in beiden Fällen geht es um Systeme, die nicht mehr aktualisiert werden können. Aber vielleicht ist es diesmal nur ein laues Lüftchen, das in der Breite keine Rolle spielt.
:
Bearbeitet durch User
Frank O. schrieb: > Ist das so? Ja ist mittlerweile üblich, mein Laptop hat auch ein Recovery Bios. T14 Gen 1 mit Ryzen 5 von Lenovo, geht das Update schief startet automatisch das Recovery und nach wenigen Minuten ist man bereits wieder mit der älteren Version arbeitsbereit.
(prx) A. K. schrieb: > Aber vielleicht ist es diesmal nur ein laues Lüftchen, das in der Breite > keine Rolle spielt. Wenn die im Hintergrund laufenden Update-Prozesse die neuen Keys nicht ins Rechner-Flash bekommt, ist der Rechner nach dem Ablaufdatum gebrickt, falls Secure Boot aktiv ist. Da das Thema aber seit Monaten durch alle einschlägigen Medien incl. Youtube geistert, sollte jeder einigermaßen helle Admin das auf dem Schirm haben. Oliver
:
Bearbeitet durch User
Jens K. schrieb: > Ich kenne mich damit zwar nicht aus, aber für dich könnte Linux eine > Alternative sein. Falls dein Linux auf einem Rechner mit Secure Boot läuft, wirst du im Fall des Falles eine böse Überraschung erleben. Microsoft bedeutet in dem Fall nicht Windows. Oliver
Jens K. schrieb: > Ich kenne mich damit zwar nicht aus, aber für dich könnte Linux eine > Alternative sein. Microsoft stellt auch Zertfikate für Fremd-OS wie Linux zur Verfügung. Ohne Zertifikate kein sicherer Boot.
Udo K. schrieb: > Jens K. schrieb: >> Ich kenne mich damit zwar nicht aus, aber für dich könnte Linux eine >> Alternative sein. > > Microsoft stellt auch Zertfikate für Fremd-OS wie Linux zur Verfügung. > Ohne Zertifikate kein sicherer Boot. Hier kann man den Status der Zertifikate überprüfen und updaten (habe ich nicht getestet): https://github.com/cjee21/Check-UEFISecureBootVariables#viewing-all-the-uefi-secure-boot-variables
Angehängte Dateien:
-
Update_failed.jpg
47 KB
(prx) A. K. schrieb: > Durch Updates gebrickte Rechner kommen gelegentlich vor. Mir spukt in > diesem Zusammenhang Fujitsu im Kopf herum. Yep. Gestern bei mir auch. Das Fuji Notebook reagiert mit: Hatte dreimal versucht "wiederholen": Gelblich unterlegtes PopUp: "Neuinstallation des Windows nötig..." Komisch: sfc scannow hat keine Fehler gefunden. Was ist da dann an Systemkomponenten kaputt? Und ja, Secure Boot ist enabled. Und, der Rechner läuft ja noch. Dasselbe Update klappte aber beim "großen" Desktop PC. Der Win 10 Rechner ließ sich gestern auch (noch) problemlos updaten. ciao gustav
:
Bearbeitet durch User
Oliver S. schrieb: > Wenn die im Hintergrund laufenden Update-Prozesse die neuen Keys nicht > ins Rechner-Flash bekommt, ist der Rechner nach dem Ablaufdatum > gebrickt, falls Secure Boot aktiv ist. So? "Gebrickt" bedeutet in diesen Kontext, dass der Rechner wie ein Ziegelstein (brick) ist: Ein handliches, totes Stück Material, mit dem man praktisch nichts mehr anfangen kann, außer es in die Hand zu nehmen und wegzuwerfen. AFAIK wurde dieser Begriff ursprünglich für Handys benutzt, bei denen das Rooten nicht geklappt hat. In unserem Fall schaltet man einfach Secure Boot ab, dann läuft der Rechner wieder. Er wird also nicht zum Brick.
Mainboards sind inzwischen wirklich sicher, was Bios-Updates angeht. Diese tief verwurzelte Urangst aus 486er-Zeiten kann man hinter sich lassen. Bei manchen Boards lässt sich das Bios sogar ohne CPU, ohne gesteckten RAM und mit ausgeschaltetem Netzteil (Also nur 5Vsb) flashen. USB-Stick in den richtigen Port, Knöpfchen drücken, warten bis das Blinken aufhört, fertig.
Frank O. schrieb: > Auch wenn ich nicht mehr die Hand am Puls habe, so lese ich > doch immer noch, aber dass die Rechner quasi ein "Basis-Bios" haben, ist > mir neu. Gibt verschiedenes, schon seit Jahrzehnten. Automatisches Dualboot, manuelles (mit Brücke, mit 5x Abwürgen, und und und), Hilfsbiosdings mit "Stick mit bestimmter Datei in bestimmten Port stecken". Und normalerweise sind Biosupdates heute a) Windowsprogramme und b) beinahe tägliches Geschäft, nicht wie früher Boot-irgendwasse mit Kommandozeile. Lenovo updated das BIOS über den normalen Lenovo-Updater, beinah jeden Monat. Karl B. schrieb: > Gelblich unterlegtes PopUp: > "Neuinstallation des Windows nötig..." Evtl. musst du den Patch nur manuell installieren.
Mittlerweile mal ein bootfähiges Win11 Medium auf USB erstellt, für alle Fälle. Noch die Keys ausgelesen mit dem dafür empfohlenen Tool und diese aufgeschrieben. Dann nochmal ins Bios geschaut. (Bios Setup Utility, Fujitsu E5411) Also doch ein Win10 auf Win11 gepimpt. Und auch da die "alten 2011-er" Zertifikate. Werde Tipp befolgen und Secure Boot abschalten im BIOS. Mal sehen, wie sich das in Zukunft entwickelt, ob die Redmonter sich noch etwas Intelligenteres einfallen lassen. ciao gustav P.S.: Mein Virenscanner sucht zunächst Systembereiche, dann Rootkits, dann erst rast der Virenscanner los. Was soll Secure Boot überhaupt Besseres vollbringen als es solchige Virenscanner-Programme schon von sich aus tun?
:
Bearbeitet durch User
Karl B. schrieb: > Was soll Secure Boot überhaupt Besseres vollbringen als es solchige > Virenscanner-Programme schon von sich aus tun? Andere Baustelle. https://it-wegweiser.de/secure-boot/
:
Bearbeitet durch User
SB soll verhindern, das die Mühle solche Dateien überhaupt erst startet, während der Scanner mit Glück irgendwann später herausfindet, dass das ja wohl nicht da hin gehört.
Karl B. schrieb: > Letzte Möglichkeit wäre natürlich Secure boot zu disablen. > Microsoft sagt: Dann bekommt man keine Sicherheitsupdates mehr. > Also. > Was soll man tun? > Abwarten und Tee trinken ist wohl keine Option. dann schaue dir Folgendes mal an https://www.youtube.com/watch?v=nVPQigviHkU
Joachim B. schrieb: >> Was soll man tun? >> Abwarten und Tee trinken ist wohl keine Option. Du brauchst gar nichts zu tun. Mache deine Arbeit, und lass Windows seine Updates machen. Wenn du so eine alte Gurke hast, die Windows nicht mehr updaten mag, dann lass sie ohne Updates weiterlaufen. Kein Grund hier Panik zu verbreiten. > dann schaue dir Folgendes mal an > https://www.youtube.com/watch?v=nVPQigviHkU Ist doch blödes Clickbaiting. Ich brauche Admin Rechte um in meinem Windows/System32/config Ordner eine Datei zu erstellen oder zu löschen. Probiere mal "rm -rf /" mit root Rechten auf deinem Linux, -rf steht für really fast...
Udo K. schrieb: > Du brauchst gar nichts zu tun. Mache deine Arbeit, und lass Windows > seine Updates machen. Gestern habe ich auch ein Update bekommen. Da stand das mit den Zertifikaten. Ich denke auch, dass man selbst nicht aktiv werden muss.
Angehängte Dateien:
-
Problembericht.png
11 KB
Frank O. schrieb: > Udo K. schrieb: >> Du brauchst gar nichts zu tun. Mache deine Arbeit, und lass Windows >> seine Updates machen. > > Gestern habe ich auch ein Update bekommen. Da stand das mit den > Zertifikaten. > Ich denke auch, dass man selbst nicht aktiv werden muss. Glaube ich nicht. Laut Problembericht ist da etwas vermurkst. Beim anderen Rechner funktionierte es ja. Manueller Installationsversuch bleibt im Status "Initialisierung" stehen. ciao gustav
Karl B. schrieb: > Dann nochmal ins Bios geschaut. (Bios Setup Utility, Fujitsu E5411) > Also doch ein Win10 auf Win11 gepimpt. Und auch da die "alten 2011-er" > Zertifikate. Wie gründlich hast du denn nachgesehen? Die alten sind natürlich noch drin, die lassen sich gar nicht löschen bzw. überschreiben, in dieser BIOS-eigenen Sperre liegt ja gerade die Sicherheit. Es geht darum, dass zusätzlich die neuen drin sind. Das ist aber AFAIK kaum ein Problem. Die hat inzwischen wahrscheinlich ohnehin jeder in seinem BIOS. ABER: Es gibt im BIOS eine zweite Datenbank, in der eingetragen wird, welche auf jeden Fall ungültig sind, selbst wenn sie noch nicht abgelaufen sind. Auch diese Einträge lassen sich nicht löschen bzw. überschreiben. Und hier liegt das eigentliche Problem: Manche alten BIOS-Versionen haben nicht genug Platz dafür, weil – was so vor 10+ Jahren nicht bedacht war – es mehr als 100 sein können.
Karl B. schrieb: > Manueller Installationsversuch bleibt im Status "Initialisierung" > stehen. In deinem Fall ist das klar und wohl echt Pech. Ich meinte das eher auf die Allgemeinheit bezogen.
Jens M. schrieb: > SB soll verhindern, das die Mühle solche Dateien überhaupt erst startet, > während der Scanner mit Glück irgendwann später herausfindet, dass das > ja wohl nicht da hin gehört. Wobei die Viren auch schon aufgerüstet haben: https://www.heise.de/news/Microsoft-reagiert-auf-Malware-in-ueber-100-signierten-Windows-Treibern-9213637.html Wenn die Zertifikate in einem Jahr nicht geupdated werden wird auch nichts großartiges passieren. Windoof wird einfache weiterlaufen, mit marginal weniger Sicherheit.
Karl B. schrieb: > Aber spätestens ab 2026 kommt der große Crash, dem ich meinerseits > vorbeugen möchte. Ich habe, seit ca. 3 Jahren, ein "HP Elite Dragonfly 13.5 inch G3 Notebook PC/897F, BIOS U90 Ver. 01.14.00 01/13/2025", auf dem Devuan installiert ist. Kein Windows. Firmware Updates bekomme ich über fwupd / lvfs, und die kommen auch in KDE Discover automatisch. Jetzt hab ich mal nachgesehen, wie es um die Secure Boot Zertifikate steht, aber die scheinen noch nicht aktualisiert worden zu sein... Um das nachzusehen, hab ich die EFI Einträge erst mal mit efi-readvar ausgelesen, wie hier beschrieben: https://ubs_csse.gitlab.io/secu_os/tutorials/linux_secure_boot.html Dann hab ich mit dem Tool da die Zertifikate daraus ausgelesen: https://github.com/developer-corner/extract-sig-list Da werde ich wohl doch noch versuchen müssen, eigene Keys zu hinterlegen. Letztes mal hatte ich das aufgegeben, weil es mir zu riskant war. Könnte ja wenn es blöd kommt plötzlich gar nichts mehr gehen... Einfach einen per UEFI zur DB hinzufügen geht bei dem Laptop leider nicht einfach so... Man kann darüber wohl die Keys / DBs irgendwie ersetzen, aber das scheint recht riskant zu sein, man muss das irgendwie alles am richtigen Ort ablegen usw. Also auch nicht einfacher, als das selbe unter Linux zu machen. Bei der Anleitung oben sieht es so aus, als ob die KEK Keys updates mit dem PK signiert sind, und die DB Updates mit einem der KEK keys, ist das richtig? Und der PK Key kann nur ersetzt werden, wenn vorher im Bios alle Keys gelöscht wurden? Ich muss mal ausprobieren, ob das bei meinem Laptop geht... Schade, das es keinen weg zu geben scheint, einfach einen eigenen Key zur DB hinzuzufügen, und ich da wohl alles ersetzen muss. Das kann momentan wohl nur HP und MS, weil nur die per default Keys im KEK drin haben. Ich nehme an, den HP Key muss ich wieder rein nehmen, der wird sicher für HPs eigene UEFI Firmware gebraucht? MS Keys kann ich dann ja entfernen, weil ich Grub & Kernel dann selber signieren kann. PS: Wenn einem das 2023 Zertifikat fehlt, die MS Zertifikate scheint es hier zu geben: https://github.com/microsoft/secureboot_objects
:
Bearbeitet durch User
Ich hab es mittlerweile hin bekommen, meine eigenen Keys zu hinterlegen. War ein ziemlicher Krampf. Als ich den PK Key hinterlegen wollte, stand dort als Grösse -4, und ich musste erst den PC Rebooten, bevor ich das machen konnte, und dann ist in der Anleitung auch noch die falsche Datei angegeben... (man braucht die .auth Datei, nicht die .esl Datei, für den PK. Oder vermutlich könnte man auch mit -k den Key nochmal angeben, wenn man die .esl nimmt). Zuerst hatte ich noch die Debian CA in die db mit reingetan. Die shim.efi war aber mit dem MS key signiert. Also habe ich das shim-signed Paket deinstalliert, und ein "grub-install --uefi-secure-boot" gemacht . Dann ist grub gestartet, ist ja von debian signiert. Aber ohne den shim lässt es mich den linux kernel nicht laden wenn secure boot eingeschalten ist. Fehlermeldung war irgendwas wegen "shim lock" nicht vorhanden... "grub-install" mit "--disable-shim-lock" ging nicht, ist in debian kaputt. Also shim-signed wieder installiert. Jetzt hab ich den halt signiert:
1 | grub-install --uefi-secure-boot --disable-shim-lock --modules="$grub_modules" |
2 | cp /usr/lib/shim/shimx64.efi /boot/efi/EFI/debian/shimx64.efi |
3 | sbsign --key master.key --cert master.crt /boot/efi/EFI/debian/shimx64.efi |
4 | cp /boot/efi/EFI/debian/shimx64.efi.signed /boot/efi/EFI/debian/shimx64.efi |
Dann den debian key wieder entfernt. War auch mühsam. Erst waren die efivars alle immutable, dann ging die .auth Datei nicht (efi-updatevar -f db.auth db) (eventuell schon zu alt?), aber mit (efi-updatevar -e -f db.esl -k master.key db) ging es dann... (Ich habe in PK, KEK, und db den selben Key rein getan. Normalerweise nimmt man da unterschiedliche, brauch ich aber nicht wirklich, und ist einfacher). -- Um zum Thema zurückzukommen, so könnte man natürlich auch die neuen Windows Keys manuell ins uefi bringen, wenn man sich das antun will. Rolf schrieb: > Wie gründlich hast du denn nachgesehen? Die alten sind natürlich noch > drin, die lassen sich gar nicht löschen bzw. überschreiben, in dieser > BIOS-eigenen Sperre liegt ja gerade die Sicherheit. Habe ich gerade gemacht, das geht. Man kann sowohl zur DB hinzufügen, als auch die ganze EFI variable, in der die gespeichert ist, ersetzen, sofern man den KEK Key hat.
:
Bearbeitet durch User
Daniel A. schrieb: >> ie lassen sich gar nicht löschen bzw. überschreiben, in dieser >> BIOS-eigenen Sperre liegt ja gerade die Sicherheit. > Habe ich gerade gemacht, das geht. Man kann sowohl zur DB hinzufügen, > als auch die ganze EFI variable, in der die gespeichert ist, ersetzen, > sofern man den KEK Key hat. Den privaten Teil des KEK hast du aber nicht, der steht ja nicht in der Firmware. Wenn ich dich richtig verstanden habe, hast du dich als OEM-Hersteller deines PC verkleidet und u. a. einen eigenen PK eingetragen. Damit besitzt du dann aber keinen Rechner von der Art, mit der sich Microsoft beschäftigt. Mit so einem PC wirst du nichts an Software laden können, das aus einer Quelle stammt, die deinen PK nicht kennt. Also ja, du kannst überschreiben, aber es nützt de facto nichts. Klar, wenn du das BIOS eines PC komplett selbst schreibst, dann kannst du dabei alle Sperren weglassen. Die UEFI-Sicherheit gilt für solche Rechner natürlich nicht – aber das ist hier ja nicht der Diskussionspunkt.
:
Bearbeitet durch User
Beitrag #7923471 wurde vom Autor gelöscht.
PK ist der Hauptkey der Maschine. Per default ist da das Zertifikat vom PC Hersteller. In der KEK sind die Keys von denen, die die DB Updaten können müssen. Normalerweise einer vom Hersteller, und einer von MS. Wenn man den privaten Teil des PK hat, kann man den KEK ändern. (Ob man das auch kann wenn man den privaten Teil eines der KEK schlüssel hat, bin ich mir gerade nicht sicher). In der DB sind dann die Keys, mit dem die Anwendungen signiert sind. Da reicht der private Teil von einem Key aus der KEK, um den zu ändern. EFI Firmware, Bootloader, usw. Die können dann manchmal auch noch eigenen Keystores haben, wenn sie selbst was nachladen. Rolf schrieb: > Den privaten Teil des KEK hast du aber nicht, der steht ja nicht in der > Firmware. Ja, am Anfang stand ich nicht in der KEK. Darum hab ich am Anfang alle Keys im Bios gelöscht (eine so vorgesehene Funktion), damit es mich neue eintragen lässt. Aber jetzt habe ich einen Key in der KEK, in der db, und den PK Key. > Wenn ich dich richtig verstanden habe, hast du dich als OEM-Hersteller > deines PC verkleidet und u. a. einen eigenen PK eingetragen. Ich hab mich im PK eingetragen. Das ist aber nicht sich "als OEM-Hersteller verkleiden". Das ist mein PC, ich bin Besitzer und Eigentümer, also ist es nur richtig, das ich den Master Key dafür habe. > Damit besitzt du dann aber keinen Rechner von der Art, mit der sich Microsoft > beschäftigt. Mit so einem PC wirst du nichts an Software laden können, > das aus einer Quelle stammt, die deinen PK nicht kennt. Doch. Der Software, inklusive Windows selbst, hat es egal zu sein, was in der PK und der KEK steht. Wenn die Anwendungen mit einem der Keys aus der db signiert sind, ist alles ok. Wenn man MS oder dem OEM noch erlauben will, die db zu verändern, packt man deren Key noch in die KEK. Für was anderes wird der nicht gebraucht. Das ist ein gewöhnliches Root of Trust System, ähnlich wie es das auch bei Webseiten mit SSL gibt. (Und auch da ist es den Webseiten egal, was für ein Key da genutzt wird, das prüft da der Browser, nicht die Webseite). > Also ja, du kannst überschreiben, aber es nützt de facto nichts. Doch. Ich könnte die 2023 MS Keys in die db packen, und könnte dann Windows auch nach 2026 mit Secure Boot starten. > Klar, wenn du das BIOS eines PC komplett selbst schreibst, dann kannst > du dabei alle Sperren weglassen. Die UEFI-Sicherheit gilt für solche > Rechner natürlich nicht – aber das ist hier ja nicht der > Diskussionspunkt. Am Bios habe ich gar nichts geändert. Ich habe lediglich per UEFI, im setup mode, über die dafür vorgesehenen UEFI Schnittstellen, die PK, KEK, und db Keys neu gesetzt. Und dann hab ich, auch normal per UEFI, mit eingeschaltetem Secure Boot, die db keys nochmal ersetzt, und dabei einen Key entfernt. Das zeigt, dass MS und der Hersteller, auch Keys entfernen könnten, denn wie ich nun, haben/hatten die in der KEK ja auch einen Key.
Wo ist denn die Sicherheit des Secureboot-Systems, wenn jeder einfach so ins Bios gehen kann und da "seine" Keys eintragen kann? Du schreibst, du da jetzt eigene Keys drin hast, d.h. du kannst jetzt trotz Secureboot eigene Software laufen lassen. Die kann dann ja wieder alles machen, also eben auch Malware sein. Letztendlich müsste ja nur ein "Update" deine Keys eintragen und schon läuft dein "Superspymalwarevirusrootkit" auch auf meinem PC.... Das kann doch nicht der Sinn des Ganzen sein? Warum hast du solche Schlüssel, bzw. wie einfach/günstig ist es die zu bekommen? Weil letztendlich ist das was du da gemacht hast ja genau das was vor dem Stichtag passieren muss: einmal alle Keys durchtauschen. Wenn man da drauf achtet das es auch mit alten W10-Installationen geht, hat man ja eigentlich das "jeden PC wieder flottmachen"-Dings.
Jens M. schrieb: > Wo ist denn die Sicherheit des Secureboot-Systems, wenn jeder einfach so > ins Bios gehen kann und da "seine" Keys eintragen kann? Ganz einfach: nicht jeder sitzt physisch vor dem PC, und kann so ins Bios rein. Und wenn man die eigenen Keys mal drin hat, hat man seine privat Keys idealerweise an einem sicheren Ort abgelegt, wo andere & Malware nicht einfach so dran kommen. Mit dem kann man dann nämlich die Keys auch updaten, ohne ins Bios gehen zu müssen. Jens M. schrieb: > Du schreibst, du da jetzt eigene Keys drin hast, d.h. du kannst jetzt > trotz Secureboot eigene Software laufen lassen. Die kann dann ja wieder > alles machen, also eben auch Malware sein. Ja klar, man muss halt aufpassen, was man mit seinen Keys signiert. Die Malware selbst kennt deinen Key nicht. Ein Gerät vor Malware zu schützen ist schon schön und gut, aber vor Dir sollte DEIN gerät nicht "geschützt" werden. Jens M. schrieb: > Letztendlich müsste ja nur ein "Update" deine Keys eintragen und schon > läuft dein "Superspymalwarevirusrootkit" auch auf meinem PC.... > Das kann doch nicht der Sinn des Ganzen sein? Wenn du bei dir meinen Key einträgst, und ich signiere ein "Superspymalwarevirusrootkit", ja, dann läuft das bei dir. Ist auch bei den OEM und MS Keys, die per drauf sind, nicht anders. Wenn MS oder der OEM dann ein "Superspymalwarevirusrootkit" signiert, läuft das. Aber wenn du selbst einen Key erstellst, und den im Bios hinterlegst, den hab ich nicht. Ausserdem, MS hat vermutlich schon versehentlich einige Rootkits signiert, wobei ich mit meinem Key nur gerade die ein zwei Anwendung signiere, die ich halt selbst für den Systemstart brauche. Jens M. schrieb: > Warum hast du solche Schlüssel, bzw. wie einfach/günstig ist es die zu > bekommen? Die kann sich jeder selbst erstellen. PS: Ich weiss das macht fast keiner, aber wenn ihr euren Laptop ausleiht, damit Reist, oder andere da ran kommen, solltet ihr auch ein Bios Passwort setzen, damit nicht jeder einfach so ein Rootkit installieren könnte :3
:
Bearbeitet durch User
Daniel A. schrieb: > Wenn du bei dir meinen Key einträgst, und ich signiere ein > "Superspymalwarevirusrootkit", ja, dann läuft das bei dir. Wir reden aber hier doch von dem Schutz durch die ganze UEFI-Mimik bzw. davon, dass der angeblich nicht existiert, weil jeder Dackel Daten in der Firmware manipulieren kann. Deine Malware müsste also bei mir vorab heimlich deinen Key eintragen. Kann sie das? > (Zertifikate) Die kann sich jeder selbst erstellen. 15 Zeilen Powershell für das RootCert und 15 Zeilen für das davon abgeleitete. Die von Powershell benutzte .NET-Library bringt alles Nötige mit.
Rolf schrieb: > Daniel A. schrieb: >> Wenn du bei dir meinen Key einträgst, und ich signiere ein >> "Superspymalwarevirusrootkit", ja, dann läuft das bei dir. > > Wir reden aber hier doch von dem Schutz durch die ganze UEFI-Mimik bzw. > davon, dass der angeblich nicht existiert, weil jeder Dackel Daten in > der Firmware manipulieren kann. > > Deine Malware müsste also bei mir vorab heimlich deinen Key eintragen. > Kann sie das? Nein, das kann sie nicht.
Rolf schrieb: > 15 Zeilen Powershell für das RootCert und 15 Zeilen für das davon > abgeleitete. Die von Powershell benutzte .NET-Library bringt alles > Nötige mit. Oder eine Zeile openssl.
Daniel A. schrieb: > Ganz einfach: nicht jeder sitzt physisch vor dem PC, und kann so ins > Bios rein. Wenn der Zugriffsschutz der ist, das ich vor deiner Maschine sitzen muss, dann glaub ich dir das kaum. Updates für BIOS, Microcode und anderen Kram aus dem Flashchip sind auch Windowsprogramme. Sicher das dieser Weg wirklich nur über den "mit Tastendruck ins BIOS und dann eine Datei laden" geht? Daniel A. schrieb: > Ein Gerät vor Malware zu schützen ist schon schön und gut, aber vor Dir > sollte DEIN gerät nicht "geschützt" werden. Da bin ich bei dir. Meine Handys sind auch alle mit Root, damit da nur Software läuft mit der ich konform gehe. Mir ging es um den hypothetischen Fall, das du bösartig wärst, und meine Annahme stimmt, das so ein "Update" wie du ihn gemacht hast, ohne Benutzereingriff (maximal "dieses Programm muss als Administrator ausgeführt werden") funktioniert. Also - Daniel schreibt einen Bootmassakervirus - Signiert den - Aktualisiert das UEFI-Secureboot - Secureboot startet Bootmassakervirus weil "Secureboot ist an und alle Zertifikate sind Grün" - Daniel greift nach der Weltherrschaft Irgendwie scheint die ganze Lästerei über das totgepfuschte Secureboot und das man das nie irgendwie richtigpfuschen kann wahr zu sein. Daniel A. schrieb: > Ist auch bei den OEM und MS Keys, die per drauf sind, nicht anders. Nuja, denen muss man halt vertrauen. Irgendjemand muss ja der Grundlegendste Zertifizierer sein, dem alle glauben. Daher wundert mich das man so einfach sich selber zum Zertgott machen kann. Daniel A. schrieb: > Nein, das kann sie nicht. Sicher? Mir fällt auf, das diese "Sicherheit" wie so oft eher Probleme für den User bringt, aber dem Gerätehersteller und Softwarekonzern alle Freiheiten einräumt. Der Benutzer hingegen steht nach dem Willen der Großen mit Pech in 30 Sekunden ohne alles da.
Jens M. schrieb: > Mir fällt auf, das diese "Sicherheit" wie so oft eher Probleme für den > User bringt, aber dem Gerätehersteller und Softwarekonzern alle > Freiheiten einräumt. > Der Benutzer hingegen steht nach dem Willen der Großen mit Pech in 30 > Sekunden ohne alles da. Sehe ich auch so und zusätzlich räumen die Hersteller sich -wenn man dabei nicht genau hinschaut und wer guckt schon in die Updates rein- immer mehr und heimlich Rechte ein, die du ihnen vorher nicht gewährt hattest.
Jens M. schrieb: > lso, die Angst vor einem Bios-Update-Fehlschlag ist ein Risiko, das man > eingehen kann. Auf meinem Gigabyte "Brett" ist das BIOS doppelt gespeichert. Geht was schief kann ich immer noch das alte einspielen...
Beitrag "Re: Windows 11 Zertifikate" Kurzer Zwischenbericht: Nach ca. 2 Stunden Reparatur-Windows-Installation ist das besagte Notebook auf dem neusten Stand. Im Bios wurde Secure Boot vorher disabled. Das beanstandete KB ist nicht im Updateverlauf zu finden. Ist wohl schon drin bei der Reparaturinstallation. Da steht nur: Update 24H2. Vom Windows Old mit 16,1 GB datenträgerbereinigt. Danke an die zahlreichen Kommentare, die einem den Horizont öffnen. So wusste ich nicht, dass die BIOS-Update deswegen nicht gehen, weil beispielsweise unter Umständen nur maximal 100 Einträge für die Verweise auf DBs vorgesehen waren. Trotzdem wird dieses Thema noch bestimmt für weitere Diskussionen sorgen. Vorerst schönen Sonntag noch ciao gustav
Herbert Z. schrieb: > Auf meinem Gigabyte "Brett" ist das BIOS doppelt gespeichert. Geht was > schief kann ich immer noch das alte einspielen... Das dachte vor Jahren ein Azubi auch, hat leider nicht geholfen, weil ein Virus einiges verbogen hatte im BIOS und dann die CPU ganz böses Fieber bekam. MB= Schrott.
Lu schrieb: > Das dachte vor Jahren ein Azubi auch, hat leider nicht geholfen Dann war aber nicht das BIOS betroffen von dem Virus. Bei Dual-Bios Boards sind einer von beiden Flash Speicher IMMER physisch (mit einem Schiebeschalter) vom Strom und Bus getrennt.
Rene K. schrieb: > Dann war aber nicht das BIOS betroffen JA, Dein 2. BIOS war evtl. noch da. Der Virus hat damals im BIOS eingegriffen und die CPU überhitzt. Dann nützt auch das schönste 2. BIOS nix mehr, wenn die CPU es nicht vertragen hat und Leiterzüge vom MB weggebrannt sind. Das Böse lauert überall.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.