cfs 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.
free 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 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
schwach 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 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
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
net-tex.de, Index
$Id: crypto.html,v 1.29 2010/06/09 06:31:33 stefan Exp $
Autor: Stefan Schumacher,
stefan@net-tex.de, PGP-Key 0xB3FBAE33
für net-tex.de/cryptomancer.de
Bitte beachten Sie, das die Seite inhaltlich seit Ende 2007 nicht mehr gepflegt wird!
Aktuellere Informationen erhalten Sie auf Kaishakunin.com