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. :)
Tags: dvds, luks, verschlüsselung
jop. die idee ist gut.
ich wollte ohnehin schon meine daten sicher backuppen ..
im moment liegt alles unsicher (=unverschlüsselt) auf der platte.. mit dem neuen pc in ein paar tagen kommt ein vernünftiges betriebssystem (ich denke ubuntu 7.04) mit festplattenverschlüsselung.
aber ansonsten: danke für die detaillierte anleitung ;)
Ubuntu als ein vernuenftiges System bezeichnen… *shrug*
Naja, die Idee mit LUKS find ich klasse.. hab ich noch gar nicht drueber nachgedacht.. echt klasse.. :-)
In der Tat, auch wenn ich eh nur selten Backups mache ;)
Die extra Schicht, die durch ISO entsteht, ist wirklich ärgerlich. Vielleicht probier ich noch damit rum (sobald ich genug mit Ubuntu 7.04 rumgespielt hab :P)
jchome: Besser als Windows als Betriebssystem zu bezeichnen ;)
Ja, die ISO-Zwischenschicht ist nervig, aber wie gesagt, nur ein hässlicher Workaround. Ich kann das Dateisystem auch direkt brennen, da kann ich dann sogar `e2fsck` drüber rennen lassen, das sagt auch, alles wäre ok. Aber mounten kann ichs nicht. Warum auch immer… wäre schön, wenn mich da jemand aufklären könnte.
Ich werde demnächst mal mit anderen Dateisystemen experimentieren, vielleicht finde ich was, das man dann auch direkt von DVD mounten kann. Solange es nicht FAT oder so sein muss, nehm ich gerne alles. ;)
Schau dir das doch einfach mal an: http://de.gentoo-wiki.com/CD_Encryption_aespipe
(die Idee ist zwar nett, aber irgendwie overkill ;))
Vor ein paar Tagen bei Koehntopp gefunden: http://blog.koehntopp.de/archives/1653-Encfs.html – sieht ganz praktisch aus habs aber noch nicht selbst getestet.
Das blocksize-Problem kommt wahrscheinlich daher, daß CDs/DVDs mit 2048 Byte großen Sektoren arbeiten. ext2 verwendet normalerweise aber 1024 Byte Blocks, deswegen tut das nicht. Kurzer Test bei mir hat grad ergeben: “mke2fs -b 2048″ hilft.
Grüße,
sur5r
Naja, Linux ist nicht wirklich mein Fachgebiet, daher kann ich nur sagen wie ich bei Windoofs etwas wirklich sicher verschlüsseln würde:
DriveCrypt von Securestar. Glaubt mir, das Zeug ist wirklich hart. Die Container ohne den richtigen Code zu knacken nicht wirklich machbar, selbst Behörden haben da ihre Probleme wenn sie an Material wollen.
Außerdem gibt Securestar sogar damit an, das es noch niemand geschafft hat sie zu knacken udn haben sogar ein Preisgeld darauf ausgegeben von irgendwas mit 100.000 $ USD.
Ist auch ne Alternative.
TrueCrypt ist sehr komfortabel unter Windows. Die CLI-Version für Linux habe ich aber noch nicht ausprobiert.
Gerade in der loop-aes readme gefunden (http://loop-aes.sourceforge.net/loop-AES.README):
———
2.5. File system soft block sizes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you intend to move encrypted file system to some other device (CD-ROM for
example), be sure to create file system with soft block size that is integer
multiple of device hard sector size. CD-ROMs have 2048 byte sectors. File
system with 1024 byte soft block size is not going to work with all CD-ROM
drives and/or drivers.
————
loop-aes ist übrigens unter linux meine erste Wahl für Verschlüsselung. Für Windows gibt’s TrueCrypt.
Zum Thema Dateisystem empfehle ich die Verwendung von UDF, dann klappt es auch mit der vollen Kapazität der LUKS-DVD:
Image und LUKS-Volume erzeugen:
dd if=/dev/zero of=/dvd.img bs=1000k count 4700
losetup /dev/loop0 dvd.img
cryptsetup -c aes-cbc-essiv_sha256 -y -s 256 luksFormat /dev/loop0
LUKS-Volume öffnen und Dateisystem erzeugen:
cryptsetup luksOpen /dev/loop0 dvd
mkudffs –media-type=dvd /dev/mapper/dvd
Jetzt mounten, mit den Dateien füllen, umounten, cryptsetup luksClose dvd aufrufen und Loopdevice mit losetup -d /dev/loop0 entfernen.
Die Image-Datei habe ich mit k3b auf eine DVD+R gebrannt.
Später lässt sich die LUKS-DVD ganz einfach wie eine Partition einbinden:
cryptsetup –readonly luksOpen /dev/hdd dvd (wobei /dev/hdd das dvd-Laufwerk ist)
mount -r -t udf /dev/mapper/dvd /mnt/dvdimage
Zum mounten und umounten habe ich mir 2 Scripte geschrieben und diese nach /usr/local/bin gespeichert.
Viel Spaß mit dieser Lösung. Viele Grüße
Syncmaster
Nachtrag zu UDF: Max. Dateigröße je nach Kernel nur 1GB
Laut
http://lkml.org/lkml/2006/9/3/43
scheint die Dateigröße zur Zeit bei vielen 2.6er Kernels leider auf 1GB beschränkt zu sein (Genauer: zwischen 2.6.17 and 2.6.21).
Ich habe zwar einen älteren Kernel als 2.6.17 im Einsatz, aber irgendwie funktionierts trotzdem nicht (auch mit anderen Werten des media-type Parameters: hd, worm… )
Irgendwelche Ideen woran es liegen könnte? Formatieren mit Ext2 klappt bei mir nicht…
Grüße
Syncmaster
Ich bin auch am herumprobieren mit LUKS, allerdings mit einer LUKS-CD. Und das funktioniert partout nicht (ohne ISO-Zwischenschicht).
Bereits Cryptsetup weigert sich, den mit
cdrecord dev=1,0,0 driveropts=burnfree -dao -v cdcrypt.img
direkt auf CD getoasteten Container zu öffnen, und kapituliert mit
device-mapper: reload ioctl failed: Invalid argument
Der Versuch, Cryptsetup mittels -b 2048 eine andere Blocksize beim formatieren mitzugeben, funktioniert zwar, nach dem Brennen weigert sich cryptsetup aber erneut zu mounten; diesmal macht es einfach gar nichts.
Was habt ihr anders gemacht, dass bei euch cryptsetup nicht meckert?
Grüße,
Lawlita
Kleiner Nachtrag:
UDF ging bei mir nicht, war aber wg. vorheriger schlechter Erfahung mit udftools von gutsy nicht überrascht. ext2 image file in iso erschien mir trotzdem unnötig, und hier ist was ich gemacht habe und was für mich funktioniert:
Nach diesem Schritt:
cryptsetup luksOpen /dev/loop0 foo
Mache ich:
genisoimage -o foo.iso -r daten/
Dann habe ich 2 image dateien rumliegen, aber das bleibt nicht so, denn:
dd if=foo.iso of=/dev/mapper/foo bs=1M
Damit wird das unverschlüsselte iso image verschlüsselt auf das luks device geschrieben.
Dann noch:
growisofs -dvd-compat -speed=2 -Z/dev/sdc0=foo.img
et voila!
Wichtig: Nicht foo.iso brennen, sondern foo.img.
Damit erkennt mein Gnome sogar, beim Einlegen, dass hier eine Passphrase fällig ist. Im GUI funzt das bei mir aber nicht. Auf der Kommandzeile funktioniert es wunderbar.
Karl.
Die Anleitung von Syncmaster hat wunderbar funktioniert. Neugierig habe ich ausprobiert, ob es auch _direkt_ geht.
Ich habe also hier eine Aldi DVD+RW Scheibe.
Mein LG DVD-RW ist /dev/hdb.
# cryptsetup -c aes -s 256 luksFormat /dev/hdb
(geht, beim LG blinkts)
# cryptsetup luksOpen /dev/hdb dvd
# mkudffs –media-type=dvd /dev/mapper/dvd
(geht auch, LG blinkt wieder)
# mount /dev/mapper/dvd /mnt/work/
# mount -oremount,rw /dev/mapper/dvd
# touch /mnt/work/file
(LG blinkt wieder)
# ls /mnt/work
file lost+found
(geht also!)
# rm /mnt/work/file
Mit dem midnight commander schreibe ich da gerade 3.4 GB Daten drauf. Scheint zu funktionieren, packetwriting ist btw. _nicht_ im Kernel integriert. Die Schreibgeschwindigkeit liegt gerade bei vernünftig scheinenenden 3,17 MB/s. Hört sich nur nicht so gesund an, der Schreibkopf scheint sich immer wieder neu zu positionieren und der Motor dreht immer wieder auf.
So, fertig, wieder umounten, cryptsetup entmappen, auswerfen um sicher zu gehen, wieder einlegen, cryptsetup mappen, mounten, als Test ein diff draufwerfen: Cool, Quell u. Zieldateien sind identisch!
Ich frage mich bloss, woran die Desktopintegration scheitert…