- Loop-AES
- Cryptoloop (als veraltet markiert seit Kernelversionen > 2.6.4[?])
- dm_crypt als Nachfolger von cryptoloop (seit Kernel 2.6.4)
Thursday, June 2. 2005
verschlüsselte Dateisysteme mit dm_crypt
Um auf einem Server, auch sensitive Daten speichern zu können, bietet sich ein Verschlüsseln der Dateien an. Hierfür gibt es seit längerem verschiedene Methoden:
Ich habe mich hier für dm_crypt als Nachfolger von Cryptoloop entschieden, da Cryptoloop offensichtlich nicht mehr aktiv entwickelt wird, sowie "known plaintext attack" Angriffe erlaubt. "Known plaintext Attack" ist ein kryptographischer Angriff, bei dem der Angreifer Zugriff auf den Geheimtext sowie den zugehörigen Klartext besitzt. Anhand dieser Informationen versucht der Angreifer aus einer gegebenen verschlüsselten Nachricht auf den Schlüssel (bzw. den Klartext) zu schließen.
Loop-AES habe ich nicht benutzt, denn dafür muß extra das Paket util-linux gepatcht und neu kompiliert werden. Das betrifft mindestens mount (z.B. Angabe des Verschlüsselungsalgorithmuses und Passwortes), umount, losetup, swapon und swapoff. Da ich keine große Lust habe, zusätzliche Aufgaben vom Packetmanager zu übernehmen, schied dieses Verfahren für mich aus. dm_crypt verwendet im Gegensatz zu Loop-AES die normalen mount, umount Utilities, sowie das zusätzliche Userspace utility cryptsetup und ist somit nicht auf gepatchte Versionen von mount angewiesen. Logischerweise erhöht dies natürlich den Aufwand, eine verschlüsselte Partition zu erstellen.
Also los gehts:
Zunächst muß überprüft werden, ob der aktuelle Kernel für dm_crypt geeignet ist:
Falls die aktuelle Kernelkonfiguration in /proc gespeichert wird, kann man folgendes machen:
Falls die aktuelle Kernelkonfiguration nicht in /proc verfügbar ist, kann man auch in /boot/config-"KernelVersion" danach suchen. Als erstes haben wir nachgeschaut, ob der "Device Mapper Support" und danach, ob "Crypt Target Support" verfügbar ist. Beide sind idealerweise bereits im Kernel enthalten, oder zumindest als Modul verfügbar (und müssen dann aber vorher geladen werden. Die entsprechenden Module heißen "dm_crypt" und "dm_mod"). Ansonsten muß der Kernel neu erstellt werden.
Zusätzlich sollte noch mindestens der AES-Verschlüsselungsalgorithmus verfügbar sein. Den findet man mit der Zeichenkette "CONFIG_CRYPTO_AES_586" in der Kernelkonfiguration.
Falls einer dieser Punkte nicht im Kernel verfügbar ist, muß ein neuer Kernel geladen werden. Hierzu sei kurz auf das Kernel-HOWTO, bzw. das Debian Kernel-HOWTO verwiesen.
Falls ein neuer Kernel erstellt werden muß, sollte man bei den folgenden Optionen ein Häkchen setzen:
Zusätzliche Verschlüsselungsalgorithmen in "Cryptographic options" sind auch möglich (z.B. Blowfish, Twofish).
Die vom momentanen Kernel unterstützten Algorithmen erhält man durch ein zgrep "CONFIG_CRYPTO_" /proc/config.gz, alternativ kann man sich auch die Datei /proc/crypto ansehen. Eventuell ist es aber notwendig, entsprechende Module zu laden, falls sie nicht in den Kernel einkompiliert wurden.
Neben dem Kernel müssen noch zusätzliche Programme installiert werden. Bei Debian reicht ein "apt-get install cryptsetup". Eventuelle Abhängigkeiten werden dabei automatisch mitinstalliert (zur Zeit: libdevmapper1.01, libgcrypt11, libgpg-error0 , libpopt0, dmsetup). In anderen Distributionen müssen diese Pakete zur Not von Hand mitinstalliert werden.
Jetzt sind die Vorbereitungen abgeschlossen und man kann damit beginnen, einen verschlüsseltes Dateisystem zu installieren. Wie bereits erwähnt, benötigt man dafür einen Container. Einen solchen Container legt man am besten mittels "dd" an:
Hier habe ich in Bob's Home-Verzeichnis einen Container mit einer Größe von 1GB angelegt. Der Container wird damit mit zufälligen Daten initialisiert. Das cryptoloop HOWTO empfiehlt das device /dev/urandom, denn ansonsten könnte ein Angreifer eventuell ein Muster im Image erkennen (und damit auf den Inhalt schließen).
Nachdem der Container erstellt worden ist, muß ein sogenanntes "loop device" aus diesem erstellt werden. Dies ist notwendig, damit man den Container später mounten kann und dort dann Daten speichern kann. Dies erledigt
Jetzt könnte man es bereits mounten, aber da wir ein verschlüsseltes Dateisystem wollen, muss jetzt noch die Verschlüsselung eingestellt werden. Hierfür benötigt man cryptsetup. Ein
macht aus dem "loop device" ein verschlüsseltes Block Device. Der allgemeine Aufruf ist cryptsetup "Aktion" "Name" "Device". Hier wird also ein neues Device erstellt ("create"). Der "Name" gibt das Gerät an, wie es später unterhalb von "/dev/mapper/" angelegt wird. Wichtig ist die Option "-y", damit wird "cryptsetup" angewiesen, die Passphrase zu verifizieren. Ansonsten könnte ein Vertipper fatale Folgen haben.
Die Passphrase wird genutzt, um einen Hash zu erstellen, der seinerseits als Schlüssel für das Dateisystem genutzt wird. Standardmäßig wird als Hash-Algorithmus Ripemd-160 verwendet. Momentan sind hier keine Schwächen bekannt. Ein alternativer Hash-Algorithmus kann über die Option "-h algorithmus" angegeben werden.
Als Verschlüsselungsalgorithmus wird standardmäßig AES genutzt. Alternative Verschlüsselungsalgorithmen können über die Option "-c algorithmus" spezifiziert werden.
Je nachdem, welche Algorithmen bei der Kernelkonfiguration angegeben worden sind, können natürlich entsprechend andere Algorithmen angegeben werden.
Nachdem jetzt der Container erstellt wurde, muß man darin noch ein Dateisystem erstellen, damit man später in der Lage ist, den Container zu mounten. Um zum Beispiel ein ext3 Journaling Filesystem zu erstellen, gibt man ein:
/dev/mapper/safe ist das Gerät, das vorhin mit cryptsetup erstellt wurde.
Um das Gerät jetzt mounten zu können, benötigt man noch einen Mountpoint, also ein Verzeichnis, in das man das Gerät einhängen kann. Das Mounten kann dann folgendermaßen erfolgen:
Das Gerät wird damit in /mnt/safe eingehängt.
Damit haben wir jetzt einen Container, der bei Bedarf eingehängt und ausgehängt werden kann. Sobald es ausgehängt worden ist, sind alle Daten verschlüsselt und nicht mehr zugänglich.
Wenn man seine verschlüsselten Daten nicht mehr benötigt, sollte man das Gerät aushängen. Denn was nützt ein verschlüsseltes Dateisystem, wenn es immer zugänglich ist? Das Aushängen erfolgt wie bei einem ganz normalen Dateisystem auch mittels umount (also z.B. umount /mnt/safe)
Zusätzlich muß nach dem Aushängen das Gerät entfernt werden:
und anschließen das loop device beendet werden:
Die verschlüsselten Daten befinden sich jetzt einzig in der Datei /home/bob/safe.img
Leider sind diese Schritte (also losetup, cryptsetup und mount) jedesmal notwendig, wenn auf die Daten zugegriffen werden soll, bzw. wenn der Zugriff nicht mehr notwendig ist.
Hierfür habe ich mir das Script cm angelegt:
Anzupassen sind die Variablen ganz am Anfang des Skriptes. Wenn das geschehen ist, reicht ein "cm mount" zum einhängen, "cm umount" zum aushängen und "cm status" um einen Status des Dateisystems zu erhalten.
Eventuell müssen alle mount, umount und cryptsetup Aufrufe mittels sudo geschehen (so ist das zumindest bei mir, aber anhand der Doku von dm_crypt sollte es auch ohne gehen).
Schwachstelle von Cryptoloop
Cryptoloop HOWTO des Linux Documentation Projects
Loop-AES Projekt auf Sourceforge.net
dm_crypt Projekt als Nachfolger von Cryptoloop seit Kernel 2.6.4 im Kernel vorhanden
dm_crypt Mini HOWTO
Kernel-HOWTO
Debian Kernel-HOWTO
Loop-AES habe ich nicht benutzt, denn dafür muß extra das Paket util-linux gepatcht und neu kompiliert werden. Das betrifft mindestens mount (z.B. Angabe des Verschlüsselungsalgorithmuses und Passwortes), umount, losetup, swapon und swapoff. Da ich keine große Lust habe, zusätzliche Aufgaben vom Packetmanager zu übernehmen, schied dieses Verfahren für mich aus. dm_crypt verwendet im Gegensatz zu Loop-AES die normalen mount, umount Utilities, sowie das zusätzliche Userspace utility cryptsetup und ist somit nicht auf gepatchte Versionen von mount angewiesen. Logischerweise erhöht dies natürlich den Aufwand, eine verschlüsselte Partition zu erstellen.
Also los gehts:
1. Vorbereitung
Zunächst muß überprüft werden, ob der aktuelle Kernel für dm_crypt geeignet ist:
Falls die aktuelle Kernelkonfiguration in /proc gespeichert wird, kann man folgendes machen:
CODE:
zgrep "CONFIG_BLK_DEV_DM" /proc/config.gz
und
zgrep "CONFIG_DM_CRYPT" /proc/config.gz
und
zgrep "CONFIG_DM_CRYPT" /proc/config.gz
Falls die aktuelle Kernelkonfiguration nicht in /proc verfügbar ist, kann man auch in /boot/config-"KernelVersion" danach suchen. Als erstes haben wir nachgeschaut, ob der "Device Mapper Support" und danach, ob "Crypt Target Support" verfügbar ist. Beide sind idealerweise bereits im Kernel enthalten, oder zumindest als Modul verfügbar (und müssen dann aber vorher geladen werden. Die entsprechenden Module heißen "dm_crypt" und "dm_mod"). Ansonsten muß der Kernel neu erstellt werden.
Zusätzlich sollte noch mindestens der AES-Verschlüsselungsalgorithmus verfügbar sein. Den findet man mit der Zeichenkette "CONFIG_CRYPTO_AES_586" in der Kernelkonfiguration.
Falls einer dieser Punkte nicht im Kernel verfügbar ist, muß ein neuer Kernel geladen werden. Hierzu sei kurz auf das Kernel-HOWTO, bzw. das Debian Kernel-HOWTO verwiesen.
Falls ein neuer Kernel erstellt werden muß, sollte man bei den folgenden Optionen ein Häkchen setzen:
CODE:
* Code maturity level options --->
o Prompt for development and/or incomplete code/drivers
* General setup --->
o Support for hot-pluggable devices
* Device Drivers ---> Multi-device support (RAID and LVM) --->
o Device mapper support
o Crypt target support
* Cryptographic options --->
o AES cipher algorithms
o Prompt for development and/or incomplete code/drivers
* General setup --->
o Support for hot-pluggable devices
* Device Drivers ---> Multi-device support (RAID and LVM) --->
o Device mapper support
o Crypt target support
* Cryptographic options --->
o AES cipher algorithms
Zusätzliche Verschlüsselungsalgorithmen in "Cryptographic options" sind auch möglich (z.B. Blowfish, Twofish).
Die vom momentanen Kernel unterstützten Algorithmen erhält man durch ein zgrep "CONFIG_CRYPTO_" /proc/config.gz, alternativ kann man sich auch die Datei /proc/crypto ansehen. Eventuell ist es aber notwendig, entsprechende Module zu laden, falls sie nicht in den Kernel einkompiliert wurden.
Neben dem Kernel müssen noch zusätzliche Programme installiert werden. Bei Debian reicht ein "apt-get install cryptsetup". Eventuelle Abhängigkeiten werden dabei automatisch mitinstalliert (zur Zeit: libdevmapper1.01, libgcrypt11, libgpg-error0 , libpopt0, dmsetup). In anderen Distributionen müssen diese Pakete zur Not von Hand mitinstalliert werden.
2. Erstellen eines Containers
Jetzt sind die Vorbereitungen abgeschlossen und man kann damit beginnen, einen verschlüsseltes Dateisystem zu installieren. Wie bereits erwähnt, benötigt man dafür einen Container. Einen solchen Container legt man am besten mittels "dd" an:
CODE:
dd if=/dev/urandom of=/home/bob/safe.img bs=1M count=1024
Hier habe ich in Bob's Home-Verzeichnis einen Container mit einer Größe von 1GB angelegt. Der Container wird damit mit zufälligen Daten initialisiert. Das cryptoloop HOWTO empfiehlt das device /dev/urandom, denn ansonsten könnte ein Angreifer eventuell ein Muster im Image erkennen (und damit auf den Inhalt schließen).
Nachdem der Container erstellt worden ist, muß ein sogenanntes "loop device" aus diesem erstellt werden. Dies ist notwendig, damit man den Container später mounten kann und dort dann Daten speichern kann. Dies erledigt
CODE:
losetup /dev/loop0 /home/bob/safe.img
Jetzt könnte man es bereits mounten, aber da wir ein verschlüsseltes Dateisystem wollen, muss jetzt noch die Verschlüsselung eingestellt werden. Hierfür benötigt man cryptsetup. Ein
CODE:
cryptsetup -y create safe /dev/loop0
Enter passphrase:
Verify passphrase:
Enter passphrase:
Verify passphrase:
macht aus dem "loop device" ein verschlüsseltes Block Device. Der allgemeine Aufruf ist cryptsetup "Aktion" "Name" "Device". Hier wird also ein neues Device erstellt ("create"). Der "Name" gibt das Gerät an, wie es später unterhalb von "/dev/mapper/" angelegt wird. Wichtig ist die Option "-y", damit wird "cryptsetup" angewiesen, die Passphrase zu verifizieren. Ansonsten könnte ein Vertipper fatale Folgen haben.
Die Passphrase wird genutzt, um einen Hash zu erstellen, der seinerseits als Schlüssel für das Dateisystem genutzt wird. Standardmäßig wird als Hash-Algorithmus Ripemd-160 verwendet. Momentan sind hier keine Schwächen bekannt. Ein alternativer Hash-Algorithmus kann über die Option "-h algorithmus" angegeben werden.
Als Verschlüsselungsalgorithmus wird standardmäßig AES genutzt. Alternative Verschlüsselungsalgorithmen können über die Option "-c algorithmus" spezifiziert werden.
Je nachdem, welche Algorithmen bei der Kernelkonfiguration angegeben worden sind, können natürlich entsprechend andere Algorithmen angegeben werden.
Nachdem jetzt der Container erstellt wurde, muß man darin noch ein Dateisystem erstellen, damit man später in der Lage ist, den Container zu mounten. Um zum Beispiel ein ext3 Journaling Filesystem zu erstellen, gibt man ein:
CODE:
mkfs.ext3 -j /dev/mapper/safe
/dev/mapper/safe ist das Gerät, das vorhin mit cryptsetup erstellt wurde.
3. Mounten des Containers
Um das Gerät jetzt mounten zu können, benötigt man noch einen Mountpoint, also ein Verzeichnis, in das man das Gerät einhängen kann. Das Mounten kann dann folgendermaßen erfolgen:
CODE:
mount -t ext3 /dev/mapper/safe /mnt/safe
Das Gerät wird damit in /mnt/safe eingehängt.
Damit haben wir jetzt einen Container, der bei Bedarf eingehängt und ausgehängt werden kann. Sobald es ausgehängt worden ist, sind alle Daten verschlüsselt und nicht mehr zugänglich.
4. Umounten des Containers
Wenn man seine verschlüsselten Daten nicht mehr benötigt, sollte man das Gerät aushängen. Denn was nützt ein verschlüsseltes Dateisystem, wenn es immer zugänglich ist? Das Aushängen erfolgt wie bei einem ganz normalen Dateisystem auch mittels umount (also z.B. umount /mnt/safe)
Zusätzlich muß nach dem Aushängen das Gerät entfernt werden:
CODE:
cryptsetup remove safe
und anschließen das loop device beendet werden:
CODE:
losetup -d /dev/loop0
Die verschlüsselten Daten befinden sich jetzt einzig in der Datei /home/bob/safe.img
5. Mount/Umount Script
Leider sind diese Schritte (also losetup, cryptsetup und mount) jedesmal notwendig, wenn auf die Daten zugegriffen werden soll, bzw. wenn der Zugriff nicht mehr notwendig ist.
Hierfür habe ich mir das Script cm angelegt:
CODE:
#!/bin/sh --
FILE=/home/bob/safe.img
MAPPER=safe
MAPDEV=/dev/mapper
DEVICE=/dev/loop0
FS=ext3
MOUNTPOINT=/mnt/safe
STATUS=`mount |grep $MAPPER`
PID=$?
if [ $# != 1 ]
then
cat <<EOF
usage: `basename $0` mount|umount|status
mount: mount $FILE
umount: umount $FILE
status: gives a short status about the encrypted filesytem
EOF
exit 2
fi
if [ $1 == "mount" ]
then
if [ $PID -eq 0 ]
then
cat <<EOF
It seems $MAPPER is already mounted.
Mount status: $STATUS
EOF
exit 3
fi
echo "mounting"
/sbin/losetup $DEVICE $FILE
/sbin/cryptsetup -y create $MAPPER $DEVICE
mount -t $FS ${MAPDEV}/${MAPPER} $MOUNTPOINT
elif [ $1 == "umount" ]
then
if [ $PID -eq 1 ]
then
cat <<EOF
It seems $MAPPER is already umounted.
Mount status: $STATUS
EOF
exit 4
fi
echo "umounting"
umount $MOUNTPOINT
/sbin/cryptsetup remove $MAPPER
/sbin/losetup -d $DEVICE
elif [ $1 == "status" ]
then
echo "status"
/sbin/cryptsetup status $MAPPER
fi
exit 0
FILE=/home/bob/safe.img
MAPPER=safe
MAPDEV=/dev/mapper
DEVICE=/dev/loop0
FS=ext3
MOUNTPOINT=/mnt/safe
STATUS=`mount |grep $MAPPER`
PID=$?
if [ $# != 1 ]
then
cat <<EOF
usage: `basename $0` mount|umount|status
mount: mount $FILE
umount: umount $FILE
status: gives a short status about the encrypted filesytem
EOF
exit 2
fi
if [ $1 == "mount" ]
then
if [ $PID -eq 0 ]
then
cat <<EOF
It seems $MAPPER is already mounted.
Mount status: $STATUS
EOF
exit 3
fi
echo "mounting"
/sbin/losetup $DEVICE $FILE
/sbin/cryptsetup -y create $MAPPER $DEVICE
mount -t $FS ${MAPDEV}/${MAPPER} $MOUNTPOINT
elif [ $1 == "umount" ]
then
if [ $PID -eq 1 ]
then
cat <<EOF
It seems $MAPPER is already umounted.
Mount status: $STATUS
EOF
exit 4
fi
echo "umounting"
umount $MOUNTPOINT
/sbin/cryptsetup remove $MAPPER
/sbin/losetup -d $DEVICE
elif [ $1 == "status" ]
then
echo "status"
/sbin/cryptsetup status $MAPPER
fi
exit 0
Anzupassen sind die Variablen ganz am Anfang des Skriptes. Wenn das geschehen ist, reicht ein "cm mount" zum einhängen, "cm umount" zum aushängen und "cm status" um einen Status des Dateisystems zu erhalten.
Eventuell müssen alle mount, umount und cryptsetup Aufrufe mittels sudo geschehen (so ist das zumindest bei mir, aber anhand der Doku von dm_crypt sollte es auch ohne gehen).
6. Linkdump:
Schwachstelle von Cryptoloop
Cryptoloop HOWTO des Linux Documentation Projects
Loop-AES Projekt auf Sourceforge.net
dm_crypt Projekt als Nachfolger von Cryptoloop seit Kernel 2.6.4 im Kernel vorhanden
dm_crypt Mini HOWTO
Kernel-HOWTO
Debian Kernel-HOWTO
Trackbacks
Warum sagt mir eigentlich keiner was?
Das erklärt natürlich den Haufen Abrufe von dem Artikel Verschlüsselte Dateisystem: Bei Google mit dem Suchwort dm_crypt auf Platz 1 und mit dem Stichwort verschlüsselte Dateisysteme auf Platz 7. Hm, na ich will mich nicht beschweren, wozu schreibe
Das erklärt natürlich den Haufen Abrufe von dem Artikel Verschlüsselte Dateisystem: Bei Google mit dem Suchwort dm_crypt auf Platz 1 und mit dem Stichwort verschlüsselte Dateisysteme auf Platz 7. Hm, na ich will mich nicht beschweren, wozu schreibe
Weblog: 256bit.org Blog
Tracked: Jul 24, 21:13
Tracked: Jul 24, 21:13
Netzkultur
Vor einer Weile hab ich ja das Tutorial über dm-crypt geschrieben. So weit so gut. Das Tutorial war in Google auch recht hoch bewertet, so dass auch recht viel Traffic kam. Dauerte nicht lange, da wurde auch in einem Forum auf das Tutorial verlinkt. Jeman
Vor einer Weile hab ich ja das Tutorial über dm-crypt geschrieben. So weit so gut. Das Tutorial war in Google auch recht hoch bewertet, so dass auch recht viel Traffic kam. Dauerte nicht lange, da wurde auch in einem Forum auf das Tutorial verlinkt. Jeman
Weblog: 256bit.org Blog
Tracked: Oct 20, 19:31
Tracked: Oct 20, 19:31
...gleich mal ausprobieren.....
Da ein Hash-Algorithmus eine Einwegfunktion darstellt, besteht keine Möglichkeit aus dem Hash Wert auf den verwendeten Schlüssel zu schließen. Natürlich immer unter der Voraussetzung, dass der verwendete Hash-Algorithmus tatsächlich ein kryptographisch sicherer ist, d.h. Unumkehrbarkeit und Kollisionsfreiheit können nicht garantiert werden.
Also die Passphrase immer schön merken
3.5 GB große Datei hin- und her kopiert zwischen zwei Partitionen, so dass dateisystemspezifisches Caching ausgeschlossen werden kann. Findet leider alles auf einer Platte statt, ich kann also nicht ausschließen, dass die Festplattenelektronik doch noch etwas cacht (was aber bei 3.5 GB Daten wohl ausgeschlossen werden kann).
Bei 3 Versuchen benötigt man beim Kopieren von einer Partition auf die andere im Durchschnitt 196 Sekunden, das Kopieren auf das verschlüsselte Dateisystem ist im Mittel nach 263 Sekunden abgeschlossen. Gleichzeitig stieg die CPU-Auslastung stark an.
Das entspricht einer effektiven Transferrate von 18,2 MB/sec gegenüber 13.6 MB/sec. Die Transferrate ist also ca: 25% geringer, was der Verschlüsselung geschuldet sein sollte.
Also ich für meinen Teil finde das akzeptabel, zumal die Verschlüsselung transparent beim Zugriff abläuft und man nicht beim mounten/umounten auf das Ver-/Entschlüsseln warten muß.
Das ist natürlich kein ausgiebiger Test, eigentlich hätte man wahrscheinlich zwischen verschiedenen Platten kopieren sollen, aber mangels 2ter Platte und großem RAM, dürfte das als Anhaltspunkt genügen. Hinzu kommt natürlich die Abhängigkeit vom verwendeten Verschlüsselungsalgorithmus. Der hier verwendete war AES, der auch eine gute Performanz besitzt. Bei anderen Verschlüsselungsalgorithmen mag das anders aussehen (Serpent ist wohl langsamer).
Alles in allem bin ich recht zufrieden. Spürbare Unterschiede wird man wohl nur selten bemerken, also nur dann wenn man wirklich sehr große Dateien bearbeitet/lädt/speichert.
Ich selber habe bis jetzt nur relativ kleine Dateien im Container gespeichert, so dass mein subjektiver Eindruck sogar noch besser ist, als der hier vermittelte objektive
wollte mich nur mal für den super Artikel bedanken. Ist nicht das 1. Mal dass ich den gebrauchen kann... man merkt sich ja auch nicht alles
Gruß
Michael