USB-Stick als Schlüssel für die Festplattenverschlüsselung

OpenSUSE bietet seit einigen Versionen die Möglichkeit bei der Installation die Festplatte komplett zu Verschlüsseln. In Anbetracht der großen Menge an Daten macht dies heutzutage nicht nur bei Laptops, sondern auch bei stationären Rechnern Sinn. Wird der Rechner aber als Server — ohne Tastatur und Monitor — betrieben stört hierbei allerdings die notwendige Passworteingabe beim Starten des Rechners. Glücklicherweise bietet LUKS aber die Möglichkeit diese auf einem USB-Stick zu speichern, womit auch bei solchen Maschinen ein komfortabler Start möglich ist.

Achtung: Diese für openSUSE 11.3 erstellte Anleitung funktioniert bis einschließlich openSUSE 13.1. Auf openSUSE 13.2 und openSUSE Leap 42.1 habe ich sie nicht getestet. Auf openSUSE Leap 42.2 funktioniert sie nicht mehr. Es gibt einen neuen Mechanismus, welchen ich, sobald ich ihn ausführlich getestet habe, verbloggen und hier verlinken werde.

Ist ein USB-Stick als Schlüssel sicher?

Sicherheit ist immer relativ zur Bedrohung zu sehen. Auch beim USB-Stick stellt sich also die Frage wovor er schützen soll. Beim stationär zuhause stehenden Rechner hat die Verschlüsselung vor allem eine Funktion, sie schützt die Daten wenn die betroffen Festplatten mal das eigene Haus verlassen. Hierbei gibt es im Prinzip nur zwei Fälle. Stellt sich eine Platte während der Garantiezeit als defekt heraus so erspart einem die Verschlüsselung das heutzutage sehr zeitaufwendige Löschen der Platte. Wird die Festplatte entwendet, so ist sie ohne den USB-Stick, der natürlich in diesem Fall nicht im Rechner gesteckt haben darf, auch nicht auszulesen.

Ein großer Vorteil des USB-Sticks besteht hier darin, dass er sehr lange Passwörter ermöglicht. Möchte man lange Passwörten auf klassischem Weg verwenden kommt man um ein Aufschreiben des Passworts oft auch nicht herum. Außerdem gewinnt man eine Möglichkeit die Herausgabe des Passworts zu verweigern, sollte man je dazu aufgefordert werden. Bei einem langen Passwort welches man nie getippt hat ist die Chance sich zu erinnern nicht existieren. Auch hier gilt natürlich, der USB-Stick darf dann nicht trivial dem Rechner zuzuordnen sein.

Die Anleitung

Backup

Wie bei allen Operationen an der Basis eines Systems ist auch hier das Backup zu beginn wichtig. In diesem Fall ist es wichtig den Kernel und die Initramdisk zu sichern, da es sonst, sollte man sich bei der Konfiguration der Entsperrung via USB-Stick vertun, schwer ist wieder in das verschlüsselte System zu booten.

Unter openSUSE ist es hierbei wichtig den Anfang des initrd und kernel-Namens zu ändern, da diese vom Befehl mkinitrd sonst dennoch aktualisiert werden. 

cp /boot/initrd-2.6.34-12 /boot/safe-initrd-2.6.34-12
cp /boot/vmlinuz-2.6.34-12 /boot/safe-enable-vmlinuz-2.6.34-12
Außerdem sollte man sich der Einfachheit halber gleich einen passenden Eintrag im Grub anlegen, wozu man in der Datei /boot/grub/menu.lst die passenden Zeilen einfügt: 
title SafetyNet -- openSUSE 11.3 - 2.6.34-12
    root (hd0,0)
    kernel /safe-vmlinuz-2.6.34-12 root=/dev/system/root resume=/dev/system/swap splash=silent quiet showopts vga=0x317
    initrd /safe-enable-initrd-2.6.34-12
Dadurch kann man anschließend jederzeit auch noch mit dem bei der Installation vergebenen Passwort das System starten.

Anlegen des Schlüssels

Als nächstes muss ein Schlüssel erzeugt werden. Um nicht zu viele zusätzliche Module in die Initramdisk packen zu müssen empfiehlt es sich einen Ext2-formatierten Stick zu verwenden. Dieser kann mit 
mkfs.ext2 -L keystick /dev/sdb
erzeugt werden. keystick gibt hierbei das Label des erzeugten Dateisystems an, /dev/sdb muss an den tatsächlichen Gerätenamen des USB-Sticks angepasst werden. Sollte der Stick bereits mit ext2 formatiert sein sollte dennoch ein Label gesetzt werden. 
tune2fs -L keystick /dev/sdb

Das Label kann natürlich frei gewählt werden. Es dient später zur Identifizierung des Sticks. Dies hat zwei Vorteile:

  • Der USB-Stick unabhängig von hinzugekommenen oder entfernten Datenträgern gefunden
  • Anders als bei der Identifizierung über die ID des Sticks kann man einen zweiten Stick mit gleichem Label als Backup verwenden. Ich recycle gerne nutzlose Werbegeschenke für diese Aufgabe. Sollte mal eines kaputt gehen spare ich mir das Zeitaufwendige zurückspielen des Backups der ganzen platte, da ich den Schlüssel ja noch von einem zweiten USB-Stick laden kann.

Anschließend sollte ein Passwort generieren und auf dem USB-Stick hinterlegen. Meine bevorzugte Methode ist diese: 

pwgen -s 1024 1 > /media/keystick/keyfile

Nun kann man den erzeugten Schlüssel der verschlüsselten Partition hinzufügen. Leider verhält sich LUKS leicht unterschiedlich was interaktiv eingegebene Schlüssel und Schlüsseldateien angeht. Deshalb müssen wir unseren Schlüssel "interaktiv" eingeben. Hierzu erzeugt man zunächst eine Datei welche eine Zeile mit dem bei der Installation gewählten Schlüssel und eine mit dem neuen enthält. 

cat oldkey /media/keystick/keyfile > tmp
Damit kann man nun die passenden Tastatureingaben simulieren: 
cryptsetup luksAddKey /dev/sda2 < tmp
Anschließend wird die temporäre Datei nicht mehr benötigt: 
rm tmp

Um zu testen ob der Schlüssel korrekt hinzugefügt wurde kann man probehalber einen leeren Schlüssel hinzufügen. LUKS ist schlau genug diesen Schlüssel nicht wirklich aufzunehmen: 

cryptsetup luksAddKey /dev/sda2 < /media/keystick/keyfile

Erstellen der neuen Initramdisk

Damit der Kernel bevor das Root-Verzeichnis eingebunden ist auf den USB-Stick zugreifen kann muss man sicherstellen, dass die USB-Module in der Initrandisk ist. Hierzu sollte man in openSUSE sicherstellen, dass die Variable INITRD_MODULES in /etc/sysconfig/kernel folgende Werte enthält: 
usb_storage scsi_mod

Um LUKS den Schlüssel zu übergeben benötigt man ein Skript welches ihn vom USB-Stick liest. Dies kann an einer beliebigen Stelle im Dateisystem liegen, es wird beim erstellen der Initramdisk in diese gepackt: 

#!/bin/sh

STICK=/dev/disk/by-label/keystick
FSTYPE=ext2
slumber=150
modprobe usb-storage 1>&2
modprobe scsi_mod 1>&2
mkdir /keystick 1>2&
sleep 5 1>2&

while [ $slumber -gt 0 ] && [ ! -e "$STICK" ]; do
      sleep 1
      slumber=$(( $slumber - 1 ))
done
if ! mount -t $FSTYPE -r $STICK /keystick ; then
   $( echo 'FAILED!!!' ) 1>2&
   echo ''
   exit 1
fi

cat /keystick/keyfile


umount /keystick 1>2&

Damit LUKS weiß, dass es den Wert von einem Skript erhält muss die Datei /etc/crypttab angepasst werden: 

cr_sda2         /dev/sda2       none    initrd,luks,keyscript=/root/keyscript.sh
Hierbei sind zwei Dinge zu beachten:
  • Ist keyscript gesetzt ist keine interaktive Eingabe mehr möglich. Deshalb sollte man die alte Initramdisk (welche die alte Konfiguration enthält) vorher sichern.
  • Der Wert initrd ist notwendig, da openSUSE bei der Generierung der Initramdisk sonst nicht merkt, dass es das Keyscript mit einpacken muss.

Zu guter letzt kann durch den Aufruf von mkinitrd die neue Initramdisk erstellt werden. Ein Neustart sollte den Schlüssel dann vom USB-Stick lesen anstatt diesen interaktiv zu erwarten.

Hat man die neue Konfiguration hinreichen getestet kann man den bei der Installation vergebenen Schlüssel aus LUKS entfernen und die gesicherte Initramdisk löschen.

Eine Anmerkung zur Distributionsaktualisierung

Diese Anleitung habe ich ursprünglich anhand von openSUSE 11.3 erstellt. Sie gilt aber auch für aktuellere Versionen bis 13.1. Auf openSUSE Leap 42.2 funktionierte diese methode aber nicht! Auf neuere Versionen kann man über das normale DVD-Update aktualisieren. Hierbei muss man allerdings die verschlüsselte Partition über einen eingetippten Schlüssel öffnen. Hierzu hilft es den bei der initialien Installation verwendeten Schlüssel nicht deaktiviert zu haben, oder aber temporär per cryptsetup luksAddKey einen kürzeren Schlüssel hinzuzufügen. Getestet habe ich auf diese Weise das Update von 11.3 auf 11.4 und von 11.4 auf 12.1. Der Installer warnt einen zwar, dass es Probleme geben kann, wenn man Partitionen per Kernel Device Name mountet, dies hat sich aber bisher nicht als Problem herausgestellt.

Quellen

Da die Literatur — was openSUSE angeht — zu diesem Thema leider noch sehr dürftig ist habe ich mich vieler Quellen bedient, von denen ich hier nur die wichtigsten nennen möchte: