UEFI Secure Boot

Aus Thomas-Krenn-Wiki
Zur Navigation springen Zur Suche springen

Secure Boot ist ein Teil der UEFI-Spezifikation, der die Echtheit bzw. Unverfälschtheit von wichtigen Software-Teilen der Firmware garantieren soll. Kritische Teile der Firmware, wie der OS-Loader, sollen nur mehr dann ausgeführt werden, wenn sie zuvor durch eine vertrauenswürdige Institution dazu autorisiert wurden. Dadurch werden unter anderem Rootkits ausgeschlossen, die sich schon vor dem Boot des Betriebssystems (OS) einnisten.

Durch kryptografische Mechanismen (Signaturen) wird verhindert, dass nicht vertrauenswürdige Software-Teile ausgeführt werden.

Die Schlüssel in der UEFI-Firmware prüfen die Authentizität von z.B. Bootloadern. Ein Bootloader wird nur dann ausgeführt, wenn er eine gültige "Unterschrift" vorweist.[1] Kann eine Unterschrift nicht überprüft werden bzw. ist sie nicht gültig wird das System am Starten gehindert. Entspricht z.B. die Unterschrift des Bootloaders nicht der, die die UEFI-Firmware erwartet, startet das System nicht.

Aktuelle Informationen

Vorteile von Secure Boot

Folgende Vorteile ergeben sich beim Einsatz von Secure Boot:

  • Schutz vor Malware: Vor allem Rootkits, die sich in kritische Betriebssystem-Teile vor dem eigentlichen Boot einhängen, werden durch Secure Boot aufgedeckt.
  • Durch das Signatur-System kann Software gezielt ausgeschlossen werden und nur gewünschte Software zum Einsatz kommen.

Nachteile von Secure Boot

  • Vor allem, dass sich der Platform Key (PK, siehe weiter unten) nicht unter der Kontrolle des Endkunden befindet, entpuppt sich als Nachteil.
  • Für Secure Boot müssen alle Software-Teile entsprechend signiert werden. Auch zugehörige Hardware-Treiber für die Firmware. Für den nachträglichen Einbau von Hardware in Systemen muss sicher gestellt sein, dass sich der Key des Hardware-Herstellers des neuen Bauteils auf dem System befindet.[1]

Wahl des Betriebssystems:

  • Alternative Betriebssysteme bzw. Dual-Boot-Konfigurationen werden durch Secure Boot erschwert. Die Tatsache, dass Linux-Installationen nur mehr nach einer manuellen Deaktivierung von Secure Boot in der UEFI-Firmware vorgenommen werden können, ergeben ein weiteres Hindernis beim Einsatz von Linux.
  • Beim Dual-Boot müsste sogar ständig zwischen Secure und Nicht-Secure Boot gewechselt werden, um signierte und nicht signierte Betriebssysteme zu starten.

Empfehlungen von Canonical

In einem Whitepaper von Canonical (blog.canonical.com) werden folgenden Empfehlungen zu Secure Boot abgegeben:

  • Factory Default: Zur Zeit steht noch nicht fest, ob Linux out of the box verwendet werden kann. Mit standardmäßig deaktiviertem Secure Boot wäre es einfacher Linux zu verwenden, in puncto Sicherheit ist diese Einstellung umstritten, da nicht signierte OS-Loader ausgeführt werden können.
  • Für den Einsatz von Custom Firmwares müsste es eine Möglichkeit geben, im Setup Modus die Schlüssel rekonfigurieren zu können. Eine GUI bzw. ein User-Interface für diese Konfiguration wäre nötig, aufgrund des eingeschränkte Nutzer-Bereichs ist es fraglich, ob Firmware-Hersteller dieses Feature anbieten werden.
  • Das UEFI-System sollte im Setup Mode ausgeliefert werden (siehe weiter unten), wodurch die ersten Signatur-Keys während der Installation des OS in die Signatur-Datenbanken eingetragen werden können. Dadurch wird verhindert, das entgegen dem Willen des Users, sich bereits bei der Auslieferung Keys auf dem System befinden, die andere System ausschließen würden.

Secure Boot und Windows 8/Server2012

Die Windows 8 Certification Requirements[2] - für die Zertifizierung von Hardware - schreiben für Secure Boot folgende wichtige Dinge vor (Seite 188ff, hier auszugsweise):

  • Mandatory. Secure Boot must ship enabled - Secure Boot per default aktiviert.
    • Note II: Windows Server systems may ship with Secure Boot disabled, but all other provisions of this sub-requirement must be met - Für Windows Server ist ein deaktiviertes Secure Boot erlaubt.
  • Mandatory. When Secure Boot is Enabled, Compatibility Support Modules (CSM) must NOT be loaded - Mit aktiviertem Secure Boot ist es nicht mehr möglich im Legacy Modus (CSM) zu booten.
  • Mandatory. Support for the UEFI "forbidden" signature database - Eine Datenbank zum Widerrufen/Black-Listen von Signaturen muss unterstützt werden.
  • Mandatory. Secure firmware update process - Ein sicherer Firmware-Update-Prozess, sodass nur signierte Firmwares installiert werden. Auch der Secure Boot Public Key wird dadurch geschützt.

Secure Boot und Linux

Die oben genannten Anforderungen für Windows 8 sowie Windows Server 2012 zertifizierte Hardware haben große Auswirkungen auf die Verwendung von gängigen Distributionen mit Secure Boot.

Wie aktuell auf die Installation unter Secure Boot eingegangen wird, findet sich im Wiki-Artikel OS-Installation auf UEFI-Systemen#Secure_Boot_und_Linux.

Zu Beginn der Secure Boot Problematik reagierten die Distributions-Hersteller auf folgende Art und Weise:

Technische Funktionsweise

Vorhandene Schlüssel

Secure Boot setzt stark auf die Verwendung von asymmetrischer Kryptographie. Die Basis des Vertrauens - Root of Trust - wird dem Besitzer eines sogenannten Platform Keys (PK) zugesprochen. Ein weiterer Satz von Schlüsseln - Key Exchange Keys (KEKs) - befindet sich auch noch in der Firmware.

Laut Spezifikation ist der Zweck von PK und KEK:[3]

  • Die PKs stellen eine Vertrauens-Basis zwischen dem Plattform-Besitzer und der Plattform-Firmware her.
  • Die KEKs stellen eine Vertrauens-Basis zwischen dem Betriebssystem und der Plattform-Firmware her.

Die Schlüssel befinden sich in sogenannten "Signature Databases", also Datenbanken in denen sie abgelegt werden. Es kommen folgende "Vertrauens-Datenbanken" zum Einsatz:[4]

  • Platform Key Database
    • Objekte zur Modifizierung der KEKs.
  • Key Exchange Key Database
    • Beinhaltet jene Trust-Objekte, welche die Allowed und Forbidden Signature Database modifizieren dürfen.
  • Allowed/Authorized Signature Database
    • Beinhaltet jene Trust-Objekte, die zur Verifizierung der Signatur der Firmware eingesetzt werden (z.B. signierte Firmware-Treiber).
  • Forbidden Database
    • Enthält Signaturen, die widerrufen wurden und denen somit nicht länger vertraut wird.

Firmware Modus

Ohne PK befindet sich das UEFI-System im Setup-Mode, in dem PK und KEK Datenbanken ohne Authentifizierung geändert und bespielt werden können. Nach dem Einspielen des PKs befindet sich die UEFI-Plattfrom um User-Mode, und bleibt solange in diesem, bis der PK wieder entfernt (PK clear) wurde. Im Prinzip können im Setup-Modus sowohl PK als auch KEK beliebig geändert werden, im User-Mode nur mehr dann, wenn sie mit dem aktuellen PK der Firmware signiert sind. Laut Spezifikation ergibt sich folgendes Schema: PK und KEK können nur geändert werden, wenn:[3]

  • Im Setup Mode, wenn PKpub mit seinem zugehörigen PKpriv signiert ist.
  • Im User Mode, wenn der PKpub mit dem aktuellen PKpriv der Firmware signiert ist.

KEKs können immer gelesen werden, aber nur geschrieben werden, wenn:

  • Im Setup Mode (ohne Authentifizierung).
  • Im User Mode, wenn der KEK mit dem aktuellen PKpriv der Firmware signiert ist.

Typischerweise ist der Besitzer des PK der "Platform-Owner". Die KEKs sind unter der Kontrolle der OEM bzw. OS-Verkäufer.

Microsoft verlangt für Windows 8, dass Secure Boot per Default aktiviert ist. Ein technet-Artikel beschreibt, wie die Schlüssel der Datenbanken zusammenspielen:[5]

The Key Enrollment Key database (KEK) is a separate database of signing keys that can be used to update the signature database and revoked signatures database. Microsoft requires a specified key to be included in the KEK database so that in the future Microsoft can add new operating systems to the signature database or add known bad images to the revoked signatures database.

The OEM stores the signature database, revoked signatures database, and KEK signature databases on the firmware nonvolatile RAM (NV-RAM) at manufacturing time. These signature databases must be included to boot Windows by using Secure Boot.

After these databases have been added, and after final firmware validation and testing, the OEM locks the firmware from editing, except for updates that are signed with the correct key or updates by a physically present user who is using firmware menus, and then generates a platform key (PK). The PK can be used to sign updates to the KEK or to turn off Secure Boot.

Zusammengefasst ergeben sich daraus folgende wichtige Punkte:

  • Microsoft besitzt in KEK einen Schlüssel, der es erlaubt neue signierte OS hinzuzufügen und Software-Teile zu widerrufen.
  • Die Signatur-Datenbanken werden zur Fertigungszeit im NVRAM der Firmware abgelegt.
  • Über einen Platform Key (PK) des Herstellers können die KEK aktualisiert werden oder Secure Boot deaktiviert werden.

Einzelnachweise

  1. ↑ 1,0 1,1 UEFI Secure Boot Impact on Linux (ozlabs.org)
  2. ↑ Windows 8 Hardware Certification Requirements (msdn.microsoft.com)
  3. ↑ 3,0 3,1 UEFI Spezikfikation S. 1451 (uefi.org/specs)
  4. ↑ Deploying Secure Boot: Key Creation and Management (uefi.org)
  5. ↑ Secure Boot Overview (technet.microsoft.com)

Das könnte Sie auch interessieren

EFI Shell USB Stick
Zum Artikel
Extreme Privilege Escalation UEFI Sicherheitslücke
Zum Artikel
OS-Installation auf UEFI-Systemen
Zum Artikel