Seiten: [1] 
|
 |
|
|
Autor
|
Thema: Erfahrungen mit „Restore Factory Keys“ und Secure-Boot-Key-Management (Gelesen 320 mal)
|
|
Sebastian
YaBB God
 Offline
Einträge: 774
|
 |
Erfahrungen mit „Restore Factory Keys“ und Secure-Boot-Key-Management
« am: 22. August 2025, 18:07:42 »
|
|
Hallo zusammen,
ich habe auf meinem Notebook (Secure Boot deaktiviert) testweise die Option „Restore Factory Keys“ im UEFI ausgeführt, um zu prüfen, ob der Microsoft KEK (2023) danach noch vorhanden ist oder ob er inzwischen fest in der Firmware integriert ist.
Ergebnis: Der Key war danach tatsächlich wieder aus dem NVRAM verschwunden.
Unter Linux habe ich anschließend folgende Befehle ausgeführt:
fwupdmgr refresh
fwupdmgr update
|
|
Daraufhin wurden mir sofort alle fehlenden Keys zur Installation angeboten – darunter auch wieder der Microsoft KEK von 2023.
Meine aktuelle Überlegung:
Im UEFI tauchen einige Keys mit Bezeichnungen wie UEFI Firmware auf.
Daher zögere ich momentan, meinen eigenen PK (Platform Key) einzuspielen, um nicht versehentlich die Vertrauenskette zu unterbrechen und das System unbootbar zu machen.
Vorher möchte ich klären, wie ich mit meinem eigenen PK die KEKs signieren kann, die per Update eingespielt werden.
Diese möchte (und muss) ich vermutlich aus Kompatibilitätsgründen behalten, damit das UEFI nicht wegen einer ungültigen Kette den Start verweigert.
Nächste Schritte:
- Trockenübungen in einer VM, um den Ablauf zu verstehen
- Danach ggf. Umsetzung auf echter Hardware, um Risiken zu minimieren
Frage an die Community:
Hat jemand von euch bereits praktische Erfahrung mit der Verwaltung von Secure-Boot-Keys?
Gibt es Tipps oder Stolperfallen, auf die man besonders achten sollte – gerade beim Einsatz eines eigenen PK in Kombination mit Firmware-Updates?
LG
Sebastian
|
|
 Gespeichert
|
Wo die digitale Kultur blüht, nutzen Angreifer Emotionen, Gewohnheiten und Markenbindung aus. Der Schutz beginnt nicht mit Technik, sondern mit Bewusstsein. Wer sich informiert, vorsichtig klickt und sichere Tools nutzt, kann auch unbeschwert an der Digitalkultur teilnehmen.
|
|
|
Andreas
Administrator
Offline
Einträge: 1537
Linux von Innen
|
|
Re:Erfahrungen mit „Restore Factory Keys“ und Secure-Boot-Key-Management
« Antwort #1 am: 23. August 2025, 06:05:04 »
|
|
Ich kann Dir bei dieser Frage nicht weiterhelfen, und ich werde mich auch mit dieser Thematik nicht beschäftigen. In meinen Augen ist das eine Einschränkung meiner Freiheit und es nimmt mir automatisiert Entscheidungen ab, die ich gerne selbst treffen würde. Deswegen kommen für mich Geräte, bei denen man das "U" / das secure Boot) nicht abschalten kann aus Prinzip nicht in Frage und ich lehne ihre Verwendung ab.
LG
Andreas
|
|
Gespeichert
|
Wissen ist das einzige Gut, das mehr wird, wenn man es teilt - wenn es Menschen gibt, die es teilen, und es Menschen gibt, die bereit sind, dieses Geschenk auch mit eigenem Einsatz anzunehmen.
Freiheit zu erkämpfen reicht nicht. Man muss sie auch verteidigen.
Ohne IT-Kompetenz ist man heutzutage ein willkommenes Opfer und Spielball anderer, egal, welches System oder Gerät man nutzt. Nur Wissen schützt vor Schaden!
|
|
|
Sebastian
YaBB God
Offline
Einträge: 774
|
|
Re:Erfahrungen mit „Restore Factory Keys“ und Secure-Boot-Key-Management
« Antwort #2 am: 23. August 2025, 12:58:38 »
|
|
Kein Problem, Andreas,
ich bin gerade dabei zu erkunden, inwieweit mich das in meiner Freiheit einschränkt. Bisher habe ich vollen Zugriff auf die komplette Secure-Boot-Funktionalität. Das heißt, ich kann selbst bestimmen, welche Eintragungen in:
- Platform Key (PK)
- Oberster Schlüssel in der Secure-Boot-Hierarchie
- Autorisiert Änderungen an den anderen Secure-Boot-Keys
- Key Exchange Key (KEK)
- Wird genutzt, um Updates an der „Allow“- und „Deny“-Liste (db, dbx) zu signieren
- Dient als Bindeglied zwischen PK und den Datenbanken
- Allowed Signature Database (DB)
- Enthält Zertifikate, Hashes oder Signaturen von vertrauenswürdiger Firmware/Bootloadern
- Nur Software in dieser Liste darf beim Booten geladen werden
- Forbidden Signature Database (DBX)
- Liste von gesperrten oder kompromittierten Signaturen/Hashes
- Verhindert das Laden unsicherer oder zurückgezogener Bootloader
gemacht werden.
Mein Vorhaben:
Aus Gründen der Einfachheit möchte ich die im UEFI hinterlegten KEKs des Mainboard-Herstellers sowie die von Microsoft extrahieren (z. B. mit den efitools) und diese anschließend mit meinem eigenen PK signieren. Dadurch bleibt die Trust Chain erhalten und die Einträge in db und dbx bleiben gültig, sodass die Firmware weiterhin ordnungsgemäß booten kann.
Alternativ könnte ich auch mit einem eigenen KEK alle Einträge in db bzw. dbx signieren. Allerdings sind dort so viele Werte hinterlegt (teilweise für den Betrieb des UEFI selbst notwendig), dass dies deutlich mehr Arbeit wäre, als einfach einen vorhandenen KEK zu signieren.
Interessant wird es bei einem UEFI-Firmware-Update: Kommen neue KEKs oder db/dbx-Einträge vom Hersteller hinzu, müsste ich diese erneut mit meinem PK signieren, um die Vertrauenskette zu wahren.
Wenn ich eigene Keys für Secure Boot verwende, muss ich also auch bei jedem Firmware-Update sicherstellen, dass die neue Firmware in der db eingetragen oder von mir signiert ist – sonst darf sie nicht booten.
Mit anderen Worten: Ich bin in meiner Freiheit nicht eingeschränkt, da ich – wenn ich möchte – die volle Kontrolle über alle Keys und db/dbx-Einträge habe. Will ich jedoch eigene Änderungen an der db-Datenbank vornehmen, muss ich selbst dafür sorgen, dass die Vertrauenskette erhalten bleibt – und das bedeutet zusätzlichen Aufwand.
Viele gehen daher einen anderen Weg: Sie hinterlegen gar keinen eigenen Schlüssel, sondern nutzen den signierten Shim Bootloader zum Chainloading, da dieser eine gültige Microsoft-Signatur enthält. Selbst wenn Microsoft diese Signatur irgendwann zurückzieht, könnte ich den entsprechenden Eintrag aus der dbx in meinem UEFI löschen – und der Bootloader würde wieder starten.
Man muss lediglich das Prozedere verstehen. Genau das bringe ich mir gerade bei – einfach, weil ich es einmal gemacht haben möchte und mich in diesem Bereich weiterbilden will. Einen konkreten Bedarf habe ich dafür aktuell nicht.
Edit:
Automatisiert werden hier keine Entscheidungen abgenommen – zumindest nicht, wenn man fwupd verwendet. Dort wird man bei jedem neuen Schlüssel oder jeder Änderung in der db- bzw. dbx-Datenbank gefragt, ob man diese einspielen möchte. Einen wirklichen Nachteil hat man eigentlich nur dann, wenn über die dbx etwas eingespielt wird, das bestimmte Komponenten blockiert, die man eigentlich weiterhin nutzen möchte.
Das verhält sich ähnlich wie bei Malware-Scannern: Verwendet man solche Tools, vertraut man zunächst auf deren Signaturdatenbank und möchte dafür auch Updates erhalten. Allerdings kann es auch dort zu False Positives kommen – also zu Fällen, in denen etwas als gefährlich eingestuft wird, das man eigentlich behalten möchte. Solange man diese Änderungen im Nachhinein wieder rückgängig machen kann, ist das in meinen Augen unproblematisch. Die Zeit und Lust, alle Einträge manuell zu überprüfen, habe ich jedenfalls nicht. Ich greife lieber erst ein, wenn tatsächlich etwas nicht mehr funktioniert.
Malware ist für mich allerdings nicht der Hauptgrund, warum ich mich mit Secure Boot beschäftige. Vielmehr liegt es daran, dass ich meine EFI-Partition nicht verschlüsseln kann. Dadurch ist mein Verschlüsselungskonzept noch unvollständig: Zwar sind meine Root-Partition und der Swap-Bereich verschlüsselt, nicht jedoch der Bootloader und der Linux-Kernel, die auf der EFI-Partition liegen. Diese sind somit ungeschützt und könnten manipuliert werden – etwa, um beim nächsten Start meine Schlüssel oder Passwörter für die verschlüsselten Partitionen abzugreifen. Ich möchte eine solche Manipulation an meinem Gerät einfach erkennen können.
Zugegeben: Ich brauche diesen hohen Schutz eigentlich nicht zwingend, und mit meiner aktuellen Lösung bin ich zufrieden. Aber der Vollständigkeit halber möchte ich es einmal umgesetzt haben – einfach, um zu verstehen, wie es funktioniert.
LG
Sebastian
|
| « Letzte Änderung: 23. August 2025, 13:31:00 von Sebastian » |
Gespeichert
|
Wo die digitale Kultur blüht, nutzen Angreifer Emotionen, Gewohnheiten und Markenbindung aus. Der Schutz beginnt nicht mit Technik, sondern mit Bewusstsein. Wer sich informiert, vorsichtig klickt und sichere Tools nutzt, kann auch unbeschwert an der Digitalkultur teilnehmen.
|
|
|
Seiten: [1] 
|
|
|
|
|
|
|
