© psdesign1, Fotolia

Secure Boot erwartet einen digital unterschriebenen Kernel. Eigene Module und Treiber von Drittanbietern lassen sich allerdings nur mit Nachhilfe laden. Außerdem hat Microsoft die Finger im Spiel.

In der UEFI-Firmware aktiviertes Secure Boot soll sicherstellen, dass auf einem Rechner nur signierte, also mit einer gültigen digitalen Unterschrift versehene Software startet. Dazu sucht UEFI auf der SSD oder Festplatte nach einem Bootloader, überprüft die digitale Unterschrift anhand einer im UEFI hinterlegten Unterschriftenprobe (Zertifikat) und – falls die digitale Signatur gültig ist – lädt und aktiviert den Code.

Der Bootloader seinerseits sucht nach dem zu ladenden Betriebssystem, verifiziert ebenso die digitale Unterschrift und startet im Erfolgsfall das Betriebssystem. Linux wiederum lädt nur Kernelmodule und Treiber, die eine gültige digitale Signatur tragen.

Die Idee: Wenn alle beteiligten Komponenten nur noch Code aus vertrauenswürdigen Quellen laden, tun sich die Malware-Schreiber in den üblen Ecken des Internets erheblich schwerer, ihre Software in den Bootprozess einzuschleusen.

Die Gemeinschaft der UEFI-unterstützenden PC-Hersteller ist der Meinung: Ja, dem US-Konzern Microsoft können wir vertrauen! Die Würdigung von Microsofts Marktmacht mag hierbei auch eine Rolle gespielt haben.

Fakt ist, dass jeder Hardwarehersteller sein eigenes Zertifikat als so genannten Platfrom Key (PK) einbrennt und dann die Microsoft-Unterschriftenprobe fest auf dem Motherboard in der so genannten Key Exchange Keys Database (KEK) und in der Authorized Signature Database (DB) hinterlegt (Abbildung 1). x.86-PCs und -Notebooks starten deshalb zunächst nur Software mit einer Unterschrift von Microsofts Gnaden.

Abbildung 1: Der verwendete Zertifikatsspeicher in einem Secure-Boot-geschützten Rechner.

Von Microsofts Gnaden

Der Linux-Kernel braucht also eine digitale Unterschrift von Microsoft – das geht vielen Linuxern zu weit. Einer von ihnen, Matthew Garrett von Red Hat (siehe den folgenden Artikel), hat mit dem Bootloader Shim eine Open-Source-Alternative zum Microsoft-Bootloader programmiert, der eigene Unterschriftenproben integriert. Ubuntu, Red Hat, Suse oder Debian generieren ihre Versionen von Shim, die ein Firmenzertifikat enthalten.

Verisign-Symantec signiert diese Version im Auftrag von Microsoft digital, damit die UEFI-Firmware Shim lädt. Shim seinerseits greift sich alles, was mit der integrierten Unterschrift – also dem Linux-Firmen-Zertifikat – digital unterschrieben ist. Extrem wichtig um unabhängig von Microsoft & Co. zu werden: Shim hat ein Zertifikatsmanagement eingebaut, in das der Besitzer des Rechners weitere Unterschriftenproben ablegen darf (Machine Owners Keys, MOK).

Die zurückgewonnene Autonomie

Mit Shim gewinnen zumindest die großen Distributoren wie Ubuntu, Suse oder Red Hat weitgehend die Kontrolle über die Hardware zurück. Mit dem in Shim hinterlegten Canonical-Zertifikat unterschreibt die Shuttleworth-Firma den Bootloader Grub 2 und schließlich auch den Linux-Kernel und seine Module. Die Firmware bootet also Shim, Shim bootet Grub 2 und Grub 2 Linux oder – auf einem Dualboot-System – auch Windows (Abbildung 2).

Tatsächlich merkt der Anwender das sicherere Booten zunächst gar nicht. Installiert er auf einem Rechner mit aktiviertem Secure Boot beispielsweise Ubuntu, platziert die Installationsroutine die unterschriebenen Bootloader Shim und Grub 2 auf die SSD beziehungsweise Festplatte und installiert den digital unterschriebenen Kernel samt verifizierbarer Module und Treiber. Ist Secure Boot dagegen nicht aktiviert, kopiert der Betriebssystem-Installer die Pendants ohne digitale Unterschrift auf den PC.

Abbildung 2: Der abgesicherte Bootvorgang durchläuft eine Reihe von Stationen.

Ausschalten hilft weiter

Wer auf einem Secure-Boot-Linux-Rechner aber Virtualbox installieren will, hat die Rechnung ohne den Wirtsrechner gemacht. Der weigert sich das zugehörige Kernelmodul zu laden, da es keine gültige digitale Unterschrift trägt. Das wiederholt sich so bei allen Drittanbieter-Paketen, die eigene Module oder Treiber mitbringen. Physischer Zugang zum Rechner vorausgesetzt, kann der Anwender auf recht plumpe Weise mit Shim die Überprüfung digitaler Unterschriften durch den Linux-Kernel deaktivieren. Dazu tippt er auf der Konsole:

sudo mokutil --disable-validation

Das Werkzeug »mokutil« verlangt dann ein Einmalpasswort einzugeben. Daraufhin deaktiviert Mokutil nicht selbst die Überprüfung, sondern stellt den Bootloader Shim so ein, dass er mit dem nächsten Reboot das Passwort abfragt und nach dessen korrekter Eingabe die gewünschte Konfiguration vornimmt.

Achtung: Es ist sinnvoll, für das Einmalpasswort auf deutsche Umlaute und Sonderzeichen zu verzichten. Denn nach einem Reboot erwartet der Bootloader Shim die Eingabe dieses Passworts innerhalb eines kurzen Zeitfensters. Dabei ist die Tastatur fest amerikanisch eingestellt ([Z] und [Y] vertauscht).

Der Anwender wählt in der Auswahlbox »Change secure boot state« aus (Abbildung 3). Nach Eingabe des zuvor vergebenen Einmalpassworts ist die Zwangsüberprüfung der digitalen Unterschriften deaktiviert. Allerdings geht damit auch der durch Secure Boot angebotene Schutz verloren – man kann auch direkt im UEFI-Setup Secure Boot ausschalten.

Abbildung 3: Quick and unsecure: In Shim lässt sich das Validieren von Unterschriften deaktivieren.

Ein eigenes Zertifikat herstellen

Die bessere Alternative besteht darin, eigene Zertifikate im Kernel zu hinterlegen und die Module selbst zu signieren. In [1] ist das klassische Vorgehen beschrieben. Mit Secure Boot funktioniert die Anleitung aber nicht, denn um einen Schlüssel dem Zertifikatsspeicher des Kernels hinzuzufügen, muss der neue Schlüssel die Unterschrift eines Schlüssels tragen, dessen Unterschriftenprobe sich bereits im Zertifikatsspeicher befindet.

Dass hier aber nur das Zertifikat des Distributors, Canonical, abgelegt ist, dessen privaten Teil (hoffentlich) niemand sonst besitzt, macht Modifikationen am Kernel-Zertifikatsspeicher unmöglich. Um das Problem zu lösen, müsste der Anwender den Kernel selbst generieren und das dazu verwendete Zertifikat im Bootloader Shim als MOK (Machine Owners Key) hinterlegen. Glücklicherweise geht es auch, ohne den Kernel neu zu übersetzen. Der Betriebssystemkern beachtet nämlich beim Signaturcheck auch die Zertifikatsverwaltung MOK des Bootloaders Shim.

Abbildung 4 zeigt das Vorgehen. Zuerst ist das neue Schlüsselpaar zu generieren. Der private Schlüssel signiert zweitens die eigenen Module beziehungsweise die Module von Drittanbietern. Den privaten Schlüssel sichert der dritte Schritt vor Fremdzugriffen, und – viertens – bekommt Shim den öffentlichen Schlüssel als Machines Owner Key übergeben. Beim nachfolgenden Reboot ploppt das Zertifikatsmanagement von Shim auf, bei dem das Zertifikat zu überprüfen und zu importieren ist. Nach dem nächsten Hochfahren kann Linux die signierten Module bereits verwenden.

Das Generieren des benötigten Schlüsselpaars auf der Konsole gelingt mit dem länglichen Kommando:

openssl req -new -x509 \
    -newkey rsa:2048 \
    -keyout ownerkey.priv \
    -outform DER \
    -out ownerkey.der \
    -nodes -days 36500 \
    -subj "/CN=Machine Owner Key of My Company/"

Nun liegen im aktuellen Verzeichnis der private Schlüssel (»ownerkey.priv«) und das Zertifikat mit dem öffentlichen Schlüssel, also die eigentliche Unterschriftenprobe (»ownerkey.der«).

Der private Schlüssel ist gut zu sichern, denn wer ihn lesen darf, kann damit digital unterschreiben! Im Sinne der Sicherheit richtig ist es, den privaten Schlüssel auf einen externen Datenträger, etwa einen USB-Stick, zu verschieben. Zu empfehlen ist es zudem, den USB-Stick beispielsweise mit Hilfe von Veracrypt [2] zu verschlüsseln.

Abbildung 4: Während der Admin physischem Zugriff auf den Rechner hat, kann er dort eigene Zertifikate einbinden. Die einzelnen, nicht besonders intuitiven Schritte in Richtung dieses Ziels sind hier zusammengefasst.

Von Schlüsseln, Passwörtern und Zertifikaten

Eigentlich ist die Unterscheidung gar nicht so schwer, dennoch benutzen selbst Fachleute die Begriffe Schlüssel, Passwort und Zertifikat manchmal falsch. Ein Schlüssel ist eine Bytefolge zum Verschlüsseln von Daten. Verschlüsselt der eingesetzte Algorithmus die Daten blockweise, hat der Schlüssel auch die Länge eines Blocks. Bei einer zeichenweisen Verschlüsselung ist der ideale Schlüssel so lang wie die zu kryptende Zeichenfolge selbst, ansonsten wird der Schlüssel wiederholt eingesetzt.

Passwort oder Schlüssel

Das Passwort bezeichnet eine Zeichenfolge, die einen Schlüssel ergibt. Wer beispielsweise einen unendlich langen Schlüssel mit Hilfe eines Pseudo-Zufallszahlengenerators erzeugt, kann als Passwort den Initialisierungswert des Zufallszahlengenerators benutzen. Bei einer 1:1-Abbildung ist dagegen das Passwort mit dem Schlüssel identisch.

Bei der symmetrischen Verschlüsselung dient ein einzelner Schlüssel sowohl zum Ver- als auch zum Entschlüsseln. Beides ist sehr performant und die Verfahren erreichen eine sehr hohe Sicherheitsstufe. Doch ist der Schlüssel ein Shared Secret, also ein Geheimnis, das allen Ver- und Entschlüsslern bekannt ist. Oft ist es zudem nötig, den Schlüssel zum Empfänger zu transportieren, was die Gefahr birgt, dass ein Dritter den Schlüssel mitliest.

Bei asymmetrischen Verfahren kommt ein mathematisch zusammenhängendes Schlüsselpaar zum Einsatz. Der private Schlüssel dient zum Entschlüsseln und für die digitale Unterschrift. Den öffentlichen Schlüssel benötigen Dritte zum Verschlüsseln und zum Überprüfen der digitalen Unterschrift.

Asymmetrisch lassen sich also Daten nicht nur digital signieren, sondern auch gezielt für einzelne Empfänger verschlüsseln. Der öffentliche Schlüssel trägt seinen Namen zurecht, er muss nicht unter Verschluss bleiben und lässt sich gefahrlos transportieren.

Schlüssel mit Anhänger

Allerdings ist es – etwa beim Überprüfen einer digitalen Unterschrift – schwierig, den Public Key der Person oder Firma zuzuordnen, die den zugehörigen privaten Schlüssel einsetzt. Daher packt man zum öffentlichen Schlüssel noch Informationen zum Inhaber hinzu und unterschreibt das ganze digital, damit es fälschungssicher wird. Diese digital unterschriebene Kombination aus Meta-Infos (Name, Firma, Adresse) plus öffentlicher Schlüssel nennt man Zertifikat (Abbildung 5).

Egal ob der öffentliche Schlüssel allein oder als Zertifikat daherkommt, der Besitzer des zugehörigen privaten Schlüssels sollte diesen aufgrund seiner Bedeutung besonders schützen. Gängig ist es, ihn symmetrisch zu verschlüsseln und per Passwort zu sichern.

Abbildung 5: Ein Zertifikat besteht aus einem Public Key, Meta-Informationen über den Besitzer des privaten Key und einer digitalen Unterschrift.

Module selbst signieren

Vorher allerdings ist es erforderlich, die unsignierten Module digital zu unterschreiben. Dazu dient das Kommando »sign-file« des Kernel-Build-Systems. Das Kommando befindet sich in den Kernelquellen und lässt sich folgendermaßen aufrufen:

sudo /lib/modules/$(uname -r)/build/scripts/sign-file sha256 ./ownerkey.priv ./ownerkey.der Name_des_Moduls

Mit dem Skript aus Listing 1 gelingt es, alle Module von Virtualbox zu unterschreiben. Das Teilkommando »$(modinfo -n vboxdrv)« in Zeile 7 liefert den Pfad zu dem Virtualbox-Modul, etwa zu »vboxdrv.ko« zurück. Alternativ beziehungsweise wer ein eigenes Kernelmodul signieren will, gibt hier direkt den Pfad inklusive Dateiname des Moduls an.

01 #!/bin/bash
02
03 for drivername in vboxdrv vboxnetflt vboxnetadp vboxpci
04 do
05   sudo /lib/modules/$(uname -r)/build/scripts/sign-file \
06     sha256 ./ownerkey.priv ./ownerkey.der \
07     $(modinfo -n $drivername)
08 done

Die Unterschriftenprobe, die der Admin nicht vor fremdem Zugriff schützen muss, übergibt das simple Kommando

sudo mokutil --import ownerkey.der

an Shims Zertifikatsverwaltung. Wie gehabt muss der Systemverantwortliche ein dabei eingefordertes Einmalpasswort nach einem Reboot innerhalb eines kurzen Zeitfensters zur Aktivierung der Zertifikatsverwaltung eingeben.

Um das jüngst erstellte Zertifikat tatsächlich zu aktivieren, wählt er in Shim »Enroll MOK« aus (Abbildung 6). »View Key« prüft den Schlüssel (Abbildungen 7 und 8). Die beiden Schritte nach dem Menüpunkt »Continue« aktivieren ihn schließlich (Abbildungen 9 bis 11).

Abbildung 6: Shim eröffnet die Möglichkeit, ein selbst erzeugtes Zertifikat zu aktivieren.

Abbildung 7: An Ort und Stelle darf sich der Aussteller des digitalen Zertifikats …

Abbildung 8: … Gewissheit verschaffen, dass es wirklich seines ist.

Abbildung 9: Das Aktivieren des Zertifikats fürs Bootsystem beginnt per »Continue«, …

Abbildung 10: … erstreckt sich über eine funktional eher überflüssige Sicherheitsbestätigung …

Abbildung 11: … und endet mit der Eingabe des zuvor vereinbarten Einmalpassworts.

Wieder unter Linux angekommen gibt

mokutil --list-enrolled

eine Liste der registrierten Zertifikate aus, in ihr taucht das selbst erzeugte auf. Das Kommando zum Laden des Virtualbox-Kernelmoduls

sudo modprobe vboxdrv

läuft jetzt erfolgreich ab. Aber Achtung: Bei jedem Update des Kernels muss der Admin die Module neu digital unterschreiben. Dazu benötigt er wieder Zugriff auf den (hoffentlich gut gesicherten) privaten Schlüssel. Übrigens triggert

sudo mokutil --delete ownerkey.der

die Zertifikatsverwaltung von Shim an, beim nächsten Reboot ein Zertifikat aus der Zertifikatsverwaltung zu entfernen – wie immer unter dem Schutz eines Einmalpassworts. Der Menüpunkt in Shim lautet »Delete MOK«.

Sicherer ist nicht sicher

Den UEFI-Bootloader Shim installieren und – bei allem Aufwand – den Kernel und seine Module signieren, das macht den Rechner zweifellos sicherer. Denn Skript-Kiddies und Hacker tun sich so schwerer, bösartige Software auf dem Rechner zu installieren und zu starten. Grund für Euphorie gibt es jedoch nicht beim Blick auf und in die diversen Zertifikatsspeicher im Rechner: Der Hersteller des Rechners, Microsoft, Verisign, Symantec und Canonical haben jetzt Dependancen auf der “sicheren” Arbeitsmaschine (Tabelle 1).

Es wäre blauäugig, zu glauben, dass in allen Firmen alle Mitarbeiter immun sind gegen das Angebot, für einen beeindruckenden Bitcoin-Betrag eine kleine Gefälligkeit zu erledigen. Zum anderen könnten die Folgen eines stets mit Geheimhaltungsklauseln versehenen und strafbewährten National Security Letter von beispielsweise dem FBI die Firmen zu Zugeständnissen beim Datenschutz zwingen. Summa summarum: Es gibt nur eine sichere Public Key Infrastruktur (PKI), und das ist diejenige, die man selbst betreibt.

Wer also im UEFI seine eigenen Schlüssel hinterlegt, die vorhandenen Schlüssel blacklistet, seinen eigenen Bootloader kompiliert und signiert, den Kernel selbst kompiliert und eigenhändig signiert und dann das Gleiche mit Modulen und Treibern macht – der kann seinem System deutlich mehr trauen. Wer noch höhere Anforderungen an die Integrität des Systems hat und/oder paranoid ist, macht sich jetzt an die Sicherung der einzelnen Anwendungen.