Festplatte verschlüsseln 2006: dm-crypt statt Cryptoloop

Zusammenfassung

Im September 2006 habe ich meine Home-Partition von Cryptoloop auf dm-crypt umgestellt, das mit dem Device Mapper im Kernel 2.6 kam. Die Partition wurde mit cryptsetup im einfachen Modus ohne Header eingebunden, wahlweise per Kennwort oder per Schlüsseldatei auf einem USB-Stick, und ein Init-Skript mountete sie beim Start. Dieser Beitrag aus meinem alten Blog zeigt das Vorgehen von damals, die gemessenen Leistungseinbußen und warum man heute LUKS2 verwendet.

Warum der Wechsel

Bis 2006 lagen meine Daten in Partitionen, die mit Cryptoloop verschlüsselt waren, also über ein Loop-Device mit eingebauter Verschlüsselung. Der Kernel 2.6 brachte mit dem Device Mapper und dessen Crypt-Ziel einen saubereren Weg: dm-crypt legt eine verschlüsselte Schicht zwischen Partition und Dateisystem, ohne Umweg über Loop-Geräte.

Dazu kam ein Sicherheitsgrund. 2004 wurden Schwächen in der Berechnung der Initialisierungsvektoren bekannt (CVE-2004-2135 für Cryptoloop, CVE-2004-2136 für dm-crypt): Bei vorhersagbaren Vektoren kann ein Angreifer mit präparierten Dateien, sogenannten Wasserzeichen, nachweisen, dass bestimmte Daten auf der Platte liegen, ohne den Schlüssel zu kennen. dm-crypt bot mit ESSIV ein Verfahren, das die Vektoren aus dem Schlüssel ableitet und damit unvorhersagbar macht. Genau das habe ich verwendet.

Kernel und Werkzeuge

Ich habe alles unter Gentoo durchgespielt. Im Kernel mussten der Device-Mapper-Support, das Crypt-Ziel und AES aktiviert sein:

Device Drivers -> Multi-device support (RAID and LVM)
  [*] Multiple devices driver support (RAID and LVM)
  <*>   Device mapper support
  <*>     Crypt target support
Cryptographic options
  <*>   AES cipher algorithms (i586)

Dazu kamen cryptsetup und für die Schlüsseldatei die sharutils. Vor der Verschlüsselung habe ich die Partition einmal mit Zufallsdaten überschrieben, damit sich belegte und freie Bereiche später nicht unterscheiden lassen:

emerge sys-fs/cryptsetup app-arch/sharutils
shred --verbose --iterations=1 /dev/sda9

Kennwort oder Schlüsseldatei

Für den Zugang gab es zwei sinnvolle Wege. Kennwort und Schlüsseldatei zu kombinieren hielt ich damals für doppelt gemoppelt: Kommt niemand an die Datei, braucht sie kein zusätzliches Kennwort, und eine Kette ist nur so stark wie ihr schwächstes Glied.

# mit Kennwort
cryptsetup -c aes-cbc-essiv:sha256 -s 256 -y create home /dev/sda9

# mit Schlüsseldatei auf dem USB-Stick
cryptsetup -c aes-cbc-essiv:sha256 -s 256 \
  -d /mnt/usbstick/crypt_keys/rechnername_partition.key create home /dev/sda9

# Dateisystem anlegen und mounten
mkreiserfs /dev/mapper/home
mount /dev/mapper/home /home

Damit die Partition nicht nach jedem Neustart von Hand eingebunden werden musste, schrieb ich ein Gentoo-Init-Skript, das beim Start cryptsetup und mount ausführte und beim Herunterfahren umount ausführte und das Mapping entfernte. Mit rc-update add mount_crypt default kam es in den Standard-Runlevel.

Was es kostete

Auf meiner SATA-Platte sank der Durchsatz von 47,18 MB/s auf der unverschlüsselten auf 21,89 MB/s auf der verschlüsselten Partition, also um gut die Hälfte. Die Prozessoren von 2006 rechneten AES noch komplett in Software. Wer es richtig machen wollte, musste außerdem an Swap und /tmp denken: Auch dort landen Daten im Klartext, wenn sie nicht verschlüsselt sind.

Was sich seitdem geändert hat

Der Aufruf cryptsetup create legt eine Abbildung im sogenannten Plain-Modus an: Auf der Platte steht kein Header, nur verschlüsselte Daten. Das hat Nachteile. Ein falsches Kennwort fällt nicht auf, das Ergebnis ist einfach Datenmüll; das Kennwort lässt sich nicht ändern, ohne alles neu zu verschlüsseln; und mehrere Schlüssel gibt es nicht.

Genau dafür entstand LUKS, das Linux Unified Key Setup, mitentwickelt von Clemens Fruhwirth, einem der Autoren von dm-crypt. LUKS legt einen Header mit Keyslots vor die Daten. Seit cryptsetup 2.1 von 2019 ist LUKS2 der Standard, mit aes-xts-plain64 als Verschlüsselung und Argon2id als Verfahren, das aus dem Kennwort den Schlüssel ableitet und Rateangriffe teuer macht. XTS hat CBC mit ESSIV für Festplatten abgelöst.

Auch der Rest ist Geschichte: Cryptoloop wurde Ende 2021 für Linux 5.16 aus dem Kernel entfernt, ReiserFS mit Linux 6.13 Ende 2024. Prozessoren mit AES-Befehlen verschlüsseln heute so schnell, dass der Verlust auf normalen Platten kaum messbar ist; cryptsetup benchmark zeigt die Werte für den eigenen Rechner. Und shred überschreibt auf SSDs wegen der internen Blockverwaltung nicht zuverlässig alle Daten; dort hilft nur, von Anfang an zu verschlüsseln.

Zahlen im Überblick

• Gemessener Durchsatz 2006: 47,18 MB/s unverschlüsselt, 21,89 MB/s mit dm-crypt (AES-256, CBC-ESSIV).
• CVE-2004-2135 und CVE-2004-2136 beschreiben die Wasserzeichen-Schwäche vorhersagbarer Initialisierungsvektoren.
• LUKS2 ist seit cryptsetup 2.1 (2019) das Standardformat.
• Cryptoloop wurde für Linux 5.16 entfernt, ReiserFS mit Linux 6.13.

Referenzen

• bk99.de 2006: CryptHD unter Linux (Webarchiv)
• Wikipedia: dm-crypt
• Wikipedia: Watermarking attack
• cryptsetup 2.1.0: Release Notes (LUKS2 als Standard)
• Phoronix: ReiserFS aus Linux 6.13 entfernt

Bemerkungen

• Dieser Beitrag stand ursprünglich am 13. September 2006 in meinem alten Plone-Blog. 2026 habe ich ihn aus dem Webarchiv geholt, sprachlich überarbeitet und um den heutigen Stand ergänzt. Befehle und Messwerte sind die von damals.
• Für neue Installationen bitte nicht abtippen: Heute legt man verschlüsselte Partitionen mit cryptsetup luksFormat an, oder gleich im Installer der Distribution.

Originalbeitrag im Webarchiv →

Links zur Originalquelle und zum Webarchiv öffnen einen neuen Tab.