Ein OpenSuse-Systeme lässt sich schon bei der Installation verschlüsseln – oder auch nachträglich. Die damit verbundene lästige mehrfache Passworteingabe beim Start kann man umgehen.

OpenSuse kann Systeme schon bei der Installation mit wenigen Klicks verschlüsseln. Die Kontrollkästchen dafür versteckt die Distribution allerdings. Zudem liefert der Installer keinen Hinweis, dass eine Verschlüsselung ohne Einsatz von Logical Volume Manager (LVM [1]) zwar funktioniert, man dann jedoch das Verschlüsselungspasswort beim Start mehrfach eingeben muss. Ein ohne LVM installiertes System lässt sich hinterher nicht mehr ohne Weiteres in ein LVM-basiertes Setup umwandeln. Das korrespondierende Problem der nervigen Mehrfacheingabe des Passworts kann man aber lösen.

Sicherer Start

Im OpenSuse-Installer wählen Sie beim Punkt Festplatte die Verschlüsselung (Abbildung 1). Nicken Sie dort den vom Installer automatisch generierten Vorschlag für Partitionierung einfach per Weiter ab, bekommen Sie das Kontrollkästchen Festplatten-Verschlüsselung aktivieren nicht zu sehen. Um es zu Gesicht zu bekommen, müssen Sie stattdessen auf den Button Geführtes Setup klicken.

Abbildung 1: Die Option zur Festplattenverschlüsselung bekommen Sie nur zu sehen, wenn Sie ins Geführte Setup einsteigen, statt den Vorschlag für Partitionierung mit Weiter zu übernehmen.

Geführt bedeutet, dass Sie wie bei Übernahme des automatischen Vorschlags für Partitionierung die Festplattenaufteilung nicht manuell zu erstellen brauchen. Anders als beim automatisch präsentierten Vorschlag stehen hier jedoch diverse Optionen zur Wahl. Dazu zählen Verschlüsselung, der Einsatz des Logical Volume Managers, das Anlegen einer separaten Home-Partition sowie eine Auswahl bei den Dateisystemen der Partitionen.

LVM dient eigentlich dazu, mehrere Festplatten oder SSDs zu einem großen, virtuellen Gerät (Logical Volume, LV) zu verbinden, auf dem Sie Partitionen wie Home, Swap und Root unabhängig von Festplattengrenzen verteilen (Abbildung 2). Sie können einem LVM-Verbund (einer Volume Group) jederzeit neue Festplatten hinzufügen.Technisch gesehen funktionieren LVs mit nur einer Platte, auch wenn ihr Einsatz dann zunächst keinen Sinn ergibt. Das ändert sich, wenn das Ein-Platten-LV die Rolle einer übergeordneten Verschlüsselungseinheit übernimmt, mit deren Hilfe sich mehrere Partitionen gemeinsam verschlüsseln lassen. Dann genügt ein Passwort.

Abbildung 2: Ein LVM ist dafür gedacht, mehrere Speichergeräte zu einem logischen Pool zu verbinden, der sich beliebig partitionieren lässt.

Wächst eine Volume Group beim Einbau neuer Speichergeräte auf mehrere Platten, gilt es zu bedenken, dass alle Daten eines LVM-Verbunds verloren gehen, sobald nur ein beteiligter Datenträger ausfällt. Die Ausfallwahrscheinlichkeiten aller Platten addieren sich dann nicht nur, sie multiplizieren sich. Am flexibelsten bleiben Anwender am heimischen PC daher mit einem Partitionsschema ohne LVM, das außerdem eine externe Home-Partition nutzt – dazu gibt es eine gleichnamige Option im Installer. Das erleichtert es, Linux neu zu installieren und dabei problemlos die Distribution zu wechseln, ohne die Daten im Home zu überschreiben.

Eines für alle

Eine zweifache Passwortabfrage beim Entsperren mehrerer Partitionen lässt sich durch eine Schlüsseldatei in der Root-Partition umgehen, die bei allen weiteren Freischaltungen ein Passwort überflüssig macht (Abbildung 3). Da die Schlüsseldatei erst nach dem Entsperren der Root-Partition lesbar wird, bleibt die Sicherheit gewährleistet. Sie müssen diesen Workaround allerdings per Hand einrichten.

Abbildung 3: Auch wenn Sie das Verschlüsselungspasswort bereits bei der Grub-Systemauswahl eingegeben haben, fragt OpenSuse in der Auslieferungskonfiguration ohne LVM noch einmal danach.

Dazu legen Sie zuerst eine versteckte Passwortdatei im Wurzelverzeichnis an und füllen sie mit 1 KByte Zufallszeichen (Listing 1, Zeile 1 bis 3). Das unter Linux am weitesten verbreitete LUKS-Verschlüsselungsformat [2] enthält vier sogenannte Slots für Passwörter oder Schlüsseldateien. Weisen Sie nun zum Beispiel der zweiten Partition der ersten Platte mit dem Kommando aus der letzten Zeile von Listing 1 eine Schlüsseldatei zu, dann überschreiben Sie damit das bei der Installation gesetzte Passwort nicht, vielmehr gelingt das Entsperren nun per Passwort und Schlüsseldatei.

$ touch /.root.key
$ sudo chmod 600 /.root.key
$ sudo dd if=/dev/urandom of=/.root.key bs=1024 count=1
$ sudo cryptsetup luksAddKey /dev/sda2 /.root.key

Unter Linux liegen im Verzeichnis /dev sogenannte Device-Dateien, die einen Zugriff auf Hardwaregeräte ermöglichen. Die für Festplattenpartitionen zuständigen Dateien heißen sda1 für die erste Partition der ersten Festplatte, sdb2 für die zweite Partition der zweiten Platte und so weiter. Per SATA-Kabel angeschlossene SSDs verhalten sich wie Festplatten.

Die Device-Files der direkt in M.2-Steckplätzen auf dem Motherboard montierten SSDs folgen dagegen dem Namensschema nvme0n1p1 für die erste Partition (p1) der SSD am ersten Controller (nvme0) und nvme1n1p2 für die zweite Partition (p2) der SSD am zweiten Steckplatz (nvme1). Die mittlere Nummer nach dem Buchstaben n steht für sogenannte Namespaces und bleibt bei im Desktop-Bereich üblichen Geräten ungenutzt, lautet also immer 1. Dieser Artikel geht nur auf das sdxY-Namensschema für SATA-Geräte ein. Die Übersetzung für NVME-Geräte ist einfach: sda1 entspricht nvme0n1p1, sdb2 wäre nvme1n1p2 und so weiter.

Beim Herausfinden der Namen der Device-Dateien hilft der Konsolenbefehl sudo lsblk (Abbildung 4): Er nennt alle Partitionen, ihre Einhängepunkte sowie die Namen der Verschlüsselungscontainer. Letztere benennt der OpenSuse-Installer als cr_root für die System-, cr_home für die Home- und cr_swap für die Auslagerungspartition. Warum es für die Sicherheit wichtig ist, auch die Swap-Partition zu verschlüsseln, erläutert der Kasten “Gründe für die Systemvollverschlüsselung”.

Abbildung 4: Lsblk zeigt, welche Festplattenpartitionen verschlüsselt sind und wie die virtuellen Festplattengeräte unter /dev/mapper heißen, die die unverschlüsselten Daten bereitstellen.

Zusätzlich verwendet ein Filesystem beim Schreiben von Dateien einfach neue, noch freie Blöcke auf den Speichermedien. Gelöschte Daten bleiben für unbestimmte Zeit unberührt und damit lesbar, auch wenn sie im Dateisystem nicht mehr auftauchen. Speichergeräte, auf denen nur verschlüsselte Daten lagern, können Sie trotzdem risikolos weiterverkaufen oder entsorgen.

Verschlüsselungstabelle

Die Datei /etc/crypttab (Listing 2) regelt, welche Partitionen der Systemstartvorgang entsperrt. Sie besteht aus vier Spalten: Die erste enthält einen frei wählbaren Namen. Ihm entspricht die nach dem Aufsperren im Verzeichnis /dev/mapper erscheinende Device-Datei. Sie kommt auch in /etc/fstab zum automatischen Einhängen der Partition zum Einsatz.

cr_swap UUID=4d0c1229-615f-4bf5-bf42-261d1e10dbd3
cr_home UUID=0e30bddb-b810-4167-8f96-bd45577f99c3
cr_root UUID=97254eee-a0a5-4d0f-8e95-4a66485a5123 none x-initrd.attach

Die zweite Spalte identifiziert die Festplattenpartition über die sogenannte UUID. Stattdessen könnte hier auch ein Device-File wie /dev/sda2 stehen, doch die UUID funktioniert auch dann noch, wenn sich die Reihenfolge verändert, in der die Platten im Rechner eingebaut sind. Sie finden die zu einem Device-File gehörige UUID mit sudo blkid heraus, doch im Moment ist das noch nicht nötig.

In der dritten Spalte tragen Sie den Pfad zur Schlüsseldatei ein. Dort steht im Auslieferungszustand entweder nichts oder der Platzhalter none, wenn die vierte Spalte belegt ist. Das dort eingetragene x-initrd.attach sorgt dafür, dass das Startsystem die Partition vor dem Einhängen der Root-Partition entsperrt. Bei der Systempartition (letzte Zeile in Listing 2), von der der weitere Startvorgang abhängt, ist das unabdingbar.

Die Root-Partition (cr_root) brauchen Sie nicht zu verändern: Sie entsperrt das vom Bootloader weitergereichte Passwort. Bei allen anderen Zeilen tragen Sie in der dritten Spalte den Pfad zur Schlüsseldatei /.root.key ein (Listing 3). Die Auslagerungspartition braucht ebenfalls x.initrd.attach in der vierten Spalte, denn sonst erscheint trotz eingetragener Schlüsseldatei eine Passwortabfrage: Das OpenSuse-System versucht jede vorgefundene Swap-Partition auch ohne Eintrag in /etc/crypttab bereits in der frühen Startphase einzubinden, kann sie dann aber nicht der Schlüsseldatei zuordnen.

cr_swap UUID=4d0c1229-615f-4bf5-bf42-261d1e10dbd3 /.root.key x-initrd.attach
cr_home UUID=0e30bddb-b810-4167-8f96-bd45577f99c3 /.root.key
cr_root UUID=97254eee-a0a5-4d0f-8e95-4a66485a5123 none       x-initrd.attach

Frühstart

Damit die Schlüsseldatei bereits vor Entsperren der Root-Partition verfügbar ist, muss Grub sie dem Linux-Kernel gleich beim Start in der sogenannten Initrd (Initial RAM-Disk) übergeben (Abbildung 5). Der Bootloader entschlüsselt nach der Passwortabfrage die Partition, auf der /boot/grub liegt, also entweder die Root-Partition oder eine zusätzliche Boot-Partition. Damit die Schlüsseldatei zur rechten Zeit vorliegt, erstellen Sie die Datei /etc/dracut.conf.d/99-root-key.conf und tragen dort die Zeile install_items+=" /.root.key " ein. Anschließend erstellen Sie die RAM-Disk mit dem Aufruf dracut -f neu.

Abbildung 5: Informationsfluss beim Booten: Grub entsperrt die Root-Partition (1). Es liest und startet den Kernel sowie die Initrd (2). Aus ihr entnimmt der Kernel die Schlüsseldatei (3), mit der er die verschlüsselte Partition entsperren kann (4).

Haben Sie ein neues Speichergerät in den Rechner eingebaut und möchten neue Partitionen darauf anlegen, dann gelingt dies am einfachsten mit Gparted: Die Rechtsklickoption Neu in einen leeren Plattenbereich startet einen Dialog mit Balkengrafik, in der Sie die Partitionsgröße intuitiv per Maus festlegen. Die richtige Option für das Dateisystem lautet für zu verschlüsselnde Partitionen nicht formatiert. Erst das entsperrte verschlüsselte Volume formatieren Sie dann mit einem Dateisystem wie Ext4 oder Btrfs.

Die Eingabe cryptsetup luksFormat /dev/sdxY formatiert die neue Partition für die Verschlüsselung. Dabei verlangt Cryptsetup eine Bestätigung mit YES (in Großbuchstaben!) und fragt nach dem Verschlüsselungspasswort. Ein cryptsetup luksOpen /dev/sdxY Name entsperrt die Partition nach Passwortabfrage und stellt ein Device-File unter /dev/mapper zur Verfügung, nämlich /dev/mapper/Name mit dem Namen aus dem luksOpen-Aufruf. Der Linux-Kernel “mappt” das ursprüngliche Festplatten-Gerät /dev/sdxY mit den verschlüsselten Daten auf dieses Device, wo die Daten dann unverschlüsselt liegen.

Doch bevor Sie mit diesem Speichergerät etwas anfangen können, benötigt es ein Dateisystem. Das Kommando mkfs.ext4 /dev/mapper/Name formatiert es mit dem unter Linux gebräuchlichen Ext4-Dateisystem. Nun können Sie es unter einem beliebigen Verzeichnis einhängen (mounten). Der Befehl mount /dev/mapper/Name /mnt macht die noch leere, als Root beschreibbare Partition unter /mnt sichtbar.

Für eine dauerhafte Einbindung im (vorher anzulegenden) Verzeichnis /data fügen Sie /etc/fstab eine Zeile wie die aus Listing 4 hinzu. Die dort angegebene UUID dient nur als Beispiel; die für Ihr System passende Zeichenfolge finden Sie über das Kommando lsblk -o +UUID heraus.

UUID=103e41c6-e913-4988-8a14-9065089b0597 /data ext4 defaults 0:*2

Nachgereicht

Mit einigem Aufwand lässt sich ein bestehendes, unverschlüsseltes OpenSuse-System nachträglich noch verschlüsseln. Das kostet in der Regel weniger Zeit, als alle Anpassungen nach einer Neuinstallation erneut vorzunehmen. Vor der Verschlüsselung drucken Sie die Ausgabe von lsblk -o +FSTYPE,UUID aus, damit Ihnen diese Informationen zur Verfügung stehen, wenn Sie während der Umstellung nicht auf das System zugreifen können.

Während einer nachträglichen Verschlüsselung darf eine bestehende Systempartition nicht aktiv sein. Booten Sie darum von der OpenSuse-Live-DVD [3] und melden Sie sich in zwei Konsolenfenstern als Root an (Abbildung 6). Das gelingt im Live-System ohne Passwort. Nehmen Sie nun den im unverschlüsselten System angefertigten Ausdruck von Lsblk zur Hand und identifizieren Sie alle Partition (Spalte Name), die es zu verschlüsseln gilt. Dazu gehören die Root-Partition, eventuell eine gesonderte Home-Partition, die Swap-Partition (siehe Kasten “Gründe für die Systemvollverschlüsselung”) und eventuell weitere per Hand hinzugefügte Partitionen.

Abbildung 6: Ein KDE-Live-System mit der Zwischenablage der grafischen Umgebung erleichtert das Übertragen von UUID-Hashes. Auch das Tastaturlayout lässt sich leicht umstellen.

Zuerst müssen Sie die Dateisysteme der bestehenden Partition geringfügig verkleinern. Bei Partitionen mit Btrfs-Dateisystem gelingt das mit den Kommandos aus Listing 5.

$ sudo mount /dev/Name /mnt
$ sudo btrfs filesystem resize -32M /mnt
$ sudo umount /mnt

Das Tool zum Verkleinern von Ext4-Dateisystemen kennt keine Option zum relativen Schrumpfen um einen bestimmten Betrag. Wollen Sie nicht lange rechnen, verkleinern Sie das Dateisystem mit resize2fs -p -M /dev/sdxY zunächst auf Minimalgröße. Diesem Befehl muss zwingend eine Dateisystemprüfung mit resize2fs -p -M /dev/sdxY vorausgehen. Nach dem im nächsten Schritt beschriebenen Verschlüsseln folgt hier, nach einem erneuten Dateisystemcheck, das Wiedervergrößern auf die neue Maximalgröße per resize2fs /dev/sdxY.

Das Dateisystem XFS, das OpenSuse im Installer immer noch für eine gesonderte Home-Partition vorschlägt, lässt sich überhaupt nicht verkleinern. Es bleibt dann nichts anderes übrig, als die Partition wie für neu eingebaute Platten beschrieben mit luksFormat zu formatieren und die Daten aus einem Backup zurückzuspielen.

Verschlüsseln Sie nach einer Dateisystemverkleinerung alle Partitionen datenerhaltend mit dem Kommando aus der ersten Zeile von Listing 6. Cryptsetup fragt nach einem Verschlüsselungspasswort, das bestimmten Sicherheitskriterien genügen muss. Je nach Größe und CPU-Leistung dauert das Verschlüsseln durchaus einige Stunden. Der Prozess muss bis zum Ende durchlaufen, sonst gehen alle Daten verloren. Generell gelten Operationen wie das Verkleinern von Dateisystemen oder ein nachträgliches Verschlüsseln eher als risikobehaftet – Backups sind dringend angeraten.

$ cryptsetup reencrypt --encrypt --reduce-device-size 16M /dev/sdxY
$ cryptsetup luksOpen /dev/sdxY cr_root
$ cryptsetup luksOpen /dev/sdxY cr_home
$ cryptsetup luksOpen /dev/sdxY cr_swap

Entsperren Sie anschließend alle verschlüsselten Partitionen (Listing 6, Zeile 2 bis 4. Für den letzten Parameter, einen frei wählbaren Namen, verwendet der OpenSuse-Installer die gezeigten Bezeichner. Ein lsblk -o +FSTYPE zeigt die neue Speichergeräteaufteilung nach der Verschlüsselung (Abbildung 7): Unterhalb der eigentlichen Partitionen (wie sda1, FSTYPE crypto_LUKS) erscheint nun ein Zweig mit dem Namen aus dem Cryptsetup-Aufruf (etwa cr_root) und dem Dateisystemtyp der Partition vor dem Verschlüsseln. Die ursprünglichen Partitionen haben zum Typ crypto_LUKS gewechselt.

Abbildung 7: Die Option -o +FSTYPE erleichtert es, in der Ausgabe von Lsblk die Btrfs-formatierte Root-Partition, die XFS-formatierte Home-Partition und die Swap-Partition auszumachen.

Umbaumaßnahmen

Im jetzigen Zustand kann das nun verschlüsselte System nicht starten. Sie müssen erst noch die Konfigurationsdateien /etc/fstab und /etc/crypttab den neuen Gegebenheiten anpassen und die Initrd neu erstellen. Den Bootloader müssen Sie nach dem Anpassen von /etc/default/grub ebenfalls neu installieren. Das gelingt nur aus einem sogenannten Chroot [4] heraus, also einer Kommandozeilenumgebung, für die das Unterverzeichnis /mnt zum Stammverzeichnis / wird.

Mounten Sie zum Aufbau eines Chroot zunächst die Systempartition und spiegeln Sie die notwendigen Verzeichnisse aus dem Live-System in die Chroot-Umgebung (Listing 7, Zeile 1 bis 5). Betreten Sie dann die Chroot-Umgebung (Zeile 6). Als Erstes mounten Sie mit mount -a alle Btrfs-Unterverzeichnisse, wie in einem normal laufenden System.

# mount /dev/mapper/cr_root /mnt
# mount --rbind /proc /mnt/proc
# mount --rbind /sys /mnt/sys
# mount --rbind /dev /mnt/dev
# mount --rbind /run /mnt/run
# chroot /mnt /mnt

Als Nächstes erstellen Sie wie schon erläutert die Schlüsseldatei /.root.key sowie die Datei /etc/crypttab. Rufen Sie dazu im Konsolenfenster ohne Chroot-Umgebung zunächst lsblk -o +FSTYPE,UUID auf und suchen Sie alle Zeilen, bei denen als FSTYPE der Eintrag crypto_LUKS angegeben ist. Im Chroot-Fenster öffnen Sie die /etc/crypttab in einem Editor wie Nano. Erstellen Sie dann in dieser Konfigurationsdatei für alle crypto_LUKS-Zeilen des Lsblk-Aufrufs aus Abbildung 8 einen Eintrag nach dem Strickmuster aus Listing 3.

Abbildung 8: Über den Befehl lsblk -o +FSTYPE,UUID finden Sie die UUIDs der Dateisysteme heraus, die Sie für das händische Erstellen der /etc/crypttab brauchen.

Nachgerüstet

Bei nachgerüsteter Verschlüsselung fällt die Konfiguration anders aus als bei von Anfang an verschlüsselten Systemen. Hier braucht auch die Root-Partition den Eintrag /.root.key in der zweiten Spalte. Da sich der Hash in der zweiten Spalte schwer abtippen lässt, kopieren Sie ihn im ersten Konsolenfenster aus der Ausgabe des Befehls lsblk und fügen ihn im Editor in die Datei /etc/crypttab ein. Nur die Root- und die Swap-Partition benötigen den Eintrag x-initrd.attach in der vierten Spalte.

Damit die neue /etc/crypttab gleich in der ersten Phase des Systemstarts zum Zug kommt, rufen Sie nun im Konsolenfenster mit dem Chroot das Tool Dracut auf, das die Initrd neu erstellt. Allerdings genügt hier ein simples dracut -f nicht, da im Live-System wahrscheinlich eine andere Version des Kernels läuft als im zu verschlüsselnden System. Sie finden die dort installierten Kernel-Versionen mittels ls /lib/modules in den Verzeichnisnamen in /lib/modules/ wieder. Anschließend rufen Sie dracut -f --kver Verzeichnis für alle dort vorliegenden Verzeichnisse aus.

Öffnen Sie dann im Chroot-Konsolenfenster im Editor die Datei /etc/default/grub und verändern Sie das n am Ende der Zeile GRUB_ENABLE_CRYPTODISK="n" in ein "y". Generieren Sie danach mit grub2-mkconfig -- /boot/grub2/grub.cfg die Grub-Konfiguration neu. Reinstallieren Sie außerdem mit grub2-install /dev/sda den Bootloader, wenn Sie von der ersten Festplatte im Rechner booten. Ansonsten ersetzen Sie sda durch die drei Buchstaben des Device-Namens für die Root-Partition (siehe ausgedrucktes Lsblk-Listing).

Nun kommt die Datei /etc/fstab im Chroot an der Reihe: Hier ersetzen Sie sämtliche UUIDs durch /dev/mapper/cr_root, /dev/mapper/cr_swap und so weiter. Der Ausdruck von Lsblk vor der Verschlüsselung zeigt den Zusammenhang zwischen den in der Fstab ursprünglich zu findenden UUIDs und den Device-Files wie /dev/sda2 (Abbildung 9).

Abbildung 9: Die UUIDs in der noch unangepassten Datei /etc/fstab entsprechen den alten Werten aus dem ausgedruckten Listing vor der Verschlüsselung der Partitionen mit cryptsetup reencrypt.

Suchen Sie zunächst für jeden UUID-Eintrag in der Fstab das Festplatten-Device, wie sda oder sdb. Dann sehen Sie im zweiten Konsolenfenster nach, ob diesem Device-File cr_root, cr_home oder ein anderer entsprechend benannter entsperrter Verschlüsselungscontainer zugeordnet ist. Ersetzen Sie den gesamten UUID-Block inklusive UUID= durch /dev/mapper/cr_root, /dev/mapper/cr_home oder die cr_xxx-Datei, die Sie im ausgedruckten Listing ermittelt haben. Jetzt bindet das System beim Start die entsperrten Partitionen anstelle der bisherigen, nun verschlüsselten Festplattenpartitionen ein.

Fazit

Es erfordert einige Schritte, um ein unverschlüsseltes OpenSuse-System in ein verschlüsseltes umzuwandeln. Sollte dabei etwas schiefgehen und das System nicht mehr starten, lässt sich das reparieren: Booten Sie das Live-System erneut und führen Sie alle beschriebenen Schritte bis zum Aufruf von chroot /mnt erneut aus. Kontrollieren Sie noch einmal alle veränderten Konfigurationsdateien und führen Sie Dracut, Grub2-mkconfig und Grub2-install erneut aus. Laufen die cryptsetup-reencrypt-Befehle ohne Fehler durch, dürfen Sie jedenfalls davon ausgehen, dass Ihre Daten noch vorhanden sind.

Haben Sie Ihr System gleich im Installer verschlüsselt, fügen Sie anhand der hier vorliegenden Tipps problemlos weitere verschlüsselte Partitionen auf neuen Speichergeräten hinzu. Gleichzeitig umgehen Sie die lästige mehrfache Passworteingabe bei verschlüsselten Systemen ohne LVM. (uba)