Hallo Forum,
habe am Wochenende die C't #13 gelesen und frage mich in wie weit
das jemand von Euch auf dem Radar hat.
Lauf dem Artikel werden alle PC's/Notbooks die von MS einen EUFI
Cert inne haben nicht mehr im UEFI Mode funktionieren können.
Falls sie Legacy im BIOS haben, können sie noch weiter verwendet
werden, falls nicht sind sie mit keinem Bootloader, weder unter
Windows noch unter Linux zu gebrauchen, sofern der Hersteller kein
FW-Update liefert.
Dies dürfte bei allen älteren Geräten der Fall sein.
Bei meinem NB mit dem ich den Beitrag gerade schreibe,
liefert mokutil z.B. für
1
PK:NotAfter:Jul1701:21:452014GMT
2
KEK:NotAfter:Jun2420:51:292026GMT
3
DB:Key1:NotAfter:Oct1918:51:422026GMT
4
Key2:NotAfter:Jun2721:32:452026GMT
5
DBX:NotAfter:Jul620:50:232025GMT
Für Windows hat die C't ein PS-Tool unter ct.de/y85v zur Verfügung
gestellt, mit dem die EFI Datenbanken-Einträge ausgelesen werden können.
Details im genannten Artikel.
Gibt es dazu Infos von Eurer Seite?
Bis dato habe ich darüber noch nichts in den Medien vernommen,
wobei es mir natürlich auch entgangen sein kann.
Für konstruktive Antworten schon mal mein Dank vorab.
Hallo Ernst,
danke für die beiden Links. Hatte die Diskussion wirklich nicht
mitbekommen.
Habe es schnell überflogen und sieht so aus, als wenn meine
Einschätzung, dass die alte HW nur noch zu gebrauchen ist, wenn sie
keinen Update
vom OS bekommt, der einen neuen Bootloader verwendet.
Ob ein Betrieb über den Zeitpunk der verfallenen 2011 Certs möglich ist
hängt noch von anderen Dingen ab.
Muss noch meine restlichen Rechner checken, habe aber die Befürchtung,
dass es ähnlich sein wird, da alle x86_64 Modelle.
Markus W. schrieb:> ... dass die alte HW nur noch zu gebrauchen ist ...
Alles Panikmache für Leute, die noch nie "Del" während des Bootens
gedrückt haben...
- Du kannst SecureBoot ausschalten, aber EFI-Boot anlassen.
- Du kannst per CSM booten.
- Du kannst eigene Zertifikate im BIOS hinterlegen, und den Bootloader
selber signieren
- Du kannst die Microsoft-Zertifikate im BIOS auch unter Linux
aktualisieren.
...
@Ernst,
>Du kannst die Microsoft-Zertifikate im BIOS auch unter Linux
aktualisieren.
In der C't steht aber das man dazu einen FW-Modifikation Key
braucht, da man sonst nicht in das BIOS an entsprechender Stelle
Dinge eintragen kann! (Stichwort KEK alias key exchange key)
Markus W. schrieb:> Stichwort KEK alias key exchange key
Ja, der Weg ist demnächst verbaut. Irgendwie blöde, den KEK zuerst
auslaufen zu lassen...
Bleibt der Weg über ein BIOS-Update, dann im BIOS die Secure-Boot-Keys
auf Werkseinstellung zurücksetzen, damit die neuen Keys aus dem Flash
in's NVRam kopiert werden.
Ist auch auf Hersteller-Support angewiesen, der das neue BIOS zur
Verfügung stellen muss.
Genau das war ja mein Anliegen, dass die HW verschrottet werden kann,
wenn der Hersteller keine BIOS Updates mehr liefert.
Dies sperrt die alten Systeme von der Nutzung mit Windows und Linux aus.
Bin gespannt, ob Dell oder HP für meine 8-10 Jahre alten NB's noch was
bereitstellt.
Ein Lenovo vom letzten Jahr hat den 2023 Key drin. Da fängt das Drama
erst wieder irgendwann zwischen 2032 und 2038.
Das sind die nächsten Verfalls-Jahre.
LG
Εrnst B. schrieb:> Du kannst SecureBoot ausschalten, aber EFI-Boot anlassen.
Prio 1: Ausprobieren, ob dies bei jeweiligen Rechner (oder einer VM!)
möglich ist und der Rechner damit startet. Wenn das funktioniert, ist
zwar ein Stück Sicherheit weg, aber auch der Druck.
Markus W. schrieb:> Lauf dem Artikel werden alle PC's/Notbooks die von MS einen EUFI> Cert inne haben nicht mehr im UEFI Mode funktionieren können.
Das ist eine Fehlinterpretation.
Es gibt lediglich Probleme mit "secure boot", wenn nicht die Zertifikate
aktualisiert werden.
Solange man "Secure Boot" nicht verwendet, hat man auch keine Probleme,
PCs können nach wie vor ganz wunderbar mit ihre UEFI-Firmware booten.
Lediglich die Scheinsicherheit, die einem durch Verwendung von "secure
boot" vorgegaukelt wird, entfällt dabei.
Markus W. schrieb:> Ein Lenovo vom letzten Jahr hat den 2023 Key drin.
Auch ältere Lenovos tun es, was den Support von Lenovo angeht. Ein Intel
Gen 8 Desktop von ~2018 hat PK und KEK bis 2037/2039 drin.
Man sollte die Situation aber wirklich bei jeder einzelnen Kiste
kontrollieren. Bloss weils bei einer passt, muss es bei der anderen
nicht auch so sein.
Markus W. schrieb:> Dies sperrt die alten Systeme von der Nutzung mit (Windows und) Linux aus.
Nö. Wenn die Maschine DIR gehört, du also der Owner bist, kannst DU
bestimmen, was bootet.
Dazu brauchst du den Machine-Owner-Key, kannst deine eigene Secure-Boot
Trust-of-Chain ausrollen, und den Bootloader selbst signieren.
Bei Windows geht das meines Wissens nicht, du könntest zwar den
Microsoft Loader selber signieren, das UEFI würde das akzeptieren, aber
Windows wird dann feststellen, dass der Stage 1 Loader modifiziert ist
und abbrechen.
Microsoft hat keine speziellen "Sonderrechte" bei Secure Boot. Nur den
Convenience-Vorteil, dass die MS-Zertifikate meistens(*) im BIOS schon
hinterlegt sind.
*) Bei neuen Server-Mainboards sind die oft nicht aktiv/optional, da
gehen die schon davon aus, dass die Admins lieber nicht auf MS
vertrauen, sondern ihre Zertifikate selber managen.
Warum ist dann die Linux-Community immer von den MS-Certs abhängig
und der Bootloader von Linux muss von MS-in der Trustchain akzeptiert
werden?
Hat es was mit dual Boot zu tun?
Bin in der Materie nicht so drin um diese Frage selber beantworten zu
können.
LG
Markus
Markus W. schrieb:> Warum ist dann die Linux-Community immer von den MS-Certs abhängig> und der Bootloader von Linux muss von MS-in der Trustchain akzeptiert> werden?
Wie hier im Thread mehrfach zu lesen, ist das nicht der Fall.
Wenn man Secure Boot mit Microsofts Zertifikaten zum Booten von Linux
nutzen möchte, dann ist es notwendig. Es gibt im Grunde nur ein
Szenario, in dem das Sinn macht: Man möchte ein Windows mit aktiviertem
Secure Boot und ein Linux auf der gleichen Maschine booten können, ohne
bei jedem Wechsel im UEFI-Setup was umstellen zu müssen. Das hat aber
mit Bequemlichkeit zu tun, nicht mit Abhängigkeit.
Harald K. schrieb:> Solange man "Secure Boot" nicht verwendet, hat man auch keine Probleme,
So isses. Privat braucht man das nicht, und auf Geschäftsrechnern sorgt
die IT schon dafür, dass die Zertifikate da sind. Das Thema ist ja auch
erst ca. 2 Jahre in der Diskussion…
Oliver
Schau mal in Ereignisanzeige, Reiter "System" rein.
Dort steht unter Meldung 1808:
Alles, was MS über Deinen Rechner weiß und tut, um Zertifikate
upzudaten.
"...Dieses Gerät hat die Zertifizierungsstelle/Schlüssel für den
sicheren Start aktualisiert. Diese Gerätesignaturinformationen sind hier
enthalten:.." ok.
Wenn da steht: ..."Voraussetzungen nicht erfüllt..." oder "...Gerät
steht unter Beobachtung...<Data Name="BucketConfidenceLevel">Under
Observation - More Data Needed</Data>..."
erst dann die Schritte nachholen, die hier ausführlich beschrieben
wurden.
https://www.msxfaq.de/windows/sicherheit/uefi_secure_boot_blacklotus.htm
ciao
gustav
Danke für den Link.
Hatte also recht, das das Problem nur bei Daul-Boot Win+Linux
tatsächlich aufpopt.
Dann bin ich beruhigt und kann weiter schlafen.
Melde mich erst wieder 2034 (2032+2) zu diesem Topic ;-)
LG+Danke für die Erklärungen.
Hm, woher wissen die Bootloader denn, ob ein Zertifikat abgelaufen ist?
Das entscheidet sich doch wohl übers aktuelle Datum, und dies wiederum
kommt aus der RTC, denn Netzwerkzugriff ist beim Booten ja i. d. R.
nicht möglich. Also ...
Andreas B. schrieb:> Netzwerkzugriff ist beim Booten ja i. d. R.> nicht möglich.
Ist das so? Netzwerk-Boot per UEFI ist doch schon lange Standard.
Natürlich kann es am Router scheitern, aber im durchschnittlichen
"Heimnetz" ist das kein Problem.
Markus W. schrieb:> Bedeutet dies, da da nichts zu machen ist?
Wenn Dell kein Firmwareupdate mit den neuen Keys anbietet, bleibt nur,
Windows zu installieren und darüber die Keys zu bekommen.
Oliver
@Oliver S.,
Bei dem alten Gerät wird sich Windows 11 wohl nicht installieren lassen.
@Alle,
Bei meinem HP ZBook 17 sieht es etwas besser aus, wenn ich das richtig
deute.
da liefert mokutils und fwupdmgr den folgenden Output.
Markus W. schrieb:> @Oliver S.,> Bei dem alten Gerät wird sich Windows 11 wohl nicht installieren lassen.
Aber sicher geht das, genauso wie auf all den anderen alten Schätzchen,
die die abstrusen MS-Anforderungen nicht erfüllen.
Es stellt sich dann aber die Frage, wofür du da Secure Boot überhaupt
brauchst.
Oliver
Markus W. schrieb:> Bin gespannt, ob Dell oder HP für meine 8-10 Jahre alten NB's noch was> bereitstellt.
Für mein 9 Jahre altes HP Elitebook gab es 2023 das letzte BIOS-Update,
da kommt wohl kein neues BIOS mehr.
Aber es wird trotzdem noch eine Weile laufen, siehe Bild oben. Zumindest
unter Windows, für Linux hat es bisher keine neuen Certs. Der PK und der
KEK von HP gelten aber bis 2033, HP könnte also zertifikatmäßig noch
nachliefern - falls zu laute Proteste kommen sollten.
Interessant übrigens, dass das alte 2011er Microsoft-Zertifikat bereits
in der dbx als gesperrt eingetragen ist. So weit ist mein 1 Jahr alter
Dell noch nicht; der würde also auch dann weiterhin booten können, wenn
man das neue 2023er Zertifikat löscht.
Markus W. schrieb:> Alle,> Bei meinem HP ZBook 17 sieht es etwas besser aus, wenn ich das richtig> deute.>> da liefert mokutils und fwupdmgr den folgenden Output.
Liefere bitte den Screenshot des c't-Tools. Den kann man lesen, ohne
sich durch den Code zu wühlen.
Oliver S. schrieb:> Privat braucht man das nicht, und auf Geschäftsrechnern sorgt> die IT schon dafür, dass die Zertifikate da sind
Bei vielen hier ist der Chef die IT-Abteilung, weiß aber wenig darüber.
Rolf schrieb:> Bei vielen hier ist der Chef die IT-Abteilung, weiß aber wenig darüber.
Freut euch, dann gibt's wieder viele günstige "Refurbished"-PCs am
Second-Hand-Markt, die nur wegen unpassenden BIOS-Einstellungen
rausgeflogen sind.
Markus W. schrieb:> Hatte also recht, das das Problem nur bei Daul-Boot Win+Linux> tatsächlich aufpopt.
Nö. Dual-Boot ist kein Problem, auch nicht mit Secure-Boot bei Windows
und Linux, egal ob Linux mit dem MOK Self-Signed startet oder einen
Shim-Loader verwendet, der von MS signiert ist.
Im UEFI können mehrere Zertifizierungsstellen gleichzeitig hinterlegt
sein.
Oliver S. schrieb:> Privat braucht man das nicht,
Sag das mal den ganzen Fortnight-Zocker-Kiddies, bei denen der
Anti-Cheat jetzt zwingend SecureBoot erfordert.
Markus W. schrieb:> Warum ist dann die Linux-Community immer von den MS-Certs abhängig> und der Bootloader von Linux muss von MS-in der Trustchain akzeptiert> werden?
Damit das ganze Secure-Boot überhaupt Sinn hat, muss es lückenlos im
Einsatz sein.
d.H. schon der USB-Stick mit dem Ubuntu-Installer soll mit aktivem
Secure Boot starten können, und das ist halt extrem unpraktisch, wenn du
erst deinen MOK enrollen musst, und dann erst damit deinen
personalisierten Install-Stick erstellen kannst.
Natürlich kannst du Secure Boot abschalten, einen "unsicheren"
Installer-Stick booten, damit deinen MOK installieren und deinen
Bootloader signieren, dann Secure Boot wieder einschalten.
Funktioniert tadellos, und wenn du dem Installationsmedium vertraust,
ist das auch kein Security-Issue.
Aber: Wenn du ein Dual-Boot-Windows mit Bitlocker und TPM auf derselben
Maschine hast, wird das dich einmal zum Eintippen deines
Wiederherstellungs-Schlüssels auffordern. Das temporäre Abschalten von
SecureBoot sorgt dafür dass das TPM den Entschlüsselungs-Key nicht mehr
herausgibt.
Meine Tagesbilanz ist nun die, dass von fünf NBs
drei bis zur Mitte der dreißiger Jahre Ruhe haben
und zwei Rechner keinen FW-Update von Hersteller
erhalten und damit wohl betroffen sind.
Kann man das nicht irgendwie aushebeln, z.B. selber
BIOS patchen? Nicht alle alten NBs haben ja die TMP
Module verbaut, in denen der Root-Key steckt, sofern
ich das richtig verstanden habe.
Einen Flash kann man doch auch selber auslesen, mit entsprechender
HW. Wurde doch früher auch oft bei den NICs gemacht, wenn die
Probleme hatten und der Hersteller nicht mehr Updates lieferte.
Mir ist bewusst, dass die Technik sich weiter entwickelt und
dass das Auslesen von Speichen immer mehr durch Schutzmaßnahmen
erschwert wird, aber vielleicht ist bei den alten Rechnern
ja noch was möglich.
Der Secur-Boot Schutz bezieht sich ja mehr auf das Booten von
externen Medien und das Verhindern der Einnistung von Root-Kits,
aber wer direkt physischen Zugriff auf einen Rechner hat und
diesen noch dazu zerlegen kann, der hat doch noch ganz andere
Möglichkeiten, die der UEFI eventuell nicht verhindern kann.
Gibt es da eventuell vom CCC was dazu, oder andere Quellen?
Danke für sachdienliche Hinweise.
@Ernst,
>Natürlich kannst du Secure Boot abschalten, einen "unsicheren">Installer-Stick booten, damit deinen MOK installieren und deinen>Bootloader signieren, dann Secure Boot wieder einschalten.>Funktioniert tadellos, und wenn du dem Installationsmedium vertraust,>ist das auch kein Security-Issue.
Wo kann ich dazu was nachlesen?
(prx) A. K. schrieb:> Das nennt man dann die Darwin'sche Auslese.
Statt "survival of the fittest" geht es heute mehr in die Richtung
"dragging along the lazy thinkers".
Markus W. schrieb:> Wo kann ich dazu was nachlesen?
z.B. im Arch-Wiki:
https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Assisted_process_with_sbctl
Das beantwortet auch gleich die Frage mit:
Markus W. schrieb:> Kann man das nicht irgendwie aushebeln, z.B. selber> BIOS patchen?
Wenn du das nach der sbctl-Anleitung machst, und erstmal im BIOS alle
Keys löscht, abschaltest dass die Keys aus dem Flash automatisch wieder
aktiviert werden, und dann mit
# sbctl enroll-keys
deinen eigenen Key in's UEFI spielst, kannst du dabei auch gleich die
Microsoft-Keys mit installieren.
# sbctl enroll-keys -m // --microsoft
Völlig unabhängig von BIOS-Updates, gültigen KEKs und anderen Updates.
Wie gesagt, Microsoft hat keine SecureBoot-Sonderbehandlung, bis darauf
dass deren Keys im Flash mitgeliefert werden und automatisch installiert
werden, wenn der User nichts anderes auswählt.
Du kannst die ganze Geschichte auch ohne diese Automatik selber machen,
und dabei auch selber die 2023er Microsoft-Keys enrollen, die sind ja
nicht geheim.
Danke Ernst für die Hinweise.
Ich bin in dieser Materie nicht so tief drin.
War bis dato der Meinung, kann aber auch falsch sein, dass
in dem TMP/TMP2 Modul der Root-Key der Vertrauenskette steckt,
zu dem alles Weitere passen muss, d.h. die Root-Key-CA muss
alle darunterliegenden Keys mit Ihrem Vertrauens-Vorschuß
absegnen, d.h. die Kette der darunter liegenden Zertifikate
muss nahtlos passen.
Und ich war bis jetzt der Ansicht, dass diese Root-CA bei x86_64 MS ist.
Ist aber offensichtlich nicht so, wenn Du schreibst, dass man
da alles selber signieren darf.
Muss mir noch einiges durchlesen, damit mir das klarer wird.
LG
PS.: Bin jetzt auf dem Weg zur Sport und erst wieder gegen Abend online.
Markus W. schrieb:> Und ich war bis jetzt der Ansicht, dass diese Root-CA bei x86_64 MS ist.
Ganz egal, um welche Zertifikatskette in welchem Kontext es geht, eine
Root-CA signiert ihre Zertifikate immer selbst, das ist ja das Prinzip
des Ganzen.
Also kannst du dir (mit Linux- oder Windows-Bordmitteln) ein
Root-Zertifikat unter deinem, meinem oder Bill Gates' Namen erstellen.
Solange die Hardware entsprechende Schreibvorgänge ermöglicht, kannst du
reinschreiben, was du willst.
Allerdings wird niemand deinen Zertifikaten glauben, was aber nicht
schaden muss. Solange du nicht Betriebssystem-Lieferant bist, muss dir
ja niemand glauben.
Εrnst B. schrieb:> Wie gesagt, Microsoft hat keine SecureBoot-Sonderbehandlung, bis darauf> dass deren Keys im Flash mitgeliefert werden und automatisch installiert> werden, wenn der User nichts anderes auswählt.
Nun ja…
Die MS-Zertifikate sind halt die, die jeder PC-Hersteller ins BIOS
schreibt, und jeder OS-Hersteller zur Signierung seiner Bootloader
benutzt.
Klar kann an da auch eigene Zertifikate im BIOS hinterlegen, das nutzt
aber ohne einen damit signierte Bootloader genau gar nichts.
Oliver
>ohne einen damit signierte Bootloader genau gar nichts.
Genau das ist mein Verständnis - Den BL bekomme ich z.B. vom
Linux-Distributor und will nicht jedes mal diesen händisch
um-signieren, falls dies überhaupt geht.
Also wenn ich nicht jedes mal meinen eigenen BL kreieren will,
bin ich auf eine öffentliche Cert. Kette angewiesen.
Also wie sieht es in der Zukunft aus, wen mein OS-Distributor
neue Pakete zur Verfügung stell und der Grub irgendwelche
Änderungen erfährt?
Markus W. schrieb:> Also wie sieht es in der Zukunft aus, wen mein OS-Distributor> neue Pakete zur Verfügung stell und der Grub irgendwelche> Änderungen erfährt?
Tatsächlich ist nicht der Bootloader signiert, sondern es gibt einen
Shim, der von MS signiert ist. Von da aus gibt es andere Mechanismen.
Es gibt auch schon länger nicht mehr nur Grub, stattdessen lässt sich
beispielsweise der Kernel auch direkt laden – da wird’s mit eigenen
Zertifikaten schon durchaus interessant, wenn man etwa einen gewissen
Gerätepark zu betreuen hat und sicherstellen möchte, dass dort nur die
von einem selbst zur Verfügung gestellten Dinge gestartet werden können.
Jack V. schrieb:> Es gibt auch schon länger nicht mehr nur Grub, stattdessen lässt sich> beispielsweise der Kernel auch direkt laden – da wird’s mit eigenen> Zertifikaten schon durchaus interessant, wenn man etwa einen gewissen> Gerätepark zu betreuen hat und sicherstellen möchte, dass dort nur die> von einem selbst zur Verfügung gestellten Dinge gestartet werden können.
Mag ja alles sein, ist aber ein für Otto Normaluser völlig
uninteressanter Spezialfall. Der und eigentlich jeder andere auch will
seinen Stick mit der OS-ISO in den Rechner stecken, und von da booten.
Oder das OS-Upgrade einfach runterladen, und anwenden. Oder…
Und all das geht ohne das passende MS-Zertifikat im BIOS nicht, wenn man
Secure Boot braucht.
Oliver
Markus W. schrieb:> Genau das war ja mein Anliegen, dass die HW verschrottet werden kann,> wenn der Hersteller keine BIOS Updates mehr liefert.
Das ist Quatsch. Nur die Secure-Boot Funktion läuft ab.
Andreas B. schrieb:> woher wissen die Bootloader denn, ob ein Zertifikat abgelaufen ist?
Der Bootloader muss das nicht wissen. Ein Betrüger muss auch nicht
wissen, daß er ein Betrüger ist. Er muss nur als solcher erkannt werden,
wenn man sicher sein will.
Das UEFI vergleicht die Signatur des Windows/Linux Bootloaders mit dem
Zertifikat, das im UEFI hinterlegt ist. Wenn dieses Zertifikat abläuft,
wird es unbrauchbar. Also kann dann die Signatur des Bootloaders dann
nicht mehr geprüft werden. Das macht den Bootloader jedoch nicht
unbenutzbar. Du musst nur die Kontrolle (Secure-Boot) deaktivieren.
Thread beobachten
Seitenaufteilung abschalten