Diese Anleitung entstand ursprünglich in den Sommerferien 1997 aus einem Schulprojekt und beschrieb wie man mittels crypt(1) einzelne Dateien verschlüsselt. Später habe ich GnuPG erweitert und wieder entfernt und mich auf das verschlüsselnde Dateisystem CFS konzentriert. Da ich meine Webseite damals noch nicht im CVS versioniert habe, liegt nur die letzte Version von ca. Sommer 2002 vor, die sich auf CFS auf NetBSD und FreeBSD so wie einem Workaround für NetBSD/Alpha konzentriert – bevor CGD herauskam. — Der Autor

Dateien schützen durch Verschlüsselung

Warum sollte man Kryptographie benutzen?

Es gibt zwar unter den Unices Benutzer und entsprechende Rechte, dies kann aber jeder Superuser einfach umgehen und aushebeln. Sollte also z. B. jemand in Besitz unserer Datenträger kommen ist es ein Leichtes diese in einem anderen System zu mounten und auszulesen. Daher ist es notwendig und wünschenswert die Daten mittels Verschlüsselung zu schützen.

Es gibt verschiedene Grundprinzipien in der angewandten Kryptographie:

Dateiweise Verschlüsselung

Die Dateiweise Verschlüsselung ist prinzipiell sehr einfach, es werden die angegebenen Dateien mit einem Verschlüsselungsprogramm ver-/entschlüsselt. Dies ist allerdings im täglichen Gebrauch kaum praktikabel und daher hinderlich. Ausserdem liegen die Dateien teilweise im unverschlüsselten Zustand auf der Platte und sind damit ungeschützt gegen Netzwerkkompromittierung oder bei Abstürzen. Das bekannteste Beispiel dürfte PGP respektive GnuPG und crypt sein.

Volume Verschlüsselung

Volume Verschlüsselung wird meistens im Device Driver Layer implementiert und ver/entschlüsselt die Daten beim Zugriff auf die Festplatte. Für gewöhnlich werden dazu Container angelegt die verschlüsselt auf der Platte liegen und bei Bedarf entschlüsselt werden, um die Daten einzubinden. Dieses Prinzip ist praktikabel für Einzelnutzer Systeme, da das Austauschen von Daten prinzipiell recht schwierig ist, allerdings ist es recht einfach ein Backup zu fahren da nur der Container gesichert wird. Ebenso lässt sich speziell als Backup ein verschlüsselter Container einsetzen welcher gesichert wird. Problematisch ist die Situation wenn der Container gemountet ist und der Rechner kompromittiert wird oder abstürzt. Vorteile sind die prinzipielle Austauschbarkeit der Container unter verschiedenen Betriebssystemwelten, sofern die Programme dies anbieten. Beispiele sind: BestCrypt, PGPDisk oder mein unten beschriebene Workaround

Kryptographische Dateisysteme

Kryptographische Dateisysteme bieten die Verschlüsselung im Dateisystem an und sind somit wesentlich komfortabler und richtig eingesetzt sicherer

• transparenter Zugriff, die Verschlüsselung fällt dem Benutzer bis auf die Eingabe des Passworts nicht weiter auf
• erleichtert die Administration und Backups
• verschiedene Zugriffsmöglichkleiten auf Benutzer-/Gruppen-/Dateibasis
• Audits und Integritätsprüfungen werden vereinfacht
• Schutz auch bei physischem Zugriff auf dem Datenträger

Anwendungen sind u.a. CFS und TCFS

Containerkryptographie unter NetBSD:

Da es für NetBSD/Alpha keine cfs-Implementierung gibt, habe ich einen kleinen Workaround mit mkisofs und mcrypt gebaut. Prinzipiell erstellt man ein ISO-Image welches bei Bedarf als Pfad eingebunden wird und ansonsten verschlüsselt auf der Platte liegt. Die Erstellung: Als erstes nimmt man eine geeignet grosse Datei um aus ihr ein ISO zu bauen, zum Beispiel ein Video oder eine Datei die mittels

$dd if=/dev/urandom of=container.fuellung bs=64k count=100

gebaut wurde. /dev/urandom ist unter den meisten Unices vorhanden und stellt einen Zufallsgenerator dar, welcher sich anbietet um den Container zu füllen. Alternativ kann man auch /dev/random oder /dev/zero verwenden. dd ist ein Programm das u. a. blockweise kopiert und hier benutzt wird um eine bestimmte Dateigröße zu erzeugen. mit bs=64k wird die Blockgröße auf 64kB gesetzt und mit count=100 bestimmt das 100 Blöcke geschrieben werden, man erhält also 100*64 Kilobytes = 6'553'600 Bytes.

Als nächstes erstellt man ein ISO-Image der Datei, so wie es auch zum CD brennen benutzt wird, mit

$mkisofs -o container.image -r -T -J container.fuellung 

nun haben wir das Image, in welches unsere Daten kommen und das verschlüsselt wird. Zum verschlüsseln können beliebige Programme wie z.B. OpenSSL, GnuPG oder crypt verwendet werden, ich verwende das in der Portscollection enthaltene mcrypt, welches auf den verschiedenen Posix-kompatiblen OS läuft. Verschlüsselt wird mit:

$mcrypt -a rijndael-256 container.image

Dies dauert je nach Rechner und Datengrösse entsprechend und erzeugt eine Datei mit der Endung .nc, hier also container.image.nc mcrypt erlaubt auch weitere Optionen wie z.B. komprimieren mit bzip2 was z.B. bei Mailboxen oder Textdateien anzuraten ist, bei einem ISO-Image aber nur unnötig Zeit kostet. Wir haben jetzt also drei Dateien vorliegen: container.fuellung ist die Fülldatei container.image ist das ISO-Image container.image.nc ist das verschlüsselte ISO-Image Fuellung und Image können jetzt gelöscht werden, dazu verwendet man idealerweise einen sogenannten Wiper, da mit rm die Daten nicht überschrieben werden und die Datei so wiederhergestellt werden kann Dazu bietet sich das kleine Programm bcwipe von http://www.jetico.com/download.htm" an, welches ebenfalls auf ziemlich allen Unixen laufen sollte. Das wipen funktioniert in dem die Datei mit Zufallsdaten aus /dev/urandom mehrfach überschrieben wird. Das US Department of Defense hat einen

Standard hrausgegeben, wonach eine Datei siebenmal überschrieben werden muß, also kann man davon ausgehen das diese Methode auch für uns ausreichen sollte, (bcwipe kann bis zu 35 mal wipen). Dies geschieht mit dem Befehl $bcwipe -I -q container.image sollte kein sicherer Wiper zur Verfügung stehen greift man gezwungernermaßen auf die rm Option -P zurück, welche allerdings nur dreimal mit 0 überschreibt und daher nicht wirklich sicher ist. Nach dem wir nun erfolgreich die Daten verschlüsselt und gewiped haben, binden wir das Image in das Dateisystem ein, um es als ganz normalen Pfad ansprechen zu können. Dazu entschlüsseln wir es per $mcrypt -d container.image.nc und Eingabe der Passphrase. Es liegt nun wieder die Datei container.image.nc und die unverschlüsselte container.image vor, welche eingebunden wird. Unter NetBSD funktioniert dies über die vnd0-Devices mit der Befehlsfolge:

$vnconfig -v vnd0 container.image

das Image wird an vnd0 gebunden

$mount -r -t cd9660 /dev/vnd0a /verschlüsseltes/zeugs

und gemountet

$vnconfig -u 

entbindet das Image von vnd0

Solange das Image nach /verschlüsseltes/zeugs gemountet ist, kann man diesen Pfad ganz normal benutzen und Daten darin verstauen. Nach dem unmount wird alles in das Image zurückgeschrieben und kann nun wie bereits beschrieben verschlüsselt und dann sicher gelöscht werden.

Mit dem selben Prinzip kann man Daten auf CD sichern indem man nun das verschlüsselte Image erneut in ein ISO-Image überführt und dieses brennt. Sollten die CDs zwischen verschiedenen Betriebsystemwelten ausgetauscht werden, kann man statt eines ISO-Images einen tarball oder ein ARJ-Archiv mit PGP/GPG verschlüsseln und brennen.

cfs unter NetBSD

Cfs ist das Cryptographic Filesystem von Matt Blaze, welches als erstes FS Verschlüsselung implementierte und auf der Basis von NFS arbeitet. Der cfsd unterliegt bei NetBSD einer Besonderheit, er kann nicht mit dem nsfd zusammen laufen, da der NetBSD nfsd und das mount_nfs NFS nicht an einem anderen Port als 2049 binden können. Dies bedeutet, das eine Maschine, die als CFS-Server arbeitet, nicht ebenfalls NFS-Server sein kann. Das cfs-Paket sollte idealerweise aus den Ports installiert werden, wenn man es selber kompiliert, müssen unbedingt die Anweisungen aus readme.netbsd befolgt werden. Das Einrichten des cfsd funktioniert folgendermassen: Zuerst das Arbeitsverzeichnis für den cfsd erstellen:

$ mkdir /null
$chmod 0 /null 

danach selbiges exportieren lassen:

$ echo /null localhost >> /etc/exports

nun den mountd starten (oder killen und neu starten, falls er bereits läuft) und den benötigten cfsd starten

$ mountd && cfsd

Nun wird der cfs mount point installiert:

$ mkdir /crypt

und mittels

$ mount -o intr,-2 127.0.0.1:/null/ /crypt

werden die beiden benötigten Arbeitsverzeichnisse des cfsd gemountet. Die Angabe von 127.0.0.1 ist notwendig, da es mit localhost wegen der IPv6 Unterstützung nicht fuktionieren würde. mountd und cfsd sollten nun automatisch in der /etc/rc.conf gestartet werden. Nun erstellen wir ein verschlüsseltes Verzeichnis:

$ cfs_mkdir cryptostuff

und übergeben eine ausreichend starke, lange und nicht im Wörterbuch stehende Passphrase. Dieses Verzeichnis ist der Ort in dem die Dateien verschlüsselt liegen und wird mit:

$ cfs_attach cryptostuff/ nutzbares_cfs

nach Übergabe des Passphrase eingebunden. Das Verzeichnis erscheint dann als /crypt/nutzbares_cfs und ist als dieser Pfad ganz normal schreib- und lesbar genutzt werden. Ausgekoppelt wird es mit

$ cfs_detach nutzbares_cfs

von jedem beliebigen Pfad aus und ohne die Angabe des Passwortes. Der Algorithmus, mit dem die Dateien verschlüsselt werden, kann bei der Erstellung des Verzeichnisses mit cfs_mkdir übergeben werden. Momentan (cfsd 1.4.1) sind die Algorithmen SAFER-SK128, MacGuffin, DES/2DES/3DES und Blowfish verfügbar. 3DES ist von diesen Algorithmen am ältesten und durch seinen Einsatz als Standardalgorithmus in der USA sehr gut untersucht.

cfs unter FreeBSD

Einrichtung: Zuerst installiert man cfs als Package oder mit cd /usr/ports/security/cfs && make install clean aus der Portscollection. Als nächstes muss der cfsd eingerichtet und gestartet werden. Dazu fügt man in /etc/exports die Zeile /var/tmp localhost ein um nur dem Localhost Zugriff auf dieses Verzeichniss zu geben.

Nun benötigen wir NFS und starten es mit portmap und mountd in /etc/rc.conf folgendermaßen:

single_mountd_enable="YES"
mountd_flags="-r"
portmap_enable="YES"
portmap_program="/usr/sbin/portmap"

Um das Dateisystem direkt im Bootprozess zu mounten editiert man die /usr/local/etc/rc.d/cfsd.sh und fügt folgendes vor “exit 0” ein:

mount -o port=3049,intr,nfsv2 localhost:/var/tmp /home/crypt

Wobei /home/crypt der Pfad ist unter dem das cfs die Daten verschlüsselt ablegt. Nun starten wir den Rechner neu und beginnen mit dem einrichten des eigentlichen cfs. Wir basteln jetzt ein Verzeichnis in das die verschlüsselten Daten kommen mit

cmkdir /home/user/crypted

(ab 1.4.0 heißt cmkdir cfs_mkdir) Ich erwähne noch einmal das die Passphrase ordentlich gewählt sein sollte! Nun binden wir es ins verschlüsselte Dateisystem mit

cattach /home/crypt /home/user/verschluesseltesArbeitsverzeichnis

(statt cattach evtl. cfs_attach verwenden) Nun existiert das Verzeichnis /home/user/verschluesseltesArbeitsverzeichnis das nicht einmal root betreten darf. Um das eingebundene und verschlüsselte Verzeichnis wieder auszubinden verwendet man den Befehl cdetach / cfs_detach

Schwachstellen der Kryptographie

Das größte Problem der Sicherheit ist der Zugang, sprich das Passwort. Was nützt AES mit 512 Bit wenn des Passwort der Name des eigenen Hundes ist? Es ist daher immanent wichtig sich eine Passphrase auszudenken, dies sollten also zum Beispiel ganze Sätze sein, wie : Ich wurde am 23.05.1980 in Blankenburg im schönen Harz geboren. Wir haben hier nun Groß/Kleinschreibung, Sonderzeichen und Zahlen, selbstverständlich sollte der Inhalt des Satzes nicht so offensichtlich zu erraten sein. Biometrische System sollten auch mit Vorsicht genossen werden, spätestens wenn eine Magnum Desert Eagle Kaliber .44 auf den Schädel des “Passwortes” gerichtet ist, kann es als schwach eingestuft werden. Ein weiteres und wesentlich subtileres Problem ist die systembedingte Unsicherheit eines Rechners, wie z. B. kompromittierende Strahlung des Monitors oder Kabel oder der Einsatz von Keyloggern in Form von Programmen oder als technisches Gerät am Tastaturkabel. Den allseits berühmten Klebezettel am Monitor brauche ich sicherlich nicht mehr zu erwähnen.

Ebenfalls problematisch ist der swap-Speicher, da es vorkommen kann, das zu schützende Daten in ihn gelangen. Wenn gpg oder mcrypt als Superuser ausgeführt werden, wird zumindest nichts in den swap geschrieben. Durch konsequentes Abschalten des swaps ist auch diese Sicherheitslücke umgangen. Sollen hochsensible Daten geschützt werden ist es wichtig den Rechner physisch zu schützen und ihn erst gar nicht in ein Netz einzubinden bzw. ein eigenes Netz anzulegen.

Kleine Benchmark mit mcrypt, rm und bcwipe

gemessen mit BASH-time: Datei: ISO-Image CD9660 aus Zufallsdaten (/dev/urandom) der Größe 96'600'064 Gemessen auf: DEC Alpha 21066 AXPpci mit 48 MB Ram und Seagate Barracuda SCSI Platte

Datei: ISO-Image CD9660 aus Zufallsdaten (/dev/urandom) der Größe 21'397'504

Datei: ISO-Image CD9660 aus MPEG-Videodaten der Größe 688'488'542 Gemessen auf: AMD K7 bei 1200MHz mit 512 MB Ram und Seagate Barracuda 7200rpm IDE Platte

[1] Es sei darauf hingewiesen das im Clinton/Lewinsky Skandal “gelöschte” eMails von Clinton verwendet wurden und es gelang die Daten der Rechner aus dem WTC zu restaurieren. Telepolis Artikel zu den WTC-Rechnern