Verschlüsseltes Verzeichnis: Unterschied zwischen den Versionen
GerBra (Diskussion | Beiträge) KKeine Bearbeitungszusammenfassung |
GerBra (Diskussion | Beiträge) Änderung 3102 von GerBra (Diskussion) wurde rückgängig gemacht. |
||
Zeile 66: | Zeile 66: | ||
strings /dev/nbd0 | strings /dev/nbd0 | ||
strings /tmp/mycrypt | strings /tmp/mycrypt | ||
findet jetzt als "Text" nur "wirres Zeug". Ohne diese Verschlüsselung würde der Befehl z.B. | findet jetzt als "Text" nur "wirres Zeug". Ohne diese Verschlüsselung würde der Befehl z.B. noch die Dateinamen aus dem Kopiervorgang (/bin) anzeigen. | ||
Version vom 1. November 2007, 19:32 Uhr
Wie kann ich z.B. private Daten so ablegen, daß diese von niemandem - auch nicht von root - gelesen werden können? Oftmals hat man ja die Notwendigkeit, etwas verschlüsselt ablegen zu müssen. Eine einzelne Datei läßt sich ja noch mit gpg verschlüsseln. Was aber, wenn man Verzeichnisse mit Unterverzeichnissen verschlüsseln will? Und darauf am besten auch noch wie auf eine "normale" Partition zugreifen will, also Mounten in den Verzeichnissbaum? Oder diese verschlüsselte Struktur auch über das Netzwerk benutzen will?
Die Lösung heißt hier: Luks Encryption. Mit diesem im Kernel enthalteten Verschlüsselungs-Standard können Partitionen verschlüsselt werden, zum Entschlüsseln und Benutzen ist ein Paßwort ("Passphrase") nötig. Luks und das Tool cryptsetup werden vornehmlich zum Verschlüsseln ganzer Partitionen, Festplatten oder des gesamten Systems verwendet (z.B. bei Laptops, die leicht gestohlen oder verloren gehen können). Dazu gibt es auch unter [1] einen Beitrag.
Brauche ich nun also eine freie Partition, damit ich das nutzen kann? Nein. Dieser Artikel zeigt, wie man am Ende eine beliebig große Datei wie eine Festplatten-Partition nutzen kann und diese dann formatieren, verschlüsseln und wie eine reale Partition ins Dateisystem einhängen kann.
1.Vorbereitung
Wir benötigen aus dem AUR ein Paket namens nbd, welches wir uns auch kompilieren müssen. Das ist aber weiter nicht schwierig. (NB: Momentan ist dieses Paket im AUR verwaist und von der Version nicht auf dem letzten Stand. Ich werde dieses Paket demnächst übernehmen und aktualisieren. Dann ist folgender Akt teilweise nicht mehr nötig)
mkdir /var/abs/local cd /var/abs/local wget http://aur.archlinux.org/packages/nbd/nbd.tar.gz tar xvf nbd.tar.gz cd nbd nano PKGBUILD (im Editor folgendes ändern: pkgver=2.9.8 Die Zeile mit md5sums löschen) makepkg -g >> PKGBUILD makepkg pacman -U nbd-2.9.8-1-i686.pkg.tar.gz
Das installiert uns u.a. zwei Programme: nbd-server und nbd-client.
Nbd (Network Block Device) ist ein Mechanismus, der seit längerem im Linux-Kernel ist. Mittels nbd können beliebige Dateien (aber auch "reale" Blockdevices wie Partitionen oder CD-laufwerke) über TCP/IP Clients zur Verfügung gestellt werden. Von diesen können diese dann wie reale laufwerke benutzt werden. Oben installiertes Paket stellt uns dann die Tools bereit, um mit diesen Devices zu arbeiten.
2. Vorgehen
Hier werden wir ein Beispiel durchspielem, damit man sehen kann wie die einzelnen Punkte zusammenhängen. Später werden wir dann etwas Komfort erstellen. Es ist deshalb auch wichtig, momentan als root zu arbeiten.
Als erstes erstellen wir uns eine Datei, die später unsere "Partition" ist.
dd if=/dev/zero of=/tmp/mycrypt bs=1M count=100
Das erstellt uns eine 100MB große Datei /tmp/mycrypt, die momentan komplett aus Nullen besteht.
Dann werden wir diese Datei als "Partition"(Blockdevice) nutzen, mittels nbd:
modprobe nbd nbd-server 127.0.0.1:2000 /tmp/mycrypt (die Warnung wegen fehlender Konfig kann ignoriert werden) nbd-client localhost 2000 /dev/nbd0
Was haben wir momentan: nbd stellt uns die Datei als Blockdevice zur Verfügung, angesprochen wird diese vom Client indem eine Verbindung zwischen dem Server-Prozeß auf Port 2000 und dem Device /dev/nbd0 erstellt wird. /dev/nbd0 ist nun für uns ein ganz normales Blockdevice wie z.B. /dev/sda1. So können wir es z.B. mit cfdisk /dev/nbd0 öffnen (wir sehen eine normale Festplatte, aber bitte nicht partitionieren).
Diese Device werden wir jetzt für die Verschlüsselung vorbereiten:
modprobe dm-crypt modprobe aes-i586 cryptsetup -y luksFormat /dev/nbd0 cryptsetup luksOpen /dev/nbd0 privat
Letzterer Befehl öffnet das verschlüsselte Device (nach Abfrage der Passphrase) und stellt uns den unverschlüsselten Zugriff über das spezielle Device /dev/mapper/privat zur Verfügung.
Jetzt fehlt unserem Blockdevice noch ein Dateisystem (hier z.B. ext3):
mkfs.ext3 /dev/mapper/privat
Nun wollen wir es auch benutzen:
mkdir /mnt/privat mount /dev/mapper/privat /mnt/privat
Die Befehle: mount oder df -h zeigen uns jetzt dieses eingebundene Device mit der richtigen Größe. Schreiben wir mal etwas:
cp -r /bin /mnt/privat/
Schließen wir alles:
umount /mnt/privat cryptsetup luksClose privat
Der Inhalt des nbd-Device /dev/nbd0 bzw. der der Ursprungs-Datei /tmp/mycrypt ist jetzt verschlüsselt.
strings /dev/nbd0 strings /tmp/mycrypt
findet jetzt als "Text" nur "wirres Zeug". Ohne diese Verschlüsselung würde der Befehl z.B. noch die Dateinamen aus dem Kopiervorgang (/bin) anzeigen.