Mit eigenen Schlüsseln

Im Folgenden wird gezeigt, wie Debian 7.1.0 in einer Dual-Secure-Boot-Umgebung neben Windows 8 Pro installiert und konfiguriert werden kann. Das Debian-System soll hierbei unabhängig von den Zertifikaten der Firma Microsoft bei aktivem Secure Boot betriebsfähig sein. Die Betriebsfähigkeit von Windows 8 Pro soll hierdurch nicht beeinträchtigt werden. Keines der beiden Systeme soll die UEFI-Zertifikatsspeicher modifizieren können.

Sofern die Installation der Betriebssysteme erfolgreich abgeschlossen ist, muss der Bootloader des Debian-Systems signiert oder dessen Hash in den db-Zertifikatsspeicher eingetragen werden. Das hätte aber einen wesentlichen Nachteil: Kommt es zu einem Update des Bootloaders, so fehlt diesem eine gültige Signatur beziehungsweise der Hash wird ungültig. Dadurch würden nachfolgende Bootvorgänge scheitern.

Aus diesem Grund wird ein Secure-Boot-Preloader genutzt, der durch die Befehle aus Listing 1 installiert wird.

01 # Erstellen der Konfigurationdatei des Secure-Boot-Preloaders
02 cat <<EOF > /tmp/conf
03 echo "Secure-Boot-Preloader: starting grub2"
04 chainloader /EFI/debian/grubx64.efi
05 boot
06 EOF
07
08 # Erstellen des Secure-Boot-Preloaders als monolithische Grub2-Version
09 grub-mkimage --format x86_64-efi --config /tmp/conf --output/boot/efi/EFI/debian/secure-
   boot-preloader.efi normal echo fat part_gpt chain
10
11 # Erstellen eines Eintrag in der UEFI-Firmware um den Secure-Boot-Loader zu
12 # booten
13 efibootmgr --create --label debian-secure-boot --loader \\EFI\\debian\\secure-boot-preloader
   .efi --disk /dev/sda --part 1
14 # disk und part müssen ggf. angepasst werden

Im Anschluss hieran wird der Secure-Boot-Loader signiert. Dazu dient das Werkzeug »sbsign« , das zu der Werkzeugsammlung »sbsigntools« gehört. Durch Ausführung des Befehls

sbsign --key db.key --cert db.pem.crt/boot/efi/EFI/debian/secure-boot-preloader.efi

wird der Secure-Boot-Loader signiert. Hierbei wird davon ausgegangen, dass der private Schlüssel, der zur Signierung von UEFI-Anwendungen verwendet werden soll, in der Datei »db.key« enthalten ist und dass das zugehörige Zertifikat in der Datei »db.pem.crt« vorliegt. Der Signierungsschritt sollte zur Sicherheit des privaten Schlüssels nicht auf dem betroffenen System selbst, sondern in einer sicheren Arbeitsumgebung stattfinden.

Nach erfolgreicher Einrichtung des Bootloaders werden die Zertifikatsspeicher der UEFI-Firmware gezielt modifiziert. Die Modifikation wird mittels der EFI-Tools durchgeführt. Hierzu wird das zugehörige USB-Image zum Beispiel mithilfe des Kommandos »dd« auf einen USB-Stick übertragen. Im Anschluss wird sowohl das Zertifikat Microsoft Windows Production PCA 2011 als auch die zum eigenen Schlüsselmaterial zugehörigen Schlüssel (PK, KEK, db) in ein Format umgewandelt, das von der UEFI-Firmware verarbeitet werden kann. Dazu dient der Befehl »cert-to-efi-sig-list« , der Bestandteil der EFI-Tools ist.

Nun wird das Secure-Boot-System der zu konfigurierenden Plattform über das UEFI-Setup in den Setup Mode versetzt, um die Modifikationen der Zertifikatsspeicher durchführen zu können. Das genaue Vorgehen hierzu ist plattformspezifisch.

Hiernach wird von dem vorbereiteten USB-Stick gebootet. Mittels der sich öffnenden UEFI-Shell wird durch Eingabe der folgenden Befehle das Werkzeug »keytool« gestartet. Es stellt eine rudimentäre textbasierte Oberfläche zur Modifikation der UEFI-Zertifikatsspeicher zur Verfügung:

fs0:
cd EFI
cd BOOT
KEYTOOL.EFI

Über den Menüpunkt »Edit Keys« wird ein Untermenü geöffnet, welches es ermöglicht, die Zertifikatsspeicher PK, KEK, db, dbx und MokList wie folgt zu modifizieren:

MokList: Alle eventuell vorhandenen Zertifikate und Hashes entfernen.

db: Alle eventuell vorhandenen Zertifikate und Hashes entfernen, Zertifikat Microsoft Windows Production PCA 2011 einfügen. Eigenes Zertifikat zur Signierung von UEFI-Anwendungen einfügen. Alternativ kann auch ein Hash des Bootloaders eingefügt werden.

dbx: Keine Änderungen notwendig.

KEK: Alle eventuell vorhandenen Zertifikate und Hashes entfernen, eigenes Zertifikat des KEK einfügen.

PK: Zertifikat des eigenen Plattform-Keys einsetzen.-

Hierbei ist zu beachten, dass die Modifikation des PK-Zertifikatsspeichers der letzte Arbeitsschritt sein muss, da durch das Einbringen eines Plattform-Keys der Setup Mode verlassen und in den User Mode gewechselt wird. Eine nachträgliche Manipulation der Zertifikatsspeicher ist dann nur noch über signierte Updates oder durch Löschen des Plattform-Keys mithilfe des UEFI-Setups möglich. Nach diesem Schritt kann Debian bei aktiviertem Secure Boot gestartet werden.

Fazit

Abschließend lässt sich festhalten, dass die UEFI-Implementierungen der untersuchten Plattformen in Bezug auf die Umsetzung von Secure Boot – soweit dies dieser Artikel untersucht hat – getreu der Spezifikation funktionieren. Das durch Microsoft im Rahmen des Windows Hardware Certification Program vorgeschriebene Zertifikat Microsoft Windows Production PCA 2011 wie auch das optionale Zertifikat Microsoft Corporation UEFI CA 2011 liefern alle untersuchten Hardware-Plattformen aus. Insbesondere durch Letzteres wird die Funktionstüchtigkeit von Betriebssystemen, die nicht von Microsoft bereitgestellt werden, bei aktiviertem Secure Boot grundsätzlich ermöglicht.

Des Weiteren unterstützen viele aktuelle Betriebssysteme wie Windows 8 Pro, Ubuntu 13.04 und Fedora 19 Secure Boot bereits. Die typische Installation dieser Systeme erzeugt einen mehr oder weniger umfassenden Schutz durch Secure Boot. Die untersuchten Betriebssysteme, welche Secure Boot von Haus aus nicht unterstützen, konkret Debian 7.0.1 und Red Hat Enterprise Linux 6.4, können mit geringem Aufwand auf allen untersuchten Hardware-Plattformen bei aktiviertem Secure Boot lauffähig gemacht werden.

Secure Boot besitzt das Potenzial, ein System effektiv vor unautorisierten Manipulationen zu schützen und die Sicherheit des Systems deutlich zu erhöhen. Wenngleich für einen umfassenden Schutz eines IT-Systems weitere Maßnahmen erforderlich sind und es einige Herausforderungen bei der Einführung von Secure Boot gibt, ermöglicht Secure Boot dem Eigentümer die Hoheit über sein IT-System zu bewahren. Dabei bieten sich dem Anwender bei handelsüblichen IT-Plattformen in der Regel keine alternativen Methoden zur Absicherung des Bootprozesses, die ähnlich effektiv eingesetzt werden könnten.

Eine weitere Stärke von Secure Boot ist, dass der Eigentümer des IT-Systems entscheiden kann, welche konkreten Schutzmaßnahmen er für das jeweilige System umsetzt. Dadurch ist es ihm möglich, das Verhältnis des Arbeitsaufwandes zum erzielten Sicherheitsgewinn zu optimieren. Darüber hinaus kann er individuelle Sicherheitslösungen erstellen.

Ein wesentlicher Nachteil des Einsatzes  von Secure Boot besteht darin, dass zwingend UEFI verwendet werden  muss. Mit Blick auf die Sicherheit UEFI-kompatibler Firmware gibt es bislang noch wenig praktische Erfahrung. Es besteht also durchaus die Gefahr, dass ein potenzieller Sicherheitsgewinn, der durch Secure Boot ermöglicht wird, durch (gewollte und ungewollte) Implementierungsfehler der Firmware zunichte gemacht wird. Speziell die flexible Erweiterbarkeit und  der Funktionsumfang ermöglichen den Herstellern die einfache Implementierung von Hintertüren. Des  Weiteren steht und fällt ein möglicher Sicherheitsgewinn mit der Integration von Secure Boot in das Betriebssystem. Wenngleich Secure Boot derzeit auf allen untersuchten Plattformen frei konfigurierbar ist, besteht die Gefahr, dass zukünftige Implementierungen diese Möglichkeit beschneiden und Geräte an die Software eines Herstellers binden.

Die Studie, die dem vorliegenden Artikel zugrunde liegt, wurde im Rahmen eines Projektes für das Bundesamt für Sicherheit in der Informationstechnik durchgeführt.