TPM und BIOS-Fallen: Warum selbst funktionierende Systeme scheitern können

Fall 7: Secure Boot - aktiv, aber irgendwie doch nicht

Ein häufiger Stolperstein bei der Umstellung ist der sogenannte Custom Mode. Viele Mainboards schalten automatisch in diesen Zustand, sobald man im UEFI die Secure-Boot-Schlüssel manuell anfasst oder ein BIOS-Update einspielt. Das System zeigt dann zwar "Secure Boot: Enabled" an, Windows meldet im Gegenzug aber "Secure Boot off". Der Widerspruch ist kein Bug, sondern schlicht ein fehlender Satz gültiger Signaturschlüssel. Im Custom-Modus erwartet das UEFI, dass die Plattform- und Key-Exchange-Keys (PK und KEK) manuell eingespielt werden. Fehlen sie, ist Secure Boot formal aktiv, aber faktisch wirkungslos. Das wiederum reicht den neuen Anti-Cheat-Prüfungen nicht, die auf eine vollständige, verifizierte Kette angewiesen sind.

Quelle: NZXT Im Custom-Modus lässt sich Secure Boot nicht aktivieren, solange kein Platform Key (PK) hinterlegt ist. Die Lösung ist möglicherweise einfach, aber versteckt: Im Secure-Boot-Menü des BIOS lässt sich über "Install Default Keys" oder "Factory Keys" der Originalzustand wiederherstellen. Danach erkennt Windows die Funktion korrekt und Secure Boot arbeitet wieder so, wie es gedacht war.

Fall 8: Wenn die Sperrliste selbst zum Problem wird

Mit den sogenannten DBX-Updates sollen eigentlich unsichere Bootloader blockiert werden, also solche, deren Zertifikate kompromittiert oder zurückgezogen wurden. In der Praxis läuft das aber nicht immer reibungslos. Manche Firmware-Versionen nehmen die aktualisierte Sperrliste schlicht nicht an oder brechen den Vorgang kommentarlos ab. Das Ergebnis: Ein System, das gültige Bootloader plötzlich ablehnt oder beim Start in einer Endlosschleife hängt. Das Problem betrifft vor allem ältere UEFI-Versionen, die das SBAT-Format (Secure Boot Advanced Targeting) noch nicht vollständig unterstützen. In solchen Fällen verweigert das Board die Aufnahme neuer DBX-Einträge, weil die interne Struktur inkompatibel ist. Windows oder das UEFI-Setup melden dann "Update failed", aber ohne weiteren Hinweis.

Abhilfe schafft meist nur ein BIOS- oder Firmware-Update, das die SBAT-Unterstützung nachrüstet. Erst danach lässt sich die DBX-Liste sauber aktualisieren. Ohne dieses Update bleibt das System in einem Zustand, der ironischerweise genau das Gegenteil von Sicherheit erreicht: Secure Boot ist aktiv, blockiert aber legitime Bootloader und damit im Zweifel auch das eigene Betriebssystem. TPM aktiv, Secure Boot läuft, und trotzdem will Windows den Bitlocker-Schlüssel? Warum das kein Fehler, sondern Absicht ist, erfahren Sie auf Seite 5.

Artikel teilen

Battlefield 6 und Co.: 11 Probleme mit TPM 2.0 und Secure Boot Wer glaubt, nach Secure Boot und UEFI sei alles geklärt, irrt. Manchmal zeigt sich, dass selbst aktuelle Systeme Probleme machen.

Per E-Mail versenden

31

1. Seite 1 Übersicht und was zu unterlassen ist
2. Seite 2 Secure Boot, CSM und GPT richtig reparieren
3. Seite 3 Wenn Secure Boot mehr blockiert als schützt
4. Seite 4 TPM und BIOS-Fallen: Funktionierende Systeme können scheitern
5. Seite 5 TPM-Fallen und OEM-Sperren
6. Seite 6 Bitlocker-Alarm nach BIOS-Update