[gelöst] Fragen zu dd/LVM/LUKS

[Patsche]

Hi, Leute!
Ich habe vom Weihnachtsmann eine neue Festplatte unter den Baum gelegt bekommen. Sie ist 1TB mit groß. Diese möchte ich nun mit LUKS verschlüsseln. LVM benötige ich nicht, da die gesamte Festplatte verschlüsselt werden soll. Nun zu meiner Frage. Vorher möchte man natürlich die Festplatte mit Zufallszahlen beschreiben. Wie lange dauert so etwas für gewöhnlich? Wie ich gelesen habe kommt es natürlich "bs-Wert" und den "count-Wert" an, den ich dd mitliefere. Was empfehlt ihr? OK, diese Frage steht nur bedingt mit LUKS in Verbindung. Aber ich habe noch eine. Ich habe hier eine externe Festplatte, welche im NTFS-Format formiert wurde. Ist es möglich LUKS mit dem NTFS-Dateisystem zu nutzen? Oder funktioniert das nur mit "Linux-Dateisystemen"? Und noch eine. Ich hole mir demnächst noch eine HDD, die ich als 2.HDD im Laptop via ultrabay verbaue. Kann ich 2 Festplatte in ein LVM packen, und dann dieses LVM mit LUKS verschlüsseln? Also damit ich nur ein Passwort benötige?

[binarycode]

Hallo,

Laut Ubuntuusers soll man folgendes nutzen http://wiki.ubuntuusers.de/LUKS#Erstellen :

sudo dd if=/dev/urandom bs=1M count=8 of=GERÄTEDATEI

Es gibt da noch folgenden Hinweis:

Bei sehr großen Containerdateien können sehr große bs-Werte wie 200M bei count=1 je nach System die Erzeugung der Datei in der gewünschten Größe stark beschleunigen. In diesem Beispiel wäre die Datei 200M * 1 = 200M groß. Alternativ beschleunigt auch die Verwendung von if=/dev/zero durch Nullen anstelle von Zufallszahlen wie bei urandom.

Jedoch kan ich dir nicht sagen ob das zu empfehlen ist bzw. was zu empfehlen ist.

Zu deiner zweiten Frage:

Ja es ist möglich, NTFS mit LUKE zu nutzen, siehe dazu http://askubuntu.com/questions/553924/c ... -in-ubuntu

dort steht folgendes:

Luks works at the block level so theoretically you can put any filesystems you want inside it including NTFS.

Gruß,
binarycode

[DeletedUserReAsG]

Anmerkung: möchte man den gesamten Datenträger beschreiben, sollte man count weglassen. Im Beispiel über diesem Beitrag würde eine 8MB große Datei an den Anfang der Platte geschrieben – ich denke nicht, dass das das ist, was man will. Mit der Blocksize kann man ein wenig experimentieren, die optimale Größe hängt auch vom System selbst ab. So oder so – es dauert eine Weile. Nachdem dd eine Weile gelaufen ist, kann man ihm ein USR1 schicken, dann gibt es aus, wo es gerade ist und welche Transferraten bis dahin im Schnitt angelegen haben – so kann man abschätzen, wie lange es insgesamt dauern wird.

Die Sache mit /dev/zero ist in diesem Kontext eine, mit Verlaub, bekloppte Idee – eine fabrikneue Festplatte ist bereits überwiegend mit Null befüllt.

NTFS lässt sich selbstverständlich nutzen, wie auch jedes andere FS. Nur wird Windows nicht drauf zugreifen können, womit die Idee irgendwie auch recht sinnlos erscheint.

[Cae]

Man kann den LUKS-Container erstellen und oeffnen und dann dorthinein Nullen schreiben. Ein guter Verschluesselungs-Algorithmus erzeugt eine gute Normalverteilung des Ciphertextes, d.h. der Ciphertext besteht auch nach ausfuehrlicher Analyse offenbar aus Zufallsdaten. Von aussen sieht man also entweder "oh, Zufallsdaten" (aus urandom) oder "oh, Zufallsdaten" (vom vollgeschriebenen Container). Dass es ein verschluesselter Container ist, wird durch den LUKS-Header offenbar, der in jedem Fall am Ende geschrieben wird (ausser, man laesst die Schluesselverwaltung LUKS weg und verwendet rohes dm_crypt).

Es ist an dieser Stelle nur wichtig, dass man das Blockdevice innerhalb von LUKS ueberschreibt und nicht in eine Datei in einem darinliegenden Dateisystem. Dieses hat naemlich typische Strukturen, wovon Teile a) nicht sicher genullt werden und b) ggf. Aufschluss ueber den Inhalt geben koennten.

Der Vorteil vom Initialisieren per LUKS waere aus meiner Sicht, dass LUKS mittlerweile multi-threaded ist und an dieser Stelle nicht von (langsamen) physikalischen Zufallsdaten abhaengt. Es ist also erheblich schneller als urandom. Und das, obwohl urandom eigentlich nur einmal geseedet wird und danach als Streamcipher weiterlaeuft und dabei Rechenzeit verbraet.

Gruss Cae

[schwedenmann]

Hallo


man kann auch pv ud dd nutzen, um den Forschritt von dd zu sehen

http://www.freebsdwiki.net/index.php/Pv


mfg
schwedenmann

[Patsche]

NTFS lässt sich selbstverständlich nutzen, wie auch jedes andere FS. Nur wird Windows nicht drauf zugreifen können, womit die Idee irgendwie auch recht sinnlos erscheint.

Es ging dort eher darum, dass diese Platte 2TB groß ist und fast vollständig belegt ist. Jetzt war die Idee die Platte zu verschlüsseln, so wie sie ist. Diese wollte Ist natürlich nicht vorher mit Zufallszahlen beschreiben. Über die Risiken ohne Backup bin ich aufgeklärt Aber mir kommt gerade der Sinn, dass die Festplatte wahrscheinlich doch formatiert werden muss, damit sie überhaupt verschlüsselt werden kann. Sehe ich das richtig?
Nochmal zu dem 2. Plattensystem:
Mir kam gerade die Idee, dass ich die 2. Festplatte ja unter einem eigenen Einhängepunkt mounten kann. Lässt der Installer von Debian das zu? Dann könnte man diesen Mountpoint mit in das LVM packen. Funktioniert das?

[DeletedUserReAsG]

Diese wollte Ist natürlich nicht vorher mit Zufallszahlen beschreiben. Über die Risiken ohne Backup bin ich aufgeklärt Aber mir kommt gerade der Sinn, dass die Festplatte wahrscheinlich doch formatiert werden muss, damit sie überhaupt verschlüsselt werden kann. Sehe ich das richtig?

Wenn du die Partition LUKS-formatierst, werden einige Daten neu geschrieben (Header und so Kram, einige kB vielleicht), und der Rest bleibt unverschlüsselt liegen, bis er irgendwann überschrieben wird. Dachtest du daran, die Daten nachträglich on the fly zu verschlüsseln? Das funktioniert mit LUKS nicht – mit reinem dm_crypt habe ich es mal gemacht, aber das ist tricky, unsauber und es gibt keine Garantie für die Daten.

[Patsche]

Achso. Vielen Dank für die Aufklärung, dann hat sich das ja geklärt Dann werde ich mal gucken wohin ich die Daten schaufel um das vernünftig neu zu realisieren. Bleibt nes gardoch die Frage zu dem 2 Plattensystem. Und:
Mit fällt es gerade nicht mehr ein....Kann man die Verschlüsselungsart im Installer festlegen? Also beispielsweise "cbc-essiv:sha256" oder "xts". Oder gibt der Installer das vor? Und eventuell noch zur Geschwindigkeit. Macht sich eine Verlangsamung durch die Verschlüsselung bei einem T60 oder T400 bemerkbar?

[Cae]

Kann man die Verschlüsselungsart im Installer festlegen? Also beispielsweise "cbc-essiv:sha256" oder "xts". Oder gibt der Installer das vor?

Der Installer macht da einen Vorschlag, man kann den LUKS-Eintrag aber im Dialog auswaehlen und da abweichende Parameter einstellen. Bin mir nicht ganz sicher, ob das auch funktioniert, weil man an gleicher Stelle auch einstellen kann, dass er eine Keyfile als Schluessel verwenden soll. Nur dummerweise kann man nirgends spezifizieren, wo diese Datei liegen soll, d.h. man hat nach der Installation ein perfekt verschluesseltes System ohne Schluessel...

Gruss Cae

[novalix]

LVM über mehrere Festplatten geht.
Der Overhead durch Verschlüsselung würde vielleicht auf nem 486er merkbar sein.

[DeletedUserReAsG]

Nah … auf ’nem handelsüblichen Atom macht es sich durchaus auch bemerkbar. Messen kann man’s im Grunde auf jedem System, das kein Hardware-AES o.ä. hat – ob’s praktisch relevant ist, muss jeder für sich entscheiden. Bei meinem letzten System ohne entsprechende Intel-CPU machte das ca. 30MB/s real aus, wenn ich mich recht erinnere. Blieben immer noch >100MB/s nutzbar übrig.

T400 mit SSD hätte ich auch hier, sobald ich den Schlüssel zur entsprechenden Partition wiedergefunden habe, kann ich bei Bedarf ja mal Werte einstellen.

[Patsche]

Hier würden nur ganz einfache mechanische Platten in Verwendung sein . Aber ic frage mich auch gerade, was passieren würde, wenn ich die 2. Platte mit in das LVM lege und ich dann aber im laufenden Betrieb das UltraBay herausnehme, weil ich beispielsweise eine DVD brennen muss. Könnte es da Probleme geben? Oder würdet ihr einfach System (/ , /home, swap) in ein LVM packen und die 2. halt extra verschlüsseln. Hätte nur den Nachteil, dass man dann 2 Passwörter bräuchte bzw. 3 mit Benutzerpasswort. Wie würdet ihr das machen? Oder halt ihr Verschlüsselung für private Zwecke zu "oversized"?

[DeletedUserReAsG]

Wenn du ein plattenübergreifendes FS hast, gibt es selbstverständlich Probleme, wenn du eine Platte rausnimmst. Bei ‘nem plattenübergreifenden Cryptocontainer und getrennten FS mit einiger Sicherheit auch, schließlich funktioniert cryptsetup remove nicht so wirklich, wenn noch ein FS aus dem Container gemountet ist.

Es wäre aus meiner Sicht schon sinnvoll, der rausnehmbaren Platte einen eigenen Container samt FS zu spendieren (und dabei darauf zu achten, dass man es so anstellt, dass das betreffende FS auch ausgehängt werden kann – i.e. /home draufzulegen wäre nicht die beste Idee, man müsste zum Aushängen den User ausloggen, ggf. seine übriggebliebenen Hintergrundsachen beenden und alles als root machen, solange /home nicht da ist). Ich habe für sowas einen Mountpoint unterhalb von ~, das geht ganz gut. Passwort sollte nicht das Problem sein: bei mir läuft z.B. ein kleines Script, welches das Entsperren und Einhängen der Platten übernimmt und dabei seinen Schlüssel von einem definierten Ort (z.B. USB-Stick) holt. Möglicherweise gibt’s da sogar native Methoden für – müsste sich jemand zu äußern, der sich damit auskennt.

Eine andere Idee, die dein Szenario möglicherweise besser bedient: es gibt die Möglichkeit, ecryptfs so zu verwenden, dass beim Anmelden des Users sein ~ automatisch entsperrt wird. Ist natürlich „nur“ eine dateibasierende Verschlüsselung, aber nutzt im Grunde die gleichen Verschlüsselungsmechanismen, wie dm_crypt auch, sollte sich performancetechnisch nicht zu sehr davon unterscheiden.

[schwedenmann]

Hallo


@niemand

es gibt die Möglichkeit, ecryptfs so zu verwenden

Ist das nicht aus Debian, wegen Sicherheitsproblemen entfernt worden ?

Bei Ubuntu und Mint ist das ja quasi Standard, es wird beim updaten der initramfs soagr gemeckert, wenn /home nicht verschlüsselt wurde.

mfg
schwedenmann

[DeletedUserReAsG]

Ich weiß nicht, ob die Funktionalität im Installer entfernt worden ist, und ob es Sicherheitsprobleme damit gibt/gab. ecryptfs selbst ist jedenfalls in Wheezy enthalten und man kann es sich ja so hinbasteln, wie man mag. Allerdings würde ich aus Sicherheitsgründen davon absehen, das ins initramfs aufzunehmen.

[Tintom]

Macht sich eine Verlangsamung durch die Verschlüsselung bei einem T60 oder T400 bemerkbar?

Es ist langsamer, aber im alltäglichen Arbeiten bemerkt man davon nichts. T400 mit 2,4 Ghz und verschlüsseltem /home:
$ head -c 2GiB /dev/zero |pv > /tmp/testdatei.dat
2GB 0:00:34 [59.3MB/s]
$ head -c 2GiB /dev/zero |pv > /home/testdatei.dat
2GB 0:00:45 [ 45MB/s]

[Patsche]

Vielen Dank für eure Hilfe. Ich werde es jetzt also getrennt verschlüsseln. Mit der 2 Platte werde ich das wahrscheinlich wirklich so machen, wie niemand es vorgeschlagen hat. Ein Key-File, welches auf dem verschlüsselten System hinterlegt ist. So muss man ja dennoch nur 1 Passwort im Kopf behalten.
Ich danke für eure Aufmerksamkeit. Sollte ich nochmal fragen haben, dann melde ich mich hier wieder. Das Thema ist für mich vorerst gelöst. Die Platte wird gerade mit den voreingestellten werden des jessie-daily Installers überschrieben. Ich weiß nicht genau, welche Werte er genommen hat, da ich die geführte Installation benutzt habe. Er braucht jedoch ca. 5 Stunden, wenn ich das hochrechne (3Min/1%). Also: Danke.

[Patsche]

Noch eine Frage fällt mir nun ein. Erhöht es eigentlich die Sicherheit, wenn ich innerhalb des der verschlüsselten LVM mit LUKS nochmal Dateien extra verschlüssele? Beispielsweise mit Truecrypt?

[Cae]

Noch eine Frage fällt mir nun ein. Erhöht es eigentlich die Sicherheit, wenn ich innerhalb des der verschlüsselten LVM mit LUKS nochmal Dateien extra verschlüssele?

Das haengt davon ab, wo der Key liegt. Z.B. kann es sinnvoll sein, bestimmte schuetzenswerte Daten, die man selten braucht, nur bei Bedarf zu entschluesseln und sonst in einem eigenen Container zu halten. Wenn du aber den Key dazu daneben auf die (per dm_crypt oder sonstwie behandelte) Platte legst, sehe ich keinen Mehrwert darin. Ggf. laesst sich der Extra-Container schneller "loswerden", aber wenn das noetig wird, will man vielleicht auch direkt das LUKS drumrum wegschmeissen.

Gruss Cae

[wanne]

Vorher möchte man natürlich die Festplatte mit Zufallszahlen beschreiben. Wie lange dauert so etwas für gewöhnlich? Wie ich gelesen habe kommt es natürlich "bs-Wert" und den "count-Wert" an, den ich dd mitliefere. Was empfehlt ihr?

Nimm einfach cat das setzt die blockgröße automatisch ist wesentlich pervormanter (dank asynchroner I/O). Und auf keinen Fall /dev/urandom. Das ist sticke lahm.
Als entweder einfach in das verschlüsselte device schreiben:

Code: Alles auswählen

cat /dev/zero > /dev/mapper/encrypted_device

oder einfach zufällig aes-verschlüsseltes zeug:

Code: Alles auswählen

openssl aes-128-cbc -in /dev/zero -kfile /dev/urandom > /dev/sdx

Das ist etwa 10 mal schneller als die dd Variante mit /dev/urandom

Ich habe hier eine externe Festplatte, welche im NTFS-Format formiert wurde. Ist es möglich LUKS mit dem NTFS-Dateisystem zu nutzen?

Du kannst da rein setzen was du willst. Leider gibt es keine Windows Programme mehr, die LUKS öffnen können. (FreeOTFE hat das früher können.) Somit finde ich das ziemlich sinnlos.

Ein Key-File, welches auf dem verschlüsselten System hinterlegt ist. So muss man ja dennoch nur 1 Passwort im Kopf behalten.

Der von cryptsetup empfohle Weg und auch absolut der robusteste und Angenehmste. Weiß nicht, warum der Debianinstaller das anders macht.

der braucht jedoch ca. 5 Stunden

Klingt als ob der mit /dev/urandom überschreibt.

Möglicherweise gibt’s da sogar native Methoden für – müsste sich jemand zu äußern, der sich damit auskennt.

Ja. Aber die sind inkompatibel zwischen Systemd-cryptsetup und cryptsetup.

Kann man die Verschlüsselungsart im Installer festlegen? Also beispielsweise "cbc-essiv:sha256" oder "xts". Oder gibt der Installer das vor?

Beim Installer kann man zwar wählen aber nur zwischen ein paar wenigen. Der Kernel im Installer ist (warum auch immer) um die performantesten Methoden beschnitten. Ich habe mein System deswegen aes-128-essiv:sha256 aufgesetzt. Und es dann per LiveCD cat in eine serpent-ctr partition kopiert. (Der kernel den der Installer dann installiert ist nämlich zu mehr oder weniger allem in der Lage.)

nd eventuell noch zur Geschwindigkeit.

Ich werde nacher (Spätestens 19:00Uhr) noch ein benchmark veröffentlichen.

Macht sich eine Verlangsamung durch die Verschlüsselung bei einem T60 oder T400 bemerkbar?

Bei normalen Fesplatten kannst du bei weitem nicht so schnell lesen, dass du deine CPU ernsthaft belasten kannst. Selbst beim Messen bekommt man da probleme Unterschiede nachzuwißen. (Wenn du gerade mit fullspeed ließt brauchst du typischerweise deine CPU eh nicht. Da kann die auch ein bisschen crypto machen. Man merkt also lediglich ein kleinen Anstieg bei der CPU auslastung aber keine verlangsamung.)
Mit SSDs sieht das anders aus: Mein T400 hat keine Hardwarebschleunigung für AES und ich habe eine SAMSUNG 840 SSD nachgerüstet. Da komme ich nur noch auf 2/3 der Geschwindigkeit. Weswegen ich mich dazu entschlossen habe /usr nicht zu verschlüsseln. Da habe ich das nur gemerkt, als ich mit Gigabit torrents geleecht habe.Was defakto ein mal im Jahr vorkommt.

[gehrke]

Ein Key-File, welches auf dem verschlüsselten System hinterlegt ist. So muss man ja dennoch nur 1 Passwort im Kopf behalten.

Der von cryptsetup empfohle Weg und auch absolut der robusteste und Angenehmste. Weiß nicht, warum der Debianinstaller das anders macht.

Ich vermute deshalb, weil der zweite Schlüssel dann im wesentlichen ungeschützt auf der Platte liegt. Ja, er ist zwar geschützt, wenn das System offline (nicht gestartet) ist. Aber wenn der umliegende Container einmal entschlüsselt ist, liegt der zweite Schlüssel transparent vor. Einziger Schutz sind dann noch die Benutzerrechte, was IMHO etwas dünn ist.

[wanne]

Acho: und wenn es um das Loswerden von Alten Daten geht, gib't das:

Code: Alles auswählen

hdparm --user-master u --security-erase NULL /dev/sdx

Dass nullt die Platte aus. (Und nach möglcihkeit so, dass auch Forensiker nicht mehr dran kommen.)

Falls das BIOS das sperrt kann man einfach kurz den Strom anziehen. Funktioniert auch bei IDE-Platten. (Obwohl das eigentlcih nur bei SATA so vorgesehehen ist. )