Kryptographie

• * Warum sollte man Kryptographie benutzen?
• * Dateiweise Verschlüsselung
• * Volume Verschlüsselung
• * Kryptographische Dateisysteme
• * Containerkryptographie unter NetBSD:
• * cfs unter NetBSD
• * cfs unter FreeBSD
• * Schwachstellen der Kryptographie

* Warum sollte man Kryptographie benutzen? (Index)

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 (Index)

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 (Index)

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 (Index)

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: (Index)

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 mitcount=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[1]. Dazu bietet sich das kleine Programm bcwipe von
Jetico 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 (Index)

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 (Index)

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 un 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 (Index)

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 Pass*phrase* auszudenken, dies sollten also zum
Beispiel ganze Sätze sein, wie: Ich wohne seit 4 Wochen in Kleinkleckersdorf.
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. Wenngpg 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

Algorithmus	Verschlüsseln	Entschlüsseln
rijndael-128	4:38	3:16
rijndael-192	3:16	3:13
rijndael-256	3:18	3:07
Tripledes-56	12:27	11:45
Blowfish	2:23	2:08
rm -P	3:42	Dreifaches Überschreiben mit 0
bcwipe -q	20:56	Siebenfaches Überschreiben mit /dev/urandom

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

rijndael-256

0:42

0:39

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

rijndael-128	2:42	2:43
rijndael-192	2:52	2:45
rijndael-256	2:56	2:48
TripleDES	6:16	6:29
blowfish	2:05	2:02
OpenSSL enc des3	1:54	1:59

[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

\$Id: crypto.html,v 1.31 2014/08/21 09:24:03 stefan Exp $



$Log: crypto.html,v $
Revision 1.31  2014/08/21 09:24:03  stefan
Umlaute und Makefile clean up