cryptsetup und crypttab Problem

F

Fluffy

Guest
Hallo!
Ich hab hier einkleines Problem mit crypttab und cryptsetup.

Ich habe ein paar Partitionen welche beim Systemstart gemounted werden und ein paar welche ebenfalls verschlüsselt sind wo ich je nach bedarf backups hinterlege.

Ich habe teilweise Passwörter genommen.
Das Problem damit ist das ich diese anscheinend immer eingeben muss.
Die Keyfiles werden gelesen, aber ich bekomme den Eindruck das Dateien welche Passwörter enthalten, als Keyfiles genommen werden, und nicht einfach nur deren Inhalt.

Wie bekomme ich cryptTab und cryptsetup dazu die Passwörter aus einer Datei auf meinem System auszulesen?

Folgender Befehl funktioniert leider nicht:
Code:
cryptsetup --key-file /pathToKey --keyfile-size 88  luksOpen UUID=XXXX myNowOpenDevice

Auch ohne --keyfile-size-Option geht es nicht.
Das hinzubekommen wäre super, denn dann müsste ich beim Booten nur einmal ein Passwort eingeben und könnte die Backups weiter automatisieren.

In der /etc/crypttab gibt es zwar auch die Ansage, das man dort sein PW reinschreiben kann, aber da liegt das gleiche Problem vor.
Reinschreiben oder Datei angeben funktioniert nicht.

Die Passwörter sind komplex, es sind also auch Zeichen enthalten welche ggf. von der Shell interpretiert werden.
Diese wurden testweise auch schon mal escaped.
Kodierung der Datei ist ASCII und die Dateien enthalten das Passwort ohne newline.
gleiches gilt auch für mein Terminal(nehme ich mal an, weil ich die Dateien mit vim erstellt habe).
Tastatur ist latin-no-deadkeys, Kernel ist 4.0.1, als Shell ist zsh im Einsatz. cryptsetup liegt in Versino 1.6.6 vor.

Liebe Grüße

Fluffy

P.s.:Ich habe in einem Ubuntu-Thread auch mal eine Option für Scripte gesehen, da diese aber nicht dokumentiert ist, würde ich davon gerne abstand nehmen.
 
Zuletzt bearbeitet von einem Moderator:
Moin
Wie bekomme ich cryptTab und cryptsetup dazu die Passwörter aus einer Datei auf meinem System auszulesen?
Das ist nicht vorgesehen und auch nicht sinnvoll.

Du kannst aber einfach ein Keyfile (KeyFile=Inhalt der Datei) in einem anderen KeySlot der Partition anlegen und das dann verwenden.

Sentrax
 
Wiso ist das nicht sinnvoll?
stdin ist eine genauso gültige Quelle wie eine Datei.
Und von den Man-Pages über cryptsetup
.....
--key-file, -d name
Read the passphrase from file.

If the name given is "-", then the passphrase will be read from stdin. In this case, reading will not stop at newline characters.

With LUKS, passphrases supplied via --key-file are always the existing passphrases requested by a command, except in the case of luksFormat where --key-file is equivalent to the positional key
file argument.

If you want to set a new passphrase via key file, you have to use a positional argument to luksAddKey.

See section NOTES ON PASSPHRASE PROCESSING for more information.

.....

und

....
NOTES ON PASSPHRASE PROCESSING FOR LUKS
LUKS uses PBKDF2 to protect against dictionary attacks and to give some protection to low-entropy passphrases (see RFC 2898 and the cryptsetup FAQ).

From a terminal: The passphrase is read until the first newline and then processed by PBKDF2 without the newline character.

From stdin: LUKS will read passphrases from stdin up to the first newline character or the compiled-in maximum key file length. If --keyfile-size is given, it is ignored.

From key file: The complete keyfile is read up to the compiled-in maximum size. Newline characters do not terminate the input. The --keyfile-size option can be used to limit what is read.

Passphrase processing: Whenever a passphrase is added to a LUKS header (luksAddKey, luksFormat), the user may specify how much the time the passphrase processing should consume. The time is used to
determine the iteration count for PBKDF2 and higher times will offer better protection for low-entropy passphrases, but open will take longer to complete. For passphrases that have entropy higher
than the used key length, higher iteration times will not increase security.

The default setting of one second is sufficient for most practical cases. The only exception is a low-entropy passphrase used on a device with a slow CPU, as this will result in a low iteration
count. On a slow device it may be advisable to increase the iteration time using the --iter-time option in order to obtain a higher iteration count. This does slow down all later luksOpen operations
accordingly.

....

von daher denke ich schon das das iw vorgesehen ist, nur frage ich mich was ich falsch mache.
 
Zuletzt bearbeitet von einem Moderator:
Mal ganz davon ab das ich die Schlüsseldatei auch iw. ablegen muss(zB auf einer mit einem PW verschlüsselten Parittion)

Verschlüsselung dient ja nicht nur dem nicht lesen, sondern auch der Integrität des Systems, in der Hinsicht das ich Sicherstellen kann das mit dem System, während meiner Abwesenheit, wodurch auch immer bedingt, nichts geschieht, zumindest auf Softwarebasis.

Anders ausgedrückt, wenn die Root-Partition kompromitiert werden kann, ist es egal ob ich die Schlüssel dort liegen habe oder nicht, man kommt ran.

Von daher ist diese Herangehensweise, zwar unter einem zusätzlichen Sicherheitsaspekt zwar verständlich, reiht sich bei mir aber in der Kategorie des 95%-Syndroms ein.
Und wenn ich Keyfiles auf einem USB-Stick mit mir rumschleppe, und der kommt mit dem Laptop abhanden, dann hat man einen begrenzten Pool an Möglichkeiten der sich schnell erschöpfen lässt.
(meistens muss man den Stick zur Bootzeit ja auch nur einstecken, soviel dazu.)
IMHO ist es auch nicht unbedingt optimal, zumal man UsbSticks eher verliert als das man wichtige Passwörter vergisst.
(Ein System ohne Zugang(verlorener USBStick) ist auch schlecht)


Ich sehe das nicht als Problem an wenn ich Keyfiles und PW zum Entschlüssel des Systems automatisch einbinde, da sie auf einer Verschlüsselten Partition liegen, denn an diese muss man erstmal rankommen.

Ist bei Passwortsafes ja auch nicht anders.
Du gibst das Masterpasswort ein und das System(aka Copy'n'Paste, mit leerung des Clipboards) macht alles für dich.


Gruß

Fluffy

//edit
Abgesehen davon geht es mir in erster Linie darum das die Daten bei Verlust sicher sind, ein Dieb fährt keine Angriff auf die Verschlüsselung sondern macht das was er kann verkaufsfertig, was ich ja getan habe, aber ein bischen mehr Usability wäre auch nett :D
 
Zuletzt bearbeitet von einem Moderator:
Moin Fluffy

Eine Passwortdatei kannst Du nicht mit cryptsetup verwenden. Wenn Du das trotzdem machen willst, dann findest Du eine Möglichkeit das zu realisieren, in den von dir zitierten man-Pages (Stw. stdin).

Warum verwendest Du nicht einfach Keyfiles, statt der Passwörter?

Keyfiles (richtig erstellte) sind sicherer als jedes Passwort.
Deshalb macht es in deinem Szenario keinen Sinn Passwörter zu verwenden.

Sentrax
 
Ich schraube nicht gerne an verschlüsselten Partitionen rum, wenn ich von diesen kein Backup machen kann, drüber nachgedacht habe ich schon.

Ich weiss auch das es ein zusätzlicher Schlüssel ist, aber unverhofft kommt ja bekanntlich oft.

Ich hab mir alles eingerichtet, eingepackt und los, und nun arbeite ich an Verbesserungen, denn bzgl. derManpages dachte ich das das so umstellbar ist wie ich mir das vorgestellt habe.
Scheint nicht so zu sein, und ich habe so wie es momentan aussieht leider auch nix falsch gemacht :( .
Naja.
thx.
 
Ich schraube nicht gerne an verschlüsselten Partitionen rum, wenn ich von diesen kein Backup machen kann, drüber nachgedacht habe ich schon.

Ich weiss auch das es ein zusätzlicher Schlüssel ist, aber unverhofft kommt ja bekanntlich oft.

Müsste es nicht ausreichen, den Header der verschlüsselten Partition zu sichern?
 
Verschlüsselung dient ja nicht nur dem nicht lesen, sondern auch der Integrität des Systems

Verschlüsselung dient ausschliesslich der Vertraulichkeit, nicht aber der Integrität. Integrität erreichst du mit kryptographischen Hashes und Signaturen. Ein Einsatzgebiet, indem Verschlüsselung ohne Integrität Sinn macht, ist z.B. die homomorphe Verschlüsselung.

IMHO ist es auch nicht unbedingt optimal, zumal man UsbSticks eher verliert als das man wichtige Passwörter vergisst.
(Ein System ohne Zugang(verlorener USBStick) ist auch schlecht)
Kauf dir zwei Yubikeys und konfiguriere sie mit einem langen statischen Passwort. Den einen YK schliesst du zuhause in irgendeine Schublade, das ist sozusagen dein Backup Key. Den anderen machst du dir an deinen Schlüsselbund. Beim Booten steckst du ihn kurz an, lässt das Passwort eingeben und ziehst ihn wieder ab. Da der YK sich eine Tastatur ins System hängt, funktioniert das sogar über nahezu alle Betriebssysteme hinweg.

Keyfiles (richtig erstellte) sind sicherer als jedes Passwort.
Erstens kommts aufs Angreifermodell an, zweitens spielt die Anzahl der Zeichen ab einer gewissen Länge keine ausschlaggebende Rolle mehr. Anders gesagt: Wen interessiert das Passwort, wenn es Plaintext auf der Festplatte gespeichert ist oder wenn es auf einem PostIt am Monitor klebt? Key Management ist deutlich schwerer bei Keyfiles, da man sie nunmal irgendwo im Klartext speichern muss, anstatt sie sich einfach zu merken.

Eine Möglichkeit wäre z.B. die Nutzung von gewöhnlichen PDF/ZIP/JPG/...-Dateien als Keyfiles (Faktor Besitz). Den Speicherort merkt man sich (Faktor Wissen). Im gegebenen Szenario machen Keyfiles allerdings wirklich keinen Sinn. Ein Angreifer in Besitz der Festplatte könnte alle Dateien einfach durchprobieren und so die Festplatte entschlüsseln.

Eventuell könnte man das Setup modifizieren:
1. Zufälliges, n-stelliges Passwort p1 generieren
2. Backup auf sicherer Partition (Rambdisk, verschlüsselter Partition) erstellen, um forensische Maßnahmen zu verhindern.
3. Backup zippen, mit p1 verschlüsseln. An beliebiger Position abspeichern.
4. Passwort mit PGP verschlüsseln und signieren.
5. Passwort an entferntes Email-Postfach versenden. Mögliche Überreste des Passworts (temporäre Dateien, ..) löschen.

Damit bräuchte ein Angreifer sowohl Zugriff auf die Festplatte, als auch auf die Postfächer, um die Backups zu entschlüsseln. Erstellung der Backups erfolgt vollständig automatisiert, Entschlüsselung und Einspielen eines Backups müsste man allerdings manuell machen (außer man schreibt ein Skript, das ... :p).
 
Zurück
Oben