Könntest du mir die Befehlszeilen aufzeigen, die ich tippen müsste, um Anstelle eines Verschlüsselten AES 512 XTS Plain ein Serpent bzw. Twofish zu erstellen? Ich meine die Zeilen aus dem System verschlüsseln Wiki, die ausschliesslich auf AES zugeschnitten sind.

Nett wäre auch, wenn du mir die Zeilen aufzeigen könntest, die ich daraus anpassen muss, um das ganze mit einem Kontainer im Kontainer zu erstellen. Das Teil muss ja nachher auch noch booten können!

Was ich mich gefragt habe. Wenn ich im Nachhinein weitere Festplatten an den Linux-Rechner hänge und ich auch möchte, dass diese beim Start des Systems mit dem gleichen Passwort entschlüsselt und eingebunden werden, was muss ich dann ändern?

Ich geselle mich mal kurz zu der gemütlichen Kaffeerunde dazu.

stfischr schrieb:

Reptile schrieb:

Habe gerade gecheckt, dass alle Partitionen die mit einem Passwort entschlüsselt werden sollen, im gleichen LVM sein müssen. Was tue ich, wenn ich möchte, dass auch andere Platten nach dem Systemstart automatisch gemountet werden. Diese aber auch verschlüsselt sind. Mit dem gleichen Passwort natürlich, sonst kanns ja nicht funktionieren.

Schlüsselableitung oder Keyfile.

Link: System verschlüsseln/Schlüsselableitung

V for Vortex:

Selbst wenn ein Geheimdienst hinter mir her wäre, (zum Glück habe ich keinen Grund das zu befürchten), wollte ich es trotzdem gut verschlüsselt haben.

xkcd: Security

Dann macht es ja schon wieder Sinn: Er rückt dann bei Bedrohung nur den ersten Schlüssel raus, wo Fake Daten drin sind. Die eigentlichen Daten in einem versteckten (!) zweiten Container gibt er nicht preis. Wer ganz paranoid ist, geht davon aus, dass der Erpresser das auch denkt und den zweiten Schlüssel auch noch erpresst. Demgegenüber kann man sich schützen, indem man noch einen dritten versteckten Container anlegt usw. . Parallel oder verschachtelt.

Hab einen Freund bei der örtlichen Behörde der Behauptet sie kriegten alles auf. Deshalb frage ich dich

*gähn* Schick dem mal einen USB-Stick mit verschlüsseltem Ubuntu - und dann lass dir deinen Testtext vorlesen. Und wenn wir schon dabei sind: Ich kann dir noch GPG/ PGP-Emailverschlüsselung empfehlen. Dabei muss kein Passwort ausgetauscht werden. Funktioniert prima z.B. mit Thunderbird und dem Paket enigmail-locale-de. Im Assistenten dann RSA 2048 Bit einstellen, evtl. ein Passwort vergeben, das Zertifikat nach 5 Jahren verfallen lassen...und dann immer mit dem öffentlichen (!) Schlüssel desjenigen verschlüsseln, der etwas als Einziger entschlüsseln können soll. Also musst du auch deinen öffentlichen Schlüssel per Menü OpenPGP mit anhängen (oder auf Server freigeben).

An sowas sowie Systemverschlüsselung kann sich - ohne Keylocker und andere Hintertürchen (/boot ist immer unverschlüsselt!) - selbst der CCC die Zähne ausbeißen. Und die "Experten" vom Staat...naja, sagen wir mal so: Die haben da sicherlich teure Spezialleute. Und vielleicht ist auch nur nicht bekannt, dass ein Verfahren/ Algorithmus bereits geknackt wurde (nicht nur eine Implementation, was ab und zu mal vorkommt, vgl. Wikipedia). Aber so wertvoll bist du wahrscheinlich nicht, dass die ein Rechenzentrum + Experten auf dein System loslassen und dabei 100.000 oder Millionen von EUR verpulvern. Dann doch eher den Keylocker...

stfischr:

Macht es überhaupt Sinn eine Kaskade zu verwenden?

Wenn man paranoid genug ist ja, ein theoretisches Plus an Sicherheit bietet es immerhin.

Soweit ich weiß, kann aber dann auch aufgrund der Beschaffenheit und Entropie der Daten evtl. sogar eine weitere Sicherheitslücke entstehen, die Hinweise zum Knacken gibt. Die Diskussion wird aber sowieso gerade sehr theoretisch.

Das mit dem erwähnten Yubikey muss ich mir mal in Ruhe zu Gemüte führen.

Grüße, Benno

Reptile schrieb:

Könntest du mir die Befehlszeilen aufzeigen, die ich tippen müsste, um Anstelle eines Verschlüsselten AES 512 XTS Plain ein Serpent bzw. Twofish zu erstellen?

Öhm ist das jetzt dein Ernst? Probiere doch einfach mal aes durch den gewünschten Algo. zu ersetzen ...

Wenn du auf sowas nicht selber kommst dann würde ich dir liebe die Standardverschlüsselung der alternateCD empfehlen. Da bekommt man ausreichend Sicherheit ohne Ahnung von Terminal und Bash haben zu müssen.

Nett wäre auch, wenn du mir die Zeilen aufzeigen könntest, die ich daraus anpassen muss, um das ganze mit einem Kontainer im Kontainer zu erstellen. Das Teil muss ja nachher auch noch booten können!

Den erste Container legst du ja auf /dev/sdXY an. Dann öffnest du diesen und den erstellst den Nächsten im entsprechenden /dev/mapper/DeinGeöffnetesCryptDevice.

Benno-007 schrieb:

Soweit ich weiß, kann aber dann auch aufgrund der Beschaffenheit und Entropie der Daten evtl. sogar eine weitere Sicherheitslücke entstehen, die Hinweise zum Knacken gibt. Die Diskussion wird aber sowieso gerade sehr theoretisch.

Du spielst darauf an, dass verschlüsselte Daten eine bestimmte Struktur haben (Pseudozufallsdaten) und man das für Angriffe nutzen kann? Nun, es gibt nichtmal eine Known-Plaintext-Attacke auf die 3 Algorithmen, was hilft es da, wenn ich nur ungefähr weiß, wie die Daten strukturiert sind?

Selbst wenn, würde es die Kaskade nur auf einen verschlüsselten Container vereinfachen.

Benno-007 schrieb:

V for Vortex:

xkcd: Security

Dann macht es ja schon wieder Sinn: Er rückt dann bei Bedrohung nur den ersten Schlüssel raus, wo Fake Daten drin sind. Die eigentlichen Daten in einem versteckten (!) zweiten Container gibt er nicht preis.

Das hat aber per se nichts mit kaskadierter Verschlüsselung zu tun. Du meinst Glaubhafte_Abstreitbarkeit, und für die genügt einfache Verschlüsselung. TrueCrypt bietet sowas z.B. an.

Nett wäre auch, wenn du mir die Zeilen aufzeigen könntest, die ich daraus anpassen muss, um das ganze mit einem Kontainer im Kontainer zu erstellen. Das Teil muss ja nachher auch noch booten können!

Den erste Container legst du ja auf /dev/sdXY an. Dann öffnest du diesen und den erstellst den Nächsten im entsprechenden /dev/mapper/DeinGeöffnetesCryptDevice.

Danke! das sollte genügen. Ich bin nicht so hohl, wie ich mich eben angestellt habe. Ich möchte nur ganz sicher sein, da eine falsch implementierte Verschlüsselung ja überhaupt nichts bringt.

Ich habe die Frage gestellt, weil man laut Wiki Artikel die /etc/devault/grub Datei bearbeiten muss:

GRUB_CMDLINE_LINUX_DEFAULT="kopt=root=/dev/mapper/vgubuntu-root"

Wie diese Zeile bei "Kaskade" auszusehen hat, kann ich mir nicht vorstellen.

Übrigens noch ne ganz wichtige Frage

Beim Start entschlüsselt Ubuntu ja nur die Partitionen, die innerhalb von diesem verschlüsselten LVM liegen. Wie gehe ich vor, wenn ich in Zukunft neue Platten in mein System schiebe und sie mit dem gleichen Passwort verschlüssle, damit sie auch beim Start entschlüsselt und gemountet werden?

Ich habe gesehen, dass man auch nach dem Ubuntustart einfach auf das Laufwerk klicken kann: Dann wird man nach dem PW gefragt. Es ist wohl aber kaum ratsam, das in dem Schlüsselbund mit Ubuntu merken zu lassen. Oder?

Also wie funktioniert das?

Wirklich bis jetzt schonmal Danke für den super Support

Benno-007 schrieb:

(/boot ist immer unverschlüsselt!)

Genau deshalb habe ich in einem anderen "Topic" gefragt, ob man die komplette /boot nicht auslagern könnte. Auf CD oder SD-Karte

Wurde aber verworfen, da Linux darauf ja auch Kernel speichert. (Braucht Linux die /boot während dem Betrieb aktiv?

Ich stelle so schreckliche Fragen, weil ich mir geschworen habe so lange Linux zu lernen, bis ich alle Funktionen, die ich mit dem Windows Server 2008 R2 hingekriegt habe auch unter Linux beherrsche.

Allerdings dürfte das ein steiniger Weg werden.

Reptile schrieb:

Beim Start entschlüsselt Ubuntu ja nur die Partitionen, die innerhalb von diesem verschlüsselten LVM liegen. Wie gehe ich vor, wenn ich in Zukunft neue Platten in mein System schiebe und sie mit dem gleichen Passwort verschlüssle, damit sie auch beim Start entschlüsselt und gemountet werden?

Unter LUKS: Öffnen sind verschiedene Methoden beschrieben.

Ich habe gesehen, dass man auch nach dem Ubuntustart einfach auf das Laufwerk klicken kann: Dann wird man nach dem PW gefragt. Es ist wohl aber kaum ratsam, das in dem Schlüsselbund mit Ubuntu merken zu lassen. Oder?

Der GNOME Schlüsselbund wird verschlüsselt gespeichert und ist bei verschlüsseltem System (oder verschlüsseltem Homeverzeichnis) somit doppelt verschlüsselt. Reicht das?

Reptile schrieb:

GRUB_CMDLINE_LINUX_DEFAULT="kopt=root=/dev/mapper/vgubuntu-root"

Hier gibst du weiterhin das Root-Dateisystem an, was ja auch in einer Kaskade auf dem LVM liegt.

V for Vortex schrieb:

Unter LUKS: Öffnen sind verschiedene Methoden beschrieben.

Danke! Dazu noch eine Frage: "Wenn ich mittels LuksAddkey einen Key hinzufüge, wie kann ich bestimmen auf welchen Slot geschrieben wird? Wie kann ich anzeigen lassen, welche Slots mit Keys versehen sind? Muss man ja dann auch wissen, um sie zu löschen.

Apropo LuksOpen Ich habe mit dem Luksclose-Befehl meine liebe mühe, da er dauernd behauptet: Device Busy. Die darunterliegende Partition ist aber unmounted! Was mache ich da wieder falsch? Ich möchte nicht dauernd zum unmounten neustarten müssen.

Der GNOME Schlüsselbund wird verschlüsselt gespeichert und ist bei verschlüsseltem System (oder verschlüsseltem Homeverzeichnis) somit doppelt verschlüsselt. Reicht das?

Ja das reicht Allerdings ist es mit dem abgeleiteten Schlüssel komfortabler. Und weniger sicher wirds ja nicht sein, da es trotzdem ein eigener ist und das Hauptlaufwerk ja zuerst entschlüsselt werden muss.

Reptile schrieb:

Danke! Dazu noch eine Frage: "Wenn ich mittels LuksAddkey einen Key hinzufüge, wie kann ich bestimmen auf welchen Slot geschrieben wird? Wie kann ich anzeigen lassen, welche Slots mit Keys versehen sind? Muss man ja dann auch wissen, um sie zu löschen.

Das steht direkt darunter: Passwörter verwalten

Bestimmen kannst Du es m.E. nicht, es wird immer der jeweils niedrigste freie Slot benutzt. Dieser wird Dir aber nach AddKey angezeigt (und auch bei LuksOpen im Terminal)

Apropo LuksOpen Ich habe mit dem Luksclose-Befehl meine liebe mühe, da er dauernd behauptet: Device Busy. Die darunterliegende Partition ist aber unmounted! Was mache ich da wieder falsch? Ich möchte nicht dauernd zum unmounten neustarten müssen.

Und es ist sicher, dass die Partition nicht evtl. doppelt gemountet ist? (= sie taucht nicht mehr bei Eingabe von mount im Terminal auf)

Wie Du evtl. herausfinden kannst, wodurch das Gerät blockiert wird, weiß ich leider nicht. Eventuell lohnt sich, dafür ein eigenes Thema zu eröffnen (oder stfischr weiß mehr ).

Der GNOME Schlüsselbund wird verschlüsselt gespeichert und ist bei verschlüsseltem System (oder verschlüsseltem Homeverzeichnis) somit doppelt verschlüsselt. Reicht das?

Ja das reicht Allerdings ist es mit dem abgeleiteten Schlüssel komfortabler.

Viele Wege führen nach Rom.

V for Vortex schrieb:

Wie Du evtl. herausfinden kannst, wodurch das Gerät blockiert wird, weiß ich leider nicht. Eventuell lohnt sich, dafür ein eigenes Thema zu eröffnen (oder stfischr weiß mehr ).

Ich vermute mal das LVM ist noch aktiv. Übrigens gibt umount nicht nur "device busy" aus, sondern:

umount: /mnt: device is busy.
        (In some cases useful info about processes that use
         the device is found by lsof(8) or fuser(1))

und wenn man sich das dann mal anschaut:

lsof /mnt

kommt meist ne nützliche Ausgabe.

V for Vortex schrieb:

Und es ist sicher, dass die Partition nicht evtl. doppelt gemountet ist? (= sie taucht nicht mehr bei Eingabe von mount im Terminal auf)

Vielleicht hilft dir die Info beim Supporten: Ich habe mal das Gerät nicht beim Systemstart einhängen lassen! Dann bin ich in die System --> Systemverwaltung --> Festplattenverwaltung gegangen und habe dort das verschlüsselte Laufwerk angeklickt. Nach dem Klick auf Unlock habe ich das Passwort eingegeben. Nun hat sich ein LVM Laufwerk unter /dev/mapper/uuid=xxxxxxx usw. angelegt. Ich habe die eigentliche Partition "Data" noch nicht gemountet und einfach mal wieder auf "Lock" geklickt.

Ich kriege schon wieder die Fehlermeldung Laufwerk busy. Aber /dev/mapper/uuid=xxxxx kann man ja als solches nicht aushängen, da es ja gar kein gemountetes Dateisystem ist. Also wieso wird das Laufwerk als Busy angegeben?

Strange

Sind wir jetzt eigentlich bei nem normalen LUKS oder ist das schon ne Kaskade? Dann musst du natürlich von innen nach außen aushängen.

Unter /dev/mapper tauchen die aufgeschlossenen Geräte auf und können wir ihre Pendants unter /dev angesprochen werden, also auch per mount oder umount.

Zeig mal bitte die Ausgabe von

ls -l /dev/mapper

und wie von stfishr vorgschlagen

lsof /dev/mapper/entsprechendesluksgeraet

edit: Juchu, Support-Bockspringen.