Haaalt!!! Haltet den Dieb!!! Shit! Da vorne rennt mein Laptop! .oO( Jetzt kann der Typ meine Mails und Daten lesen, hat meinen PGP und SSH Private Key... ) Nicht gerade eine angenehme Vorstellung, oder? Hättest Du Deine Daten doch bloss besser geschützt!

Dateien und E-Mails verschlüsselt man ja standardmäßig mit PGP oder GnuPG. Aber wie kann man unter Linux eigentlich ganze Partitionen oder eine Cd verschlüsseln?

Ganz einfach! Mit Hilfe von Cryptoapi und gepatchten util-linux Sourcen.

Dieser Artikel ist ein Update von Doobee R. Tzeck Artikel "Encrypting your Disks with Linux" in DS #68.

Naja, warum hab ich ja eigentlich schon in der Einleitung geklärt... Aber Du könntest jetzt ja behaupten, dass Du Dein System gut geschützt hast und das niemand ohne Root Zugriff Deine Daten lesen kann.

Dann wechsel mal beim Lilo Bootprompt in die Texteingabe (ESC / F2) und tipp folgendes ein: kernel-image name init=bin/bash rw Schwups! Schon landet man in ner Root Shell (Bash les- und schreibar)... Alter Trick. Dein Lilo ist dagegen geschützt?

Dann kann man immer noch die Platte in einen anderen Rechner einbauen und so auf die Daten zu greifen. Wenn man physikalischen Zugriff auf Deinen Rechner hat, müssen Deine Daten also anders (durch Verschlüsselung) geschützt werden! Kommen wir zur nächsten wichtigen Frage: Was sollte man denn nun eigentlich alles verschlüsseln?

Das man seine eigenen Dateien und Dokumente verschlüsseln sollte, ist glaube ich absolut klar, daneben am besten auch noch sein /home Verzeichnis, weil dort SSH und PGP Private Keys, E-Mails, der Browser Cache, das Adressbuch, die Bash History und ne Menge anderer persönlicher Krempel gespeichert wird. Vielleicht wäre es auch nicht falsch /var/log und /var/spool (oder gleich /var) für Unbefugte unlesbar zu halten. Dort befinden sich immerhin ne Menge Informationen über das System und seine Vergangenheit! Wenn man zu Hause oder in der Firma einen eigenen Proxyserver stehen hat und nicht möchte, dass jemand nach vollziehen kann wohin man wann gesurft ist, dann sollte man auch den Cache und die Logdateien des Proxies verschlüsseln. Zusätzlich fallen mir jetzt noch so die Daten einer Datenbank ein (z.B. bei Mysql /var/lib/mysql), das DocumentRoot Verzeichnis eines Webservers, das Mailverzeichnis eines Mailservers / Faxservers, CVSROOT des Cvs Servers, Backup Cds und Bänder und alle anderen Verzeichnisse, die im Falle eines Diebstahls wertvolle Firmengeheimnisse bzw. persönliche Daten preisgeben könnten.

Dabei sei noch angemerkt, dass die Daten im laufenden Betrieb, wenn sie einmal entschlüsselt wurden natürlich auch entschlüsselt bleiben, aber Diebe haben so die Angewohnheit die Geräte vom Strom zu nehmen und Knallgas zu geben... Also zu verschlüsseln gibts viel. Packen wirs an! =)

Normalerweise befindet sich ein Dateisystem immer direkt auf einem Blockdevice wie z.B. /dev/hda1. Aber was ist schon normal? Das Dateisystem kann sich eben so gut in einer Image Datei befinden, die dann über ein Loopback Device an ein Blockdevice gebunden wird. Dazu passt ganz gut die Frage: Was ist eigentlich genau ein Loopback Device? Laut der Kerneldokumentation ist ein Loopback Device folgendes:

The loopback devices are used to mount filesystems not associated with block devices. The binding to the loopback devices is handled by mount(8) or losetup(8).

Über Loopback Devices kann man mit mount also Dateisysteme mounten, die nicht auf Blockdevices gespeichert werden. Das hat ja erstmal nichts mit Verschlüsselung zu tun, aber...

Das Paket Cryptoapi enthält Kernelmodule zum verschlüsseln von Loopback Devices , Verschlüsselungsalgorythmen wie z.B. blowfisch, twofish, DES, IDEA und XOR (süß...) und einen Patch für das util-linux Paket, damit mount die verschlüsselten Devices mounten bzw. losetup die zusätzlichen Algorythmen nutzen kann.

Das ist doch eigentlich 'ne super Sache! Warum ist das nicht im Standardkernel implementiert? Ganz einfach; Weil es entweder die entsprechenden Patente oder aber die Kryptoexporte einiger Länder (wie vor allem die der USA), die Verbreitung verbieten und den Fortschritt behindern. Für den ganzen Spass muss Dein Kernel natürlich Loopback Devices generell unterstützen (Block devices / Loopback device support). Diese Loopback Devices solltest Du übrigens nicht mit dem lo Netzwerk Device verwechseln! Das ist dafür zuständig, dass sich lokale Prozesse quasi über ein Netzwerk, welches sich nur auf dem lokalen Rechner abspielt, verständigen können, wie z.B. der X-Server. Aber nicht so schnell! Ich sollte vielleicht erstmal erklären wie man den ganzen Krempel installiert...

Cryptoapi unterstützt die Kernel 2.4.7, 2.4.16, 2.4.17 und 2.4.18. Also ist die Grundvoraussetzung, dass Du einen der angegebenen Kernel laufen hast! Schau am besten mal kurz auf der offiziellen Cryptoapi Homepage vorbei, um zu sehen, ob Dein aktueller Kernel mittlerweile unterstützt wird, weil dieser Artikel ist auf dem Stand von Jpalawan 2002.

Die Installation von Cryptoapi ist fast schon langweilig: ./configure && make && make install. Danach findest Du unter /lib/modules/kernel-version/cryptoapi die verschiedenen Kernelmodule.

Jetzt musst Du noch die Sourcen von util-linux entpacken und patchen. Den Patch findet Du im doc Verzeichnis von Cryptoapi.

cd util-linux
patch -p1 < ../cryptoapi/doc/util-linux.patch

Und anschließend wie gewohnt noch die util-linux Sourcen compilieren: ./configure && make && make install.

Jetzt lädst Du auf jeden Fall die Module cryptoapi.o und cryptoloop.o plus mindestens ein Modul für den gewählten Verschlüsselungsalgorythmus. Falls Dein Kernel keine Module unterstützen soll, kannst natürlich auch den Kernel patchen und die Fähigkeiten von Cryptoapi direkt in den Kernel compilieren. Einen entsprechenden Patch findest Du auf der Homepage von Cryptoapi (patch-int-kernel-version). Soweit so gut...

Jetzt muss ne Imagedatei her, in die Du später das Dateisystem und Deine Daten packen kannst. Die Imagedarei legt man via dd an:

dd if=/dev/urandom of=/path/image-file bs=1024 count=device-size

Solltest Du vergessen mit count eine Grösse an zu geben, dann kann es "schnell" passieren, dass Du dir Deine Festplatte mit einem 0 / 1 Gesülze zumüllst, aber ich behaupte mal die Handhabung von dem Befehl dd sollte Dir bekannt sein... Jetzt verbindet man die Imagedatei mit einem freien Loopback Device und legt den Verschlüsselungsalgorythmus (z.B. twofish) fest:

losetup -e twofish /dev/loop0 /path/image-file

Man wird nach einer Keysize und einem Passwort gefragt. Anschließend muss noch 'n Dateisystem her:

mke2fs /dev/loop0

Nun kann man das Device /dev/loop0 wie jedes andere Device mounten und seine Daten übertragen. Danach löst man die Imagedatei nach einem umount wieder von dem Loopback Device:

losetup -d /dev/loop0

Die Daten liegen jetzt verschlüsselt in der Imagedatei und können nur mit dem Wissen über den Verschlüsselungsalgorythmus, der Keysize und natürlich dem Passwort wieder über das Loopback Device entschlüsselt werden.

Es ist ziemlich lästig, wenn man nach dem Booten immer von Hand seine ganzen Loopback Devices einbinden muss, deswegen muss ein Shell Script her, das dies automatisch und mit einmaliger Passwortabfrage erledigt. Ein Beispiel Script, welches auch die benötigten Kernelmodule lädt, könnte so ausssehen:

#!/bin/bash
echo "---:[ Loading Crypto LKMs"
insmod /lib/modules/2.4.7/cryptoapi/cryptoapi.o
insmod /lib/modules/2.4.7/cryptoapi/cryptoloop.o
insmod /lib/modules/2.4.7/cryptoapi/cipher-twofish.o
echo "Are you allowed to play the game??"
echo ""
read -s -p "---:[ Password to mount encrypted devices: " PASS; echo
echo ""
read -s -p "---:[ Enter the keysize: " KEY; echo
echo "Trying to mount the encrypted devices..."
echo "$PASS" | /sbin/losetup -e twofish -p 0 -k $KEY /dev/loop0 /crypt/data
e2fsck /dev/loop0
mount -t ext2 /dev/loop0 /data
echo "$PASS" | /sbin/losetup -e twofish -p 0 -k $KEY /dev/loop1 /crypt/home
e2fsck /dev/loop1
mount -t ext2 /dev/loop1 /home
[...]

Außerdem ist es bis jetzt root vor behalten auf die verschlüsselten Partitione zu zu greifen. Wenn user karl_arsch diese auch mounten können soll, dann muss man die /etc/fstab ein wenig anpassen. Die Optionen einer verschlüsselten Partition werden um loop, encryption=algorythm, user ergänzt:

/crypt/data /data ext2 noauto, loop, encryption=twofish, user 0 0

Wenn der User karl_arsch jetzt die in /crypt/data verschlüsselten Daten nach /data mounten will, dann ruft der mount Befehlt automatisch losetup auf und fordert ihn auf die Keysize und das Passwort ein zu geben. Aber was macht man jetzt wenn folgende Situation eintritt?

Verdammt! Irgendso ein ***** hat mein Passwort gehackt und sich Zugriff zu meinem Loopback Device verschafft! Ich muss sofort das Passwort und den Algorythmus (am besten auch die Keysize) ändern! Keep cool!

Als erstes brauchst Du 'n freies Loopback Device. Waaas? Du hast alle verbraten? Dann leg ein neues an!

mknod /dev/loop1 b 7 7

Jetzt hängst Du die Partition einmal wie gewohnt ein und ein anderesmal mit den neuen Einstellungen auf einem freien Loopback Device. Anschließend überträgst Du die Daten mit dd von dem alten auf das neue Loopback Device und hängst das alte wieder aus.

losetup -e twofish /dev/loop0 /crypt/data
losetup -e idea /dev/loop1 /crypt/data
dd if=/dev/loop0 of=/dev/loop1 bs=1024 conv=notruns
losetup -d /dev/loop0

Du kannst mit diesem Verfahren auch die Grösse der Imagedatei anpassen indem Du eine kleinere / grössere Imagedatei an /dev/loop1 hängst und die Daten dorthin überträgst.

Eine ausführlichere Anleitung dazu sowie zu sämtlichen anderen Themen rund um die Cryptoapi gibt's unter

• Encryption Howto
• Linux Magazin 11/2001 - Verschlüsselte Dateisysteme mit dem Loopback-Device

Seine Daten auf verschlüsselten Loopback Devices zu speichern, hat nicht nur Vorteile.

Was wohl jeden klar sein sollte: Wenn Du selbst den Verschlüsselungsalgorythmus , die Keysize und Dein Passwort vergisst, dann haste ein ernsthaftes wenn nicht unlösbares Problem!

Genauso ist die Verschlüsselung nur so sicher wie Dein Passwort und Dein Betriebsystem. Wenn Du ein zu leichtes Passwort oder nen Keylogger auf dem Rechner hast, dann hilft Dir keine Verschlüsselung. Aber das kennt man ja... Nach meinen Erfahrungen sind verschlüsselte Loopback Devices aber auch anfälliger gegen plötzlichen Stromausfall, zumindest wenn sie gross (mehr als 7 Gb) sind.

Mir ist es hier schon ein paar mal passiert, dass das Dateisystem nicht mehr her zu stellen war, da keine einzige Inode mehr stimmte, weil ich vor dem runter fahren die Loopback devices nicht richtig ausgehängt hatte. Deshalb schreib Dir auch dafür 'n Script! Und vermeide Loopback Devices über einer Größe von 7 Gb.

Manch einer könnte jetzt behaupten, dass man ja eh keine Dateien größer als 4 Gb mit einem 2.4.x Kernel erstellen kann. Das ist erstmal richtig. Wenn Du versucht eine 7 Gb Datei mit rm zu entfernen, dann zeigt Dir der Kernel den dicken Finger! Aber mit dd kann man auch größere Dateien anlegen. Und die kann man anschließend auch nur mit dd wieder los werden:

dd if=big-file of=/dev/null bs=0 count=0

Damit Deine Daten im Falle eines Crashes nicht futsch sind, solltest Du sie vielleicht in einem verschlüsselten Loopback Device auf Deinem Backup Server sichern oder auf einer Cd.