Diskussion:DM-Crypt
Aus Gentoo Linux Wiki
Wie schaut das aus, wenn man das System komplett verschluesseln will, aber nur Zugriff per Netzwerk hat?
Ich bin dafür die "Laut-Gerüchten"-Box herauszunehmen. Dieses "Gerücht" ist mir weder bekannt, noch ist es mit einer Quelle belegt und gehört meiner Meinung nach nicht hier her.
Wenn es auf Sicherheit drauf ankommt, würde ich die Key-Datei auf keinen Fall unverschlüsselt auf einem USB-Stick ablegen, denn nach meiner Erfahrung (bin Sysadmin) werden diese oft aus Versehen irgendwo liegen-/steckengelassen. cryptsetup lieber mit einem Passwort aufrufen. Am sichersten: Key-Datei verwenden und diese zusätzlich mit gpg verschlüsseln. Das gpg-Passwort dient dann als Key, um den Key zu verschlüsseln. Wenn man ein starkes Passwort verwendet, kann man den verschlüsselten Key auch auf der Festplatte speichern. Aber Key + Passwort müssen in den Safe! Sonst sind alle Daten weg, falls Key/Passwort verloren/vergessen werden.
dd if=/dev/random count=1 | gpg --symmetric -a --cipher-algo aes > key.gpg # Schlüssel generieren + mit Pwd. verschlüsseln gpg --decrypt key.gpg | cryptsetup luksFormat /dev/sda3 # verschlüsselte luks-Partition erstellen
(2.12.2006)
Ist die erste Formatierung vor luksFormat nicht unnötig? Besser wäre eine urandom Überschreibung. Warum /dev/hda1 und nicht direkt /dev/hda? Ist es möglich ein /dev/mapper/_dev_hda erneut zu partitionieren?
- Stimmt, habe das Anwendungsbeispiel geändert. Direkt /dev/hda muss ich erst noch testen, wer es schon getestet hat, kann das Howto dahingehend ergänzen. /dev/mapper/* ist möglich zu partitionieren, jedoch werden keine devices erstellt, über die man dann dadrauf zugreifen kann. --Misterjack 16:10, 21. Mär 2006 (GMT)
Habe im Artikel "Loopback-Device" durch "Loop-Device" ersetzt, denn "Loopback" wird i.A. im Zusammenhang mit dem "Loopback-Interface" (127.0.0.0/8) verwendet (SK).
[Bearbeiten] Vorschlag: Partition mit Zufallszahlen füllen
Eine andere Möglichkeit eine Partition zu überschreiben wäre direkt ein Crypto-Mapping zu benutzen. Da es ein Designziel von Chiffriermodi ist nach Zufallszahlen auszusehen (wenigstens ab lrw), kann man diese auch als Pseudozufallszahlengeneratoren missbrauchen. Außerdem ist diese Methode deutlich schneller (circa 30 MB/s):
cryptsetup -d /dev/urandom -s 384 -c aes-lrw-benbi create target /dev/target dd if=/dev/urandom of=/dev/target bs=1M count=128 dd if=/dev/target of=/dev/mapper/target bs=1M seek=128
[Bearbeiten] Vorschlag: Loop Device verschlüsseln
bitte berichtigen, foolproof machen und gegen eventualitäten absichern: z.B.: loop/0 bereits belegt
einrichten (folgende zeilen in einer textdatei namens ein.sh speichern und mit
sudo sh ein.sh
ausführen.
#bitte korrekten pfad und dateiname hier eintragen P=/home/ftp/Kontainer.bin #groesse des Containers in MegaByte N=50 #name des erstellten Volumes V=Sicher #mountpoint M=/mnt/$V # # D=$(losetup -f) dd if=/dev/zero of=$P bs=1M count=$N losetup $D $P #(mit losetup -F und einem entsprechenden Eintrag in der fstab #auch ohne sudo möglich, siehe man losetup) cryptsetup -c blowfish-cbc-essiv:sha256 -y -s 256 luksFormat $D cryptsetup luksOpen $D $V mkdir $M mkfs.reiserfs /dev/mapper/$V # (für erneuten aufruf wieder schließen:) cryptsetup luksClose $V losetup -d $D
aufrufen:
sudo losetup /dev/loop/0 ~/Kontainer.bin sudo cryptsetup luksOpen /dev/loop/0 Sicher sudo mount /dev/mapper/Sicher /mnt/Sicher
schließen:
sudo umount /dev/mapper/Sicher sudo cryptsetup luksClose Sicher sudo losetup -d /dev/loop/0
löschen:
sudo rmdir /mnt/sicher sudo shred ~/Kontainer.bin
[Bearbeiten] pam_mount: (u)mount.crypt
Bei pam_mount sind die Skripte (u)mount.crypt bei, die einem recht angenehm erlauben, (Luks) verschlüsselte Partitionen zu (u)mounten. mount.crypt versteht auch "-o fsck", was bewirkt, dass verschlüsselte Partitionen auch mal einem fsck unterzogen werden, wenn das Limit erreicht ist. Till 21:15, 8. Apr 2006 (GMT)
Achja, es kann auch mit loop etc umgehen, lohnt sich auf jeden Fall mal auszuprobieren, da man so nicht evt. etwas im selbstgeschriebenen Skript übersieht und falsch macht. Till 21:17, 8. Apr 2006 (GMT)
[Bearbeiten] root verschluesseln
damit mal ein anfang gemacht ist: wenn root verschluesselt werden soll, muss die initrd entschluesseln koennen. unter debian ist das angeblich schon drin und muss nur aktiviert werden
[Bearbeiten] initrd/initramfs möglichst klein
Man kann übrigens, mit etwas Aufwand auch cryptsetup gegen die uclibc linken. Wenn man z.B. auf dem USB Stick nur eine 2. kleine Partition fürs Booten eines verschlüsselten rootfs nutzen möchte. Das Initramfs wird dann deutlich kleiner (ca. 400kb auf i386). Wenn man aber genug Platz hat/opfern möchte, muss man sich den Stress allerdings nicht antun. Wenn man nicht von USB booten kann, wäre damit eventuell auch booten von der Floppy möglich (wobei das natürlich quälend langsam ist). Hier habe ich mal meinen aktuellen Stand hochgeladen: http://home.arcor.de/irc-stuff/software/initramfs/index.html
[Bearbeiten] Umstieg von cryptsetup auf cryptsetup-luks
Ist soetwas möglich? Habe meine Partition auf alte Weise verschlüsselt. Muss ich die Daten in unverschlüsselter Weise auf eine Festplatte kopieren, und das neueinrichten oder gibt es eine "Upgrade" möglichkeit?
[Bearbeiten] Rechtslage ?
Was ist mit dem Satz "Vorsicht Die Rechtslage ist unsicher, wenn du das Keyfile verlierst!" gemeint ? Wenn man das Keyfile verliert sind die Daten weg. Aber was hat das mit Rechtslage zu tun ?
Hallo, habe mich genau das auch gefragt und den Teil rausgenommen. Ich denke hierbei handelt es sich um ein Relikt aus einer übersetzten Version des amerikanischen Artikels. In DE ist es aber (noch) nicht soweit, dass man sich als Beschuldigter selbst belasten und das PW an die Strafverfolgungsbehörden weitergeben muss.
Zur derzeitigen Rechtslage in Deutschland könnte der Vortag Udo Vetters auf dem 23C3 interessant sein ("Sie haben das Recht zu schweigen" [1]) Tenor: Man muss Passwörter nicht rausrücken, da man nicht gezwungen werden darf, sich selbst zu belasten. (IANAL)
[Bearbeiten] Wie viele Atome hat das Universum?
Zitat: "Durch die beliebige Variierbarkeit müsste ein Universalwörterbuch mehr Einträge als Atome im Universum besitzen, um auf alle möglichen PBKDF2-Kombinationen zu passen."
Ich halte diesen Satz für übertrieben bzw. falsch. Wie viele Atome hat denn das Universum?
Kein seriöser Physiker wird diese Frage mit einer Zahl beantworten. Es wäre angebrachter einfach eine Zahl zu nennen. (EDIT, Calvin) Ein Matheprofessor würde darauf sagen das die Zahl hinreichend groß ist. (/EDIT, Calvin)
Es gibt circa 10^80 - 10^85 Teilchen im sichtbaren Universum (also weniger Atome). Das laesst sich berechnen. --Ein serioeser Physiker
Hi, eine genau Zahl wird sicherlich niemand nennen können. Wobei, der Highlander, wenn er lange genug durchhält und Nachts nicht einschlafen kann... :-) Aber Schätzen ist erlaubt und man Schätzt die Zahl der Atoma im Universum auf irgendwas um die 10^79. Das wären dann Pi x Daumen 2^262 Bit :-)
- Eine Zahl zu nennen, unter der sich keiner etwas vorstellen sieht nicht so schön aus wie der Satz. So ähnlich stehts übrigends auch im Magazin drin, also ich plädiere dafür den so stehen zu lassen ;) --Misterjack 14:55, 24. Apr 2007 (UTC)
[Bearbeiten] Warum extra init-script für verschlüsselten Swap?
Da der Schlüssel für den Swap bei jedem Hochfahren zufällig erzeugt wird ist mir nicht einsichtig, warum die LUKS-Funktionalität verwendet werden sollte. In Sachen kryptographischer Sicherheit kann ich keine Vorteile entdecken, weshalb der Teil mit dem gesonderten Init-Script das Aufsetzen der Verschlüsselung nur unnötig erschwert. Anyone?
In der Tat: LUKS ist für die Verwendung von durch Zufallsschlüssl verschlüsselten Daten (swap, /tmp) nicht notwendig. Werde daher die Tage den Abschnitt über verschlüsselten Swap entsprechend ändern.
--dmaus 11:34, 24. Feb 2007 (UTC)
[Bearbeiten] RAID
Mich überrascht das sich noch kaum jemand der Verschlüsselung von root auf einem RAID angetan hat. Ich plane ein RAID 1 root und ein RAID 5 "Datenlager", traue mich aber nicht an das init-Skript heran. Zum rumprobieren fehlt mir momentan leider die Hardware und somit die Testumgebung. Es wäre super wenn sich da tatsächlich jemand die Zeit dafür nehmen könnte. Dies hier könnte als Grundlage dienen: http://www.saout.de/tikiwiki/tiki-index.php?page=RootCryptoraid
[Bearbeiten] Keyfile aus /dev/random?
Im Beispiel zur Erzeugung des Keyfiles wird /dev/urandom verwendet:
head -c1024 /dev/urandom >/mnt/usb/key.sda1
Wäre es nicht sicherer /dev/random zu verwenden oder spielt die Pseudozufallszahlenproblematik hier keine Rolle?
[Bearbeiten] "aes-lrw-benbi:sha256 -s 384", RAID1, amd64
Diese Kombination hat bei mir nicht funktioniert. Beim luksOpen habe ich im Log immer folgende Fehlermeldung bekommen:
device-mapper: table: device /dev/md5 too small for target device-mapper: table: 253:2: crypt: Device lookup failed device-mapper: ioctl: error adding target to table device-mapper: ioctl: device doesn't appear to be in the dev hash table.
Das cryptsetup sollte unter einem amd64 System auf einer knapp 50 Gig Raid1 Partition laufen. Verwendet habe ich kernel 2.6.23.1. Ich konnte leider nicht genauer untersuchen ob das Setup ohne ein Raid dazwischen funktioniert haette, oder woran es genau liegt. "aes-lrw-benbi -s 256" beim luksFormat hingegen hat funktioniert und luksOpen war erfolgreich. Da ich aber nicht sicher bin welchen Einfluss die Parameteraenderung auf die Sicherheit hat, habe ich mich stattdessen fuer "aes-cbc-essiv:sha256 -s 256" entschieden, was problemlos zu laufen scheint.
- gleiches problem hier: "emerge -C cryptsetup-luks && emerge -av cryptsetup" hat geholfen. Wie es scheint, brauch man für "-s 384" cryptsetup >=1.0.5.
[Bearbeiten] Mehrere Keys in einem gpg verschluesselten Archiv parken
Ich moechte spaeter mehrere Partitionen mit dmcrypt verschluesseln, jedoch ohne beim Booten jedesmal einen eigenen Key fuer alle Partitionen eingeben zu muessen. Da das dm-crypt-start.sh dies nicht unterstuetzt und auch noch einen Fehler im gpg-Handling beim Booten hat (siehe http://gentoo-wiki.com/Talk:SECURITY_System_Encryption_DM-Crypt_with_LUKS#Bug_in_dm-crypt-start.sh_when_using_gpg_encrypted_keys ), habe ich mich fuer ein kleines selbstgebasteltes Script entschieden, das ich nach dem Booten manuell ausfuehre. Dabei lege ich alle plaintext-Keys in ein Verzeichnis, packe dies mit tar, und verschluessele das tar mit gpg. Wichtig ist das man alle plaintext Files mit shred oder aehnlichem anschliessend beseitigt. Das Script entschluesselt den gpg-file, entpackt das Archiv, fuehrt cryptsetup luksOpen aus, mountet und raeumt mit shred auf:
#!/bin/bash /usr/bin/gpg --output /root/crypt.tar --decrypt /root/crypt.tar.gpg /bin/tar xvf crypt.tar /sbin/cryptsetup luksOpen /dev/md5 crypt-home --key-file /root/crypt/key.md5 /usr/bin/shred -u /root/crypt/* /bin/rmdir /root/crypt /usr/bin/shred -u /root/crypt.tar mount /mnt/dump1
Shred funktioniert nicht korrekt auf Dateisystemen mit Journal oder Logs (siehe man shred). Stattdessen lieber ein (kleines) tmpfs nehmen, die Schlüssel dort lagern, und unmounten, wenns nicht mehr gebraucht wird. Wenn swap verschlüsselt wird, ist das recht sicher.
Sehr einfach also, aber imho recht wirkungsvoll. Man sollte bereits vorher swap und /tmp verschluesselt haben damit nicht noch irgendwelche Reste irgendwo rumliegen. Ausserdem ist das Script prizipiell anfaellig gegen timing Attacken, da die Keys ein paar Sekunden ungeschuetzt auf der Platte liegen. Also in Summe sicher nicht ideal das Ganze. Auf die Tour kann man aber zumindest mehrere Partitionen mit einem gpg-Schluessel verwalten. Wenn man zusaetzlich noch einen Dummyeintrag fuer jedes Device unter /etc/conf.d/cryptfs (mit einem nicht existenten Schluessel) anlegt, dann sorgt das gentoo Script dm-crypt-stop.sh beim Herunterfahren automagisch dafuer das die Devices korrekt ausgehaengt werden (luksClose). Leider hat dies zwar eine Warning beim Booten zur Folge, aber so spart man sich wenigstens ein gesondertes stop-Script.
[Bearbeiten] Software-Suspend
Ich habe in einem Paragraphen grob beschrieben, wie man Software-Suspend mit verschlüsselter root-Partition benutzt (so wie es bei mir verwendet wird). Wäre glaube ich nicht schlecht, wenn jemand das mal aufgreift, etwas verallgemeinert (damit auch Leute, die nur /home, /tmp und swap verschlüsseln was davon haben). Eventuell auch noch ein paar Details hinzufügen und die Scripte anpassen (ich benutze kein Gentoo, daher kann ich keine Details liefern). Hier der Teil aus dem init-Skript, den ich geändert habe:
[...]
# Swap-Partition (die verschlüsselte):
SWAP_DEV=/dev/hda1
# Namen des Mappers
SWAP_MAP=swap
[...]
# == Hier kommt der Luks-Teil
[...]
# Nutzereingabe:
echo " --- Enter passphrase for root partition ---"
read -s pass
echo
# Versuchen, Swap Partition zu mounten:
echo "${pass}" | cryptsetup luksOpen ${SWAP_DEV} ${SWAP_MAP}
mainsucc=$?
# root nur versuchen, wenn swap erfolgreich
if [ ${mainsucc} -eq 0 ] ; then
# Versuche resume (Software Suspend)
if [ -n "$(echo $CMDLINE|grep resume=)" ] ; then
echo "Trying Resume..."
resume
fi
# resume fehlgeschlagen
echo "Resume failed. Continuing normal boot process"
# Versuchen, root Partition zu mounten:
echo "${pass}" | cryptsetup luksOpen ${ROOT_DEV} ${ROOT_MAP}
fi
sesam=$mainsucc
done
[...]
[Bearbeiten] Automatisches mounten?
Also ich weiß ja nicht, der Artikel erwähnt nirgendwo, ob die verschlüsselten Partitionen auch gemountet werden - sollten sie wohl, werden sie aber bei mir nicht. Woher kommt diese Info? Ich habe meine /etc/fstab richtig gesetzt, trotzdem wird mein /dev/mapper/crypt-home und /dev/mapper/crypt-tmp nicht automatisch gemountet (obwohl bei tmp die pre_mount Befehle abgearbeitet werden). Das ist extrem nervig. Braucht man dazu ein zweites Skript in rc-update? Muss dmcrypt boot oder default Runlevel sein? ICh finde, das gehört in den Artikel rein, ich komm da grad nicht weiter.
[Bearbeiten] Unzureichend...
Kann mir jemand den Grund dafür nennen warum die Ausgabe von 'dmsetup targets' kein 'crypt v1.5.0' enthalten sollte? Das geht aus dem HowTo nicht hervor, geschweige denn was man in einem solchen Fall machen kann/muss.
