Was ist UEFI Secure Boot?

UEFI Secure Boot ist ein Verifikationsmechanismus, der sicherstellt, dass von der Firmware gestarteter Code vertrauenswürdig ist. Die ordnungsgemäße, sichere Verwendung von UEFI Secure Boot erfordert, dass jede beim Booten geladene Binärdatei anhand bekannter Schlüssel in der Firmware validiert wird, die vertrauenswürdige Anbieter und Quellen für die Binärdateien oder vertrauenswürdige spezifische Binärdateien angeben, die über kryptografisches Hashing identifiziert werden können.

Die meiste x86-Hardware ist ab Werk mit Microsoft-Schlüsseln vorinstalliert. Dies bedeutet, dass wir uns im Allgemeinen darauf verlassen können, dass die Firmware auf diesen Systemen Binärdateien vertraut, die von Microsoft signiert sind, und die Linux-Community verlässt sich stark auf diese Annahme, damit Secure Boot funktioniert. Dies ist der gleiche Prozess, der beispielsweise von Red Hat und SUSE verwendet wird.

Viele ARM- und andere Architekturen unterstützen auch UEFI Secure Boot, laden jedoch möglicherweise keine Schlüssel in die Firmware vor. Auf diesen Architekturen kann es erforderlich sein, Boot-Images mit einem Zertifikat neu zu signieren, das vom Besitzer der Hardware in die Firmware geladen wird.

Initialer Implementierungsplan: Implementierungsplan.

Unterstützte Architekturen

• amd64: Eine von Microsoft signierte Shim-Binärdatei und eine von Canonical signierte Grub-Binärdatei werden im Ubuntu-Hauptarchiv als shim-signiert oder grub-efi-amd64-signiert bereitgestellt.

• arm64: Ab 20.04 (‚focal‘) werden eine von Microsoft signierte Shim-Binärdatei und eine von Canonical signierte Grub-Binärdatei im Ubuntu-Hauptarchiv als shim-signed oder grub-efi-arm64-signed bereitgestellt. Es wird ein GRUB-Fehler untersucht, der behoben werden muss, bevor dies von Ende zu Ende funktioniert.

Testen von UEFI Secure Boot

Wenn Sie Secure Boot auf Ihrem System testen möchten, lesen Sie die Anleitung hier: UEFI/SecureBoot/Testing.

Funktionsweise von UEFI Secure Boot unter Ubuntu

Unter Ubuntu sind alle vorgefertigten Binärdateien, die als Teil des Startvorgangs geladen werden sollen, mit Ausnahme des initrd-Images, vom UEFI-Zertifikat von Canonical signiert, dem implizit vertraut wird, indem es in den von Microsoft signierten Shim-Loader eingebettet wird.

Auf Architekturen oder Systemen, auf denen vorinstallierte Signaturzertifikate von Microsoft nicht verfügbar oder in Firmware geladen sind, können Benutzer die vorhandenen Signaturen auf shim oder grub ersetzen und nach Belieben laden, wobei sie ihre eigenen Zertifikate überprüfen, die in die Firmware des Systems importiert wurden.

Beim Booten des Systems lädt die Firmware die Shim-Binärdatei, wie in den Firmware-BootEntry-Variablen angegeben. Ubuntu installiert zur Installationszeit einen eigenen Bootloader und kann ihn jederzeit aktualisieren, wenn der GRUB-Bootloader aktualisiert wird. Da die Shim-Binärdatei von Microsoft signiert ist; es wird von der Firmware validiert und akzeptiert, wenn es anhand von Zertifikaten überprüft wird, die bereits in der Firmware vorhanden sind. Da die Shim-Binärdatei ein Canonical-Zertifikat sowie eine eigene Vertrauensdatenbank einbettet, können weitere Elemente der Boot-Umgebung zusätzlich zur Signierung durch eines der in der Firmware vorinstallierten akzeptablen Zertifikate mit dem UEFI-Schlüssel von Canonical signiert werden.

Das nächste, was von shim geladen wird, ist das Bild der zweiten Stufe. Dies kann eines von zwei Dingen sein: entweder GRUB, wenn das System normal bootet; oder MokManager, wenn eine Schlüsselverwaltung erforderlich ist, wie durch Firmware-Variablen konfiguriert (normalerweise geändert, wenn das System zuvor ausgeführt wurde).

Wenn normal gebootet wird; die GRUB-Binärdatei (grub*.efi) geladen und seine Validierung wird anhand aller zuvor bekannten vertrauenswürdigen Quellen versucht. Die GRUB-Binärdatei für Ubuntu ist mit dem kanonischen UEFI-Schlüssel signiert, sodass sie erfolgreich validiert wird und der Startvorgang fortgesetzt wird.

Wenn Sie booten, um mit Schlüsselverwaltungsaufgaben fortzufahren, wird die MokManager-Binärdatei (mm*.efi) geladen wird. Diese Binärdatei wird von shim explizit als vertrauenswürdig eingestuft, indem sie von einem kurzlebigen Schlüssel signiert wird, der nur während der Erstellung der Shim-Binärdatei vorhanden ist. Dies bedeutet, dass nur die mit einer bestimmten Shim-Binärdatei erstellte MokManager-Binärdatei ausgeführt werden darf und die Möglichkeit von Kompromissen durch die Verwendung kompromittierter Tools begrenzt ist. MokManager ermöglicht jedem Benutzer, der an der Systemkonsole anwesend ist, Schlüssel zu registrieren, vertrauenswürdige Schlüssel zu entfernen, binäre Hashes zu registrieren und die Secure Boot-Validierung auf Shim-Ebene umzuschalten, aber die meisten Aufgaben erfordern die Eingabe eines zuvor festgelegten Kennworts, um zu bestätigen, dass der Benutzer an der Konsole tatsächlich die Person ist, die Änderungen angefordert hat. Solche Passwörter überleben nur über einen einzigen Lauf von shim / MokManager; und werden gelöscht, sobald der Prozess abgeschlossen oder abgebrochen wird. Sobald die Schlüsselverwaltung abgeschlossen ist, wird das System neu gestartet und fährt nicht einfach mit dem Booten fort, da die Änderungen an der Schlüsselverwaltung erforderlich sein können, um den Start erfolgreich abzuschließen.

Sobald das System weiter auf GRUB bootet, lädt der GRUB-Prozess jede erforderliche Konfiguration (normalerweise wird die Konfiguration von der ESP (EFI-Systempartition) geladen, wobei auf eine andere Konfigurationsdatei auf der Root- oder Boot-Partition verwiesen wird), die auf das zu ladende Kernel-Image verweist.

EFI-Anwendungen, die bis zu diesem Zeitpunkt vollen Zugriff auf die Systemfirmware haben, einschließlich des Zugriffs auf sich ändernde vertrauenswürdige Firmware-Variablen, muss der zu ladende Kernel auch gegen die Vertrauensdatenbank validiert werden. Offizielle Ubuntu-Kernel, die mit dem kanonischen UEFI-Schlüssel signiert sind, werden erfolgreich validiert und die Kontrolle wird an den Kernel übergeben. Initrd-Bilder werden nicht validiert.

Im Fall von inoffiziellen Kerneln oder von Benutzern erstellten Kerneln müssen zusätzliche Schritte unternommen werden, wenn Benutzer solche Kernel laden möchten, während sie die vollen Funktionen von UEFI Secure Boot beibehalten. Alle Kernel müssen signiert sein, damit sie von GRUB geladen werden können, wenn UEFI Secure Boot aktiviert ist. Alternativ können Benutzer die Validierung in shim deaktivieren, während Secure Boot auf einem offiziellen Kernel aktiviert ist, indem sie ’sudo mokutil –disable-validation‘ verwenden, ein Kennwort angeben, wenn sie dazu aufgefordert werden, und neu starten. oder Secure Boot in der Firmware insgesamt deaktivieren.

Bis zu diesem Punkt wird jeder Fehler bei der Validierung eines zu ladenden Images mit einem kritischen Fehler beantwortet, der den Startvorgang stoppt. Das System wird nicht weiter gestartet und wird möglicherweise nach einer gewissen Zeit automatisch neu gestartet, da andere BootEntry-Variablen gültige und vertrauenswürdige Bootpfade enthalten können.

Nach dem Laden deaktivieren validierte Kernel die Boot-Dienste der Firmware, wodurch Privilegien fallen und effektiv in den Benutzermodus gewechselt wird; wo der Zugriff auf vertrauenswürdige Variablen auf schreibgeschützt beschränkt ist. Angesichts der weitreichenden Berechtigungen, die Kernelmodulen gewährt werden, muss jedes Modul, das nicht in den Kernel integriert ist, auch beim Laden validiert werden. Module, die von Canonical mit den offiziellen Kerneln erstellt und ausgeliefert werden, sind mit dem Canonical UEFI-Schlüssel signiert und als solche vertrauenswürdig. Benutzerdefinierte Module erfordern, dass der Benutzer die notwendigen Schritte unternimmt, um die Module zu signieren, bevor sie vom Kernel geladen werden dürfen. Dies kann mit dem Befehl ‚kmodsign‘ erreicht werden.

Unsignierte Module werden vom Kernel einfach abgelehnt. Jeder Versuch, sie mit insmod oder modprobe einzufügen, schlägt mit einer Fehlermeldung fehl.

Da viele Benutzer Module von Drittanbietern benötigen, damit ihre Systeme ordnungsgemäß funktionieren oder einige Geräte funktionieren; und da diese Module von Drittanbietern lokal auf dem System aufgebaut werden müssen, um an den laufenden Kernel angepasst zu werden, bietet Ubuntu Tools zur Automatisierung und Vereinfachung des Signiervorgangs.

Wie kann ich Treiber nicht automatisch signieren?

Einige Projekte erfordern möglicherweise die Verwendung benutzerdefinierter Kerneltreiber, die nicht so eingerichtet sind, dass sie mit DKMS funktionieren. In diesen Fällen sollten die Benutzer die im shim-signierten Paket enthaltenen Tools verwenden: Das Skript update-secureboot-policy ist verfügbar, um ein neues MOK zu generieren (wenn noch keine von DKMS erstellten Module die Generierung eines MOK ausgelöst haben).

Verwenden Sie den folgenden Befehl, um einen vorhandenen Schlüssel in shim einzutragen:

sudo update-secureboot-policy --enroll-key

Wenn kein MOK vorhanden ist, wird das Skript mit einer entsprechenden Meldung beendet. Wenn der Schlüssel bereits registriert ist, wird das Skript beendet, ohne etwas zu tun. Wenn der Schlüssel vorhanden ist, aber nicht als registriert angezeigt wird, wird der Benutzer nach dem Neustart zur Eingabe eines Kennworts aufgefordert, damit der Schlüssel registriert werden kann.

Man kann einen neuen MOK mit dem folgenden Befehl generieren:

sudo update-secureboot-policy --new-key

Und dann den neu generierten Schlüssel mit dem zuvor erwähnten Befehl für diese Aufgabe in shim einschreiben.

Kernelmodule können dann mit dem Befehl kmodsign (siehe UEFI/SecureBoot/Signing) als Teil ihres Erstellungsprozesses signiert werden.

Auswirkungen auf die Sicherheit bei der Verwaltung der Schlüssel des Maschinenbesitzers

Der bei der Installation oder beim Upgrade generierte MOK ist maschinenspezifisch und darf nur vom Kernel oder Shim Kernelmodule signieren, indem eine bestimmte keyUsage-OID (1.3.6.1.4.1.2312.16.1.2) verwendet wird, die die Einschränkungen des MOK angibt.

Neuere Shim-Versionen enthalten Logik, um den Einschränkungen von Nur-Modul-Signaturschlüsseln zu folgen. Diese Schlüssel dürfen in die Firmware in der Vertrauensdatenbank von shim aufgenommen werden, werden jedoch ignoriert, wenn shim oder GRUB Images zum Laden in die Firmware validieren. Die verify() -Funktion von Shim validiert nur erfolgreich Bilder, die mit Schlüsseln signiert sind, die nicht die keyUsage-OID „Module-signing only“ (1.3.6.1.4.1.2312.16.1.2) enthalten. Die Ubuntu-Kernel verwenden die globale Vertrauensdatenbank (die sowohl Shim als auch Firmware enthält) und akzeptieren beim Laden von Kernelmodulen alle enthaltenen Schlüssel als Signaturschlüssel.

Angesichts der Einschränkungen, die dem automatisch generierten MOK auferlegt werden, und der Tatsache, dass Benutzer mit Superuser-Zugriff auf das System und Zugriff auf die Systemkonsole zur Eingabe des Kennworts, das bei der Registrierung von Schlüsseln erforderlich ist, bereits übergeordneten Zugriff auf das System haben, wird der generierte MOK-Schlüssel als reguläre Dateien im Besitz von root mit schreibgeschützten Berechtigungen im Dateisystem gespeichert. Dies wird als ausreichend erachtet, um den Zugriff auf das MOK zum Signieren durch böswillige Benutzer oder Skripte einzuschränken, insbesondere da auf dem System kein MOK vorhanden ist, es sei denn, es werden Treiber von Drittanbietern benötigt. Dies begrenzt die Möglichkeit einer Kompromittierung durch den Missbrauch eines generierten MOK-Schlüssels zum Signieren eines schädlichen Kernelmoduls. Dies entspricht einer Kompromittierung der Userland-Anwendungen, die bereits mit Superuser-Zugriff auf das System möglich wäre, und deren Sicherung liegt außerhalb des Anwendungsbereichs von UEFI Secure Boot.

Bei früheren Systemen war die Secure Boot-Validierung in shim möglicherweise deaktiviert. Im Rahmen des Upgrade-Prozesses werden diese Systeme migriert, um die Secure Boot-Validierung in shim erneut zu aktivieren und gegebenenfalls einen neuen MOK-Schlüssel zu registrieren.

MOK-Generierung und Signiervorgang

Der Schlüsselgenerierungs- und Signiervorgang unterscheidet sich geringfügig, je nachdem, ob es sich um eine brandneue Installation oder ein Upgrade eines Systems handelt, auf dem zuvor Ubuntu ausgeführt wurde.

In allen Fällen, wenn das System nicht im UEFI-Modus bootet, werden keine speziellen Signierschritte des Kernelmoduls oder Schlüsselgenerierung stattfinden.

Wenn Secure Boot deaktiviert ist, erfolgt die MOK-Generierung und -registrierung weiterhin, da der Benutzer später Secure Boot aktivieren kann. Das System sollte ordnungsgemäß funktionieren, wenn dies der Fall ist.

Der Benutzer installiert Ubuntu auf einem neuen System

Der Benutzer führt den Installer durch. Bereits bei der Vorbereitung der Installation und nur dann, wenn das System Module von Drittanbietern benötigt, wird der Benutzer zur Eingabe eines Systemkennworts aufgefordert, das nach Abschluss der Installation eindeutig als erforderlich gekennzeichnet ist.

Vom System benötigte Treiber oder Kernelmodule von Drittanbietern werden automatisch erstellt, wenn das Paket installiert wird. Der Signierungsschritt verwendet automatisch die zuvor generierte MOK, um das Modul zu signieren, sodass es sofort geladen werden kann, sobald das System neu gestartet wird und die MOK in die Vertrauensdatenbank des Systems aufgenommen wird.

Sobald die Installation abgeschlossen ist und das System neu gestartet wird, wird dem Benutzer beim ersten Start das MokManager-Programm (Teil des installierten Shim-Laders) als eine Reihe von Textmodus-Panels angezeigt, die es dem Benutzer ermöglichen, das generierte MOK zu registrieren. Der Benutzer wählt „MOK registrieren“ aus, erhält einen Fingerabdruck des Zertifikats zur Registrierung und wird aufgefordert, die Registrierung zu bestätigen. Nach der Bestätigung wird das neue MOK in die Firmware eingegeben und der Benutzer wird aufgefordert, das System neu zu starten.

Wenn das System neu gestartet wird, werden Treiber von Drittanbietern, die vom MOK-Treiber signiert wurden, nach Bedarf geladen.

Der Benutzer aktualisiert ein UEFI-fähiges Ubuntu-System auf eine neue Version, bei der das System Treiber von Drittanbietern benötigt

Beim Upgrade werden die Shim- und Shim-signierten Pakete aktualisiert. Die Post-Install-Tasks des shim-signierten Pakets generieren einen neuen MOK und fordern den Benutzer zur Eingabe eines Kennworts auf, das nach Abschluss des Upgrade-Vorgangs und dem Neustart des Systems eindeutig als erforderlich angegeben wird.

Während des Upgrades werden die Kernelpakete und Module von Drittanbietern aktualisiert. Module von Drittanbietern werden für die neuen Kernel neu erstellt, und ihr Post-Build-Prozess signiert sie automatisch mit dem MOK.

Nach dem Upgrade wird dem Benutzer empfohlen, sein System neu zu starten.

Beim Neustart wird dem Benutzer das MokManager-Programm (Teil des installierten Shim-Laders) als eine Reihe von Textmodus-Panels angezeigt, die es dem Benutzer ermöglichen, das generierte MOK zu registrieren. Der Benutzer wählt „MOK registrieren“ aus, erhält einen Fingerabdruck des Zertifikats zur Registrierung und wird aufgefordert, die Registrierung zu bestätigen. Der Benutzer wird außerdem aufgefordert, die Secure Boot-Validierung erneut zu aktivieren (falls festgestellt wurde, dass sie deaktiviert ist). und MokManager erfordert erneut eine Bestätigung des Benutzers. Sobald alle Schritte bestätigt sind, wird die Shim-Validierung wieder aktiviert, der neue MOK wird in die Firmware eingegeben und der Benutzer wird aufgefordert, das System neu zu starten.

Wenn das System neu gestartet wird, werden Treiber von Drittanbietern, die vom MOK-Treiber signiert wurden, nach Bedarf geladen.

Sobald das System mit aktiviertem UEFI Secure Boot und einer aktuellen Version von shim ausgeführt wird; Die Installation eines neuen DKMS-Moduls (Treiber eines Drittanbieters) wird fortgesetzt, um das integrierte Modul mit dem MOK zu signieren. Dies geschieht ohne Benutzerinteraktion, wenn ein gültiger MOK-Schlüssel auf dem System vorhanden ist und bereits registriert zu sein scheint.

Wenn kein MOK vorhanden ist oder der vorhandene MOK nicht registriert ist, wird kurz vor dem Signieren automatisch ein neuer Schlüssel erstellt, und der Benutzer wird aufgefordert, den Schlüssel durch Angabe eines Kennworts zu registrieren, das beim Neustart erforderlich ist.