akopalypse.net

Block-Layer-Encryption mit dm-crypt und LUKS

Block-layer encryption, also known as “whole disk encryption”, “on-disk encryption” or “full-disk encryption” is a kind of disk encryption software or hardware which encrypts every bit of data that goes onto a disk, disk partition or disk volume of some sort (LUN, RAID Volume, ordinary disk, etc.). The term “full-disk/on-disk encryption” is often used to signify that everything on a disk is encrypted, including the programs that can encrypt bootable operating system partitions. Block-layer encryption is in contrast to filesystem-level encryption, which is a form of disk encryption where individual files or directories are encrypted by the filesystem itself. The enterprise-class block-layer encryption for Linux goes by the name dm-crypt. There is also an extensions to it called LUKS (Linux Unified Key Setup) which enables us to do fancy things like key management for example. dm-crypt and LUKS, both are free-software working together in order to provide data encryption on storage media thus allowing that what is a secret stays a secret. dm-crypt is a device-mapper and part of the Linux operating system kernel. LUKS is a hard disk encryption specification, represented by cryptsetup, its actual implementation. 1

LUKS erlaubt gleichzeitig acht verschiedene passphrases, so daß mehrere Leute ein Cryptodevice teilen können, ohne gegenseitig ihre Passwörter zu kennen.
Geht ein Passwort verloren oder ist die Integrität nicht mehr gewährleistet, kann es gelöscht und durch ein anderes ersetzt werden, ohne daß eine Neu-Verschlüsselung erforderlich wird.
Bei der Anlage des Device wird ein verschlüsselter Master Key im Header angelegt. Dieser Key entschlüsselt das Device, die passphrases entschlüsseln ausschließlich den Master Key. Daher ist eine schwache passphrase oder ein nicht ausreichend gesichertes oder umfangreiches keyfile das schwächste Glied in der Kette.

Auch brandneue Festplatten können beschädigte Sektoren haben. Wenn man vor Anlage eines verschlüsselten Gerätes einen entsprechenden Test macht, können die kaputten durch Ersatzsektoren ersetzt werden.

Mit badblocks aus dem Paket mtools kann man diese Reparatur durchführen. Dabei werden Pseudozufallszahlen geschrieben. Das dauert je nach Rechenpower und Größe der Festplatte einige Stunden!

Achtung! Die auf der Platte vorhandenen Daten werden bei dieser Aktion unwiederbringlich gelöscht!

root@device # badblocks -c 10240 -s -w -t random -v /dev/sdX

Die Optionen:

-c Zahl der Blöcke, die gleichzeitig getestet werden
-s show progress, Fortschrittsangabe in Prozent
-w write-test-mode
-n non-destructive mode

(-w und -n schließen sich aus!)
-t testpattern, entweder numerischer Wert (zwischen 0 und ULONG_MAX-1) inklusive oder random. random ist cpu-hungrig.
-v verbose mode

Man kann entweder das gesamte Device verschlüsseln oder zunächst eine Partition anlegen, die danach verschlüsselt wird. Meine Backup-Festplatten habe ich unpartitioniert gelassen.

root@device # fdisk /dev/sdX

Ein keyfile anlegen und Rechte anpassen

root@device # dd bs=4096 if=/dev/random of=/pfad/zum/key

root@device # chmod 400 /pfad/zum/key

root@device # cryptsetup luksFormat <device> <keyfile>

In diesem Beispiel also:

root@device # cryptsetup luksFormat /dev/sdX /etc/.cryptdisk/key

Das keyfile kann man sich ja nicht merken. Soll eine passphrase zur Entschlüsselung des master key benutzt werden, dann

root@device # cryptsetup --verify-passphrase luksFormat /dev/sdX

Nun kann man auf das Cryptodevice zugreifen:

root@device # cryptsetup luksOpen <device> <name>

Soll die verschlüsselte Festplatte blue heißen und wird vom Kernel unter /dev/sdX geführt:

root@device # cryptsetup luksOpen /dev/sdX blue

bzw

root@device # cryptsetup luksOpen --key-file /etc/.crypt/key /dev/sdX blue

Nachschauen, ob das Device tatsächlich gemappt ist:

$ ls -l /dev/mapper/

Jetzt kann man ein beliebiges Filesystem auf das entschlüsselte Device schreiben. Bei großen Platten, z.B. einer externen Backup-Festplatte, bietet es sich an, mit der Option -m [Zahl] die Zahl der root standardmäßig vorbehaltenen 5% aller Blöcke zu reduzieren. Auf einer Backup-Platte mit 4TB Speicher braucht root i.d.R. nicht 40GB reservierten Platz…

root@device # mkfs.ext4 (-m 0.25) /dev/mapper/blue

das man kann anschließend eingebinden kann:

root@device # mount /dev/mapper/blue <mountpoint>

Ab jetzt kann transparent auf das Device geschrieben werden.

Wird das Device nicht mehr benötigt, umount und den Cryptocontainer wieder schließen. Erst nach luksClose sind die Daten nicht mehr zugänglich!

root@device # umount /dev/mapper/blue && cryptsetup luksClose blue

Neue passphrase oder keyfile hinzufügen

root@device # cryptsetup luksAddKey --verify-passphrase /dev/sdX

bzw

root@device # cryptsetup luksAddKey /dev/sdX /pfad/zum/neuen/keyfile

Die neue passphrase bzw. das keyfile muß im folgenden Dialog mit einer gültigen passphrase bestätigt werden.

Alternativ Bestätigung mit gültigem keyfile:

root@device # cryptsetup luksAddKey /dev/sdX /pfad/zum/neuen/keyfile --key-file /etc/.crypt/key

Die Schlüsselfächer werden in aufsteigender Reihenfolge gefüllt. Die erste, bei der Einrichtung vergebene passphrase entschlüsselt über keyslot 0. Die zweite über keyslot 1 usw.

Passphrases oder keyfiles löschen

root@device # cryptsetup luksKillSlot /dev/sdX [0-7]

Wird auch das letzte Schlüsselfach geleert, sind die Daten nicht mehr zu entschlüsseln. Versehentlich kann das kaum passieren, die Entfernung des letzten Schlüssels muß nach eindrücklicher Warnung mit YES bestätigt werden.
Auch das Löschen eines Schlüssels muß man mit einem gültigen keyfile oder einer gültigen passphrase bestätigen.

Backup relevanter Informationen

Zum Header gehören sämtliche keyslots und diverse Informationen zur Beschaffenheit des Master Key. Den Header des luks-Containers sichern:

root@device # cryptsetup luksHeaderBackup /dev/sdX --header-backup-file /etc/.crypt/<header-backup>

Eine Sicherung des Headers einspielen:

root@device # cryptsetup luksHeaderRestore /dev/sdX --header-backup-file /etc/.crypt/<header-backup>

Wenn aus irgendwelchen Gründen die Partitionstabelle (falls eine erstellt wurde) beschädigt ist, sind die Daten im luks-Container nicht verloren, debianforum.
Zunächst sucht man den Beginn des Headers:

root@device # hexdump -C /dev/sdX | grep "4c 55 4b 53 ba be"

Der output ohne Partitionstabelle lautet

00000000 4c 55 4b 53 ba be 00 01  61 65 73 00 00 00 00 00  |LUKS....aes.....|

Die erste Zahl bezeichnet die Position auf der Festplatte, an der der Header beginnt.

Den Hexadezimalwert “00000000” umrechnen in einen Dezimalwert. Dabei helfen diverse Websites, z.B. diese oder diese. “00000000” kann man aber auch im Kopf von hex nach dez umrechnen: 0.

root@device # losetup -o 0 /dev/loop5 /dev/sdX

root@device # cryptsetup luksOpen /dev/loop5 rettung

Nach Eingabe der passphrase kann das gemappte Device gemountet werden:

root@device # mount /dev/mapper/rettung <mountpoint>

Wenn sich mehrere Logical Volumes auf dem Cryptodevice befinden, wirft der mount-Versuch eine Fehlermeldung:
»mount: unbekannter Dateisystemtyp „LVM2_member“«.

root@device # lvs

zeigt u.a. die Logical Volumes (LV) und zu welcher Volume Group (VG) sie gehören. Nach einer Aktivierung

root@device # vgchange -ay <volume-group>

können die einzelnen Partitionen(?)/ Logical Volumes(?) gemountet werden:

root@device # mount /dev/<volume-group>/<logical-volume> -o ro,user <mountpoint>