[gelöst] Wie sicher ist UEFI Secure Boot?

Das ist nicht nur eine Frage sondern soll eine Diskussion starten.
Wie kommen die Keys in's UEFI? Klar, die sind vorinstalliert. Sicherlich müssen die aber mal aktualisiert werden. Aber wie? Über UEFI/BIOS Update? Über Windows Update? Wer oder was darf die verändern oder hinzu fügen?
Ich habe eben openSUSE Leap 15.1 installiert. Da kam beim Booten vom Stick als Erstes die Frage (auf englisch), ob ich den Sicherheitszertifikaten vertraue. Nach Bejahen lief die Installation dann durch. Bei einem erneuten Booten vom Stick kam diese Frage nicht mehr. Also ab in's UEFI. Aha, da wurde ein Key hinzu gefügt. So einfach geht das? Die Abfrage beim Starten hätte ja auch lauten können: Wollen sie XYZ starten? Dann würde wohl (fast) jeder auf Ja klicken. Geht das so einfach oder müssen die Keys bestimmte Anforderungen erfüllen, um vom UEFI angenommen zu werden?
Also Hauptfrage: Könnte eine Malware das auch ausnutzen?

Also ab in's UEFI. Aha, da wurde ein Key hinzu gefügt. So einfach geht das?

Zum Vergrößern anklicken....

Bei mir kann man keine Keys sehen.
Windows 10 KEYs sind im Bios Baustein und auch nicht zu sehen. Auslesen ist ja wohl was anderes.
Ansonsten geht es bei Secureboot doch um Bootmedien.
Secure Boot: Was ist das? Wie deaktivieren?

Ich habe in meinem UEFI Bios nie irgendwelche Keys gesehen oder die Möglichkeit gegebenenfalls vorhandene Keys auszulesen.
Wie macht man das? Welche Keys würden den gegebenenfalls dort gespeichert?
Sorry,wenn ich mich da etwas doof anstelle.Doch solche Fragen haben mich eigentlich bis jetzt nie beschäftigt.
Ich weiss nur,wenn Secure Boot aktiviert ist,kann man kein anderes BS installieren.
Soooo sicher scheint es aber auch nicht zu sein.Das ist von 2016. Vielleicht wurde das ja zwischenzeitlich verbessert.

Hier noch der Link auf den von @Iskandar zitierten Wikipedia-Artikel

Unified Extensible Firmware Interface – Wikipedia

Da kann man noch weiter lesen.

Meine Meinung: Secure Boot hat viel mehr Ärger verursacht als es an Sicherheit gebracht hat.

Hallo,

Sicherlich müssen die aber mal aktualisiert werden. Aber wie? Über UEFI/BIOS Update? Über Windows Update? Wer oder was darf die verändern oder hinzu fügen?

Zum Vergrößern anklicken....

Leitfaden zur Erstellung und Verwaltung von Windows-sicheren Start Schlusseln | Microsoft Docs


wer Interesse hat kann sich ja hier Informieren !

Gruß

Porky schrieb:

Das ist nicht nur eine Frage sondern soll eine Diskussion starten.
Wie kommen die Keys in's UEFI? Klar, die sind vorinstalliert. Sicherlich müssen die aber mal aktualisiert werden. Aber wie? Über UEFI/BIOS Update? Über Windows Update? Wer oder was darf die verändern oder hinzu fügen?

Zum Vergrößern anklicken....

Abseits von Sicherheitslücken nur über die von Dir genannten Methoden und natürlich der Nutzer, indem er in den BIOS-Einstellungen manuell Keys von den angeschlossenen Datenträgern oder aus dem Netz installiert.

Ich habe eben openSUSE Leap 15.1 installiert. Da kam beim Booten vom Stick als Erstes die Frage (auf englisch), ob ich den Sicherheitszertifikaten vertraue. Nach Bejahen lief die Installation dann durch. Bei einem erneuten Booten vom Stick kam diese Frage nicht mehr. Also ab in's UEFI. Aha, da wurde ein Key hinzu gefügt. So einfach geht das? Die Abfrage beim Starten hätte ja auch lauten können: Wollen sie XYZ starten? Dann würde wohl (fast) jeder auf Ja klicken. Geht das so einfach oder müssen die Keys bestimmte Anforderungen erfüllen, um vom UEFI angenommen zu werden?
Also Hauptfrage: Könnte eine Malware das auch ausnutzen?

Zum Vergrößern anklicken....

Kommt alles auf das UEFI an. Die meisten UEFI erlauben eine derartige Prozedur nicht. Wenn doch, sollte die abschaltbar sein. Die Abfrage kommt natürlich nicht von der Software, sondern vom UEFI und sollte so einfach nicht manipuliert werden können. Die Keys müssen abseits vom Format nur die Anforderungen erfüllen, die der jeweilige Nutzer, also in diesem Fall Du, stellt.

Secure Boot funktioniert nur über Vertrauen. Das UEFI vertraut ab Werk nur den Keys von Microsoft bzw. denjenigen, die Microsoft signiert hat. Diverse Linux-Distritutionen haben sich letztere von Microsoft ausstellen lassen und laufen so auch mit aktiviertem Secure Boot. Das ganze funktioniert aber auch nur, wenn alle Komponenten in der Kette vom Bootloader bis zum Betriebssystemkern, den geladenen Treibern usw. sich jeweils gegenseitig bzw. den jeweils signierten Zertifikaten vertrauen. Bei einem unveränderten Windows ist das gewährleistet. Aber bei Linux läßt sich das i.d.R. kaum einhalten. Erst recht nicht, wenn man Teile des Systems selbst kompiliert. Bei Linux endet dann das Vertrauen dann kurz hinter dem Bootloader und Secure Boot ist somit mehr oder weniger wirkungslose.

Iskandar schrieb:

Ich habe in meinem UEFI Bios nie irgendwelche Keys gesehen oder die Möglichkeit gegebenenfalls vorhandene Keys auszulesen.
Wie macht man das? Welche Keys würden den gegebenenfalls dort gespeichert?

Zum Vergrößern anklicken....

Den Platform Key (PK) muss man nicht sehen - der nützt einem auch nichts. Der Platform Key wird jedes Mal neu vergeben, nachdem das CMOS resettet oder geflasht wurde.

Für Deine Intel-Plattform lohne es sich dann ebenso, die Intel Software Guard Extensions (SGX) mit zu aktivieren.
Damit besteht zwar eine Sicherheitslücke, doch dafür wird ein Microcode verteilt, der die Kennung "Virtual Translation Bypass: CVE-2018-3615" trägt:

- Spectre Next Generation Variant 5a (Spectre-NG V5a)
- Google Project Zero Variant 5a (GPZ V5a)
- L1 Terminal Fault: Software Guard Extensions (L1TF:SGX)
- Meltdown-P

Seltsam, ich bekomme die Zertifikatsabfrage nicht mehr hin, obwohl ich die Factory Keys geladen habe. Bei dem markierten Eintrag stand vorher Mixed, jetzt wieder Factory:
Linux bootet trotzdem. Auf Clear CMOS habe ich keine Lust.

Hallo, schaue doch mal ob "Secure-Boot" überhaupt vom System akzeptiert ist !

UEFISecureBootEnabled =1 !

Gruß

Ja, ist aktiviert. Da habe ich schon bei der Installation drauf geachtet.

Secure Boot ist nur eine Datenbank mit Bootloader-Signaturen. Betriebssystem-Entwickler, die ihr System unter Secure Boot bootfähig haben wollen, müssen ihre Signatur an den entsprechenden Stellen einreichen, und dann werden sie in die Standard-Datenbank übernommen und von den Mainboard-Herstellern per UEFI-Update an die Endkunden verteilt. Soweit ich weiß, dürfen Betriebssysteme, die schon in der Datenbank freigegeben sind, auch Updates für diese einspielen.

Große Linux-Distributionen wie Ubuntu haben das gemacht und bieten daher z.B. auch volle Secure Boot - Unterstützung. Im UEFI-Setup kann man normalerweise die hinterlegten Signaturen einsehen, meist gibt es dort Funktionen wie "Install default Secure Boot Keys" oder "Install custom Secure Boot Keys".

Wichtig ist die Unterscheidung, ob sich Secure Boot im "Setup"- oder "User"-Modus befindet. Änderungen an den Signaturen sollte eigtl. nur im Setup-Modus gehen meines Wissens. Nach der Installation des OS sollte das dann automatisch in den User-Modus switchen.
Problematisch ist es nur, wenn der Board-Hersteller sich nicht so 100% an die Spezifikationen hält. Bei meinem Board lässt sich z.B. Secure Boot auch bei aktiviertem CSM einschalten, wobei es dann genau gar nichts bringt. Denn wenn man klassisch per BIOS bootet (per CSM), wird Secure Boot komplett getunnelt und greift gar nicht. Trotzdem meldet Windows, dass die Plattform beim Booten sicher ist, was dann natürlich völliger Mumpitz ist. In dem Zustand würde das System anstandslos von jeder x-beliebigen Live-CD booten.

Irgendsoein Mist wird das daher bei dir vermutlich auch sein. Es ist definitiv nicht Sinn der Sache, dass jeder nicht hinterlegte Bootloader dort beim Hochfahren auf Knopfdruck eingetragen wird. Das sollte nur dann gehen, wenn der Nutzer ins UEFI-Setup geht und in die entsprechende Konfiguration. Damit das sicher ist, muss im UEFI selbstverständlich ein Supervisor/Admin-Passwort vergeben sein, sonst kann jeder der physisch Zugriff auf den PC hat sich einen fremden Bootloader selber signieren.

Betriebssystem-Entwickler, die ihr System unter Secure Boot bootfähig haben wollen, müssen ihre Signatur an den entsprechenden Stellen einreichen, und dann werden sie in die Standard-Datenbank übernommen und von den Mainboard-Herstellern per UEFI-Update an die Endkunden verteilt.

Zum Vergrößern anklicken....

Die Stelle ist Microsoft. Andere Signaturen werden normal nicht vom Werk mitgeliefert. So habe ich das jedenfalls in Erinnerung.

Zumindest wird das überall so verbreitet. In der Linux-Gemeinde hält sich ja auch die Angst, daß Microsoft bei Verfehlungen einer Distribution diese von Secure Boot ausschließen würde.

Den aktuellen Stand weiß ich nicht, aber in der Vergangenheit haben einige Linux-Distributionen tatsächlich nach dem Bootloader die Überprüfung von Signaturen beendet bzw. das dem Nutzer zur Wahl gestellt. Keine Ahnung wie Microsoft dazu steht, aber bisher habe ich noch nichts davon gehört, daß Microsoft irgendeinem System das Vertrauen entzogen hat. Im Gegenteil sind es immer mehr Distributionen geworden, die mit aktiviertem Secure Boot starten können.

Microsoft konnte das übrigens nur durchsetzen, weil man als Hersteller eines Systems bzw. Mainboards ohne Secure Boot kein OEM-Windows bekommt bzw. kein Windows-Logo auf seine Hardware kleben darf. Bei aller Kritik an Microsoft, ist Secure Boot grundsätzlich eine sehr gute Lösung, wenn es vom System tatsächlich bis hin zu den signierten Treibern umgesetzt wird, was bei Linux natürlich manchmal schwierig ist.

Als ich kürzlich auch eine Frage zum Secure-Boot hatte und erst jetzt meinen ersten PC mit einem UEFI-Motherboard zusammengebaut habe, bekam ich von einem Kollegen diesen sehr aufschlussreichen Artikel zum Lesen:

UEFI-Secure-Boot und alternative Betriebssysteme - ADMIN IT-Praxis & Strategie

Ich fand ihn sehr nützlich, er hatte mein Wissen dieses für mich neuen Themas erheblich verbessert und kann ihn daher wärmstens empfehlen. Anschließend sollte es möglich sein, sich selbst ein Urteil über den Sinn oder Unsinn dieser Sicherheitsmaßnahme zu bilden. Man sollte sich allerdings auch die Mühe machen, alle 5 Seiten der Abhandlung zu lesen, sonst kann man es gleich sein lassen und hier oder in anderen Foren langwierig weitere Bruchstücke aufsammeln.

Ich habe ein Problem unter Linux mit einem selbst kompilierten Treiber, der nicht geladen wird. Kann ja dann auch an Secure Boot liegen. Noch will ich das nicht deaktivieren...

Du musst dann gar nicht Secure Boot deaktivieren, sondern nur die Fortsetzung der Überprüfung der Signatur des nächsten Elements nach dem Bootloader deaktivieren bzw. den Treiber selbst signieren. Linux lässt da eine viel feinkörnigere Vorgehensweise zu als Windows. In Windows kann man letztendlich nur die Überprüfung der Treibersignaturen abschalten, einen Treiber signieren können nur die Hardwarehersteller. In den meisten Distributionen kann man einstellen, ob nach dem Bootloader auch die Signatur des Kernels oder weiterer Komponenten überprüft wird. Es sollte auch möglich sein den Kernel eine Ausnahme für den unsignierten Treiber machen zu lassen.

Ideal wäre ein eigenes signiertes Zertifikat für den Treiber, das dann im System als vertrauenswürdig eingestuft wird. Da die Überprüfung dieser Signatur vom Betriebssystem durchgeführt wird und nicht vom UEFI, sind auch keine Änderungen am UEFI und den dort hinterlegten Keys notwendig, denn die Distribution selbst bzw. deren Bootloader ist schon signiert.

Ich denke, ich weiß jetzt, was openSuSE bei der Abfrage in #1 gemacht hat: Es wurde ein user password auf der SSD gesetzt. Aufgefallen ist das, weil im UEFI kein Secure Erase mehr ging. Zurücksetzen ließ sich das nur mit dem Herstellertool der SSD und der auf der SSD aufgedruckten PSID. Aber was hat das mit Secure Boot zu tun?