Verschlüsselung - 2 Grundsatzfragen

[luggi83]

Hallo,

ich habe im Moment ein RAID-Array mit knapp 1.5 TB am Laufen (RAID-5). Dieses möchte ich jetzt ggf. verschlüsseln.

1. Ich befürchte mal, es gibt keine Möglichkeit, das on-the-fly zu machen? Also: Daten auslagern, neuen Container anlegen, auf den (leeren) Container zurückzukopieren ist die einzige Möglichkeit?

2. Wenn ich die entsprechenden Anleitungen richtig verstanden habe, muss ich das Passwort bei jedem Reboot physisch am Computer eingeben (OK, sonst macht auch Verschlüsselung nicht eben Sinn). Wenn ich jetzt aber (ausnahmsweise) remote rebooten möchte und mir sicher bin, dass der Rechner in den nächsten 5 Minuten nicht kompromittiert wird, gibt es dann eine Möglichkeit, das PW für den *nächsten* Bootvorgang irgendwie zu hinterlegen, um *einmal* ohne PW-Eingabe booten zu können?

GRüße,

lukas

[pluvo]

Also: Daten auslagern, neuen Container anlegen, auf den (leeren) Container zurückzukopieren ist die einzige Möglichkeit?

Soweit ich weiß ja. (Naja man könnte auch alles über verschiedene Partition verschieben und jeweils verkleinern und vergrößern... aber das würde auch einige Arbeit bedeuten )

2. Wenn ich die entsprechenden Anleitungen richtig verstanden habe, muss ich das Passwort bei jedem Reboot physisch am Computer eingeben

Du kannst den Schlüssel auch auf einem USB-Stick speichern. (Oder auf einer anderen Partition.)

Wenn ich jetzt aber (ausnahmsweise) remote rebooten möchte und mir sicher bin, dass der Rechner in den nächsten 5 Minuten nicht kompromittiert wird, gibt es dann eine Möglichkeit, das PW für den *nächsten* Bootvorgang irgendwie zu hinterlegen, um *einmal* ohne PW-Eingabe booten zu können?

Du könntest mit LUKS einen zusätzlichen Schlüssel anlegen, diesen unter der /boot-Partition speichern und beim nächsten booten diesen zum Aufschließen des verschlüsselten Volumes verwenden. Nach dem Boot-Vorgang löscht du den Schlüssel wieder von der /boot-Partition und entfernst den Schlüssel wieder mit LUKS. (Das habe ich noch nicht ausprobiert, und bin mir auch nicht sicher ob du den Schlüssel entfernen kannst, wenn das Volume zu dem Zeitpunkt damit entschlüsselt wird.)

[goeb]

Euin paar Ergänzungen zu pluvos Antwort:

Zu 1.: Mit LUKS ist on-the-fly Verschlüsselung nicht möglich, wenn du dmcrypt ohne LUKS verwenden möchtest würde es gehen. Ich würde dir trotzdem empfehlen die Daten erstmal zu sichern, die Partitionen mit LUKS zu verschlüsseln und dann zurück kopieren.

Zu 2.: Machbar ist es sicher, und die Schlüsseldatei solltest du auch löschen können (glaube ich, sie wird ja nur gebraucht um das Masterpasswort zu entschlüsseln, das bleibt dann im RAM, die Datei wird dann nicht mehr gebraucht). Aber: du mußt die Datei sicher löschen, d.h. ein einfaches rm keyfile reicht nicht. Und du solltest dann den Schlüssel auch wieder löschen (cryptsetup luksDelKey). (Möglicherweise reicht es auch nur den Schlüssel zu entfernen, wenn cryptsetup die entsprechenden Bytes auf der Platte auch überschreibt. Aber geh lieber auf Nummer sicher.)

Alternative: IIRC habe ich auf https://www.debian-administration.org/ mal einen Artikel gesehen in dem erklärt wird wie man das Passwort über SSH eingeben kann. (Die Seite ist grad down oder so, kann leider nicht nachschauen...)

MfG, gœb

[pluvo]

Und du solltest dann den Schlüssel auch wieder löschen (cryptsetup luksDelKey).

Und genau so lautet mein Frage: Kann man den Schlüssel mit luksRemoveKey/luksKillSlot/luksDelKey löschen, wenn man mit dem Schlüssel gerade das Volume offen hat? (Vielleicht findet sich ein freiwilliger Tester )

[goeb]

Ja, gerade ausprobiert. cryptsetup luksDelKey ... funktioniert auch mit dem Slot der aktuell zur Entschlüsselung verwendet wurde, war zu erwarten, wie gesagt, das Masterpasswort ist dann ja schon RAM. Allerdings muß man zum Entfernen des Schlüssels eines der Passwörter (oder Keyfile) angeben das danach noch aktiv ist. Aber man könnte ja ein Keyfile auf der verschlüsselten Partition selbst anlegen das dann für diesen Zweck verwendet werden kann.

Edit: Der weiter oben erwähnte Artikel: https://www.debian-administration.org/articles/579

MfG, gœb