Luks: Key über ssh transferieren.

[crhn]

Hallo,

Situation:
Auf meinem Laptop liegt der Key zum entschlüsseln einer Platte (nicht root).
Die externe Platte hängt an meinem "Server" und soll über ssh entschlüsselt werden.
Verschlüsselt ist mit dm-crypt/ luks (cryptsetup).
Im Moment mach ich das mit nem Passwort über ssh mit cryptsetup luksOpen.

Frage:
Gibt's da was mit dem ich das komfortabel vom Laptop aus verwalten könnte?
Sonst hätte ich mir jetzt selber was gebastelt mit ner Pipe zwischen ssh und cryptsetup oder so.

Mein Problem bei der Suche war, dass ich immer nur Beiträge zu nem verschlüsselten rootfs
mit dropbear und initrd gefunden hab.

Vielen Dank,
crhn

[syssi]

Wie waers mit:

Code: Alles auswählen

ssh server "cat | cryptsetup --key-file=- luksOpen /dev/disk/by-uuid/a412f.... usb_crypto && mount /dev/mapper/usb_crypto /media/usb" << ~/keyfile.txt
sshfs server:/media/usb ~/usb
ls -l ~/usb

[Lohengrin]

Wie waers mit:

Code: Alles auswählen

ssh server "cat | cryptsetup --key-file=- luksOpen /dev/disk/by-uuid/a412f.... usb_crypto && mount /dev/mapper/usb_crypto /media/usb" << ~/keyfile.txt
sshfs server:/media/usb ~/usb
ls -l ~/usb

Vorsicht! Das Keyfile geht über die bash. Könnte das dabei unverschlüsselt irgendwo herumliegen und abgeschnorchelt werden?
Bei Parametern ist das der Fall. Wie ist das hier bei der Standardeingabe?

[syssi]

Die Standardeingabe taucht nicht in irgendwelchen Prozesslisten auf. Ich behaupte sie ist ebenso sicher, wie die Eingabe eines Passwoerts ueber die gleiche SSH-Verbindung. Klar kann man auf der Gegenseite so Spaesse veranstalten, wie "alias cat='tee mitschrift.txt' aber dann ist sowieso das System kompromitiert. Wovon ich definitiv absehen wuerde ist ein temporaeres ablegen des Keyfiles auf dem fremden System.

[Lohengrin]

Die Standardeingabe taucht nicht in irgendwelchen Prozesslisten auf. Ich behaupte sie ist ebenso sicher, wie die Eingabe eines Passwoerts ueber die gleiche SSH-Verbindung.

Klingt plausibel. Das sind ja alles Prozesse, die dem Benutzer gehören, der auch das Passwort über ssh eingeben würde, und das geht auch über die Standardeingabe der Shell.

Klar kann man auf der Gegenseite so Spaesse veranstalten, wie "alias cat='tee mitschrift.txt' aber dann ist sowieso das System kompromitiert.

Richtig. Wenn jemand weiß, dass die Gegenseite ein verschlüsseltes Dateisystem hat, kann er auf diese Weise das Passwort abfangen. Sollte allerdings jemand kommen, und einfach nur den Rechner mitnehmen, fällt das demjenigen, der den Server wie gewöhnlich starten will, auf, bevor er noch einmal sein Passwort eingibt.

Wovon ich definitiv absehen wuerde ist ein temporaeres ablegen des Keyfiles auf dem fremden System.

Im unverschlüsselten Bereich der Festplatte würde ich das auch nicht tun. Aber auf einer Ramdisk ist das in Ordnung. Während des Betriebs liegt der Schlüssel eh irgendwo im Ram.

[syssi]

Oder man speichert den Schluessel in CPU Registern, damit niemand den Arbeitsspeicher runterkuehlt und extern dumpt.
http://www1.informatik.uni-erlangen.de/ ... tresor.pdf

(nicht ernst gemeint)

[crhn]

Oder man speichert den Schluessel in CPU Registern, damit niemand den Arbeitsspeicher runterkuehlt und extern dumpt.

Den Vortrag hab ich gesehen. Fand ich ziemlich interessant, aber so sicherheitskritisch sind meine Daten dann doch nicht.
Ich hab dann auch noch das hier gefunden:
http://www.youtube.com/watch?v=QSIZOJ_3KrM
Das ist eigentlich das was ich such, scheint mir aber noch nicht so ganz fertig.
Ich versuch mir erstmal nen Bashscript zu basteln das dann über ssh die Keys stdin piped (schreibt man das so?).

Danke ihr zwei. Ich setzt mal auf gelöst, falls aber noch jemand nen Vorschlag hat schau ich mir das gerne an.

[Lohengrin]

Oder man speichert den Schluessel in CPU Registern, damit niemand den Arbeitsspeicher runterkuehlt und extern dumpt.

Den Vortrag hab ich gesehen. Fand ich ziemlich interessant, aber so sicherheitskritisch sind meine Daten dann doch nicht.
Ich hab dann auch noch das hier gefunden:
http://www.youtube.com/watch?v=QSIZOJ_3KrM
Das ist eigentlich das was ich such, scheint mir aber noch nicht so ganz fertig.

Solange das /bin/ unverschlüsselt ist, kann dir jemand die Befehle manipulieren, und dann hat er dich. Ich weiß nicht, wie du einen Rechner remote hochkriegen kannst, ohne dass irgend etwas Manipulierbares unverschlüsselt auf dem remote Rechner liegt. Daher schützt, den Schlüssel nicht im Ram liegen zu haben, nur gegen jemanden, der eindringt, den laufenden Rechner findet, und zufällig das Werkzeug zum Kühlen dabei hat. Sollte er das dann noch vorbereiten müssen, wird er eher Programme manipulieren, und warten, bis er von dir das Passwort bekommt.

Wie immer gilt: Es gibt keine absolute Sicherheit. Es kann immer jemanden geben, der schlauer als du ist. Du hast es mit der verschlüsselten Platte einem Angreifer schon sehr schwer gemacht.

[jeff84]

Solange das /bin/ unverschlüsselt ist, kann dir jemand die Befehle manipulieren, und dann hat er dich. Ich weiß nicht, wie du einen Rechner remote hochkriegen kannst, ohne dass irgend etwas Manipulierbares unverschlüsselt auf dem remote Rechner liegt. Daher schützt, den Schlüssel nicht im Ram liegen zu haben, nur gegen jemanden, der eindringt, den laufenden Rechner findet, und zufällig das Werkzeug zum Kühlen dabei hat. Sollte er das dann noch vorbereiten müssen, wird er eher Programme manipulieren, und warten, bis er von dir das Passwort bekommt.

Wie immer gilt: Es gibt keine absolute Sicherheit. Es kann immer jemanden geben, der schlauer als du ist. Du hast es mit der verschlüsselten Platte einem Angreifer schon sehr schwer gemacht.

Naja, für den Fall könnte man ja Checksummen über die unverschlüsselten Ordner bilden und die überprüfen lassen, bevor man den Key übermittelt...

[Cae]

Naja, für den Fall könnte man ja Checksummen über die unverschlüsselten Ordner bilden und die überprüfen lassen, bevor man den Key übermittelt...

Mit was? md5sum, das noch nicht verschlüsselt vorliegt? Mit einem hasher, den man jedes Mal hochlädt? Wer sagt, dass der nicht vor dem Ausführen durch eine Fnord-Variante ersetzt wird? Ich habe Zweifel, ob man rein softwaretechnisch aus dem Dilemma heraus kommt.

Gruß Cae

[Lohengrin]

Naja, für den Fall könnte man ja Checksummen über die unverschlüsselten Ordner bilden und die überprüfen lassen, bevor man den Key übermittelt...

Mit was? md5sum, das noch nicht verschlüsselt vorliegt? Mit einem hasher, den man jedes Mal hochlädt? Wer sagt, dass der nicht vor dem Ausführen durch eine Fnord-Variante ersetzt wird? Ich habe Zweifel, ob man rein softwaretechnisch aus dem Dilemma heraus kommt.

Ich meine mich zu erinnern, dass man theoretisch beweisen kann, dass so etwas prinzipiell nicht geht.
Man kann es aber dem Angreifer noch etwas schwieriger machen.

Das große Problem, das ich sehe, ist die Authentifizierung des SSH-Servers. Das dafür nötige Zertifikat muss unverschlüsselt vorliegen. Und da ist der Platz in der Mitte für den Angreifer.

[jeff84]

Ich meine mich zu erinnern, dass man theoretisch beweisen kann, dass so etwas prinzipiell nicht geht.
Man kann es aber dem Angreifer noch etwas schwieriger machen.

Das große Problem, das ich sehe, ist die Authentifizierung des SSH-Servers. Das dafür nötige Zertifikat muss unverschlüsselt vorliegen. Und da ist der Platz in der Mitte für den Angreifer.

Ok, klar. Gegen einen fähigen Gegner, der Zugriff auf den Rechner hat/hatte, dürfte es schwierig sein. Aber ein wenig Aufwand wäre es schon die Sachen zu umgehen...