Der Linux-Kernel verschlüsselt Dateisysteme – nach aktuellem Wissensstand so sicher, dass niemand ohne das Passwort an die Daten gelangt. Wir zeigen, wie Sie diese Technik nutzen.

Wer denkt, nach dem Ausschalten des automatischen Logins seien seine Daten ohne Kenntnis des Benutzerpassworts sicher, der vergisst, dass nach dem Booten eines Live-Systems (wie eines Installationsmediums von OpenSuse oder Ubuntu) per USB-Stick voller Root-Zugriff auf das System besteht. Ein rein lesender Zugriff lässt sich hinterher nicht einmal mehr erkennen.

Erst eine Verschlüsselung der Speichergeräte sperrt Neugierige auch bei physischem Zugang zum Rechner aus: Der Angreifer kann dann die Speichermedien zwar noch auslesen, doch ohne den passenden Schlüssel bekommt er nur Folgen zufälliger Bytes zu Gesicht – die verschlüsselten Daten, die erst das Passwort wieder lesbar macht. Ist das System entsperrt, hilft eine Festplattenverschlüsselung übrigens nicht länger gegen Angriffe, ihr Schutz greift nur bei ausgeschaltetem Computer.

In den Genuss der Festplattenverschlüsselung kommen OpenSuse-Anwender denkbar leicht: Der Installer [1] bietet bereits bei der Partitionierung der Festplatten im Geführten Setup an, die Option Festplattenverschlüsselung aktivieren zu setzen (Abbildung 1). So lange Sie sonst nichts weiter antasten, ändert sich außer der Verschlüsselung nichts an der Partitionierung: Das System inklusive Home liegt in einem einzigen Btrfs-Dateisystem. Auch das Systemschnappschusswerkzeug Snapper [2] funktioniert genauso wie auf unverschlüsselten Systemen.

Abbildung 1: Der OpenSuse-Installer bietet im Geführten Setup der Plattenpartitionierung die Option Enable Disk Encryption an.

Komfortproblem

In der Praxis stört dabei allerdings, dass Sie im Standard-Setup beim Systemstart das Verschlüsselungspasswort zwei Mal eingeben müssen – zuerst an der rudimentären Eingabeaufforderung des Bootloaders Grub, und ein weiteres Mal beim Hochfahren des eigentlichen Systems (Abbildung 2). Der Bootloader entsperrt die Systempartition und lädt den Linux-Kernel. Der startet dann die Kernkomponente Systemd. Eine Weitergabe des Passworts vom Bootloader an das eigentliche Linux-System ist technisch nicht vorgesehen.

Abbildung 2: In der Praxis nervig: Das vom OpenSuse-Installer eingerichtete Setup fragt beim Systemstart zwei Mal nach derselben Festplatten-Passphrase.

Allerdings gibt es einen Workaround. Er besteht darin, dass Sie in der beim Booten als Erstes geladenen Initial RAM Disk (Initrd) eine Schlüsseldatei ablegen, mit dem das System sich anstelle eines eingetippten Passworts entsperren lässt (Abbildung 3). Die Initrd enthält unter anderem die Dateisystemtreiber für das Root-Dateisystem, die der Kernel sich ja mangels Treiber nicht direkt von dort besorgen kann, und nun zusätzlich die sonst nicht vorhandene Schlüsseldatei.

Abbildung 3: Eine Weitergabe des abgefragten Passworts zwischen Bootloader und zweiter Boot-Phase ist technisch nicht vorgesehen. Das Durchreichen einer Schlüsseldatei mittels Initrd funktioniert jedoch.

Auch wenn Ihnen diese technischen Anmerkungen kompliziert erscheinen, gelingt die Einrichtung des beschriebenen Verfahrens kinderleicht, indem Sie sich an die geschilderte Vorgehensweise halten. Dazu erzeugen Sie zunächst mit dem Befehl aus der ersten Zeile von Listing 1 eine Schlüsseldatei. Das Kommando füllt die versteckte Datei .keyfile im Stammverzeichnis / mit einer 1024 Stellen langen, zufälligen Zeichenfolge.

$ sudo dd if=/dev/urandom of=/.keyfile bs=1024 count=1
$ sudo cryptsetup luksAddKey /dev/sda2 /.keyfile
$ sudo cryptsetup luksAddKey /dev/sda3 /.keyfile

Es wäre möglich, hier erneut das bei der Installation angegebene Passwort zu verwenden, doch fördert die Sicherheit, wenn in der im laufenden System mit Adminstratorrechten lesbaren Datei viele kryptische Zeichen stehen, die sich niemand so einfach merken kann. Apropos Administratorrechte: Stellen Sie als Root mit chmod 600 /.keyfile sicher, dass tatsächlich nur Root diese Datei lesen kann.

Das unter Linux verbreitete und auch von OpenSuse genutzte Verschlüsselungsverfahren Linux Unified Key Setup (LUKS [3]) erlaubt es, einem verschlüsselten Dateisystem bis zu acht Schlüssel zuzuweisen. So ist es möglich, das bei der Installation gewählte Passwort für die manuelle Eingabe am Bootloader (Abbildung 2) beizubehalten und das Key-File als zweiten Schlüssel hinzuzufügen. Das erledigt der Befehl aus der zweiten Zeile von Listing 1 – allerdings nur dann, wenn das Root-Dateisystem tatsächlich in der zweiten Partition (Ziffer 2 in /dev/sda2) der ersten Festplatte (Buchstabe a in /dev/sda2) liegt, wie es bei Standardinstallationen der Fall ist.

Auf älteren BIOS-Systemen oder solchen, die im BIOS-Kompatibilitätsmodus laufen, enthält /dev/sda1 eine winzige BIOS-Partition für den Bootloader, das Wurzelverzeichnis liegt in /dev/sda2. Bei neueren UEFI-Systemen liegt in der ersten Partition (/dev/sda1) die EFI-Partition. Gewissheit bringt der Aufruf sudo lsblk -fs: Achten Sie darauf, von welchem Device-File (wie sda2) der Ast cr_root ausgeht, und ersetzen Sie gegebenenfalls sda2 im Cryptsetup-Aufruf durch den bei Ihrem System passenden Namen (Abbildung 4).

Abbildung 4: Das verschlüsselte Root-Dateisystem (cr_root) und die verschlüsselte Auslagerungspartition (cr_swap) liegen bei einer Standard-Installation von OpenSuse in den Partitionen sda2 und sda3.

In der Regel legt der Installer auch eine verschlüsselte Auslagerungspartition an, die bei knappem Arbeitsspeicher oder Suspend-to-Disk zum Einsatz kommt. Verschlüsselt ist sie deswegen, weil der im laufenden System im Arbeitsspeicher vorgehaltene Krypto-Schlüssel dort landen kann. Ihn zu finden, ist zwar nicht trivial, doch für Experten möglich.

Das Device-File der Auslagerungspartition bildet den Ausgangspunkt des Zweigs cr_swap im Lsblk-Aufruf. Es heißt meist sda3. Wiederholen Sie den vom Root-Dateisystem bekannten Cryptsetup-Aufruf nun mit dem passenden Wert, also in der Regel so wie in der letzten Zeile von Listing 1.

Scharfschalten

Nun lassen sich die System- und die Auslagerungspartition mit dem Keyfile entsperren, doch damit Systemd das beim Booten überhaupt versucht, müssen Sie die nur für Root sichtbare Datei /etc/crypttab anpassen. In einem Standard-OpenSuse-System enthält sie die zwei Zeilen cr_root UUID=[...] und cr_swap UUID=[...]. Die Auslassungspunkte stehen für systemspezifische, 36 Zeichen lange Hashes. Fügen Sie beiden Zeilen mit einem Leerzeichen Abstand nach den Hashes den Text /.root.key hinzu.

Bis jetzt liegt das Keyfile nur im Wurzelverzeichnis /. In der Initrd, von der aus es zum Entsperren des Root-Dateisystems ausgelesen werden soll, ist es noch nicht zu finden. Das ändert sich, sobald Sie als Root dem Verzeichnis /etc/dracut.conf.d/ eine Datei 99-root-key.conf mit dem Inhalt install_items+=" /.root.key " hinzufügen und danach die Initrd als Root mit mkinitrd neu erzeugen.

Damit im laufenden System normalen Anwendern auch die Initrd-Dateien verborgen bleiben, die jetzt ja das Festplattenpasswort enthalten, ändern Sie noch die Zugriffsrechte des Ordners /boot/. Unter OpenSuse passen Sie dazu die Datei /etc/permissions.local an, damit die strikteren Zugriffsrechte permanent erhalten bleiben. Sie fügen der Datei die Zeile /boot/ root:root 700 hinzu und wenden die Veränderung mit chkstat --system --set an. Nun sollte das System nach einmaliger Eingabe des Festplattenpassworts ohne weitere Rückfrage starten.

Nachrüsten

Viele OpenSuse-Anwender haben das System ohne Verschlüsselung installiert und fragen sich nun, ob sich bestehende Setups nachträglich verschlüsseln lassen. Tatsächlich ist das möglich, auch wenn man im Internet oft anderslautende Aussagen findet. Ganz trivial fällt der Umbau jedoch nicht aus: Man muss dazu unter anderem das Rettungssystem von der OpenSuse-Installations-DVD [1] starten.

Sollte während der Verschlüsselung das System abstürzen, gehen alle Daten verloren. Ein Backup der Daten im Home ist deshalb zwingende Voraussetzung. Wer nicht darauf vorbereitet ist, das System notfalls nach einem (wenn auch unwahrscheinlichen) Fehlschlag neu zu installieren, der braucht auch ein Backup der Root-Partition. Ein generell unter Linux einsetzbares Verfahren erläutert ein Artikel aus dem Arch-Linux-Wiki [4].

Starten Sie zunächst das Rettungssystem des OpenSuse-Installationsmediums, indem Sie es von der DVD oder einem USB-Stick booten. Im Boot-Menü wählen Sie More … | Rescue System, und loggen Sie sich nach dessen Start ohne Passwort als Root ein.

Wie erwähnt liegt die Hauptsystempartition bei OpenSuse meist in der zweiten Partition der ersten Festplatte. Das zugeordnete Hardware-Gerät lässt sich mit /dev/sda2 ansprechen, was der schon angesprochene Aufruf von lsblk -fs (Abbildung 4) verifiziert. Der Artikel geht im Folgenden von /dev/sda2 aus; gegebenenfalls müssen Sie sda2 durch den selbst herausgefundenen Wert ersetzen.

Den ersten Schritt bildet das Verschlüsseln der Hauptsystempartition. Derzeit kann die stabile Version des Bootloaders Grub2 nur mit LUKS1-Verschlüsselung umgehen. Die lässt sich jedoch nur einem nicht in Benutzung befindlichem Dateisystem hinzufügen. Daher gelingt der Vorgang erst nach dem Start eines externen Rettungssystems. Beim neueren LUKS2 wäre hingegen sogar eine Online-Verschlüsselung möglich.

Btrfs-Dateisysteme, wie Sie OpenSuse standardmäßig nutzt, lassen sich nur in eingehängtem Zustand vergrößern oder verkleinern: mount /dev/sda2 /mnt mountet das Root-System unter /mnt, btrfs resize -32M /mnt/ verkleinert es dann um 32 MByte, also sicherheitshalber ein paar MByte mehr als nötig.

Zum Verschlüsseln müssen Sie das Dateisystem mit umount /mnt wieder aushängen. Mit dem Kommando aus Listing 2 verschlüsseln Sie es schließlich (Abbildung 5). Dieser Vorgang dauert bei einer OpenSuse-Standardinstallation ohne weitere Daten im Home, die etwa 23 GByte Daten umfasst, rund zehn Minuten, bei einem größeren System entsprechend länger. Bevor Cryptsetup loslegt, fragt es nach der Passphrase, mit der Sie Ihr System zukünftig entsperren.

# cryptsetup-reencrypt /dev/sda2 --new --reduce-device-size 4096S

Abbildung 5: Das Verschlüsseln einer bisher unverschlüsselten Partition geht zügiger über die Bühne als das Zurückspielen eines Backups in ein neu erstelltes verschlüsseltes Dateisystem.

Schlüsselfertig

Nach Abschluss des Vorgangs entsperren Sie die nun verschlüsselte Partition erstmals mit cryptsetup open /dev/sda2 cr_root und der eben gewählten Passphrase. mount /dev/mapper/cr_root /mnt hängt sie unter /mnt ein, sodass Sie dann mit ls /mnt prüfen, ob Ihre Daten wie erwartet dort vorhanden sind.

Auch eine Swap-Partition, wie Sie der OpenSuse-Installer gewöhnlich auf der Partition /dev/sda3 anlegt, muss wie erwähnt für ein sicheres System verschlüsselt werden. Bei ihr braucht aber der bisherige Inhalt nicht erhalten zu bleiben, denn er geht nach jedem Reboot ohnehin verloren.

Das Einfachste ist daher, die Swap-Partition neu zu formatieren. Es lohnt sich dennoch, deren bestehende UUID wiederzuverwenden. Das erspart ein Anpassen von /etc/fstab. Sichern Sie die UUID darum mit dem Kommando aus der ersten Zeile von Listing 3 in einer Datei. Anschließend formatieren Sie zunächst die Swap-Partition als LUKS-Container (zweite Zeile), wobei Sie das schon für die Root-Partition genutzte Passwort verwenden. Dann entsperren Sie die Partition (Zeile 3).

$ blkid -o value /dev/vda3 | head -n1 > tmpblkid
$ cryptsetup luksFormat --type luks1 /dev/sda3
$ cryptsetup open /dev/sda3 cr_swap
$ mkswap -U $(cat tmpblkid) /dev/mapper/cr_swap

Fügen Sie nun das Swap-Dateisystem hinzu (Zeile 4). Die Command Substitution $(cat tmpblkid) nach dem Parameter -U wendet dabei wieder die gesicherte UUID an, sodass das System den Auslagerungsbereich beim Start findet – wenn er denn entsperrt ist (doch dazu später mehr).

Startrampe

Als Nächstes gilt es, den Bootloader für den Start vom nun verschlüsselten Dateisystem anzupassen. Dazu binden Sie einige Systemverzeichnisse des laufenden Rettungssystems über das unter /mnt eingehängte Dateisystem ein (Listing 4). Das letzte Kommando gilt nur für UEFI-Systeme. Sie erkennen ein solches daran, dass findmnt /boot/efi einen Wert zurückgibt.

$ mount -o bind /dev /mnt/dev
$ mount -o bind /sys /mnt/sys
$ mount -t proc /proc /mnt/proc
$ mount -o bind /var/ /mnt/var/
### nur UEFI, nicht bei BIOS:
$ mount /dev/sda1 /mnt/boot/efi

Der Aufruf von chroot /mnt macht das /mnt-Verzeichnis nun für den aktuellen Konsolen-Prompt temporär zum Wurzelverzeichnis /. Alle dort aufgerufenen Programme merken nicht mehr, dass sie in der Rettungsumgebung ablaufen, und funktionieren, als würden sie in Ihrem eigentlichen OpenSuse-System laufen.

Passen Sie mit nano /etc/default/grub die Grub-Basiskonfiguration an. Suchen Sie in der Datei die Variable GRUB_ENABLE_CRYPTODISK, und verändern Sie deren Wert zu y. Mit [Strg]+[O][Strg]+[X] speichern Sie die Anpassung und schließen den Editor. Dann erzeugen Sie die eigentliche Grub-Konfiguration mit folgendem Kommando:

§§bonumber
$ grub2-mkconfig -o /boot/grub2/grub.cfg

Anschließend installieren Sie den Bootloader mit grub2-install /dev/sda neu. Falls Sie sda2 durch eine mit sdb oder sdc beginnende Zeichenkette ersetzen mussten – sprich: wenn Sie von der zweiten oder dritten Platte booten – müssen Sie auch hier sda entsprechend abändern.

Nun legen Sie noch die Datei /etc/crypttab an, die uns bei der Anpassung eines verschlüsselt installierten Systems schon begegnet ist, die in einer unverschlüsselten Installation jedoch fehlt. Sie hat dort vor der im ersten Teil des Artikels vorgeschlagenen Anpassung einen Inhalt wie in Abbildung 6 gezeigt.

Abbildung 6: Die Datei /etc/crypttab enthält vor dem Einbinden des im ersten Artikelteil vorgeschlagenen Key-Files lediglich zwei Zeilen. In der ersten Spalte steht der Device-Name in /dev/mapper/ (siehe Mount-Befehl weiter oben), in der zweiten eine individuelle UUID.

Die für Ihr System geltenden 36 Zeichen langen Hashes für die UUIDs finden Sie mit blkid /dev/sda2 und blkid /dev/sda3 heraus (sofern sda2 und sda3 auf die Hauptsystem- und die Auslagerungspartition deuten). Da es auf der Konsole keine Zwischenablage gibt, erzeugen Sie mit den Kommandos aus Listing 5 zunächst eine Vorform der Datei, die nur die Hashes enthält.

$ blkid -o value /dev/vda2 | head -n1 >> /etc/crypttab
$ blkid -o value /dev/vda3 | head -n1 >> /etc/crypttab

Diese in das im Listing genannte Format zu erweitern, stellt dann kein Problem mehr dar. Achten Sie jedoch darauf, die von blkid ausgegebenen Anführungszeichen um die UUID in /etc/crypttab zu entfernen. Auch muss nach den zwei Zeilen ein Zeilenumbruch folgen.

Damit die Datei schon im frühen Bootvorgang zur Verfügung steht, rufen Sie noch mkinitrd auf. Eine neue Konfigurationsdatei wie im ersten Teil des Artikels ist hier nicht erforderlich: /etc/crypttab wird automatisch in die Initrd aufgenommen, wenn die Datei vorhanden ist.

Ihr System sollte nun genau wie nach Auswahl der Option Enable Disk Encryption im Installer nach zweimaliger Abfrage einer Passphrase starten. Da es sich technisch im selben Zustand befindet wie nach einer verschlüsselten Standardinstallation, lässt sich auch der im ersten Abschnitt vorgestellte Workaround zur Vermeidung der doppelten Eingabe anwenden.

Sicher!

Um private Daten vor neugierigen Blicken zu schützen, sollten zumindest Nutzer von mobilen Computern nicht auf Festplattenverschlüsselung verzichten. Das Einrichten bei der Installation erfordert nur wenige zusätzliche Mausklicks. Auch ein nachträgliches Verschlüsseln gelingt, wenngleich mit größerem Aufwand.

Der Linux-Kernel bringt bereits alle nötigen Funktionen zur Verschlüsselung mit. Das Mehr an Sicherheit kostet lediglich einige Prozent Performance bei Lese- und Schreiboperationen beziehungsweise eine dabei erhöhte CPU-Last. Wie stark die Verschlüsselung das System ausbremst, lässt sich schwer vorhersagen: Das hängt vom Verhältnis der Platten-Performance zur CPU-Geschwindigkeit ab und macht sich am ehesten bemerkbar, wenn hohe Prozessorlast und umfangreiche Lese- und Schreibzugriffe zusammenfallen.

Zu guter Letzt noch ein Hinweis: In der OpenSuse-Standardeinstellung fährt ein Notebook nach dem Zuklappen in den Standby-Modus (Suspend-to-RAM), in dem die Speichergeräte offenbleiben. Da dies den Sicherheitsgewinn einer Verschlüsselung negiert, sollten Sie stattdessen, wie in Abbildung 7 für die KDE-Systemeinstellungen zu sehen, den Ruhezustand (Suspend-to-Disk) wählen. Er fragt nach dem Aufwachen erneut nach der Platten-Passphrase. (cla)

Abbildung 7: Zur Sicherheit eines mobilen Geräts mit verschlüsselten Datenträgern gehört auch, dass das Herunterklappen des Bildschirms mit dem Ruhezustand die Festplatten versperrt, statt sie im Standby-Modus unversperrt zu lassen.