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.
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.
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)
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.
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.
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.
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?
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.
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…
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.
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 ...
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.
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.
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.
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?
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.
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.
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.
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.
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.
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?
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.
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.
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.
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).
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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...
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.
