LUKS Header auf USB-Stick verschieben (für Debian Jessie): Unterschied zwischen den Versionen
K |
|||
| Zeile 3: | Zeile 3: | ||
Wir gehen davon aus, dass Sie eine LUKS verschlüsselte Festplatte haben, deren Header Sie entfernen und stattdessen von einem USB Stick aus benutzen wollen. Für Geräte, die erst nach dem Bootprozess entschlüsselt werden, ist dies im Allgemeinen kein Problem. Soll dagegen von dem Gerät gebootet werden, ist der Vorgang etwas komplizierter und wird hier beschrieben. | Wir gehen davon aus, dass Sie eine LUKS verschlüsselte Festplatte haben, deren Header Sie entfernen und stattdessen von einem USB Stick aus benutzen wollen. Für Geräte, die erst nach dem Bootprozess entschlüsselt werden, ist dies im Allgemeinen kein Problem. Soll dagegen von dem Gerät gebootet werden, ist der Vorgang etwas komplizierter und wird hier beschrieben. | ||
| − | + | == FAQ == | |
| − | == Wozu sollte ich den Header von der Festplatte entfernen? == | + | ==== Wozu sollte ich den Header von der Festplatte entfernen? ==== |
LUKS-verschlüsselte Partitionen sind schwer zu knacken, sofern man keine Konfigurationsfehler begangen hat. Jedoch benötigt jede LUKS-Partition einen Header, in dem steht, wie genau verschlüsselt wird und wo die verschlüsselten Daten beginnen. Dieser Header ist natürlich unverschlüsselt. Selbst mit den Informationen des Headers ist eine Entschlüsselung jedoch sehr aufwendig. Aber: Seine Existenz verrät, dass verschlüsselte Daten vorliegen; und mit einem erpressten Passwort oder Schlüsselfile werden diese Daten zugänglich. Ist der Header (sowie Boot-Partition und Bootloader) aber nicht auf dem Gerät zu finden, das verschlüsselt worden ist, so sind seine Inalte nicht mehr von zufälligen Daten zu unterscheiden und eine Verschlüsselung kann abgestritten werden. Zudem benötigt ein Angreifer nun das Passwort/Schlüsselfile '''und''' den Header, man hat also nebenbei eine wirksame Zwei-Faktor-Authentifizierung eingerichtet. | LUKS-verschlüsselte Partitionen sind schwer zu knacken, sofern man keine Konfigurationsfehler begangen hat. Jedoch benötigt jede LUKS-Partition einen Header, in dem steht, wie genau verschlüsselt wird und wo die verschlüsselten Daten beginnen. Dieser Header ist natürlich unverschlüsselt. Selbst mit den Informationen des Headers ist eine Entschlüsselung jedoch sehr aufwendig. Aber: Seine Existenz verrät, dass verschlüsselte Daten vorliegen; und mit einem erpressten Passwort oder Schlüsselfile werden diese Daten zugänglich. Ist der Header (sowie Boot-Partition und Bootloader) aber nicht auf dem Gerät zu finden, das verschlüsselt worden ist, so sind seine Inalte nicht mehr von zufälligen Daten zu unterscheiden und eine Verschlüsselung kann abgestritten werden. Zudem benötigt ein Angreifer nun das Passwort/Schlüsselfile '''und''' den Header, man hat also nebenbei eine wirksame Zwei-Faktor-Authentifizierung eingerichtet. | ||
| − | == Ist das nicht unsicherer, wenn ich den Header unverschlüsselt mit mit herumtrage? == | + | ==== Ist das nicht unsicherer, wenn ich den Header unverschlüsselt mit mit herumtrage? ==== |
Der Header ist auch auf der Festplatte schon unverschlüsselt und kann direkt ausgelesen werden, sobald man physischen Zugriff auf das Gerät hat. Auf dem Header ist aber der eigentliche Schlüssel nur verschlüsselt abgelegt; verschlüsselt mit dem Passwort oder Schlüsselfile, das man angelegt hat. Um die Daten auf dem Gerät zu entziffern, muss ein Angreifer nun also den USB Stick '''und''' den Rechner in die Hände bekommen. Zwei Arten und Unsicherheit treten aber in der Tat neu auf: | Der Header ist auch auf der Festplatte schon unverschlüsselt und kann direkt ausgelesen werden, sobald man physischen Zugriff auf das Gerät hat. Auf dem Header ist aber der eigentliche Schlüssel nur verschlüsselt abgelegt; verschlüsselt mit dem Passwort oder Schlüsselfile, das man angelegt hat. Um die Daten auf dem Gerät zu entziffern, muss ein Angreifer nun also den USB Stick '''und''' den Rechner in die Hände bekommen. Zwei Arten und Unsicherheit treten aber in der Tat neu auf: | ||
* Erhält jemand den USB Stick, so kann er in Ruhe eine Brute-Force-Attacke gegen den Master Key auf dem Header fahren. Hat er den geknackt und bekommt nun physischen Zugriff auf das verschlüsselte Gerät, so sind dessen Daten sofort entziffert. Der Master Key lässt sich nur durch eine komplette Neuverschlüsselung ändern, so dass ein Verlust des USB Sticks großen Sicherungsaufwand bedeutet. | * Erhält jemand den USB Stick, so kann er in Ruhe eine Brute-Force-Attacke gegen den Master Key auf dem Header fahren. Hat er den geknackt und bekommt nun physischen Zugriff auf das verschlüsselte Gerät, so sind dessen Daten sofort entziffert. Der Master Key lässt sich nur durch eine komplette Neuverschlüsselung ändern, so dass ein Verlust des USB Sticks großen Sicherungsaufwand bedeutet. | ||
* Files auf einem USB-Stick sind volatiler und die Gefahr einer unabsichtlichen Zerstörung des Headers größer als zuvor. Um dem zu begegnen, schreiben wir den Header nicht als Datei oder in die initramfs auf den Stick, sondern in einen unpartitionierten Bereich. Dort kann nur absichtlich geschrieben oder gelesen werden. Wie zuvor aber auch, ist es empfehlenswert, ein Backup des Headers zu haben. | * Files auf einem USB-Stick sind volatiler und die Gefahr einer unabsichtlichen Zerstörung des Headers größer als zuvor. Um dem zu begegnen, schreiben wir den Header nicht als Datei oder in die initramfs auf den Stick, sondern in einen unpartitionierten Bereich. Dort kann nur absichtlich geschrieben oder gelesen werden. Wie zuvor aber auch, ist es empfehlenswert, ein Backup des Headers zu haben. | ||
| − | == Warum kann ich nicht einfach die header option in der crypttab benutzen? == | + | ==== Warum kann ich nicht einfach die header option in der crypttab benutzen? ==== |
Debian Jessie benutzt beim Booten nicht die normale cryptsetup-Binary, sondern "systemd-cryptsetup", eine Version, die im Bootvorgang sicherer sein soll. Momentan ist die Übergabe der "header="-Option dafür nicht implementiert. | Debian Jessie benutzt beim Booten nicht die normale cryptsetup-Binary, sondern "systemd-cryptsetup", eine Version, die im Bootvorgang sicherer sein soll. Momentan ist die Übergabe der "header="-Option dafür nicht implementiert. | ||
Wir laden deshalb die später benutzte cryptsetup-Binary nach und benutzen sie mit der Header-Option während der intitramfs-Phase. | Wir laden deshalb die später benutzte cryptsetup-Binary nach und benutzen sie mit der Header-Option während der intitramfs-Phase. | ||
| − | == Was genau ist unsere Strategie? == | + | ==== Was genau ist unsere Strategie? ==== |
Wir schreiben ein Shellskript, das für die Entschlüsselung unter Benutzung des entfernten Headers sorgt. | Wir schreiben ein Shellskript, das für die Entschlüsselung unter Benutzung des entfernten Headers sorgt. | ||
| − | Die Disk-Entschlüsselung startet mit dem Aufruf von cryptroot. Dies geschieht als letztes Script im Ordner /usr/share/initramfs-tools/scripts/local-top. Um dem zuvor zu kommen, legen wir unser Shellskript in diesen Ordner. | + | Die Disk-Entschlüsselung startet mit dem Aufruf von cryptroot. Dies geschieht als letztes Script im Ordner <nowiki>/usr/share/initramfs-tools/scripts/local-top</nowiki>. Um dem zuvor zu kommen, legen wir unser Shellskript in diesen Ordner. |
Über einen Hook sorgen wir dafür, dass dem Shellskript die normalen cryptsetup und vgchange zur Verfügung stehen. | Über einen Hook sorgen wir dafür, dass dem Shellskript die normalen cryptsetup und vgchange zur Verfügung stehen. | ||
| Zeile 25: | Zeile 25: | ||
== Die Anleitung Schritt für Schritt == | == Die Anleitung Schritt für Schritt == | ||
| + | Wir gehen im Folgenden davon aus, dass die verschlüsselte Partition <nowiki>/dev/sda5</nowiki> ist und der USB Stick unter <nowiki>/dev/sdb</nowiki> zu finden ist. Bitte passen Sie die unten folgenden Schritte Ihrer Situation entsprechend an. Für alle Schritte bnötigen Sie Administratorrechte. Gegebenenfalls müssen Sie daher <nowiki>sudo</nowiki> vor die entsprechenden Befehle schreiben. | ||
| + | Um herauszufinden, wie die Gerätedateien tatsächlich heißen, kann man den Befehl <nowiki>lsblk</nowiki> benutzen. LUKS-entschlüsselte Geräte sind die Eltern der Geräte vom Typ <nowiki>crypt</nowiki>. | ||
| + | |||
| + | ==== Verzeichnisse vorbereiten ==== | ||
| + | Wir legen das Verzeichnis an, dass unsere Bootkonfiguration ergänzen soll. | ||
| + | <nowiki>mkdir /etc/remoteheader</nowiki> | ||
| + | |||
==== Vorbereitung des USB Sticks ==== | ==== Vorbereitung des USB Sticks ==== | ||
| + | Wir exportieren zunächst den Header | ||
| + | <nowiki>cryptsetup luksHeaderBackup /dev/sda5 --header-backup-file /etc/decryptkeydevice/header</nowiki> | ||
Version vom 29. März 2016, 09:21 Uhr
Inhaltsverzeichnis
Ausgangssituation und Ziel
Wir gehen davon aus, dass Sie eine LUKS verschlüsselte Festplatte haben, deren Header Sie entfernen und stattdessen von einem USB Stick aus benutzen wollen. Für Geräte, die erst nach dem Bootprozess entschlüsselt werden, ist dies im Allgemeinen kein Problem. Soll dagegen von dem Gerät gebootet werden, ist der Vorgang etwas komplizierter und wird hier beschrieben.
FAQ
Wozu sollte ich den Header von der Festplatte entfernen?
LUKS-verschlüsselte Partitionen sind schwer zu knacken, sofern man keine Konfigurationsfehler begangen hat. Jedoch benötigt jede LUKS-Partition einen Header, in dem steht, wie genau verschlüsselt wird und wo die verschlüsselten Daten beginnen. Dieser Header ist natürlich unverschlüsselt. Selbst mit den Informationen des Headers ist eine Entschlüsselung jedoch sehr aufwendig. Aber: Seine Existenz verrät, dass verschlüsselte Daten vorliegen; und mit einem erpressten Passwort oder Schlüsselfile werden diese Daten zugänglich. Ist der Header (sowie Boot-Partition und Bootloader) aber nicht auf dem Gerät zu finden, das verschlüsselt worden ist, so sind seine Inalte nicht mehr von zufälligen Daten zu unterscheiden und eine Verschlüsselung kann abgestritten werden. Zudem benötigt ein Angreifer nun das Passwort/Schlüsselfile und den Header, man hat also nebenbei eine wirksame Zwei-Faktor-Authentifizierung eingerichtet.
Ist das nicht unsicherer, wenn ich den Header unverschlüsselt mit mit herumtrage?
Der Header ist auch auf der Festplatte schon unverschlüsselt und kann direkt ausgelesen werden, sobald man physischen Zugriff auf das Gerät hat. Auf dem Header ist aber der eigentliche Schlüssel nur verschlüsselt abgelegt; verschlüsselt mit dem Passwort oder Schlüsselfile, das man angelegt hat. Um die Daten auf dem Gerät zu entziffern, muss ein Angreifer nun also den USB Stick und den Rechner in die Hände bekommen. Zwei Arten und Unsicherheit treten aber in der Tat neu auf:
- Erhält jemand den USB Stick, so kann er in Ruhe eine Brute-Force-Attacke gegen den Master Key auf dem Header fahren. Hat er den geknackt und bekommt nun physischen Zugriff auf das verschlüsselte Gerät, so sind dessen Daten sofort entziffert. Der Master Key lässt sich nur durch eine komplette Neuverschlüsselung ändern, so dass ein Verlust des USB Sticks großen Sicherungsaufwand bedeutet.
- Files auf einem USB-Stick sind volatiler und die Gefahr einer unabsichtlichen Zerstörung des Headers größer als zuvor. Um dem zu begegnen, schreiben wir den Header nicht als Datei oder in die initramfs auf den Stick, sondern in einen unpartitionierten Bereich. Dort kann nur absichtlich geschrieben oder gelesen werden. Wie zuvor aber auch, ist es empfehlenswert, ein Backup des Headers zu haben.
Warum kann ich nicht einfach die header option in der crypttab benutzen?
Debian Jessie benutzt beim Booten nicht die normale cryptsetup-Binary, sondern "systemd-cryptsetup", eine Version, die im Bootvorgang sicherer sein soll. Momentan ist die Übergabe der "header="-Option dafür nicht implementiert. Wir laden deshalb die später benutzte cryptsetup-Binary nach und benutzen sie mit der Header-Option während der intitramfs-Phase.
Was genau ist unsere Strategie?
Wir schreiben ein Shellskript, das für die Entschlüsselung unter Benutzung des entfernten Headers sorgt. Die Disk-Entschlüsselung startet mit dem Aufruf von cryptroot. Dies geschieht als letztes Script im Ordner /usr/share/initramfs-tools/scripts/local-top. Um dem zuvor zu kommen, legen wir unser Shellskript in diesen Ordner. Über einen Hook sorgen wir dafür, dass dem Shellskript die normalen cryptsetup und vgchange zur Verfügung stehen.
Das Shellskript lädt eine Konfigurationsdatei, die dem Skript sagt, wo der Header auf dem Stick zu finden ist - in einem unpartitionierten Bereich des Sticks - und lädt ihn in das temporäre Filesystem der initramfs. Dort wird er zum Entschlüsseln benutzt. Im Kontrast dazu, den Header direkt in das initrd.img-File zu schreiben, hat das die Vorteile, dass der Header nicht auf dem Filesystem vorgehalten werden muss (weder in der Bootpartition noch in den verschlüsselten Partitionen), um Kernel-Updates reibungslos zu erlauben. Der Header wird nur kurz während des Bootvorgangs in den RAM des Rechners geladen und ist ansonsten nirgends auf dem Filesystem zu finden.
Die Anleitung Schritt für Schritt
Wir gehen im Folgenden davon aus, dass die verschlüsselte Partition /dev/sda5 ist und der USB Stick unter /dev/sdb zu finden ist. Bitte passen Sie die unten folgenden Schritte Ihrer Situation entsprechend an. Für alle Schritte bnötigen Sie Administratorrechte. Gegebenenfalls müssen Sie daher sudo vor die entsprechenden Befehle schreiben. Um herauszufinden, wie die Gerätedateien tatsächlich heißen, kann man den Befehl lsblk benutzen. LUKS-entschlüsselte Geräte sind die Eltern der Geräte vom Typ crypt.
Verzeichnisse vorbereiten
Wir legen das Verzeichnis an, dass unsere Bootkonfiguration ergänzen soll.
mkdir /etc/remoteheader
Vorbereitung des USB Sticks
Wir exportieren zunächst den Header
cryptsetup luksHeaderBackup /dev/sda5 --header-backup-file /etc/decryptkeydevice/header
