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.
Εrnst B. schrieb:> 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.
Ich glaube man muss da zwischen eigenen MOK und PK Zertifikaten
unterscheiden. Bei PK prüft UEFI ob die Signatur passt. Aber MOK ist
doch auf Bootloader ebene. Wenn also zuerst z.B. Shim (oder ein anderer
Bootloader mit MOK Support) geladen wird, und Shim lädt die MOK
Zertifikate, dann heisst das doch, dass wenn Shim mit den alten MS
Zertifikaten signiert wurde, aber nur noch die neuen gehen, dass dann
Shim nicht mehr geladen werden kann, selbst wenn man noch ein eigenes
Zertifikat im MOK hätte und dem Shim eine zusätzliche Signatur damit
verpasst hätte. (Und all das was Shim dann geladen hätte, könnte man
dann natürlich auch nicht mehr starten).
Oliver S. schrieb:> Mag ja alles sein, ist aber ein für Otto Normaluser völlig> uninteressanter Spezialfall.
Das stelle ich nicht in Abrede, aber ich dachte, es könnte dem TE beim
Verständnis helfen.
Oliver S. schrieb:> Und all das geht ohne das passende MS-Zertifikat im BIOS nicht, wenn man> Secure Boot braucht.
Soweit ich das verstanden habe, ist man aus der Abhängigkeit befreit,
sobald man einen eigenen PK hinterlegt hat; nur Windows würde dann nicht
mehr mit Secure Boot starten. Hab ich was übersehen?
Jack V. schrieb:> nur Windows würde dann nicht mehr mit Secure Boot starten.
Windows funktioniert auch ohne Secure Boot. Beim Abschalten kann
allerdings passieren, dass du nach dem Wiederherstellungs-Key von
Bitlocker aufgefordert wirst. Also besser vorher ausdrucken, es sei
denn, du wolltest Windows eh neu installieren.
Für Linux-User ist das ganz einfach: man startet in der Konsole "mokutil
--sb-state". Erscheint die Meldung "EFI variables are not supported on
this system" oder die Meldung "SecureBoot disabled", kann man sich
beruhigt zurücklehnen und die ganze Sache vergessen. Ansonsten muss man
sich noch ins BIOS begeben und Secure Boot abschalten.
Ich merke gerade, ich habe weiter oben PK und DB verwechselt.
Jack V. schrieb:> Oliver S. schrieb:>> Und all das geht ohne das passende MS-Zertifikat im BIOS nicht, wenn man>> Secure Boot braucht.>> Soweit ich das verstanden habe, ist man aus der Abhängigkeit befreit,> sobald man einen eigenen PK hinterlegt hat; nur Windows würde dann nicht> mehr mit Secure Boot starten. Hab ich was übersehen?
KEK und DB sind Listen von Zertifikaten. Wenn du dein eigenes in DB drin
hast, kann man damit direkt damit signierte EFI Anwendungen starten. Um
das zu machen, muss man in der Regel aber auch PK und KEK ersetzen, denn
du brauchst PK um KEK zu ändern und KEK um DB zu ändern oder so. Von PK
gibt es nur einen Key. Verhindert aber nicht, dass man Windows starten
könnte, man muss nur daran denken, die MS Keys auch in DB mit drin zu
lassen / aufzunehmen. Und in KEK, wenn man sie die Keys in DB auch
ändern lassen will.
Das ist was anderes, als die MS Bootloader usw. mit einem eigenen
Zertifikat zu Signieren. Das könnte MS durchaus erkennen und verhindern.
Ob das in der Praxis auch machbar ist, weiss ich nicht.
PS: Wenn man selbst die DB / KEK etc. Keys ändert könnte es noch
passieren, dass TPM Sachen wie Bitlocker kaputt gehen.
Nemopuk schrieb:> Windows funktioniert auch ohne Secure Boot.
Meine Überlegung war, dass es nicht mehr mit Secure Boot starten
würde. Dass ohne Secure Boot egal ist, was in der Datenbank steht,
sollte jedem klar sein, der hier mitgelesen hat.
Daniel A. schrieb:> Von PK> gibt es nur einen Key. Verhindert aber nicht, dass man Windows starten> könnte, man muss nur daran denken, die MS Keys auch in DB mit drin zu> lassen / aufzunehmen.
Du schreibst, ich könne den PK auswechseln, MS’ Zertifikate aber in der
KEK-Datenbank behalten, sodass Windows trotz Nicht-MS-PK mit Secure Boot
starten könnte – hab ich das so richtig erfasst? Ich hatte es bislang so
verstanden, dass beim Austausch des PK der Rest auch neu gemacht werden
müsste, und damit wären die Zertifikate für Windows halt raus.
Jack V. schrieb:> Du schreibst, ich könne den PK auswechseln, MS’ Zertifikate aber in der> KEK-Datenbank behalten, sodass Windows trotz Nicht-MS-PK mit Secure Boot> starten könnte – hab ich das so richtig erfasst?
Ob man die PK, KEK und DB komplett neu machen muss, hängt etwas vom UEFI
des Herstellers ab. Ich hatte mal einen Server, da konnte man die DB
Keys ganz einfach in den Einstellungen beim Starten hinzufügen /
entfernen, aber das ist eher die Ausnahme.
Um Windows zu Starten muss der richtige Key in der DB sein. In der KEK
muss er nur sein, wenn du Microsoft erlauben willst, die DB und DBX zu
verändern.
> Ich hatte es bislang so> verstanden, dass beim Austausch des PK der Rest auch neu gemacht werden> müsste, und damit wären die Zertifikate für Windows halt raus.
Bei meinem HP laptop muss man erst in den Setup Mode - man "löscht" in
den Einstellungen alle Keys. (Bei meinem HP Laptop kann man das auch
wieder auf die Firmware Defaults zurücksetzen).
Dann fügt man alle Zertifikate / Keys hinzu, die man braucht. PK, KEK,
DB.
Hier muss man wissen, dass bei diesen Keys Asymetrische Kryprographie
verwendet wird - es gibt einen Public Key (im Zertifikat), und einen
Private Key. Mit dem Private Key signiert man Sachen, mit dem Publik Key
kann man die Signaturen prüfen.
PK, KEK und DB sind Zertifikate, also der Public Key Teil. (btw. KEK und
DB sind listen von Zertifikaten). Man kann die auch auslesen, und die MS
Zertifikate findet man auch irgendwo auf dem Github von MS.
Du setzt also das PK Zertifikat. Dann kannst du dein KEK Zertifikat
hinzufügen. Das kann man vom OS aus über die UEFI Variablen machen. Das
was man da Reinschreibt, der Auftrag das Zertifikat zur KEK
hinzuzufügen, das signiert man mit seinem PK. Mit der DB dann das
gleiche Spiel, nur diesmal signiert man den Auftrag mit seinem KEK. Das
UEFI sieht den Private Key nie, nur das Zertifikat und die Signatur.
Du brauchst dafür also nicht den Private Key von MS, wenn du das MS
Zertifikat hinzufügen willst. Du brauchst nur den Private Key zu
irgendeinem der Zertifikate in der KEK, damit du den Auftrag signieren
kannst, und dass kann ja dein eigenes sein.
Da du die Private Keys von MS nicht hast, kannst du natürlich den
Windows Bootloader damit nicht signieren - aber das hat ja Microsoft
schon gemacht, ist also kein Problem. Und für deine eigenen Sachen hast
du ja selbst einen Key in der DB.
@Stephan,
danke für den Hinweis. Für mich ist nur relevant ob meine
Linux Kisten weiter laufen können. In wie weit das Problem mit
den Keys bei alter HW auch die Windows-Nutzer betrifft war
mir soweit egal, da ich in meinem Umfeld (privat) die ganze
Verwandtschaft auf Linux getrimmt habe, nebst meiner Frau ;-)
1
mokutil--sb-state
2
SecureBootdisabled
Wir werden ja sehen wie sich das weiter entwickelt und was MS
noch so in Peto hat.
Mit dem Wandel zu ARM wird sich das eventuell sowieso bald wandeln
und die MS Macht wird hoffentlich reduziert.
Jack V. schrieb:> Soweit ich das verstanden habe, ist man aus der Abhängigkeit befreit,> sobald man einen eigenen PK hinterlegt hat; nur Windows würde dann nicht> mehr mit Secure Boot starten. Hab ich was übersehen?
Ja. Das diese MS-Zertifikate zwar von MS sind, aber von allen OS zur
Signierung der Bootloader benutzt werden. Egal, wie die auch heißen. Out
of the box bootet da Secure ohne das passende MS-Zertifikat gar nichts.
Nemopuk schrieb:> 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.
Sofern man Windows auf der Kiste hat, aktualisiert das mit seinen
Updates auch die Keys im BIOS. Da brauchts kein BIOS-Update vom
PC-Hersteller.
Oliver
Oliver S. schrieb:> Sofern man Windows auf der Kiste hat, aktualisiert das mit seinen> Updates auch die Keys im BIOS. Da brauchts kein BIOS-Update vom> PC-Hersteller.
Lenovo Desktop mit Intel Gen 8, BIOS von 2023. Weder die aktuellen
Zertifikate noch die Defaults waren frisch, die von MS auch nicht. Trotz
aktueller MS Updates (allerdings 23H2). Nach BIOS Update auf 2026
stimmten die Defaults. Nach Factory Reset der Zertifikate auch die
genutzten.
Markus W. schrieb:> Mit dem Wandel zu ARM wird sich das eventuell sowieso bald wandeln> und die MS Macht wird hoffentlich reduziert.
Eher das Gegenteil. Während auf amd64 im BIOS meistens sowohl die "UEFI
CA" als auch die "Production PCA" aktiviert sind (Mit der UEFI-CA
signiert Microsoft den SHIM-Loader für Linux) ist bei den ARM-Geräten
für Windows meist nur die Production PCA aktiv, kann aber in den
UEFI-Settings möglicherweise umgestellt werden.
Und bei den ersten ARM-für-Windows Geräten war Vorgabe von Microsoft,
dass Secure Boot nicht abschaltbar sein darf... Bei den Neueren haben
sich da glücklicherweise die Hardware-Hersteller durchgesetzt.
Oliver S. schrieb:> Ja. Das diese MS-Zertifikate zwar von MS sind, aber von allen OS zur> Signierung der Bootloader benutzt werden. Egal, wie die auch heißen. Out> of the box bootet da Secure ohne das passende MS-Zertifikat gar nichts.
Bist du sicher? Zwei Beiträge über deinem steht es in etwa so, wie ich
es auch verstanden habe: Ich kann eigene Zertifikate ausrollen und damit
meinen Bootloader signieren, ohne dass dann noch MS-Zertifikate
vorhanden wären. Dieser Nebenzweig der Diskussion begann ja mit der
Frage, ob ein System völlig ohne MS-OS dennoch von den MS-Zertifikaten
abhängig wäre, und das scheint nicht so zu sein. Wie es OOTB ist, wäre
an dieser Stelle unerheblich.
Jack V. schrieb:> Ich kann eigene Zertifikate ausrollen und damit> meinen Bootloader signieren, ohne dass dann noch MS-Zertifikate> vorhanden wären.
Schaut im UEFI-Setup etwa so aus wie in den Bildern (Sorry, Handy-Foto
vom Bildschirm, und bevor jemand wegen Bildformaten ankommt: PNG wäre 7×
größer)
Alle Zertifikate raus, abschalten dass die Default-Zertifikate
installiert werden, Secure Boot ist dann im "Setup Mode".
1
# mokutil --sb-state
2
SecureBoot disabled
3
Platform is in Setup Mode
"Setup Mode" bedeutet, dass du jetzt beliebig selber Zertifikate
installieren kannst. Eigenen PK, eigenen KEK, eigenen DB.
>"Setup Mode" bedeutet, dass du jetzt beliebig selber Zertifikate>installieren kannst. Eigenen PK, eigenen KEK, eigenen DB.
Das wäre ja gut, nur bin ich mir nicht sicher ob das jedes BIOS so
handhabt, vor allem die älteren!
Weiter oben sieht man meinen Output von mokutils
1
mokutil--sb-state
2
SecureBootdisabled
Da fehlt der Hinweis 'Platform is in Setup Mode'
Kann natürlich sein, dass man trotzdem die Keys
selber einspielen kann.
Markus W. schrieb:> Nicht alle alten NBs haben ja die TMP> Module verbaut, in denen der Root-Key steckt, sofern> ich das richtig verstanden habe.
Wenn deine Maschine kein TPM hat, kann sie kein Secureboot haben und
ergo ergibt sich kein Problem aus abgelaufenen Zertifikaten, denn die
werden ja gar nicht geprüft sofern überhaupt da.
Nemopuk schrieb:> 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.
Soweit ich weiß gilt das alte Zertifikat weiterhin, denn zum Zeitpunkt
der Signaturerzeugung war es ja noch gültig.
D.h. so lange es keine Updates am System gibt bleiben die alten
abgelaufenen Zertifikate benutzbar.
Ein Update der die Signaturen aktualisiert schlägt aber evtl. fehl, denn
der benötigt mit "jetzt" gültigem Zert signierte Schlüssel und wenn sich
alle an das Zert bzw. dessen Datum halten kann man ja eigentlich keine
Dinger mehr nach dem Datum zertifizieren ;)
Die Datei selber zerstört sich ja aber nicht, es sind sich nur alle
einig, das sie nach dem Gültigkeitsablauf nicht mehr (zum Signieren!)
benutzt werden soll...
Man kann sich einen ansaufen bei UEFI. Dualboot wäre früher echt viel
einfacher gewesen. Die Steam-Statistiken sprechen aber auch schon wieder
Bände. Mein Gott, wie kann man nur so Windows-Abhängig sein? Ich
wechsele einfachhalber die Rechner, habe dann aber auch andere Sorgen.
Leider bekommt man aber aktuell kaum noch Hardware, wo nicht schon ein
Windows draufgeorgelt ist. Schlimm schlimm schlimm..ein Teufelskreis.
Ich handhabe das so, dass ich seit dem meine Notebooks M2 SSDs verbaut
haben diese vor dem ersten Einschalten sofort raus baue.
Deshalb habe ich nur Notebooks, die diesbezüglich gut zerlegbar sind.
Dann kommt eine neue meist größere SSD rein und darauf wird Linux
installiert.
Von der orig. Windows SSD ziehe ich mir mittels M2-2-USB3 Adapter
ein Abbild, um dieses dann für eventuelle VM's mit Windows verwenden
zu können.
So bin ich die letzten Jahre bei etlichen Notebooks vorgegangen.
Zwar ist das Geld für die Windows Version und die SSD verschwendet,
das ist es mir aber durchaus wert, wenn ich zumindest partiell von
MS unabhängig bin.
(prx) A. K. schrieb:> Weder die aktuellen> Zertifikate noch die Defaults waren frisch, die von MS auch nicht. Trotz> aktueller MS Updates (allerdings 23H2).
Ok. Ich hätte für alle Fälle natürlich ganz korrekt schreiben sollen:
wenn man ein aktuell vom MS mit Updates versorgtes Windows auf dem
Rechner hat. Eigentlich impliziert das schon die Aussage, dass MS das
über die Updates erledigt, aber ok.
Sonst kommt hier gleich der nächste Birnbichler, und beschwert sich,
dass das bei Win95 auch nicht klappt.
Oliver
Oliver S. schrieb:> aktuell vom MS mit Updates versorgtes Windows
Eben zufällig im c't-Bericht gelesen:
Win10 muss mit verlängertem Support laufen (und auch dann nur bis
Oktober 26).
Win11 muss noch aktuell im Support sein, bei den üblichen Pro und Home
also später als 23H2.
Man kann bei diesen aber manuell einen Zertifikatsupdate anstupsen,
sofern die Dateien dazu via aktuellem Windowsupdate verteilt sind.
Dazu brauchts zwei Powershell-Kommandos, die einerseits einen Regkey
erzeugen und andererseits einen geplanten Task starten. Das kann man
m.E. auch via CMD und oder manuell machen....
Infos gibt's im KB5025885, da stehen die Kommandos auch drin.
Jens M. schrieb:> Wenn deine Maschine kein TPM hat, kann sie kein Secureboot haben
Verbreite halt nicht diese uralten Urban-Legend Schauergeschichten.
Natürlich geht das. Da werden stumpf Signaturen gegen Public Keys
geprüft.
Das konnten Computer schon vor 40 Jahren, ganz ohne Krypto-Zusatz-Chip.
Keiner der verwendeten Schlüssel ist im TPM gespeichert, warum auch, es
sind ja Public Keys.
Keine der Datei-Signaturen wird vom TPM geprüft, warum auch, das hat die
CPU schon 100mal fertig, bevor überhaupt die ersten paar Bytes in's TPM
geflossen wären.
Andersherum macht die Geschichte mehr Sinn: Du kannst das TPM anweisen
bestimmte Private Keys nur zu entsperren, wenn die PCRs passen, und da
kann auch die Secure-Boot Konfiguration mit einfließen.
Εrnst B. schrieb:> Das konnten Computer schon vor 40 Jahren, ganz ohne Krypto-Zusatz-Chip.
Aha?
Das wäre mir neu, TPM gibt's schon sehr lange, aber wird erst wirklich
seit Windows 10 verkauft (dort aber oft noch als Steckoption), fix
eingebaut erst seit Windows 11.
Secureboot eigentlich ebenso, jedenfalls können meine alten Intel und
Gigabyte-Bretter aus der Core-i-Ära 2xxx bis 7xxx mit einem TPM
nachgerüstet werden und SB geht nur wenn das steckt.
Macht m.E. auch keinen Sinn, die Schlüssel in einem per se unsicheren
Speicher zu lagern und dann zur Prüfung zu nutzen, denn ich könnte ja
einfach im Flash meine Keys einbauen und wäre golden.
Ich würde wirklich gern einen DOS-Computer sehen, der Secureboot kann...
Wir sind hier immerhin 10 Jahre vor Windows 95!
Oder gern auch ein System vor Windows 10 das sich wesentlich um ein
fehlendes TPM oder Secureboot schert.
Oliver S. schrieb:> wenn man ein aktuell vom MS mit Updates versorgtes Windows auf dem> Rechner hat.
Hat man. Die Enterprise Version von 23H2 wird noch mit Updates versorgt.
Stand in den Screenshots.
Jens M. schrieb:> Das wäre mir neu,
So neu ist das nicht. RSA wurde 1983 patentiert.
Jens M. schrieb:> Macht m.E. auch keinen Sinn, die Schlüssel in einem per se unsicheren> Speicher zu lagern und dann zur Prüfung zu nutzen, denn ich könnte ja> einfach im Flash meine Keys einbauen und wäre golden.
Die Public Keys sind Public, veröffentlicht, frei verfügbar.
Nur die Private Keys sind Privat. Und die sind bei Microsoft hoffentlich
gut gesichert.
Und nein, du musst die Keys nicht im Flash austauschen, es reicht die
Kopie im NVRam auszutauschen. Da gibt es zwei offizielle Wege für, plus
noch mehr falls dein BIOS da extra was anbietet (z.B: Keys vom USB-Stick
direkt zu installieren)
Ob du damit "golden" bist oder nicht, hängt davon ab was du erreichen
willst.
Ansonsten noch zur Aussage, dass SecureBoot angeblich nur mit TPM geht:
die ersten TPM - Specs sind von 2003. (bzw. 2005 für TPM 1.2)
Secure Boot ist von 2011.
TPM2.0 ist von 2014.
Nach 2011 wurden noch lange PCs/Mainboards ohne TPM (bzw. mit leerem
TPM-Steckplatz) aber funktionierendem Secure Boot verkauft.
Das TPM beinhaltet keine der Funktionen, die zum Implementieren von
Secure Boot nötig sind.
Im UEFI-Setup kann ich problemlos das fTPM abschalten, aber Secure-Boot
anlassen. Nervt nur wegen der Plattenverschlüsselung.
In der umgedrehten Aussage steckt ein Fünkchen Wahrheit:
im TPM-Chip kann man optional ein paar Bytes Daten speichern, auf die
nur zugegriffen werden kann, wenn das PCR7 keine Änderungen an den
Secure-Boot-Einstellungen festgestellt hat.
Irgendwelche Verschwörungstheoretiker haben das umgedreht und
irgendwelche Phantasiegeschichten dazugeschwurbelt, die sich leider zum
Teil in vielen Köpfen festgesetzt haben.
Den Zusammenhang zwischen Bill Gates=CoronaImpfstoffChips=TPM=Microsoft
kannst du dir ja denken.
Jens M. schrieb:> Das wäre mir neu, TPM gibt's schon sehr lange, aber wird erst wirklich> seit Windows 10 verkauft (dort aber oft noch als Steckoption), fix> eingebaut erst seit Windows 11.
TPM ist Hardware, die steckt schon seit mehr als einem Jahrzehnt auf den
meisten Motherboards. Benutzt wurde das halt im Privatbereich seltenst
bis gar nicht, nur im Firmenumfeld. Windows hello Z.B. nutzt das, aber
nutzt Windows hello?
Oliver
Oliver S. schrieb:> Windows hello Z.B. nutzt das
Richiger: "Windows Hello kann das nutzen".
Dann wird ein Schlüsselpaar erzeugt, Private Key im TPM, Unlock z.B.
über die PIN, die du für dein Hello-Login verwendest. Der TPM-Chip wird
sozusagen zum zweiten Faktor für den Login.
Geht aber auch ohne TPM, dann macht Windows das halt in Software ohne
die extra "Sicherheit".
Wobei das bei den ersten TPMs mit der Sicherheit so eine Sache war. Die
hingen über SPI an einem leicht erreichbaren Stecker am Mainboard,
kommuniziert wurde unverschlüsselt. War trivial da einen Logic Analyzer
dranzuhängen und mal mitzulesen...
Oliver S. schrieb:> Benutzt wurde das halt im Privatbereich seltenst> bis gar nicht
Inzwischen lässt sich das TPM unter Linux recht gut einsetzen.
z.B. LUKS-Festplattenverschlüsselung: langes Passwort und kurze PIN+TPM
in den Keyslots.
Der TPM-Chip verhindert Brute-Force Durchprobieren der PIN, und optional
lässt sich einstellen dass nur mit PIN entschlüsselt werden kann wenn
das gebootete Kernel-Image+InitRD auch von mir signiert war, und an der
Kernel-Cmdline nicht gedreht wurde. Damit wären wir wieder bei Secure
Boot.
Thread beobachten
Seitenaufteilung abschalten