Fragen zur Verschlüsselung der zweiten Festplatte

[bluecat]

Situation:
Debian-Jessie-8.6.0-amd64.
Rechner vorhanden mit erster Festplatte (unverschlüsselte „/boot-Partition“ und Rest der Platte als verschlüsselte LVM-Partition mit „/root“, „/swap“ und „/home“).

Hinzu kommt jetzt eine zweite 4.0 TB große Festplatte als Datenlager/Arbeitsplatz.
Da das Grundsystem verschlüsselt angelegt ist, soll die neue Festplatte ebenfalls verschlüsselt werden.
Angedacht ist eine Verschlüsselung der Platte mittels LUKS-Modus.

Im Laufe der Recherchen dazu, sind jedoch ein paar Fragen aufgetaucht, die ich gerne beantwortet hätte.




Frage-1:
Wenn ich das recht verstanden habe, kann ich die Festplatte einfach als ganzes komplett per dm-crypt und LUKS verwenden, ohne vorher eine Partition (über die gesamte Größe) anlegen zu müssen.?
Also

Code: Alles auswählen

cryptsetup --cipher=aes-xts-plain64 --key-size=512 --hash=sha512 --iter-time=5000 --verify-passphrase luksFormat /dev/sdb

statt extra eine Partition anzulegen und dann per

Code: Alles auswählen

cryptsetup --cipher=aes-xts-plain64 --key-size=512 --hash=sha512 --iter-time=5000 --verify-passphrase luksFormat /dev/sdb1

Gibt es irgendwelche Vor- Nachteile bei den jeweiligen Methoden.?

Zusatzfrage:
Festplatte hat Sektorgröße von (logical/physikal) 512 bytes / 4096 bytes,
und I/O-Size (minimal/optimal) 4096 bytes / 4096 bytes
Wenn ich jetzt die komplette Platte (ohne Partition) verwende (/dev/sdb), fängt er ja direkt am Plattenanfang beim Offset 0 an. Damit sollte es ja auch mit dem Alignment/Ausrichtung wieder passen.?




Weiter per...

Code: Alles auswählen

cryptsetup luksOpen /dev/sdb data_crypt
mkfs.ext4 /dev/mapper/data_crypt

Frage-2:
Standardmäßig verwendet er ja 5% für root. Bei formatierten 3.7 TiB wären dass rund 190 GiB. Gibt es einen Einsatzzweck, der solche Größen rechtfertigt, oder sollte man den Platz dafür per Parameter m begrenzen. Z.B. auf 75GiB (2%).?





Weiter per...
Da ich in einigen (älteren) Beiträgen gelesen habe, daß es mit der Schlüsselableitung und systemd Probleme geben kann, habe ich mich entschlossen einen weiteren Slot von LUKS mit einem Keyfile zu belegen, zur automatischen Einbindung der zweiten Festplatte beim Systemstart.

Code: Alles auswählen

cryptsetup --iter-time=5000 luksAddKey /dev/sdb /home/key.img

Die „normale“ /etc/crypttab und /etc/fstab müßten dann imo wie folgt am Ende erzänzt werden...

Code: Alles auswählen

crypttab:
data_crypt UUID=12345-1234-12345-12345678 /home/key.img luks

fstab:
/dev/mapper/data_crypt /home/data ext4 defaults 0 2

Frage-3a:
Wenn ich jetzt hergehen möchte, und die zweite Platte nicht gleich am Anfang einbinden will, sondern automatisch erst dann, wenn ein Zugriff darauf erfolgt,...

Code: Alles auswählen

crypttab:
data_crypt UUID=12345-1234-12345-12345678 /home/key.img luks,noauto

fstab:
/dev/mapper/data_crypt /home/data ext4 defaults,noauto,x-systemd.automount 0 2

Passt das so.? Laut dem, was ich gefunden habe sollte zumindest die fstab das automount beim Zugriff gehen. Die Frage, ist aber, ob die crypttab-Zeile so korrekt ist, oder ob für das Automount in der fstab die Platte bereits entschlüsselt vorliegen muss. Ich sie also beim Start des Systems auf jeden Fall schon entschlüsseln muss.


Frage-3b:
Bezüglich fstab lese ich in einigen Beiträgen z.B. von Options-Angaben wie (nur als Beispiel):

Code: Alles auswählen

noauto,user,defaults

In anderen Beiträgen lese ich hingegen, und auch nach meinem Verständnis müsste es aber heißen

Code: Alles auswählen

defaults,noauto,user

Da noauto und user die Standardvorgeben in default überschreiben sollen, und deshalb danach kommen müssten. Oder ist es egal, in welcher Reihenfolge die Optionsangaben gemacht werden.?




Frage-4:
Ich hätte vor, die zweite Festplatte in ein Unterverzeichnis von /home einzubinden („/home/datenort“). Sollte eigentlich soweit ich das verstanden habe, möglich sein, soweit das Verzeichnis „/home/datenort“ zuvor existiert.
Oder ist es (aus mir noch unbekannten Gründen) doch besser, die zweite Festplatte auf /media oder /mnt einzubinden.?

Frage-5:
Beim Herunterfahren muß ich die Platte ja nicht aushängen, und abschließen.? Das System sollte das, wenn ich es recht gelesen habe, ja -wie beim LVM auch- selbstständig machen.



Besten Dank, Gruß
bluecat

[rendegast]

Frage-1: Verschlüsselung RAW sdX, statt partitioniert sdX1
Bei einem unbedachten fdisk kann das die "raw"-Verschlüsselung zerstören.

Frage-2: extfs, 5% für root
'reserved' kann per tune2fs jederzeit geändert werden.
Normalerweise dürften/sollten gesetzte quota vorher anschlagen.



Frage-4:
/home2 ?

Frage-5:
Wer will dafür seine Hand ins Feuer legen?
Zum Glück sind journaled-Dateisysteme sehr gutmütig.

[breakthewall]

Frage-1:
Wenn ich das recht verstanden habe, kann ich die Festplatte einfach als ganzes komplett per dm-crypt und LUKS verwenden, ohne vorher eine Partition (über die gesamte Größe) anlegen zu müssen.?
Gibt es irgendwelche Vor- Nachteile bei den jeweiligen Methoden.?

Wenn Du das gesamte Volume verschlüsseln willst, dann langt eine Formatierung mittels cryptsetup. Jedoch werden über das cryptsetup keine Partitionen angelegt, und müssen bereits zuvor existieren. Desweiteren muss man die Parameter nicht in Langform schreiben, und die Passphrase auch nicht verifizieren da das ohnehin geschehen wird.

Code: Alles auswählen

cryptsetup luksFormat -s 512 -i 5000 -h sha512 -c aes-xts-plain64 /dev/sdb

Zusatzfrage:
Wenn ich jetzt die komplette Platte (ohne Partition) verwende (/dev/sdb), fängt er ja direkt am Plattenanfang beim Offset 0 an. Damit sollte es ja auch mit dem Alignment/Ausrichtung wieder passen.?

Das passiert alles automatisch.

Frage-2:
Standardmäßig verwendet er ja 5% für root. Bei formatierten 3.7 TiB wären dass rund 190 GiB. Gibt es einen Einsatzzweck, der solche Größen rechtfertigt, oder sollte man den Platz dafür per Parameter m begrenzen. Z.B. auf 75GiB (2%).?

Das ist historisch bedingt und stammt noch aus Zeiten, in denen Speicherplatz schon mal durchaus knapp werden konnte. Und damit man als Root im Ernstfall nicht handlungsunfähig ist, gab es hier diesen reservierten Speicherplatz. Bei der Installation von Debian lässt sich das beiläufig erwähnt auch auf 0% setzen.

Nachträglich kann das mittels dieses Befehls entfernt werden:

Code: Alles auswählen

tune2fs -m 0 /dev/sdX

Allerdings ist zu empfehlen mindestens 1-2% an reserviertem Speicherplatz einzuräumen, zumal das Dateisystem somit mehr Luft hat für Dateioperationen, auch wenn der Speicherplatz knapp wird. Und somit kann das System auch durch beliebige Prozesse legitimer oder schädlicher Natur nicht vollgeschrieben werden.

Weiter per...
Da ich in einigen (älteren) Beiträgen gelesen habe, daß es mit der Schlüsselableitung und systemd Probleme geben kann, habe ich mich entschlossen einen weiteren Slot von LUKS mit einem Keyfile zu belegen, zur automatischen Einbindung der zweiten Festplatte beim Systemstart.

Code: Alles auswählen

cryptsetup --iter-time=5000 luksAddKey /dev/sdb /home/key.img

Solche Probleme sind mir nicht bekannt. Lediglich das Starten des ganzen Systems via USB-Key kann bisweilen etwas knifflig sein. Eine Schlüsseldatei darf auch niemals unter /home liegen, wenn man Verschlüsselung wirklich sicher umsetzen will. Diese gehört immer unter /root bzw. in Verzeichnisse die vom Nutzer nicht gelesen werden können.

Frage-3a:
Wenn ich jetzt hergehen möchte, und die zweite Platte nicht gleich am Anfang einbinden will, sondern automatisch erst dann, wenn ein Zugriff darauf erfolgt,...
Passt das so.? Laut dem, was ich gefunden habe sollte zumindest die fstab das automount beim Zugriff gehen. Die Frage, ist aber, ob die crypttab-Zeile so korrekt ist, oder ob für das Automount in der fstab die Platte bereits entschlüsselt vorliegen muss. Ich sie also beim Start des Systems auf jeden Fall schon entschlüsseln muss.

An sich reichen hier die noauto Parameter. Dein LUKS-Volume wird ohnehin im Dateimanager erscheinen, womit es einfach einhängen kannst mittels Root-Passwort.

Frage-3b:
Da noauto und user die Standardvorgeben in default überschreiben sollen, und deshalb danach kommen müssten. Oder ist es egal, in welcher Reihenfolge die Optionsangaben gemacht werden.?

Die Reihenfolge ist hierbei egal. Wichtig ist nur das die Struktur der fstab eingehalten wild, und die einzelnen Optionsfelder getrennt voneinander sind.

Frage-4:
Ich hätte vor, die zweite Festplatte in ein Unterverzeichnis von /home einzubinden („/home/datenort“). Sollte eigentlich soweit ich das verstanden habe, möglich sein, soweit das Verzeichnis „/home/datenort“ zuvor existiert.
Oder ist es (aus mir noch unbekannten Gründen) doch besser, die zweite Festplatte auf /media oder /mnt einzubinden.?

Nun wenn Du einen Ordner bzw. Mountpoint unter /home erstellst, dann ist dein LUKS-Volume nicht länger im Dateimanager verfügbar, ausser man nutzt einen Mountpoint unter /media/user, was beim automatischen Einhängen geschieht. Ansonsten wird das LUKS-Volume bei deinem Vorhaben, wie ein gewöhnliches Verzeichnis nutzbar sein.

Frage-5:
Beim Herunterfahren muß ich die Platte ja nicht aushängen, und abschließen.? Das System sollte das, wenn ich es recht gelesen habe, ja -wie beim LVM auch- selbstständig machen.

Das geschieht alles automatisch, wenn dein LUKS-Volume ordentlich in der fstab als auch crypttab eingetragen ist. Schlecht wäre dagegen den PC hart herunterzufahren, was dann meist Dateisystemfehler nach sich zieht. Aber unter anderem Ext4 ist hier recht robust, und korrigiert das idR. problemlos beim Systemstart.

[wanne]

Eine Schlüsseldatei darf auch niemals unter /home liegen,

Ganz im Gegenteil. Dateiberechtigungen setzen kann man wie man will. Und du selbst darfst btw. dein passwort sowieso wissen. Aber wenn dein /root nicht verschlüsselt ist, ist die Verschlüsslung Sinnlos, wenn da das Passwort liegt. Bei den typischen nur /home verschlüsselt installationen ist es sogar unumgänglich, das der Schlüssel unter /home liegt.

Dein LUKS-Volume wird ohnehin im Dateimanager erscheinen, womit es einfach einhängen kannst mittels Root-Passwort.[…]
Nun wenn Du einen Ordner bzw. Mountpoint unter /home erstellst, dann ist dein LUKS-Volume nicht länger im Dateimanager verfügbar

Ich würde jetzt mal nicht von irgend welchen Fancy gnome-Systemd-polkit Features auf die Allgemeinheit schließen.
Schon KDE handhabt das anders.

Das System sollte das, wenn ich es recht gelesen habe, ja -wie beim LVM auch- selbstständig machen.

Ja macht es. Und man bekommt es nicht los. Aber das ist ein anderes Thema.

Oder ist es (aus mir noch unbekannten Gründen) doch besser, die zweite Festplatte auf /media oder /mnt einzubinden.?

Nö. da wo er hingehört.

Gibt es irgendwelche Vor- Nachteile bei den jeweiligen Methoden.?

Ich würde eine GPT drauf machen. Hat den großen Vorteil, dass man den Partitionen Namen geben kann und die Paltte ein GUID:
sdb ist halt die 2. Platte, die das System gefunden hat. Irgend wann ist sda mal etwas langsamer und die Namen vertauschen sich. Vergibst du einen Namen bleibt der immer gleich. Und vor allem: Du erkennst auch nach Jahren der nicht Benutzung wieder was das für eine Platte war. Ansonsten lasse ich mir immer so 250MiB vorne frei. das sind 0.006% also halt nichts. (Weniger als der unterschied einer runtergefallen Erbse in der Erbsensuppe.) Der Platte und hin und wieder ist es dann doch mal sau geschickt, wenn man unverschlüsselt einen Grub ablegen kann, oder von Windows ein Word Dokument sichern.

[breakthewall]

Ganz im Gegenteil. Dateiberechtigungen setzen kann man wie man will. Und du selbst darfst btw. dein passwort sowieso wissen. Aber wenn dein /root nicht verschlüsselt ist, ist die Verschlüsslung Sinnlos, wenn da das Passwort liegt. Bei den typischen nur /home verschlüsselt installationen ist es sogar unumgänglich, das der Schlüssel unter /home liegt.

Beim Platzieren von Schlüsseldateien geht es nicht darum sie selbst lesen zu können, sondern darum zu verhindern das andere ausser Root sie lesen können. Unter /home nutzen Dateiberechtigungen auch nicht viel, wenn der Nutzer im eigenen Verzeichnis vollen Zugriff hat, und diese Schlüsseldatei sogar einfach gelöscht werden kann, ob nun absichtlich, versehentlich, oder durch ein Programm. Das ist unsichere Praxis. Es wurde doch anfangs bereits angegeben, dass das ganze System verschlüsselt sei, und nur noch ein 4TB Volume hinzugefügt werden soll.

Kannst mir mal verraten wie das cryptsetup an die Schlüsseldatei eines verschlüsselten /home Volumes kommt, auf dem genau jene Schlüsseldatei liegt? Da kann man auch gleich seinen Wohnungsschlüssel in der Wohnung lassen, und die Tür hinter sich schliessen. Die kriegt man dann ebenso wenig wieder auf.

Ich würde jetzt mal nicht von irgend welchen Fancy gnome-Systemd-polkit Features auf die Allgemeinheit schließen.
Schon KDE handhabt das anders.

Ich gehe bei solchen Anfragen immer vom Standard aus. Und aufgrund der Fragen schließe Ich ein exotisches Setup völlig aus.

Das System sollte das, wenn ich es recht gelesen habe, ja -wie beim LVM auch- selbstständig machen.

Ja macht es. Und man bekommt es nicht los. Aber das ist ein anderes Thema.

Oder ist es (aus mir noch unbekannten Gründen) doch besser, die zweite Festplatte auf /media oder /mnt einzubinden.?

Nö. da wo er hingehört.

Beide Zitate stammen nicht von mir.

[bluecat]

Bevor hier ein Krieg ausbricht...
Habe ich doch – trotz aller Sorgfalt - Dinge vegessen zu erwähnen.

Debian-Jessie-8.6.0-amd64
Desktop ist KDE
In Anwendung kam damals die erweiterte grafische Installation, und dort wurden, bis auf wenige Ausnahmen (Partitionieren, Netzwerk und Uhrzeit) die Standardvorgaben verwendet.

Das System ist bis auf die Boot-Partition voll verschlüsselt (dm-crypt und LVM). D.h. swap, / und /home sind verschlüsselt. Schlüsseleingabe beim Starten des Systems.

–--------

Da ich in einigen (älteren) Beiträgen gelesen habe, daß es mit der Schlüsselableitung und systemd Probleme geben kann, habe ich mich entschlossen einen weiteren Slot von LUKS mit einem Keyfile zu belegen, zur automatischen Einbindung der zweiten Festplatte beim Systemstart.

Code: Alles auswählen

cryptsetup --iter-time=5000 luksAddKey /dev/sdb /home/key.img

Solche Probleme sind mir nicht bekannt. Lediglich das Starten des ganzen Systems via USB-Key kann bisweilen etwas knifflig sein. Eine Schlüsseldatei darf auch niemals unter /home liegen, wenn man Verschlüsselung wirklich sicher umsetzen will. Diese gehört immer unter /root bzw. in Verzeichnisse die vom Nutzer nicht gelesen werden können.

Ich habe das schon so verstanden, dass es zumindest früher Probleme mit der Schlüsselableitung im Zusammenspiel mit systemd gibt bzw. gab. Und da dachte ich mir, bevor ich jetzt in unsicheres Fahrwasser gerate, umschiffe ich das Ganze mit einer eigenen Schlüsseldatei. Dann muß ich mir als Anfänger keine weiteren Gedanken machen.


Betreff vorgesehener Speicherort der Schlüsseldatei...
Das Verzeichnis „/home“ gehört „root“. Zumindest ist das bei mir so. Und ich habe während der Installation von Debian Jessie an den Werten dafür nichts geändert.
Ich habe als Benutzer nur schreibenden Zugriff auf mein Home-Verzeichnis. Und das liegt in „/home/nutzername“. Es wurde automatisch von Debian während der Installation angelegt, und mit den entsprechenden Rechten versehen.
Von daher dachte ich mir, es passt schon.

Auch habe ich extra getrenne logische Volumes für / und für /home. Weil es für etwaige einfachere System-Updates oftmals so empfohlen wird, es so zu machen, daß „/home“ getrennt vom Stammverzeichnis ist. Das „/home“-Verzeichnis kann man somit beim Systemwechsel immer unangetastet lassen, und das System auf / einfach erneuern, ohne dass etwas passiert. Soweit mein Gedankengang damals. Habe ich da was falsch verstanden.

Die Schlüsseldatei liese sich sicher mit „chmod“ mit „root read only“ noch weiter absichern, um etwaige Bedenken zu zerstreuen.

Aber natürlich kann man die Datei bzw. eine Kopie davon unter / bzw. /root legen. Das hätte den Vorteil, dass die Schlüsseldatei etwas früher zur Verfügung stehen würde, da zuerst das Stammverzeichnis, und erst dann /home gemounted wird. Anschließend dann die zweite Festplatte.
Wo wäre dann der passende Ort dafür. --> /etc




Eine Frage zur (zusätzlichen) Schlüsseldatei.
Lauf Beschreibung beträgt die maximale Größe 8192 Bytes. Da ich ja oben bei der Verschlüsselung mit dem Primärschlüssel (Passphrase) angebeben habe

Code: Alles auswählen

--cipher=aes-xts-plain64 --key-size=512

müßte ja eine Schlüsseldatei von 512 Bytes ausreichend sein. Oder sehe ich das falsch.




Zu Frage-2:

Allerdings ist zu empfehlen mindestens 1-2% an reserviertem Speicherplatz einzuräumen, zumal das Dateisystem somit mehr Luft hat für Dateioperationen, auch wenn der Speicherplatz knapp wird. Und somit kann das System auch durch beliebige Prozesse legitimer oder schädlicher Natur nicht vollgeschrieben werden.

Gut, dann werde ich den reservierten Speicherplatz auf 2% reduzieren. Das wärten dann rund 75 GiB.




Zu Frage-1:

Wenn ich das recht verstanden habe, kann ich die Festplatte einfach als ganzes komplett per dm-crypt und LUKS verwenden, ohne vorher eine Partition (über die gesamte Größe) anlegen zu müssen.?
Gibt es irgendwelche Vor- Nachteile bei den jeweiligen Methoden.?

Wenn Du das gesamte Volume verschlüsseln willst, dann langt eine Formatierung mittels cryptsetup. Jedoch werden über das cryptsetup keine Partitionen angelegt, und müssen bereits zuvor existieren.

Das kapiere ich jetzt nicht ganz.
Wenn ich hergehe, und eine Partition anlege, und dann doch statt sdX1, sdX verwende, findet doch wieder die komplette Platte, ohne die Partition Verwendung. Wiso muß ich dann erst eine Partition anlegen, wenn ich sie eh nicht verwende.?

Frage-1: Verschlüsselung RAW sdX, statt partitioniert sdX1
Bei einem unbedachten fdisk kann das die "raw"-Verschlüsselung zerstören.

Gut, das leuchtet ein. Da außer mir aber niemand mit möglichen Admin-Rechten am System arbeitet, ist die Gefahr als gering einzuschätzen.

Ich würde eine GPT drauf machen. Hat den großen Vorteil, dass man den Partitionen Namen geben kann und die Paltte ein GUID:
sdb ist halt die 2. Platte, die das System gefunden hat. Irgend wann ist sda mal etwas langsamer und die Namen vertauschen sich. Vergibst du einen Namen bleibt der immer gleich. Und vor allem: Du erkennst auch nach Jahren der nicht Benutzung wieder was das für eine Platte war. Ansonsten lasse ich mir immer so 250MiB vorne frei. das sind 0.006% also halt nichts. (Weniger als der unterschied einer runtergefallen Erbse in der Erbsensuppe.) Der Platte und hin und wieder ist es dann doch mal sau geschickt, wenn man unverschlüsselt einen Grub ablegen kann, oder von Windows ein Word Dokument sichern.

Also eine UUID sollte mit luksFormat erstellt werden. Zumindest wenn ich das richtig verstanden habe. Somit sollte die verschlüsselte Einheit auch per UUID ansprechbar sein. Damit sollten Verwechslungen dann ausgeschlossen sein.
Allerdings ist die Idee mit dem Label nicht schlecht. Zumindest, wenn man die Platte als Wechseldatenträger verwenden will.

Jetzt bin jetzt aber bezügleich der Plattengeometrie genauso schlau wie vorher.
GPT und Partition (sdb1) oder doch die ganze Platte als sdb. Ich tendiere irgendwie zur Verwendung der gesamten Platte, also Verschlüsselung RAW als sdb.
Bisher hat mir niemand dringend davon abgeraten.???

Frage:
Gibt es eigentlich einen Befehl, der mit sagt, wo genau dm-crypt bzw. LUKS mit dem Datenbereich genau anfangen. Sodass man die Sektorgrenze / Sektornummer genau bestimmen kann, ab der die Daten wirklich geschrieben werden.
Es heißt zwar immer, dass sich das System schon darum kümmert, dass das Sektor-Alingment bei 4K-Sektor-Platten richtig verläuft, und es beim Schreiben nicht zu Geschwindigkeitsverlusten kommt, aber ich würde es doch gerne selber verifizieren, sofern möglich.


Gruß

[wanne]

Das Verzeichnis „/home“ gehört „root“. Zumindest ist das bei mir so. Und ich habe während der Installation von Debian Jessie an den Werten dafür nichts geändert.
Ich habe als Benutzer nur schreibenden Zugriff auf mein Home-Verzeichnis. Und das liegt in „/home/nutzername“. Es wurde automatisch von Debian während der Installation angelegt, und mit den entsprechenden Rechten versehen.
Von daher dachte ich mir, es passt schon.

Womit du vollständig recht hast. Prinzipiell werden Dateien per default für alle lesbar erstellt. Kannst du aber damit abändern:

Code: Alles auswählen

chmod o-r /home/key.img

Das „/home“-Verzeichnis kann man somit beim Systemwechsel immer unangetastet lassen, und das System auf / einfach erneuern, ohne dass etwas passiert. Soweit mein Gedankengang damals. Habe ich da was falsch verstanden.

Nope. Wobei die viele Programme halt doch Probleme bekommen, wenn sie in einem home arbeiten, dass mit einer neueren Programmversion erstellt wurde.

Wo wäre dann der passende Ort dafür. --> /etc

Da passt es am ehesten hin.

Lauf Beschreibung beträgt die maximale Größe 8192 Bytes.

Da wird sha512 drauf angewendet der frisst eigentlich bis zu 2¹²⁵Byte können. Kann mir nicht vorstellen, dass die da was dran gedreht haben.

Da ich ja oben bei der Verschlüsselung mit dem Primärschlüssel (Passphrase) angebeben habe

Code: Alles auswählen

--cipher=aes-xts-plain64 --key-size=512

müßte ja eine Schlüsseldatei von 512 Bytes ausreichend sein. Oder sehe ich das falsch.

512Bit=64Byte. Wenn du die zufällig erzeugst. Kannst aber ein bisschen mehr nehmen, wenn dein Zufallsgenerator nicht perfekt ist. (z.B. wenn du nur Tippbare Ziechen ohne Umlaute machst hast du ~6.5Bit pro Byte mit Umlauten etwas weniger ohne Sonderzeichen ~6Bit pro Byte ohne case 5Bit pro Byte…)

Wenn ich hergehe, und eine Partition anlege, und dann doch statt sdX1, sdX verwende, findet doch wieder die komplette Platte, ohne die Partition Verwendung. Wiso muß ich dann erst eine Partition anlegen, wenn ich sie eh nicht verwende.?

Wir hatten dir halt beide empfohlen Partitionen zu verwenden.

Also eine UUID sollte mit luksFormat erstellt werden. Zumindest wenn ich das richtig verstanden habe. Somit sollte die verschlüsselte Einheit auch per UUID ansprechbar sein.

Ja. Mit LUKS hast du das Problem nicht. Sprechende Namen finde ich trotzdem schöner. Wobei man das mit leet auch in die UUID machen kann

Bisher hat mir niemand dringend davon abgeraten.???

Wird auch niemand. Bei sachgerechter Bedienung absolut kein Problem. Gibt halt nur ein paar Stolperfallen mehr. Ist nicht nur fdisk das sich da so verhält. Auch Windows fragt direkt beim booten nach, ob es da mal drüber formatieren soll. drückt man OK wars das mit deiner verschlüsselten Partition. Auch kannst du eventuell alte Daten möglicherweise weiter mounten, wenn du nicht die ersten paar kiB mit 0en überschreibst.

Gibt es eigentlich einen Befehl, der mit sagt, wo genau dm-crypt bzw. LUKS mit dem Datenbereich genau anfangen.

Code: Alles auswählen

dd if=/dev/sdxX skip=26 count=1 bs=4 2> /dev/null | hexdump -C

Das sind Sektoren in Hex
Halt schöner:

Code: Alles auswählen

cryptsetup luksDump /dev/sdxX | grep "Payload offset:"

Auch das sind Sektoren. Aber hier in dezimal.
Und Gemessen natürlich vom Partitions/Plattenanfang.

Beide Zitate stammen nicht von mir.

Sorry, habe ich mich vertan.

[breakthewall]

Bevor hier ein Krieg ausbricht...

Keine Sorge. Meist sieht das nur so aus.

Betreff vorgesehener Speicherort der Schlüsseldatei...
Das Verzeichnis „/home“ gehört „root“. Zumindest ist das bei mir so. Und ich habe während der Installation von Debian Jessie an den Werten dafür nichts geändert.
Ich habe als Benutzer nur schreibenden Zugriff auf mein Home-Verzeichnis. Und das liegt in „/home/nutzername“. Es wurde automatisch von Debian während der Installation angelegt, und mit den entsprechenden Rechten versehen.
Von daher dachte ich mir, es passt schon.

Das ist auch richtig so. Bei meiner Intention bzw. um das war Ich immer wieder gelernt habe, ging es letztlich darum, nicht nur Schlüsseldateien für den Nutzer unlesbar zu machen, sondern deren Existenz wie auch den genauen Speicherort zu verschleiern. Sollte tatsächlich mal etwas passieren, würde der Angreifer nicht unmittelbar sehen wo Schlüsseldateien liegen, oder ob überhaupt welche genutzt wurden. Ist in dem Sinne nur ein Zusatz, aber auch nicht zwingend notwendig, weshalb auch bei deinem Vorhaben bleiben kannst.

Auch habe ich extra getrenne logische Volumes für / und für /home. Weil es für etwaige einfachere System-Updates oftmals so empfohlen wird, es so zu machen, daß „/home“ getrennt vom Stammverzeichnis ist. Das „/home“-Verzeichnis kann man somit beim Systemwechsel immer unangetastet lassen, und das System auf / einfach erneuern, ohne dass etwas passiert. Soweit mein Gedankengang damals. Habe ich da was falsch verstanden.

Völlig richtig. Somit kann das System nicht unmittelbar vollgeschrieben werden, einzelne Volumes können so auch als bspw. read-only eingehängt werden, wie / und /boot, bzw. jedes getrennte Volume kann einen eigenen Sicherheitskontext besitzen.

Aber natürlich kann man die Datei bzw. eine Kopie davon unter / bzw. /root legen. Das hätte den Vorteil, dass die Schlüsseldatei etwas früher zur Verfügung stehen würde, da zuerst das Stammverzeichnis, und erst dann /home gemounted wird. Anschließend dann die zweite Festplatte.
Wo wäre dann der passende Ort dafür. --> /etc

Besser nur die eine Schlüsseldatei und keine Kopien anfertigen, sonst hat man nur noch mehr an was man denken muss. An sich wenn man die Rechte entsprechend setzt, kann die Schlüsseldatei natürlich überall liegen. Unter /root wäre sie eben von Haus aus nur für Root lesbar, ohne sich um mehr kümmern zu müssen.

Eine Frage zur (zusätzlichen) Schlüsseldatei.
Lauf Beschreibung beträgt die maximale Größe 8192 Bytes. Da ich ja oben bei der Verschlüsselung mit dem Primärschlüssel (Passphrase) angebeben habe

Code: Alles auswählen

--cipher=aes-xts-plain64 --key-size=512

müßte ja eine Schlüsseldatei von 512 Bytes ausreichend sein. Oder sehe ich das falsch.

Eine Maximalgröße von 8KB ist natürlich schon eine Hausnummer, aber nun wirklich nicht nötig. Und ein Schlüssel der länger ist als die Sicherheitsmarge des Verschlüsselungsalgorithmus, bringt letztlich auch kein echtes Plus an Sicherheit. Also wäre ein Schlüssel von über 256-Bit kontraproduktiv, was einem Schlüssel von 32 beliebigen Zeichen entspricht. Über den XTS-Modus wird das nochmals verdoppelt, womit der Schlüssel bei 512-Bit bzw. 64 Zeichen bleiben kann. Mehr Länge wäre nur eine Sache des vl. besseren Gefühls, aber bringt wirklich nichts. Bis so etwas einmal geknackt werden kann, werden AES, Twofish, Serpent etc. längst abgelöst worden sein. Nebenbei erwähnt ließen sich ja für das cryptsetup beliebige auch binäre Schlüssel verwenden, wodurch man zur Tarnung bspw. ebenso ein valides Bild als Schlüsseldatei nutzen könnte. Unter tausenden Bildern wäre das dann ziemlich unscheinbar.

Das kapiere ich jetzt nicht ganz.
Wenn ich hergehe, und eine Partition anlege, und dann doch statt sdX1, sdX verwende, findet doch wieder die komplette Platte, ohne die Partition Verwendung. Wiso muß ich dann erst eine Partition anlegen, wenn ich sie eh nicht verwende.?

Das war anders gemeint. Deine ursprüngliche Aussage las sich so, als könnte man mit dem cryptsetup beliebige Partitionen anlegen, was ja nicht so ist. Es kann nur mit dem gearbeitet werden, was bereits vorhanden ist. Hast also deine 4TB in mehrere Partitionen unterteilt, dann kannst diese auch separat verschlüsseln via /dev/sdX1,2 etc., ansonsten bleibt es bei /dev/sdX und den ganzen 4TB.

[bluecat]

512Bit=64Byte.

Aaah... Mist, mal wieder nicht aufgepasst.
Bit nicht Byte.

Ich war so frei, mich bei urandom zu bedinen.

Code: Alles auswählen

dd if=/dev/urandom of=/etc/wd40key.img bs=64 count=1

Für die fest installierte Festplatte habe ich jetzt doch die gesamte Platte verwendet, ohne extra eine Partition anzulegen. Erschien mir irgendwie logischer.

Code: Alles auswählen

cryptsetup luksDump /dev/sdxX | grep "Payload offset:"

Payload-Offset ergibt 4096.
512 * 4096 = 2MiB --> ohne Rest teilbar. Damit sollte imo das Alignment stimmen.




Dank an die Beteiligten
bluecat

[wanne]

Code: Alles auswählen

dd if=/dev/urandom of=/etc/wd40key.img bs=64 count=1

Ich mache immer das:

Code: Alles auswählen

head -c 64 /dev/urandom | base64 | tr -d '\n' > /etc/wd40key.img

Vorteile:
* Das Passort ist ASCII und kann notfalls auch mal abgeschrieben werden.
* Man hat keine kryptische dd syntax.
Nachteil:
* Den Zeilenumbruch am Ende wieder zu entfernen macht das ganze wider ähnlich cryptisch wie deinen Befehl.
Alternative, die exakt das selbe wie deiner macht wäre der:

Code: Alles auswählen

head -c 64 /dev/urandom > /etc/wd40key.img

Finde ich als bash user viel eleganter.

[breakthewall]

Code: Alles auswählen

head -c 64 /dev/urandom | base64 | tr -d '\n' > /etc/wd40key.img

Code: Alles auswählen

head -c 64 /dev/urandom > /etc/wd40key.img

Noch eine mögliche Kombination:

Code: Alles auswählen

tr -cd [:alnum:] </dev/urandom | head -c64 > crypt.key

Vermeidet von vorne herein binäre Zeichen, zwecks Lesbarkeit, und kann variabel über Zeichenklassen verändert werden. Wäre auch bspw. kompatibel mit gpg und dergleichen.