Amish Geeks » luks Hier steht mal irgendwann ein toller Titel. Mon, 07 May 2012 20:22:54 +0000 en hourly 1 http://wordpress.org/?v=3.2.1 DVDs verschlüsseln /blog/dvds-verschlusseln/ /blog/dvds-verschlusseln/#comments Sun, 22 Apr 2007 00:27:54 +0000 MichiK /blog/dvds-verschlusseln/ Ich habe einige dutzend Gigabytes an Daten, die nicht jeder sehen soll — aus guten Gründen, die ihr euch vermutlich denken könnt. ;) Zur Zeit ist mein Paranoia Level wieder monoton steigend und ich habe mir mal überlegt, wie man die Backups vernünftig verschlüsselt sichert, aber gleichzeitig auch ordentlich Zugriff darauf bekommt.

Die erste Idee war es, die Dateien einfach mit GnuPG zu verschlüsseln. Guter Plan eigentlich, aber mit einigen Haken:

  • Wenn ich meinen privaten Schlüssel verliere, sind die Daten weg. Unwiederbringlich.
  • Wenn man eine einzige Datei aus dem großen Image braucht, muss man alles entschlüsseln. Das dauert lange. Außerdem muss man dann 4,7 GB für die temporär entschlüsselten Daten vorhalten.
  • Die entschlüsselten Daten landen auf der Festplatte oder einem anderen schreibfähigen Medium. Nicht wünschenswert.

Dann die Idee: Warum macht man es mit DVDs nicht einfach genauso wie mit Festplatten? LUKS ist bequem und funktioniert. Wenn man eine gute Passphrase hat und die für sich behält, sind die Daten sicher. Man kann da ein Filesystem drauftun und das beliebig mounten und draus lesen. Perfekt.

Wie aber vorgehen? Erstmal brauche ich eine temporäre Datei, in die die Daten kommen sollen:

dd if=/dev/zero of=foo.img bs=1M count=4450

Wer extrem paranoid ist, kann auch aus “/dev/random” lesen, aber das ist meiner Meinung nach etwas zu viel des guten. Mit 4450 MiB ist man recht gut bedient. 4700000000 Bytes sind ca. 4482 MiB – ich weiß leider nicht, wieviel Overhead da noch ist, also lieber großzügig kalkulieren.

Nun muss in diese Datei ein LUKS-Volume. Ein simples `cryptsetup luksFormat foo.img` scheitert, da der Device Mapper natürlich richtige Devices sehen will und nicht mit Dateien kann. Also nehme ich den Umweg über ein Loop-Device:

losetup /dev/loop0 foo.img
cryptsetup -c aes -s 256 luksFormat /dev/loop0

Dann mit “YES” antworten und eine schöne Passphrase ausdenken. 20 Zeichen sollten das Minimum sein. Anschließend muss das ganze ein richtiges Blockdevice werden:

cryptsetup luksOpen /dev/loop0 foo

Nun ist unter “/dev/mapper/foo” ein Gerät zu finden, das man mit beliebigen Dateien füllen kann. Im Idealfall natürlich ein Dateisystem. Ich entscheide mich da für ext2. Letztendlich ist es egal, jeder soll nehmen, was er mag, aber dabei im Hinterkopf behalten, dass das ganze mal read-only wird. Also ist Journaling beispielsweise Schwachsinn.

mke2fs /dev/mapper/foo
tune2fs -c 0 -i -1 -m 0 /dev/mapper/foo

Mit `tune2fs` setze ich nun noch die maximale Anzahl von Mounts, bevor das System einen Check will auf unendlich, sowie die Maximale Zeit, bevor das passiert auf ca. 138 Jahre. Außerdem bekommt der Superuser keine reservierten Blocks. So wird einerseits sichergestellt, dass man keinen Stress bekommt, falls man das Image irgendwann einmal zurück auf die Platte kopiert, den Inhalt ändert und dann das selbe Dateisystem wieder brennt. Anderseits braucht der Superuser hier keinen garantierten Platz (bei / oder /var ist das ja sinnvoll, ansonsten: nö).

Anschließend kann das ganze gemountet werden und außerdem noch direkt einem User, der das ganze dann befüllen darf, die entsprechenden Rechte gegeben:

mount /dev/mapper/foo /mnt/foo
chown user /mnt/foo && chgrp user /mnt/foo

Anschließend kann der User das Dateisystem beliebig mit vertraulichen Daten zuschaufeln. Um den Tresor abzusperren, genügen drei Zeilen:

umount /mnt/foo
cryptsetup luksClose foo
losetup -d /dev/loop0

Meine erste Idee war nun, “foo.img” direkt auf eine DVD zu schreiben. Ohne Dateisystem drunter. Obscurity und so. ;) Allerdings gab es da etwas Stress. Ich konnte das zwar bequem brennen und den Safe aufschließen, aber `mount` hat dann immer rumgemeckert: “blocksize too small for device”. Weiß da jemand mehr?

Als Workaround habe ich nun einfach ein ISO-Image mit “foo.img” drin erstellt und das dann auf die DVD getoastet:

mkisofs -J -R -o foo.iso foo.img
growisofs -dvd-compat -speed=4 -Z=/dev/hda=foo.iso

So hat man halt eine zusätzliche Abstrahierungsschicht noch dazwischen, aber dafür funktioniert es wenigstens. Wie kommt man da jetzt wieder dran, mag man sich fragen? Ganz einfach:

mount /dvdrom
losetup /dev/loop0 /dvdrom/foo.img
cryptsetup --readonly luksOpen /dev/loop0 foo
mount -o ro /dev/mapper/foo /mnt/foo

Ebenso leicht kann man den Tresor wieder abschließen:

umount /mnt/foo
cryptsetup luksClose foo
losetup -d /dev/loop0
umount /dvdrom

Natürlich versteht sich von selbst, dass man noch einige zusätzliche Sicherheitsvorkehrungen treffen sollte, damit auch ansonsten die Sicherheit gewährleistet wird:

  • Die DVDs nur auf eigenen, wirklich vertrauenswürdigen Maschinen mounten. Wenn die Passphrase auf einem möglicherweise kompromittierten Rechner eingegeben wird, ist die Sicherheit dahin.
  • Die DVDs nicht mit dem wahren Inhalt beschriften, sondern entweder mit Codebezeichnungen oder einfach durchnummerieren. Man kann gerne eine Zuordnungstabelle der einzelnen DVDs zu ihrem Inhalt anlegen, sollte diese dann aber ebenfalls nur sicher verschlüsselt aufbewahren. Ich brenne einfach die aktuelle Fassung auf die neuste DVD und lösche sie dann von meiner Festplatte. So muss ich nur die aktuellste DVD mounten und habe einen Überblick über die Inhalte.
  • Auch die restlichen Teile des Systems entsprechend sichern. Eine verschlüsselte Swap sowie ein verschlüsseltes /tmp sind schon fast Pflicht. Die DVDs nicht mounten, wenn andere Personen Zugriff (auch remote) auf den selben Rechner haben. Die DVDs nicht gemountet lassen, wenn man den Rechner verlässt.

Anregungen? Weitere Ideen? Verbesserungsvorschläge? Kritik? Ich bin für alles offen. Falls das Konzept für tauglich befunden wird, wird die nächste Spindel so befüllt. :)

]]>
/blog/dvds-verschlusseln/feed/ 15
VIA PadLock fetzt /blog/via-padlock-fetzt/ /blog/via-padlock-fetzt/#comments Mon, 04 Dec 2006 20:37:30 +0000 MichiK /blog/via-padlock-fetzt/ Ich habe jetzt endlich mal einen neuen Kernel hier gebaut und nun tut auch das PadLock (AES in Hardware) meiner VIA-CPU wieder richtig. Für alle, die mal wissen wollen wie das abgeht, hier ein kleiner Vergleich der Transferraten beim Lesen einer großen Datei von meinem verschlüsselten /home (XFS auf einem LUKS-Volume in einem LVM auf einem Software-RAID5).

Ohne PadLock:

1767928932 Bytes (1,8 GB) kopiert,
352,82 Sekunden, 5,0 MB/s

Mit PadLock:

1767928932 Bytes (1,8 GB) kopiert,
89,2294 Sekunden, 19,8 MB/s

:)

]]>
/blog/via-padlock-fetzt/feed/ 3