staging.inyokaproject.org

Vielen Dank, dass beantwortet alle meine Fragen.

Hallo zusammen,

ich würde im LUKS-Artikel gerne etwas ergänzen, möchte aber nicht einfach drin rumfuschen, weil es sich hierbei um sicherheitsrelevante Fragen handelt und ich da gelinde gesprochen allenfalls mäßig Ahnung von habe.

Worum geht es? Wird eine LUKS-Partition (z.B. auf einer externen HD) nicht über die Konsole, sondern mithilfe der GUI des Systems gemountet ("Device Notifier" oder "Dolphin" oder so), wird sie in /media/user/UUID eingehängt (so zumindest unter *K*ubuntu 14.04). Das ist zunächst einmal verwirrend und mitunter auch unpraktisch, wenn man z.B. mit Skripts arbeitet, bei denen ein menschenlesbarer Mount-Point der Partition hilfreich wäre. Hat das Dateisystem im LUKS-Container jedoch ein Label, wird dieses anstelle der UUID für den Ordner in /media/user/ verwendet. Sehr praktisch! Nur darauf muss man auch erst einmal kommen. Darum würde ich unter der Überschrift "Erstellen", Punkt 4. ergänzen:

–-

Optional kann dem Dateisystem ein Label zugewiesen werden, das beim späteren Einhängen der Partition mithilfe der GUI des Systems als Name der Partition dient:

sudo tune2fs -L LABEL /dev/mapper/usb-crypt

–-

Wie das Verhalten unter *U*buntu ist, müsste dann natürlich auch jemand testen, ich vermute aber mal, dass es identisch sein dürfte. Was denkt ihr?

Gegen ein Label spricht nichts, solange man aufpaßt, daß es eindeutig bleibt. Mit der Verschlüsselung an sich hat es nichts zu tun.

Eine Frage: Man kann ja auch mit dem Programm "Laufwerke" unter Unity verschlüsselte Datenträgern mittels LUKS erstellen.

http://wiki.ubuntuusers.de/Laufwerksverwaltung#Datentraeger-verschluesseln

Das wird im Text jetzt nicht erwähnt. Besteht da irgendein Nachteil? Das ist doch genau das gleiche, oder?

Edit: Ok, sehe gerade, dass man über Terminal doch etwas flexibler ist (z.B. bei den Bits)...

Ich habe da mal eine Frage:

Es wird im Artikel empfohlen, vor dem luksFormat den Anfang der zu verschlüsselnden Partition mit Zufallszahlen zu überschreiben. Wozu dient das?

Um alte Metadaten loszuwerden, falls welche drauf sind und man sich nicht an den Tipp gehalten hat, das gesamte Gerät zu überschreiben.

luksFormat überschreibt die ersten 129KiB. Der Bereich 129KiB-2MiB bleibt dann erstmal unangetastet, wird teilweise beim anlegen weiterer Keys gefüllt (128KiB pro Key). Ab 2MiB gehen dann die verschlüsselten Nutzdaten los.

Das heißt, wenn ich weniger paranoid ( 😉 ) bin, und es mir in erster Linie darum geht, dass der Dieb meines Laptops nicht gleichzeitig auch meine Bankdaten und den Zugang zum Emailaccont erbeutet, kann ich darauf auch verzichten, oder?

Im Artikel wird ja von der Schlüsseldatei abgeraten. Wenn sich diese Schlüsseldatei jedoch nur auf einem verschlüsselten Laufwerk befindet, spricht doch eigentlich nichts gegen die Verwendung einer solchen Schlüsseldatei - oder habe ich da etwas übersehen?

Ich gehe jetzt von einem Szenario aus, bei dem mehrere Installationen auf separat verschlüsselten Partitionen liegen. Die Boot-Partition wird mit einem starken Passwort geöffnet, aber die übrigen Partitionen kann man dann mit einer Schlüsseldatei, die auf der Boot-Partition liegt, automatisch öffnen lassen.

Das Ableiten des Schlüssels aus einem verschlüsselten Device funktioniert unter 16.04 bei mir nicht mehr, ich habe genau das unter ^[1] beschriebene Problem. Laut ^[2] funktioniert es "mit systemd" nicht und als Workaround wird eine Schlüsseldatei vorschgeschlagen. Mich würde deshalb interessieren, ob der Artikel für 16.04 generell nicht mehr gilt und was genau gegen eine Schlüsseldatei spricht.

^[1] https://lists.debian.org/debian-user-german/2014/10/msg00032.html

^[2] https://lists.debian.org/debian-user-german/2014/10/msg00035.html

Wenn die Schlüsseldatei nicht verschlüsselt ist, dann entspricht das in etwa dem Passwort, das auf einem Notizzettel am Bildschirm klebt.

Ein weiterer möglicher Unterschied ist, daß die Schlüsselableitung sicher nur für Root funktioniert, während du bei einer Datei explizit drauf achten musst, sie nur für Root lesbar zu machen.

Ich nutze selbst (direkt verschlüsselte) Schlüsseldateien, also das Passwort das ich eingebe macht die Schlüsseldatei auf und die darin enthaltenen Schlüssel alle LUKS-Container. Das ist allerdings eine selbstgestrickte Lösung.

Zur Schlüsselableitung/Systemd war mir so als wäre das hier schon diskutiert und eine Lösung dafür gefunden worden aber ich finds selbst nicht mehr.

Vielleicht wars das hier: https://forum.ubuntuusers.de/topic/zweite-verschluesselte-festplatte-wird-nicht-m/2/

Da war mal die Rede von daß das bei systemd sowieso funktioniert wenn man allen LUKS das gleiche Passwort gibt und man die Schlüsselableitung damit gar nicht mehr braucht. Obs stimmt weiß ich aber nicht.

Oder das hier (auch am Ende vom vorigen Thread verlinkt): https://forum.ubuntuusers.de/topic/baustelle-system-verschluesseln-schluesselable/#post-8190363

Ich habe ein ähnlich gelagertes Problem: Ich habe die Entschlüsselung bei mir mittels USB-Schlüssel realisiert. Die Schlüssel für die LUKS-Container sind zwar nicht abgeleitet, aber mehrere LUKS-Container sind mit dem gleichen Schlüssel ausgestattet. Das hat unter 14.04 tadellos funktioniert, indem ich für alle als Schlüssel in der /etc/crypttab das Keyscript angegeben habe.

Seit 15.10 hing der Rechner weil dies, außer für die Systempartition, für keine Partition mehr funktioniert hat. Auch die Entschlüsselung per Passwort hat nur für die Systempartition funktioniert, alle weiteren in der /etc/crypttab eingetragenen Partitionen führten dazu, dass das System nicht mehr vollständig startete. Erst ein Login ins verschlüsselte System mittels chroot und die Änderung der /etc/crypttab nebst update-initramfs machte das System wieder startfähig.

Ich habe mir dann auch eine eigene Lösung gebastelt, die das Öffnen der übrigen Partitionen mit Hilfe eines Skripts im Autostart erledigt.

frostschutz, danke für die links. leider hatte ich auch mit überall gleiches passwort keinen erfolg (musste alle gleichen passwörter eingeben). Bei mir schien aber auch noch was anderes nicht zu stimmen, die swap-partition hat es regelmäßig verhauen (es hieß dann plötzlich "is not a luks device", wenn ich versucht hab mit cryptsetup darauf zu arbeiten). Als das das letzte mal passierte, bekam ich dann nur noch die meldung "cryptsetup: lvm is not available" beim start, die auch nicht mehr mit chroot nebst update-initramfs wegging.

ich habe jetzt meine alte partitionierung aufgegeben und ein komplett neues 16.04 mit verschlüsseltem LVM (wie bei der installation vorgeschlagen) installiert. diese LVM-Sache scheint mir zwar ein bisschen overkill für meinen privatrechner, aber wenigstens beschäftige ich mich dann auch mal damit...

nochmal zu dem wiki-artikel LUKS/Schlüsselableitung: steht ja drüber, dass der für 12.04 gilt, aber vielleicht sollte man da nochmal explizit einen hinweis reinschreiben, dass die schlüsselableitung seit... ja seit wann genau eigentlich? .... also mit systemd nicht mehr funktioniert. oder?

Es gibt nun einen für viele Interessierte sicherlich nützlichen Hinweis im Artikel:

Das haben meine Tests (auf ext4) ergeben.

Es gibt nun einen getesteten Hinweis darauf, dass im Chroot der Name des Targets mit dem in der crypttab festgelegten übereinstimmen muss, zumindest für update-initramfs.

Schlüsseldatei wurde im Wesentlichen (Keydatei nutzen) auch für 16.04 getestet, pam-mount könnte noch jemand für (ab) 16.04 testen - wird sicherlich auch funktionieren.

Im Abschnitt Sicherheitsschluessel anlegen wird der Befehl

cryptsetup luksAddKey <Gerät> 

vorgeschlagen. Dieser Befehl funktioniert aber nicht, weil eine existierende Passphrase eingegeben werden muss, um einen weiteren Schlüssel hinzuzufügen. Diese existiert aber nicht, weil der Schlüssel ja abgeleitet wurde - darum will man ja gerade eine Passphrase hinzufügen.

Nach längerer Suche bin ich darauf gestoßen, dass man, sofern das Laufwerk derzeit entschlüsselt ist, den Masterkey zur Authentifizierung benutzen kann. Der Befehl würde dann lauten:

 cryptsetup luksAddKey <Gerät> --master-key-file <(dmsetup table --showkey /dev/mapper/<MAP> | awk '{print$5}' | xxd -r -p) 

wobei <MAP> dem Namen entspricht, unter dem das Laufwerk geöffnet wurde und nur in /dev/mapper zu finden ist, während <Gerät> dem Name /dev/SDXY entspricht.