Secure Boot

Secure Boot bei UEFI

Secure Boot ist Bestandteil der UEFI-Spezifikation ab Version 2.3.1. Der Sinn liegt darin, die Echtheit und Unverfälschtheit der Software zu garantieren, welche vom UEFI gestartet werden kann. Dazu gehören sowohl die Boot-Loader, als auch UEFI-Treiber und UEFI-Applikationen sowie UEFI-Erweiterungen in Form von Images. Durch die Mächtigkeit von UEFI ist dieses ein sehr wichtiger Punkt, und soll unter anderem Rootkits und Malware an dieser Stelle auszuschließen, die sich ansonsten schon vor dem Boot des Betriebssystems und für den Nutzer des Rechners vollkommen unbemerkt im System einnisten könnten. Das Prinzip dahinter sind kryptografische Mechanismen (Signaturen), die vor der Ausführung der Software vom UEFI überprüft werden. Hat eine Software keine Signatur, oder ist der Aussteller der Signatur im UEFI nicht bekannt, oder wurde anhand der Signatur festgestellt, die Software ist geändert oder manipuliert, dann darf diese Software im Secure Boot Modus nicht von UEFI in den Speicher geladen und ausgeführt werden.

Vorteile von Secure Boot

Die sehr weitreichenden Möglichkeiten von UEFI werden damit kontrolliert und gezügelt ohne sie generell auszuschließen. Es bietet Schutz vor Software aus ungeprüften Quellen sowie vor Malware und Rootkits, welche sich in diesem sensiblen Umfeld vor dem eigentlichen Boot schon im Rechner einnisten könnten. Es können Pro-Operating-System Software und Bootloader gezielt ausgeschlossen werden und nur überprüfte oder gewünschte Software und Betriebssysteme zugelassen werden. .

Nachteile von Secure Boot

Der Besitzer oder Endkunde hat mit Secure Boot nicht die volle Kontrolle über die Software, die auf seinem Rechner ausgeführt werden kann. Der Plattform Owner (Hersteller) und dominante Softwarehersteller haben auf all seinen Systemen stets einen "Generalschlüssel" mit dem sie verbindlich vorschreiben können, was der Kunde an UEFI Tools, Bootloodern und UEFI-Treibern verwenden kann. Als Alternative bleibt allzu oft nur die Möglichkeit, den Secure Boot Modus auszuschalten und somit den Rechner in einem ungeschützten Modus zu betreiben. Dieses kann sowohl die Wahl des Betriebssystems betreffen, als auch die Möglichkeit des Einsatzes bestimmter zusätzlicher HW-Komponenten einzuschränken. Die Zertifikate, mit denen der Hersteller und Softwarehersteller den Kunden gängeln kann, werden im Normalfall schon bei Produktion im UEFI-Bios abgelegt, und befinden sich damit schon bei der Auslieferung an den Kunden im Rechner.

Secure Boot verstehen

Grundlage

Die Grundlage von Secure Boot ist asymetrische Verschlüsselung. Es wird mit mathematischen Methoden ein Schlüsselpaar erzeugt mit dem man mit dem einen der beiden Schlüssel etwas verschlüsseln kann, welches man nur mit dem anderen Schlüssel wieder entschlüsseln kann. Dabei gibt es aber keinerlei Methode, um von einem der beiden Schlüssel auf den jeweilig anderen zu schließen. Die Schlüssel haben dabei eine solche Größe und damit Sicherheitsstärke, das es selbst mit sehr viel Rechnenleistung nicht möglich ist, den jeweils anderen Schlüssel zu finden. Einer der dieser beiden Schlüssel ist der Private Schlüssel, dieser verbleibt beim Aussteller des Schlüsselpaares und wird geheim und unter Verschluss gehalten und ist meistens zusätzlich mit einem Passwort gesichert.
Der zweite Schlüsse ist public, das bedeutet, jeder der möchte darf diesen Schlüssel besitzen, und dieser Schlüssel wird meistens auch schon mit Hard- oder Software zusammen ausgeliefert, bzw. kann bei Bedarf downgeloadet werden.
Aus diesem Schlüsselpaar wird ein Zertifikat erstellt. Hauptinhalt des Zertifikates ist der öffentliche Schlüssel. Zusätzlich sind im Zertifikat mit dem Privaten Schlüssel dieses oder eines anderen Schlüsselpaares Daten verschlüsselt abgelegt, die zur Überprüfung des Zertifikates herangezogen werden. Der private Schlüssel bleibt geheim und absolut sicher verwahrt beim Ersteller des Zertifikates.

Diese Zertifikate mit dem öffentlichem Schlüssel werden im UEFI Umfeld meistens einfach als Key bezeichnet. Solche Keys werden im UEFI in einer speziellen und geschützten Datenbank aufbewahrt. Die UEFI Software (Treiber, Bootloader usw) wird von den Ausstellern der Zertifikate (also entweder vom Hersteller oder dem Softwarehersteller) mit dem privaten Schlüssel und dem dazugehörigen Zertifikat signiert. Diese Signatur für deren Erstellung zwingend der geheime private Key erforderlich ist, wird an die Datei angehängt und enthält unter anderem eine verschlüsselte Quersumme der Dateidaten mit dem geheimen privatem Schlüssel. UEFI kann jetzt anhand dieser Signatur feststellen, ob es eine passenden Key (also den public Schlüssel) für diese Signatur hat. Wenn ja, wird mit dem im Key befindlichen öffentlichen Schlüssel versucht, die Signatur zu überprüfen. Der öffentliche Schlüssel sollte die Dinge in der Signatur, welche mit dem privaten Schlüssel verschlüsselt wurden, richtig entschlüsseln können und diese Daten (ua. die Quersumme) sollten dann auch mit den eigentlichen Dateidaten übereinstimmen. In diesem Fall ist sichergestellt, die Datei ist nicht manipuliert und ist wirklich von dem Ersteller dieses Zertifikates (und damit Besitzer des geheimen private Schlüssels) genauso signiert worden.
Damit ist sichergestellt, es kann im UEFI im Secure Mode nur etwas ausgeführt werden, das vom jemanden mit dem privaten Schlüssel signiert wurde, und sich das öffentliche Zertifikat (Key) im UEFI in der Datenbank befindet.

Die geschützte und separat (gegebenenfalls sogar auf einem verschlüsseltem Chip) befindliche Datenbank welche UEFI dazu nutzt, schützt sich selbst mit einem ähnlichem Konzept und mit den selben Zertifikaten. Hier können nur Änderungen vorgenommen werden, wenn diese Änderungen vom einem privaten Key eines dafür vorgesehenen Zertifikates autorisiert sind. Hiermit wird erreicht, das diese sich im UEFI befindliche Datenbank nicht durch einen nicht autorisierten Befehl oder Eintrag geändert werden kann, somit sich niemand einen Weg bahnen kann durch einen anderes Zertifikat andere Software freizuschalten.

Aufbau und Funktion der Key-Verwaltung

Die Schlüsselverwaltung besteht aus mehreren Gruppen, welche jeweils unterschiedliche Funktionen erfüllen:

• PK (Platform Key database)
• KEK (Key Exchange Key Database)
• db (Allowed/Authorized Signature Database)
• dbx (Forbidden Database)

sowie einem zusätzlichen für uns und Secure Boot unwichtigen "Secure Boot firmware update key", welcher dafür zuständig ist, dass nur vom Hersteller selbst freigegebene UEFI- und BIOS-FW upgedatet werden kann. Bei "wichtigen" Rechnertypen wird mit diesem Key die Checksumme der Firmware sogar bei jedem anschalten des Rechners überprüft, mindestens würde vor einem Update aber eine neue Firmware daraufhin überprüft, ob sie mit dem privaten Update Key signiert ist. Mit diesem Key ist somit die Gesamtheit der Firmware geschützt und braucht deshalb beim Secure Boot Modus nicht überprüft zu werden.

Die Schlüsselverwaltung kann man sich als eine Art kleiner vor Manipulation und Veränderung geschützte Datenbank vorstellen und dort werden x509 Zertifikate abgelegt ( in db und dbx auch sha-1 hash möglich). Gespeichert werden diese Daten unter anderem in einem meist in einem speziellem und nicht durch HW-Reset veränderbaren Bereich eines verschlüsselten Flashspeichers. Von dort werden sie beim Start in UEFI-Variablen geschrieben.

Platform Key Database

PK ist für die Vertrauens-Basis zwischen dem Plattform-Besitzer und Plattform-Firmware. Hier befindet sich genau ein Zertifikat, Dieses ist vom "Plattform Owner" (Hersteller), es kann immer nur eines dort geben und es ist das Wichtigste überhaupt. Wer den privat Key zu diesem Zertifikat hat, hat die volle Kontrolle über alle anderen in der Datenbank hinterlegten Einträge. Ohne ein solches Zertifikat befindet sich der UEFI im "Setup mode", In diesem Modus können problemlos die anderen Datenbanken Einträge in KEK db oder dbx geändert oder gelöscht werden. Wird ein solches PK Zertifikat installiert, wechselt UEFI sofort in den "User Mode" und schaltet damit auch automatisch Secure Boot aktiv. Um im "User Mode" dann einen Eintrag in PK oder KEK vorzunehmen oder zu ändern, oder zurück in den "Setup Mode" zu kommen, würde man den privaten Key vom PK benötigen um dieses zu autorisieren . Ein solches PK Zertifikat wird schon bei der Herstellung dort installiert, Aussteller und Eigentümer ist der HW-Hersteller

Key Exchange Key Database

KEK bildet die Vertrauens-Basis zwischen dem Betriebssystem und der Plattform-Firmware. Hier können 1 oder auch mehrere Zertifikate abgelegt werden. Mit diesen Zertifikaten ( und den passenden privat Keys dazu) ist es möglich Einträge in die db und dbx vorzunehmen wenn sich der UEFI im "User Mode" befindet und man mit dem Privaten Key die Änderung zertifiziert. Derzeit muss bei jedem PC aber schon im Herstellungsprozess ein Microsoft Zertifikat dort im KEK abgelegt werden. Um später Einträge im KEK im "User Mode" vorzunehmen oder zu ändern, würde man den privaten Key vom PK (also vom Hersteller) benötigen.

Allowed/Authorized Signature Database

db bildet die Vertrauensbasis zu UEFI-Treibern, Bootloadern, Bootimages, Option ROMs und UEFI Applikationen. Hier werden die Zertifikate hinterlegt gegen die sich im Secure Modus die Treiber, Bootloader und Applikationen direkt verifizieren müssen. Sprich, alles was im Secure Modus gestartet werden darf, muss mit einem der Zertifikate signiert sein, (wozu man den priv Key eines dieser Zertifikates benötigen würde)
Theoretisch ist es möglich hier auch einen sha1 Hash eines dieser Objekte abzulegen, was dann diesem speziellem Objekt auch ein laden und starten ermöglichen würde.
In db müssen bei PCs derzeit im Herstellungsprozess schon mindestens 2 Windowszertifikate abgelegt werden. Microsoft Windows Production PCA 2011 (mit diesem Zertifikat werden die Microsoft Bootloader signiert) und Microsoft Corporation UEFI CA 2011 (mit diesem Zertifikat werden Treiber, Applikationen und Bootloader von anderen Herstellern signiert. zB auch von shim ) Weiterhin ist es möglich das sich dort weitere Zertifikate befinden, zB könnte sich auch eine Linuxdistribution bemühen hier schon Herstellerseitig einen Key in die db zu bekommen, oder der OEM (Hersteller) hat hier weitere eigene Zertifikate ablegt, zB. für optionale UEFI-Hardwareapplikationen des Hardwareherstellers
Änderungen und Erweiterungen im "User Modus" müssten entweder mit dem PK oder KEK Zertifikat und dem dazugehörigen priv Key autorisiert werden.

Forbidden Database

dbx ist das Gegenteil von db also eine Blacklist. Dort könnten auch Keys hinterlegt werden, (macht aber wohl weniger Sinn), hier werden wenn überhaupt wohl ehr irgendwann mal sha Hash von Binären Opjekten abgelegt. Objekte die einen sha Hash in der dbx haben, dürften nicht zum starten von UEFI im Secure Boot akzeptiert werden, selbst wenn sie mit einem in der db eingetragenen Zertifikat signiert sind. Hiermit ist es also möglich einzelne schon signierte Objekte wieder zu sperren.

unterschiedliche Modi

Bereits im Herstellungsprozess werden also schon Keys im UEFI abgelegt, die Privaten Schlüssel dazu liegen beim Hersteller und Microsoft, nur diese wären damit im Stande bei Updates oder Firmwareupdates mit ihren privaten Schlüsseln Änderungen an der UEFI Keydatenbank vorzunehmen. Diese stimmt aber nur zum Teil, denn es gibt Ausnahmen die der User im Setupmenu des UEFI aktivieren kann.

UEFI unterscheidet unterschiedliche Modi. Ein Umschalten zwischen den einzelnen Modi ist auf Betriebssystem- oder UEFI-Ebene nur mit Authorisierung mittels des privaten Key des PK möglich (im Normalfall also Microsoft und dem HW-Hersteller vorbehalten). Für den Enduser gibt es im Setupmenu einen oder mehrere Menupunkte mit denen der User das eine oder andere an/aus/um schalten kann.

"User Mode" und "Setup Mode"

Im Normalfall wird das System immer im "User Mode" betrieben. Bedeutet, es ist ein PK key installiert, welcher nur mit Hilfe des privatem Key des PK zu löschen oder zu ändern ist. Auslieferung ist immer im "User Mode"

Secure Boot "an" oder "aus"

Der Status des Secure Boot ändert sich automatisch mit dem Wechsel von Setup und Usermod, und kann ansonsten nur mit Hilfe des privaten Key des PK geändert werden. Auslieferung bei Serverhardware ist Secure Boot "aus", und bei PC-Hardware Secure Boot "an". SecureBoot Mode sollte auf jedem Rechner aber durch einen Menüpunkt im Setup manuell änderbar sein. Die Hersteller nutzen hier aber durchaus wenig aussagekräftige Beschreibungen dazu. zB "Windows Betriebssystem" für Secure Boot "an" und "Anderes Betriebssystem" für Secure Boot "aus".

"Custom Mode" oder "Standard Mode"

Default und Auslieferung ist "Standard Mode". Auf vielen(allen?) UEFI Rechnern sollte es aber möglich sein den PK aus dem Setupmenu heraus entweder zu löschen oder zu ersetzen, bzw. irgendwo im Setup zwischen Standard- und Custom Mode zu wecheln was einem löschen aller Einträge (bzw mindestens ein löschen des aktuellen PK ) in der Datenbank mit sich ziehen würde und damit ein Umschalten in den "Setup Mode" bedeutet. Hiermit wird dem User ermöglicht die volle Kontrolle über die Datenbankeinträge und der darin enthaltenen Keys selbst zu übernehmen, unabhängig von den immer schon vorinstallierten Keys des Herstellers und von Microsoft. Der User kann in diesem Modus zB alle Microsoft Keys entfernen und seine eigenen Keys installieren und anschließend einen eigenen PK installieren und damit SecureBooot wieder aktivieren. Ist im PK ein KEY des Users oder einer anderen Institution, also nicht der orginal PK Key, dann befindet sich das System im "Custom Mode". Dieses ist nicht für alle UEFI Plattformen vorgesehen, für x64 aber schon.

Umschalten Standard Mode / Custom Mode

Beim Umschalten aus dem Setupmenü zurück auf "Standard Mode", oder ein Reset über Jumper des Systemboards oder zurücksetzten auf Default Werte des UEFI, würde alle sich in der Datenbank befindenlichen User Keys jedoch wieder löschen und automatisch wieder die orginal Key von der Auslieferung die sich immer noch im verschlüsseltem Flash befinden installieren. Damit würde der Rechner wieder zurück in den Auslieferungszustand versetzt.

Der Menüpunkt für das Umschalten von Standard Mode in Custom Mode ist oftmals versteckt oder nicht sofort als solches erkennbar. Eventuell sind auch vorher andere Bootoptionen im UEFI-Setup zu setzen und den Rechner anschließend noch einmal zu rebooten, bevor dieser Menüpunkt sichtbar wird. Microsoft hat für PC-Hardware in den für Windows 10 HW-Zertifizierungs Richtlinien diesen Menüpunkt für x86 jedenfalls vorgegeben, er sollte sich also auf entsprechender neuer Hardware auch finden lassen.

MOK-List eine Erweiterung der Funktion

Die MOK-LIST (Machine Owner Key-List) ist eine private Erweiterungsliste der UEFI Secure Boot Datenbank speziell für Keys des shim-Bootloader unter Linux. Der Pre-Bootloader shim wird offiziell mit einem in der db vorhandenen Zertifikat signiert zur Verfügung gestellt. Seine Aufgabe ist es einen Bootloader zu laden, welcher wiederum den Kernel des Linuxbetriebssystems laden soll.
Die Signaturen des von shim zu ladenen Bootloader und die der Kernel stammen dabei nicht von Zertifkaten die in der Secure Datenbank des UEFI enthalten sind. Bootloader und Kernel werden mit den offiziellen Keys des Buildsystems der Distribution signiert.
Shim prüft die von ihm zu ladenden Binaries deshalb zusätzliche gegen ein in ihm selbst integriertes Zertifikat und gegen eine eventuell optionale vorhandene Key-liste. Diese Keyliste ist die MOK-List.
Diese MOK-List besteht ebenfalls wie die Secure Boot Datenbank aus Keys und Hashes, kann aber anders als die UEFI-Datenbank vom Lokalem User am Rechner selbst erweitert und bearbeitet werden. Das Tool das diese Funktion erlaubt ist Bestandteil von shim, und wird per default auch mit shim zuammen schon installiert(siehe MOK-Liste)

Verwaltung und Administation der Keys

Als normaler Linux Benutzer braucht man sich darum nicht zu kümmern, und man kann es im Normalfall auch gar nicht, da dazu die privaten Keys benötigt werden die beim Hersteller und den Softwareherstellern unter Verschluss liegen.

KeyTool.efi

Hier ein paar Beispiele wo sich solche Administrativen Ziele ergeben könnten:

Personenkreis	mögliches Ziel der Administration
Entwickler Paketbauer	UEFI-Binaries offiziell signieren lassen, oder mit eigenem Zertifikat signieren ;-)
Professionelle Administration sicherheitsrelevanter Rechner	den Rechner im "Custom Mode" betreiben und damit alle Keys im UEFI selbst kontrollieren und verantworten z.B.
Erweiterte Linux Administration	die MOK-Liste erweitern um zB. Distributionsfremde oder eigene Kernel zu booten

Mit ein wenig Hintergrundwissen den richtigen Howtos und bestehenden Tools ist es möglich sowohl vom UEFI als auch aus Linux den Zertifkatspeicher von UEFI zu administrieren. Dieses soll aber nicht Bestandteil dieses Artikel sein.

Links

• Managing EFI Boot Loaders for Linux: Dealing with Secure Boot (Rod Smith)
• Owning your Windows 8 UEFI Platform (James Bottomley)