dm-crypt und luks für eine Container-Datei

Wednesday, October 5. 2011

In einem vorigen Eintrag hatte ich die Verschlüsselung kompletter Partitionen und deren Einbindung mit dm-crypt und luks beschrieben, hier als Ergänzung, wie das mit Container-Dateien geht.

# ggf vorbereiten
modprobe loop
losetup -a

#  erstelle 2G container mit zufallsfuellung
dd if=/dev/urandom of=
testfs.bin bs=1M count=2048

# die (leere) Imagedatei auf das naechste freie Loop-Gerät legen, wird angezeigt
losetup -f --show  
testfs.bin

# und zunächst als Partition formatieren
cryptsetup luksFormat /dev/loop0

# dabei wird die Eingabe einer Passphrase verlangt, die gut verschluesselt notieren...

# jetzt kann die Datei-Partition geöffnet werden
cryptsetup luksOpen /dev/loop0 testfs

# mit einem Dateisystem formatiert
mkfs -t ext4 /dev/mapper/testfs

# und schliesslich gemounted werden
mount /dev/mapper/testfs /mnt/testfs

Damit ist ein Dateisystem in einem verschlüsselten Container angelegt und kann benutzt werden. Hier noch mal die Aufrufe im Einsatz, Einbinden und Lösen:

Einbinden:
losetup -f --show 
testfs.bin
cryptsetup luksOpen /dev/loop0 testfs
mount /dev/mapper/testfs /mnt/testfs

Lösen:
umount /mnt/testfs
cryptsetup luksClose /dev/mapper/testfs
losetup -d /dev/loop0

Am Beispiel einer externen Festplatte, die sich nach dem Anstöpseln als /dev/sdc meldet:

fdisk -l
gibt unter anderem:

Disk /dev/sdc: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x08040000

Disk /dev/sdc doesn't contain a valid partition table

Die Partition mit ziemlichem Zufall initialisieren und dabei gleichzeitig die Zuverlässigkeit der Platte prüfen:

badblocks -c 10240 -s -w -t random -v /dev/sdc
(dauert ewig.)

Formatieren und mit dem Namen silva einbinden:
luksformat -t ext3 /dev/sdc
cryptsetup luksOpen /dev/sdc silva

Optional die fsck-Frequenz etwas ausdünnen: 
tune2fs -c 1000 /dev/mapper/silva
tune2fs -i 365 /dev/mapper/silva

und ins Dateisystem holen:
mount /dev/mapper/silva /mnt/silva

und zurück:
umount /mnt/silva , falls dass mit device busy hakt, ggf fuser -m /mnt/silva
cryptsetup luksClose /dev/mapper/silva


Mehr Infos

dm-crypt vs. truecrypt:
- beide können einen Container in einer Datei, einer Partition oder einem ganzen device einrichten, beide sind opensource und bier-frei, beide sind schwer genug zu knacken dass es aussichtsreicher ist, das Versteck für den Schlüssel zu finden.
- dm-crypt ist gefühlt paarmal schneller. Bei einem Container mit Passwörtern und Tagebüchern etc. macht das keinen nennenswerten Unterschied, aber bei einer TB-Platte mit der Musiksammlung dann schon.
- dafür hat truecrypt deutlich die Nase vorn, wenn man den Container mal von win*, mal von linux her öffnen möchte
- mit dem Konzept der plausible deniability und hidden volumes hat truecrypt ein Alleinstellungsmerkmal, das unter Umständen den Abstand zwischen Kopf und Kragen regulieren helfen kann.

Vom Einsatz-Szenario her würde ich das Projekte-Device, auf dem unter anderem auch Vorhaben, die unter NDA stehen, gewiss auf dm-crypt legen, dito die Sammlung von vmware und vmbox - Maschinen oder Videos fraglicherer Herkunft.
Die MindMaps, Tagebücher, Liebesbriefe und org/finanzamt wären da eher auf einem trauecrypt-Volumen gut aufgehoben und die Sammlung von Belegen all' der schoflen  Begebenheiten, die irgendwann mal reif für ein Upload nach wikileaks sein wird, käme wohl am besten zu truecrypt in ein hidden volume.

(Page 1 of 1, totaling 2 entries)