Mit dem richtigen Know-how lässt sich Arch Linux leicht und komfortabel als voll verschlüsseltes System aufsetzen.

Bereits der Linux-Kernel liefert die Technik zum Verschlüsseln von Festplatten-Partitionen [1]. Der Userspace, sprich: die eingesetzte Linux-Distribution, muss sich lediglich um das Entsperren beim Booten kümmern.

Anwender von LVM oder Software-RAID kennen das dabei genutzte Device-Mapper-Prinzip, bei dem sich zwischen das Hardware-Festplattengerät (zum Beispiel /dev/sda) noch eine Zwischenschicht schiebt. Das Ergebnis ist ein sekundäres Device wie etwa /dev/mapper/Volume_Group-Volume (Abbildung 1). Diese Kernel-Zwischenschichten erlauben beliebige Kombinationen: Ebenso, wie sich LVM auf ein RAID-Device aufpropfen lässt, kann man auch RAID/LVM-Kombinationen genau wie simple Festplatten-Devices (/dev/sdX) noch um eine Verschlüsselungsschicht erweitern.

Abbildung 1: Der Device Mapper des Linux-Kernels kombiniert Hardware-Geräte zu einem RAID, LVM, oder verschlüsselt Daten. Die so entstandenen abgeleiteten Devices akzeptiert er erneut als Input, sodass sich seine Funktionen stapeln lassen.

Der Ubuntu-Installer platziert zum Beispiel zur System-Komplettverschlüsselung Home-, Root- und Swap-Partition in eine gemeinsame LVM-Volume-Gruppe. Beim Systemstart entsperrt das System das LVM, sodass die Eingabe eines Passworts alle logischen Volumes aufschließt. Ein Nachteil dieses Vorgehens liegt allerdings darin, dass nach Ausfall einer am LVM beteiligten Platte alle Daten verloren gehen.

Schlüsseldatei

Dieser Artikel schlägt deshalb einen flexibleren Ansatz vor, um mit einer einmaligen Passworteingabe beliebig viele Partitionen zu entsperren (Abbildung 2): Er nutzt die Fähigkeit neuerer Grub-Versionen, verschlüsselte Boot-Partitionen zu entsperren. Eine in der Initial Ramdisk [2] eingebettete Schlüsseldatei (Abbildung 3) öffnet die Root-Partition. Nach dem Entsperren von /root in der frühen Boot-Phase kann Systemd den dort ebenfalls vorliegenden Schlüssel in der zweiten Boot-Phase zum Aufschließen aller weiteren verschlüsselten Dateisysteme nutzen.

Abbildung 2: Beim vorgestellten Verfahren genügt das einmalige Eingeben eines Passworts am Boot-Prompt, um alle Partitionen des Systems in einem Rutsch zu entsperren.

Abbildung 3: Grub entsperrt die Boot-Partition, ein in der Initial Ramdisk eingebetteter Schlüssel entriegelt die Root-Partition. Der weitere Boot-Vorgang nutzt den Schlüssel /etc/key, um beliebig viele weitere verschlüsselte Volumes zu entsperren.

Das Verfahren funktioniert für beliebige Partitionsschemata, auch solche mit LVM oder RAID. Das Verschlüsseln der Boot-Partition verhindert außerdem ein unbemerktes Unterschieben eines manipulierten Kernels, das bei physischem oder Root-Zugriff auf den Rechner sonst möglich wäre. Diesen Vorteilen steht der Nachteil gegenüber, dass das Entsperren der Boot-Partition mit Grub deutlich länger dauert als das Entsperren über das Linux-System: Offenbar ist der portabel gehaltene Code von Grub weniger gut auf Performance optimiert als der im Kernel.

Aber genügt es nicht, nur die Home-Partition zu verschlüsseln, in der alle persönlichen Daten liegen? Die Antwort lautet: Es ist fast unmöglich, das Heraussickern der Daten zu verhindern. Im schlimmsten Fall landet ein – bei entsperrten Volumes im RAM vorgehaltener – Schlüssel in der Auslagerungspartition. Viele Programme schreiben zudem nach /tmp oder /var. Verlässliche Sicherheit garantiert daher nur eine Gesamtverschlüsselung des Systems.

Neu oder recycled

Dieser Artikel geht zunächst von der Neuinstallation eines Systems aus. Es ist aber ohne Weiteres möglich, wie im Folgenden beschrieben, verschlüsselte Partitionen zu erstellen, darauf ein Backup [3] einer Arch-Linux-Installation einzuspielen, und die nötigen Änderungen dann an den Konfigurationsdateien im bestehenden System vorzunehmen.

Das Arch-Wiki erklärt außerdem, wie sich bestehende Dateisysteme nachträglich verschlüsseln lassen [4]. Hier kommt allerdings eine noch experimentelle Funktion von Cryptsetup zum Zuge, die alle Daten zerstört, falls sie aus irgendwelchen Gründen nicht bis zum Ende durchläuft. Ein Backup benötigen Sie also auch hier.

Booten Sie zunächst eine aktuelle Arch-Linux-Live-Umgebung [5]. Dort stehen alle Werkzeuge, die Sie zum Nachvollziehen dieses Artikels benötigen, bereits vorinstalliert bereit. Am Anfang jeder Arch-Linux-Installation steht das Partitionieren der Festplatten. Achten Sie dabei darauf, dass auf der Platte, von der Sie booten möchten, eine Ext4-Boot-Partition mit 100 bis 250 MByte bereitsteht. Ansonsten teilen Sie den Plattenplatz genauso auf, wie Sie es ohne Verschlüsselung tun würden.

Dann richten Sie die Verschlüsselung zunächst für die Boot-Partition [6] ein (Listing 1, erste Zeile). Ist Ihre Boot-Partition nicht die erste Partition der ersten Platte, dann passen Sie den Device-String sda1 entsprechend an. Der Parameter --type luks1 ist bei der Boot-Partition erforderlich, weil Grub das neuere und sicherere LUKS2-Format noch nicht unterstützt.

Cryptsetup bittet Sie nun um die Eingabe von YES in Großbuchstaben und fragt zweimal nach einem Passwort, das Sie später am Boot-Prompt eingeben, um das System zu starten. Cryptsetup kalibriert dabei die Zeit, die das Entsperren des Volumes dauert, auf zwei Sekunden für das vorliegende System. Doch Grub braucht wie erwähnt wesentlich länger als der Kernel, im Test mehr als fünf Mal so lang.

# cryptsetup luksFormat --type luks1 /dev/sda1
# cryptsetup open /dev/sda1 cryptboot
# mkfs.ext4 /dev/mapper/cryptboot
# cryptsetup luksFormat /dev/sda2
# cryptsetup open /dev/sda2 cryptroot

Die Bremse lösen

Erscheint Ihnen diese zehnsekündige Verzögerung, bis der Boot-Vorgang startet, zu lang, dann können Sie diese durch Hinzufügen des Parameters -i 500 vor dem Device-String vom Default-Wert 2000 auf ein Viertel reduzieren: Eine zigtausendfache Iteration einer kryptografischen Funktion über das Rohpasswort erzwingt diese Verzögerung künstlich, um das Durchprobieren von Passwörtern zu erschweren.

Das Verringern der zum Entsperren nötigen Zeit geht also auf Kosten der Sicherheit, denn Brute-Force-Angriffe gelingen dann leichter. Das Umsetzen der Festplatte in einen schnelleren Rechner verkürzt diese Entsperrzeit noch weiter. Ist die Boot-Partition geknackt, dann liegt bei unserem Ansatz der Schlüssel für alle weiteren bloß.

Haben Sie die kleine verschlüsselte Boot-Partition erstellt, dann entsperren Sie sie gleich (Listing 1, zweite Zeile). In entschlüsselter Form reiht sie sich nun als Device /dev/mapper/cryptboot ins System ein. Der Name unterhalb von /dev/mapper entspricht dem letzten Parameter des Cryptsetup-Aufrufs. Diese Partition braucht nun ein Ext4-Dateisystem (Zeile 3).

Als Nächstes legen Sie die verschlüsselte Root-Partition an (Zeile 4), wobei Sie /dev/sda2 aus dem Beispiel wieder durch den korrekten Device-String ersetzen müssen. Wie schon bei der Boot-Partition geben Sie YES und ein Passwort ein. Auch dieses verschlüsselte Volume entsperren Sie anschließend (Zeile 5). Es steht dann unter /dev/mapper/cryptroot zur Formatierung mit dem Dateisystem Ihrer Wahl bereit.

In der Folge gehen Sie mit allen Partitionen der Arch-Linux-Installation so vor. Falls Sie RAID- oder LVM-Devices verwenden, können Sie, wie bereits erwähnt, die entsprechenden virtuellen Devices ebenso als Basis für die Verschlüsselung nutzen wie die Hardware-Geräte /dev/sda1 oder /dev/sdb2. Auch später, nach der Installation, gelingt das Hinzufügen weiterer verschlüsselter Partitionen nach dem hier vorgestellten Strickmuster problemlos.

Das System erlaubt, neben den verschlüsselten Partitionen auch unverschlüsselte in /etc/fstab einzutragen – Sie sollten dann sicher sein, dass keine vertraulichen Daten dorthin geraten. Wie erläutert, müssen Sie aber /var und /tmp sowie (falls vorhanden) die Auslagerungspartition auf jeden Fall verschlüsseln.

Mit Inhalt füllen

Haben Sie die verschlüsselten Partitionen angelegt, entsperrt und formatiert, dann mounten Sie sie im Live-Installations-System entsprechend des späteren Dateisystem-Layouts unterhalb von /mnt. Das Vorgehen unterscheidet sich bei einem verschlüsselten System nicht von jenem, das der Arch-Linux-Installationsleitfaden im Abschnitt “Mount the file systems” beschreibt [5].

Dann installieren Sie, ebenfalls gemäß dem Arch-Wiki im Abschnitt “Installation”, das System in diese Verzeichnishierarchie. Der Aufruf des Helfer-Skripts genfstab -U /mnt >> /mnt/etc/fstab funktioniert wie in der Installationsanleitung beschrieben: Es sind ja die aufgesperrten Partitionen gemountet, genau wie später im betriebsbereiten System. In der Fstab landen also die richtigen UUIDs und Mount-Punkte.

Wechseln Sie dann gemäß offizieller Anleitung mit arch-chroot /mnt in eine Chroot-Umgebung und konfigurieren Sie das System (siehe “Configure the system” im Installationsleitfaden). Lediglich beim letzten Schritt im Arch-Wiki, dem Reboot des neuen Systems, müssen Sie sich noch ein wenig gedulden. Bleiben Sie stattdessen weiterhin im Chroot. Alternativ zur Neuinstallation können Sie an dieser Stelle auch ein Systembackup in die im Live-System gemounteten verschlüsselten Verzeichnisse zurückspielen [3].

Nun richten Sie das automatische Entsperren der Partitionen ein. Dazu fügen Sie dem System Initramfs-Hooks [7] sowie Kernel-Boot-Parameter beim Start mit Grub [8] hinzu. Bei der Initial Ramdisk handelt es sich um ein vorläufiges Root-Dateisystem, das der Kernel zu Beginn des Boot-Vorgangs noch vor dem eigentlichen Root mountet. Früher enthielt es lediglich die Kernel-Module zum Lesen des Root-Dateisystems; heute laufen dort beim Booten etliche kleine Skripte ab, die Arch Linux “Hooks” nennt.

Schließanlage

Zum Entsperren kommt der Hook sd-encrypt zum Einsatz, der auf ein in das Initramfs eingebettetes Systemd-Binary aufsetzt und der daher den Hook systemd voraussetzt. Auch muss das Paket cryptsetup installiert sein, was Sie im Installations-Chroot mit pacman -S cryptsetup sicherstellen. Details erläutert, wie unter Arch Linux üblich, die bereits erwähnte Wiki-Seite zu den Initramfs-Hooks [7]. Ein Beispiel für eine passende Hooks-Konfiguration finden Sie in Listing 2.

HOOKS=(base systemd autodetect keyboard sd-vconsole modconf block sd-encrypt sd-lvm2 filesystems fsck)

sd-encrypt folgt also nach keyboard und sd-vconsole, damit Sie das Passwort mit dem gewohnten Keyboard-Layout eingeben können, sowie vor dem LVM- und filesystems-Hook, für den die entsperrten Dateisystem-Geräte bereits vorliegen müssen. Auch den Schlüssel zum Entsperren der verschlüsselten Partitionen ohne Passworteingabe müssen Sie in der Initial Ramdisk einbetten, damit er vor dem Einhängen des endgültigen Roots zur Verfügung steht.

Erzeugen Sie für diesen Schlüssel nun zuerst in der Chroot-Umgebung des zukünftigen Systems eine zufällige Zeichenkette (Listing 3, erste Zeile). Die entstandene Datei /etc/key sperren Sie für den Zugriff aller Anwender außer Root (zweite Zeile), und tragen Sie im Array FILES() in der Datei /etc/mkinitcpio.conf ein: FILES(/etc/key). Um die Initial Ramdisk mit der neuen Hook-Konfiguration und dem eingebetteten Schlüssel zu erzeugen, führen Sie im Installations-Chroot noch das Kommando mkinitcpio -P aus.

# dd bs=512 count=4 if=/dev/random of=/etc/key iflag=fullblock
# chmod 600 /etc/key

Vordereingang

Beim Erstellen der verschlüsselten Volumes mit Cryptsetup haben Sie zwar ein Passwort angegeben, doch beim Systemstart soll die Schlüsseldatei zum Einsatz kommen. Verschlüsselte LUKS-Volumes enthalten vier sogenannte Slots für Authentifizierungsdaten, also für Passwörter oder Schlüsseldateien. Folgendes Kommando fügt die Passwortdatei dem nächsten freien Slot hinzu:

# cryptsetup luksAddKey /dev/sdXY /etc/key

Dazu benötigen Sie das vorher gesetzte Passwort, das auch nach Hinzufügen der Schlüsseldatei erhalten bleibt. So kann Grub die Boot-Partition per Passwort entsperren; der später bootende Kernel erledigt das hingegen ohne erneute Passworteingabe anhand der Schlüsseldatei. Auch allen anderen verschlüsselten Partitionen fügen Sie mit Cryptsetup den Schlüssel /etc/key hinzu. Auch hier sollte das Passwort parallel zur Schlüsseldatei erhalten bleiben, sonst gehen nach einem Verlust der Daten in der Root-Partition auch die Inhalte aller anderen Partitionen verloren.

Der sd-encrypt-Hook erwartet die UUIDs der von ihm zu entschlüsselnden Volumes als Kernel-Bootparameter, die Grub ihm beim Start übergibt. Installieren Sie daher zunächst Grub in die Chroot-Umgebung (Installationsleitfaden, Abschnitt “Chroot”). Sie finden die UUIDs durch Eingabe von blkid heraus (Abbildung 4), in dessen Ausgabe Sie die Zeilen mit TYPE="crypto_LUKS" suchen. Die Zeilen mit den entschlüsselten Dateisystemen vom Typ ext4, btrfs oder den anderen Dateisystemen, die Sie mit Mkfs erstellt haben, stimmen hier nicht.

Abbildung 4: Das Kommandozeilenwerkzeug Blkid listet die UUIDs der verschlüsselten Partitionen (Typ crypto_LUKS) auf. Anhand der Gerätedateien in der linken Spalte können Sie die Zeilen den von Ihnen erstellten Volumes zuordnen.

Startvorbereitung

Um die UUIDs nicht abtippen zu müssen, speichern Sie sie mit blkid > /tmp/blkid in einer temporären Datei und öffnen sie zusammen mit /etc/default/grub in einem Texteditor, wie etwa dem vorinstallierten Vi. Eventuell installieren Sie vorher auch den komfortableren Vim in die Chroot-Umgebung.

In der nun geöffneten Grub-Konfigurationsdatei /etc/default/grub tragen Sie die UUID des Root-Dateisystems zwischen die Anführungszeichen der mit GRUB_CMDLINE_LINUX= beginnenden Zeile ein. Die Syntax folgt der Form rd.luks.name=UUID=Volume-Name, zum Beispiel also rd.luks.name=c345[...]5f7a=cryptroot (Abbildung 5).

Abbildung 5: Kernel-Startparameter (Zeile GRUB_CMDLINE_LINUX) veranlassen das Aufschließen der Root-Partition im frühen Userspace.

Außerdem fügen Sie dem String hinter GRUB_CMDLINE_LINUX= noch, mit Leerzeichen abgetrennt, den Parameter rd.luks.key=/etc/key hinzu. Zu guter Letzt kommentieren Sie die Zeile GRUB_ENABLE_CRYPTODISK=y aus, um die Entschlüsselungsfunktion von Grub überhaupt erst zu aktivieren. Ohne Angabe einer UUID gilt der bei rd.luks.key angegebene Schlüssel für alle in der Initial-Ramdisk-Phase zu entsperrenden Volumes. Weitere Kernel-Startparameter beeinträchtigen die rd.luks-Einträge nicht.

Der Name nach dem zweiten Gleichheitszeichen in den rd.luks.name-Parametern steht für den Gerätenamen unter /dev/mapper/ im laufenden System. Er hat bei einer Fstab auf Basis der UUIDs, wie sie der Arch-Linux-Installationsleitfaden empfiehlt, keine technische Bedeutung. Aussagekräftige Namen helfen aber bei der Systemadministration und Fehlerbehebung. Nach dem Speichern von /etc/default/grub erzeugen Sie die eigentliche Grub-Konfigurationsdatei neu:

# grub-mkconfig -o /boot/grub/grub.cfg

Root muss bereits von der Initial Ramdisk aus entsperrt werden, damit der normale Boot-Vorgang starten kann. Möchten Sie Suspend to Disk nutzen, dann benötigt auch die Swap-Partition einen analog gestalteten Eintrag in /etc/default/grub. Der resume-Hook muss in /etc/mkinitcpio.conf nach sd-encrypt stehen: Er benötigt eine bereits entsperrte Swap-Partition, mit der verschlüsselten kann er nichts anfangen.

Alle weiteren Partitionen erhalten einen Eintrag in der Datei /etc/crypttab (Abbildung 6). Systemd entsperrt sie in der zweiten Bootphase, wenn der Schlüssel im Root bereits zur Verfügung steht. Auch die Boot-Partition müssen Sie dort eintragen, da sie der Kernel wie erwähnt noch einmal entsperren muss. Ansonsten wäre es nicht möglich, vom laufenden System aus einen neuen Kernel dorthin zu installieren. Die Einträge in /etc/crypttab folgen dem simplen Schema Device-Name UUID=UUID Schlüsseldatei, also beispielsweise crypthome UUID=fa7[...]fe3 /etc/key.

Abbildung 6: In der zweiten Stufe des Boot-Vorgangs wertet Systemd die /etc/crypttab aus, um alle weiteren Volumes außer dem bereits entsperrten Root aufzuschließen. Auch hier erspart die Schlüsseldatei die Eingabe eines Passworts.

Nun ist das System nach Verlassen der Chroot-Umgebung mit exit bereit für den Neustart. Sollte jetzt oder später das Entsperren nicht funktionieren, können Sie immer noch die Install-Disk booten und die verschlüsselten Partitionen mit Cryptsetup sowie dem parallel zur Schlüsseldatei gültigen Passwort entsperren.

Fazit

Seit Grub auf verschlüsselte Partitionen zugreifen kann, gibt es einen Weg, ein Linux-System inklusive der für die Sicherheit nicht ganz unwichtigen Boot-Partition voll zu verschlüsseln und trotzdem mit einmaliger Passworteingabe zu entsperren. Dazu schließt Grub die Boot-Partition auf, eine dort in der Initial Ramdisk abgelegte Schlüsseldatei öffnet dann die Root-Partition. Nach dem Einhängen des entsperrten Roots wertet Systemd die /etc/crypttab aus und entsperrt mithilfe einer Schlüsseldatei im Root beliebig viele weitere Partitionen.