UEFI-Secure-Boot und alternative Betriebssysteme

Eugenio Marongiu, 123RF

Einlasskontrolle

,
Ist es ein nützliches Sicherheitsfeature oder ein Mechanismus, um freie Betriebssysteme auszubremsen? An UEFI-Secure-Boot scheiden sich die Geister. Aber wie schwierig ist es wirklich, in einer UEFI-Umgebung ein gängiges Linux zu booten?
ADMIN 03/14 stellt Erste-Hilfe-Tipps zu Windows-Rettung, Backup und Recovery bei Datenbanken vor und verrät wie man Linux-Systeme vollständig sichert und ... (mehr)

Für das Booten eines Computers war in der Vergangenheit das BIOS zuständig: Es übernahm die Initialisierung und den Start des Betriebssystems. Viele moderne Rechner verwenden aber inzwischen anstelle des BIOS die UEFI-Firmware. Das Unified Extensible Firmware Interface (UEFI) unterstützt eine einfache Erweiterung der Firmware durch unterschiedlichste Module. Dazu gehören zum Beispiel ein eingebettetes Netzwerkmodul für die Fernwartung, Module für Digital Rights Management und die BIOS-Emulation mit dem Compatibility Support Module (CSM). UEFI kennt zudem einen Secure-Boot-Mechanismus. Die Secure-Boot-Technologie prüft in diesem Fall, ob der Bootloader mit einem kryptographischen Schlüssel signiert ist, den eine in der Firmware enthaltene Datenbank autorisiert. Durch die Kontrolle der Signatur des Bootloaders, des Kernels und möglicherweise weiteren Userspace-Codes wird die Ausführung unsignierter Software unterbunden.

Windows 8 ist das erste Betriebssystem, das diese Funktion nutzt. Damit kann es die Ausführung von Schadcode verhindern. Allerdings kann der Eigentümer des Rechners nun nicht mehr frei entscheiden, welches Betriebssystem er installieren kann.

UEFI-Secure-Boot

UEFI-Secure-Boot validiert den Bootvorgang. Die UEFI-Spezifikation 2.3 definiert dafür die folgenden Komponenten und Verfahren:

  • eine Programmierschnittstelle für den Zugriff auf kryptographisch geschützte UEFI-Variablen im Flash-Speicher,
  • ein Format zum Speichern von X.509-Zertifikaten in UEFI-Variablen,
  • ein Verfahren zur Validierung des Bootloaders und der Treiber mithilfe von AuthentiCode-Signaturen,
  • einen Mechanismus für den Widerruf (Revocation) kompromittierter Zertifikate und Signaturen.

UEFI-Secure-Boot unterscheidet die in Tabelle 1 aufgelisteten Schlüssel (Abbildung 1).

Tabelle 1

UEFI-Schlüssel

Schlüssel

Funktionen

Platform Key (PK)

Meist ein Schlüssel des Hardware-Herstellers (OEM), PK erlaubt die Manipulation der KEK, nur ein einziger PK möglich.

Key Exchange Key (KEK)

Mehrere Zertifikate möglich, unterschiedliche Schlüssel für unterschiedliche OS-Anbieter möglich, zum Beispiel: Microsoft KEK CA; KEK erlaubt die Manipulation der db und dbx.

Autorisierte DB (db)

Mehrere Zertifikate und Hashes möglich, zum Beispiel: Microsoft Windows Production CA; zur Identifizierung von vertrauenswürdigem Code.

Nicht autorisierte DB (dbx)

Mehrere Zertifikate oder Hashes möglich; zur Identifizierung von kompromittiertem Code oder Schadcode.

Abbildung 1: Diese Schlüssel können am Secure-Boot-Prozess beteiligt sein.

Des Weiteren beschreibt die Spezifikation zwei Modi, in denen sich Secure Boot befinden kann. Der Erste ist der Setup Mode. Eine UEFI-Firmware, deren Secure-Boot-Implementierung in diesem Modus betrieben wird, schützt die Zertifikatsspeicher nicht vor Manipulation. Es ist insbesondere möglich, aus einem laufenden Betriebssystem heraus Zertifikate als auch Hashes in die UEFI-Zertifikatsspeicher einzufügen oder zu entfernen. Dieser Modus dient primär zur Einrichtung von Secure Boot.

Zweitens existiert der User Mode. Befindet sich eine Secure-Boot-Implementierung im User Mode, so ist eine Manipulation der Zertifikatsspeicher nur sehr eingeschränkt möglich. Insbesondere sind Änderungen ohne Authentifizierung aus einem laufenden Betriebssystem nicht mehr durchführbar. Zur Veränderung des db- oder dbx-Zertifikatsspeichers ist eine Autorisierung mittels des privaten Schlüssels eines im KEK-Speicher hinterlegten Zertifikats nötig. Zur Änderung des KEK- und PK-Speichers bedarf es hingegen des privaten Schlüssels des hinterlegten Plattform-Key-Zertifikats.

Der Wechsel vom User Mode in den Setup Mode ist zum einen durch das Entfernen des Plattform Keys möglich. Dies setzt die Kenntnis des privaten Schlüssels des installierten Plattform Keys voraus. Alternativ kann mittels des UEFI-Setups in den Setup Mode gewechselt werden. Dabei ist der Zugang zur Hardware und gegebenenfalls die Kenntnis von Kennwörtern zur Nutzung des Setups Voraussetzung.

UEFI-Secure-Boot verhindert nicht die Installation von Malware oder die Modifikation des Bootloaders, sondern stellt dessen Vertrauenswürdigkeit während des Bootvorgangs sicher. Kann die Vertrauenswürdigkeit nicht festgestellt werden, so wird das Booten unterbunden (vereinfacht in Abbildung 2).

Abbildung 2: So läuft der Secure-Boot-Vorgang ab. Kann sich der Bootloader nicht als vertrauenswürdig ausweisen, wird das System nicht gestartet.

Secure Boot mit Windows

Microsoft unterstützt Secure Boot ab Windows 8. Jedoch ist Secure Boot keine zwingende Voraussetzung für die Funktionstüchtigkeit des Betriebssystems. Ältere Microsoft-Betriebssysteme können auf einem System mit aktiver Secure-Boot-Funktion nicht eingesetzt werden, weil Microsoft für diese noch keine signierten Bootloader bereitstellt.

Hardware-Hersteller, die ihre Systeme mit dem Windows-8-Logo ausstatten möchten, müssen jedoch UEFI-Secure-Boot unterstützen und diese Funktion im Auslieferungszustand aktivieren. Daher müssen diese Systeme auch über das notwendige Schlüsselmaterial in der UEFI-Firmware verfügen. Hierzu gehört mindestens das Microsoft-Windows-Production-PCA-2011-Zertifikat, das von Microsoft für die Signatur eigener Produkte genutzt wird. Die Hardware-Hersteller dürfen weitere Microsoft-Zertifikate – wie das Microsoft-Corporation-UEFI-CA-2011-Zertifikat – und eigene Zertifikate in den UEFI-Speicher ablegen.

UEFI-Secure-Boot wird bisher hauptsächlich auf Client-Systemen eingesetzt. Zukünftige Microsoft-Betriebssysteme werden diese Technologie jedoch wahrscheinlich auch auf Serversystemen zur Verfügung stellen oder deren Nutzung sogar erzwingen.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2018