Secure Boot mit Linux

Um Secure Boot auch mit anderen Betriebssystemen nutzen zu können, stehen grundsätzlich drei Möglichkeiten zur Verfügung:

• Signieren der eigenen Bootloader durch Microsoft.
• Hinterlegen eines eigenen KEK-Schlüssels durch den Hardware-Hersteller. Offenbar verfügt jedoch kein weiterer Betriebssystemanbieter über die entsprechende politische Marktmacht, um die Hardware-Hersteller flächendeckend von der Installation weiterer KEK-Schlüssel überzeugen zu können.
• Erzeugen eines eigenen Platform Key (PK) und Hinterlegen in der UEFI-Firmware. Durch den Austausch des Platform Keys wird ein Zugriff auf alle weiteren Zertifikatsspeicher möglich. Das Ersetzen eines Platform Keys bedingt jedoch physischen Zugang zum System.

Alle von uns untersuchten Betriebssysteme, die Secure Boot unterstützen, schlagen den ersten Weg ein. Damit ist die Installation ihrer Bootloader auf einem System mit aktivem Secure Boot und installierten Microsoft-Schlüssel-material möglich. Hierzu bietet Microsoft einen Signaturdienst an, der ursprünglich nur für die Signatur von UEFI-Treibern vorgesehen war. Er wurde auch auf alternative Bootloader von Drittanbietern erweitert. Dazu sendet der Drittanbieter seinen Bootloader an Microsoft. Die Firma prüft den Bootloader und sendet ihn mit einer AuthentiCode-Signatur zurück. Die Signatur bestätigt nicht den Urheber, sondern lediglich die Unversehrtheit des Bootloaders.

Die Signatur erfolgt mit dem Zertifikat Microsoft Corporation UEFI CA 2011. Daher ist die Funktionsfähigkeit des Bootloaders nicht auf jeder Hardware garantiert, denn dieses Zertifikat muss nach Microsoft-Spezifikation nicht installiert sein.

Durch das Signieren des Bootloaders durch Microsoft bestehen grundsätzlich zwei Gefahren bei dem Einsatz in der Produktion:

• Microsoft kann das Zertifikat widerrufen. Würde das Zertifikat durch Software-Updates in die Revocation-Lists in der UEFI-Firmware gelangen, erlaubt die Firmware die Nutzung des entsprechenden Bootloaders nicht mehr.
• Die Signatur ist nur für eine bestimmte Zeit gültig. Die UEFI-Firmware kann den signierten Bootloader nach Ablauf der Signatur ablehnen und den Bootvorgang abbrechen. Wird nicht erneut signiert, kann das System nicht mehr booten.

Shim

Beim abgesicherten Booten mithilfe des Signierdienstes von Microsoft wird typischerweise der Bootloader Shim eingesetzt. Bei Shim handelt es sich um einen einfach strukturierten Open-Source-Bootloader. Er startet indirekt Bootloader, die nicht von Microsoft signiert sind. Shim kann somit als Bindeglied zwischen der von Microsoft geprägten Secure-Boot-Umgebung und Betriebssystemen Dritter eingesetzt werden ( Abbildung 3 ).

Abbildung 3: So läuft das Booten ab, wenn der Open-Source-Bootloader Shim im Spiel ist.

Ermöglicht wird dies unter anderem durch eine öffentlich zugängliche Shim-Version, die von Microsoft mittels des Zertifikats Microsoft Corporation UEFI CA 2011 signiert ist. Aufgrund dieser Signatur kann Shim von allen untersuchten Hardwareplattformen mittels des jeweiligen Standardschlüsselmaterials mit aktivierten Secure Boot gestartet werden. Ferner installieren einige Linux-Systeme wie etwa Ubuntu 13.04 und Fedora 19 alternative Versionen von Shim, die ebenfalls von Microsoft signiert sind.

Shim überprüft die Signatur des nächsten Bootloaders, der zu laden ist. Das Schlüsselmaterial für diese Verifizierung kann hierbei aus drei Quellen stammen:

• Den UEFI-Zertifikatsspeichern db und dbx,
• der Machine Owner Key List (MokList): einem Shim-eigenen Zertifikatsspeicher,
• einem im Shim-Binary hinterlegten Zertifikat oder Hash.

Die MokList kann sowohl Zertifikate als auch Hashes speichern. Die Nutzung von Zertifikaten bedingt die Signierung des zweiten Bootloaders. Die MokList wird zwar ebenso wie die UEFI-spezifischen Zertifikatsspeicher im NVRAM der UEFI-Firmware gespeichert, sie ist jedoch zumindest während des Bootvorgangs typischerweise ohne Authentifizierung modifizierbar.

Weil sich Zertifikate direkt in der Binärdatei von Shim hinterlegen lassen, kann der Verifizierungsvorgang unabhängig vom Inhalt der Zertifikatsspeicher sein. Diesen Weg wählen die Linux-Distributionen Ubuntu 13.04 und Fedora 19.

Ist die Verifizierung des zweiten Bootloaders – typischerweise Grub2 – erfolgreich, so wird er ausgeführt. Schlägt sie dagegen fehl, so wird die zu Shim gehörende Anwendung MokManager aufgerufen. Der MokManager ermöglicht es dem Anwender, interaktiv Zertifikate oder Hashes in die MokList einzufügen und somit die Ausführung des zweiten Bootloaders zu erlauben.