Secure Boot

Achtung dieser Artikel ist noch in Arbeit und dient vorläufig nur als Vorlage. Dieser Beitrag zu Linux oder der Abschnitt ist in Bearbeitung. Weitere Informationen findest du hier. Der Ersteller arbeitet an dem Beitrag oder Abschnitt und entsorgt den Wartungsbaustein spätestens 3 Tage nach der letzten Bearbeitung. Änderungen außer Rechtschreibkorrekturen ohne Absprache mit dem Urspungsautor sind möglichst zu vermeiden, solange dieser Baustein noch innerhalb der genannten Frist aktiviert ist.

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 OS-Loader, als auch UEFI-Treiber und UEFI-Applikationen und 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 ausgeschließ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 Aufü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 ausgeführt werden.

Vorteile von Secure Boot

Die sehr weitreichenden Möglichkeiten von UEFI werden kontrolliert 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 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 allzuoft 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, befinden sich 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 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. Aus diesem Schlüsselpaar wird ein Zertifikat erstellt. Hauptinhalt des Zertifikates ist der öffentliche Schlüssel. 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. UEFI Software wird von den Austellern der Zertifikate (also entweder vom Hersteller oder dem Softwarehersteller) mit dem privaten Schlüssel und dem dazugehörigen Zertifikat signiert. Diese Signatur wird an die Datei angehängt. Dabei wird unter anderem eine Quersumme der Dateidaten mit dem geheimen privatem Schlüssel verschlüsselt. UEFI kann jetzt anhand dieser Signatur feststellen, ob es eine passenden Key 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 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 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 (gegenenfalls 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 authorisiert sind. Hiermit wird erreicht, das diese sich im UEFI befindliche Datenbank nicht durch einen nicht authorisierten Befehl oder Eintrag geändet 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 FW upgedatet werden kann, und bei "wichtigen" Rechnertypen sogar bei jedem anschalten des Rechners überprüft wird. Mit ihm ist die Gesamtheit der Firmware geschützt und braucht desshalb beim Secure Boot Modus nicht überprüft zu werden.

In dieser Struktur werden x509 Zertifikate abgelegt ( in db und dbx auch sha-1 hash möglich)

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 in die anderen Datenbanken Einträge vorgenommen werden. Wird ein solches PK Zertifikat abgelegt, wechselt UEFI in den "User Mode" und schaltet automatisch auch 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.

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. Es muss aber schon im Herstellungsprozess ein Microsoft Zertifikat dort im KEK abgelegt werden. Um Einträge im KEK im "User Mode" vorzunehmen würde man den privaten Key vom PK 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 mit denen im Secure Modus die Treiber, Bootloader und Applikationen 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 muss im Herstellungsprozess schon mindestens 2 Windowszertifikate abgelegt werden. Microsoft Windows Production PCA 2011 (mit diesem Zertifikat werden die Microsoft Bootloader signiert) und [go.microsoft.com/fwlink/?LinkID=321194 Microsoft Corporation UEFI CA 2011] (mit diesem Zertifikat werden Treiber, Applikationen und Bootloader von anderen Herstellern signiert. zB auch 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 hier hin zu bekommen, oder der OEM hier eigene Zertifikate ablegen.
Änderungen und Erweiterungen im "User Modus" müssen 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

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. Allerdings gibt es im Setupmenu einen oder mehrere Menupuntke 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", bei PC-Hardware "an". Secure Mode sollte auf jedem Rechner aber durch einen Menüpunkt im Setup ä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 in der Datenbank mit sich ziehen würde und 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. 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.
Ein 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 löschen und automatisch wieder die orginal Key von der Auslieferung dort installieren.

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 desshalb zusätzliche gegen ein in ihm selbst integriertes Zertifikat und gegen eine eventuell 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 erweitert und bearbeitet werden. Das Tool das diese Funktion erlaubt ist Bestandteil von shim, (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 is 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)