Archiv verlassen und diese Seite im Standarddesign anzeigen : Verschlüsselung von mehreren Festplatten via LUKS
Guten Abend,
ich habe mich heute dazu entschlossen meine Daten-Festplatten mit AES (256bit) via LUKS und dm-crypt zu verschlüsseln. Da ich nich jede für jede Partition (genauer: Mapping Device) ein einzelnes Passwort eingeben möchte, wenn ich sie mounte, habe ich mir das folgende (rekursive) System überlegt:
Platte 1 wird mit Passwort (ausreichend sicher) entschlüsselt.
Platte 2 wird durch ein Keyfile, das auf Platte 1 liegt entschlüsselt.
Platte 3 wird durch ein Keyfile, das auf Platte 2 liegt entschlüsselt.
usw.
Nun bin ich mir jedoch nicht über die Mountreihenfolge beim Booten sicher. Wird die /etc/fstab der Reihenfolge nach abgearbeitet, oder werden die Partitionen nach ihrem Devicenamen (/dev/sd?) geöffnet.
Des weiteren bin ich mir nich sicher, ob die zu entschlüsselnde Partition schnell genug gemountet werden kann, sodass der Key für die nächste Partition auch tatsächlich in /mnt/* vorhanden ist.
M.f.G.
ventura
Verzichte doch einfach auf die fstab und trag die Partitionen dort gar nicht erst ein. (Un/)mounte doch in einem (Start-)Script, welches Dich bei jedem Aufruf nach dem einem,erstem Passwort fragt.
Alternativ: Nimm immer das selbe Passwort und erstelle ein Script, dass alle Partitionen (un)mountet. Auch dieses Script wird Dich nach dem Passwort fragen.
Ergänzung: Ganz hart gesottene nehmen kein kurzes Passwort sondern ein extrem langes Passwort. Man kann das extrem lange Passwort (z.B. ein 4096 Bit starken RSA-Key) auf einem USB-Stick speichern (und noch zwei weiteren als Backup). Man könnte dann einrichten, dass die Platten gemountet werden, sobald der USB-Stick eingesteckt wird (ohne Passworteingabe). Die erwähnten ganz hart gesottenen haben jedoch Angst, dass den USB-Stick wer in die Finger bekommt und nutzen zusätzlich noch ein Passwort um den USB-Stick zu entschlüsseln.
Danke für den Hinweis, ich hab nun ein Problem in meinem System erkannt: Was ist, wenn eine der Festplatten ausfällt --> Alle darauffolgenden lassen sich nichtmehr entschlüsseln. Ergo ist es wohl wirklich sinnvoller ein Passwort zu verwenden.
Zu den, wie du sie nennst "hart gesottenen" gehöre ich nicht, bzw. sehe ich genau das Problem was du genannt hast (was ist, wenn jemand den Stick findet). Die Lösung, den Stick mit einem Passwort zu schützen würde den Sinn des Sticks wiederum zerstören (wenn ich ein PW für den Stick benötige, kann ich dieses PW auch gleich für die einzelnen Partitionen verwenden; ich gehe davon aus, dass der Stick in die Hände des "Gegners" fällt!).
Am liebsten würde ich den Mount-Vorgang beim Booten erledigen, es ist also ein init-Script von Nöten. Leider habe ich so gut wie keine Erfahrung mit Scripten im allgemeinen. Ich würde mich freuen, wenn mir jemand eine Art "Vorlage" für eine LUKS Entschlüsselung (bei der das Passwort für mehrere Devices nur einmal abgefragt wird) für ein Gentoo System geben könnte, oder eine Quelle, wo dies oder etwas ähnliches zu erfahren ist.
Danke für den Hinweis, ich hab nun ein Problem in meinem System erkannt: Was ist, wenn eine der Festplatten ausfällt --> Alle darauffolgenden lassen sich nichtmehr entschlüsseln. Ergo ist es wohl wirklich sinnvoller ein Passwort zu verwenden.Man kann sich die anderen natürlich auch merken oder notfalls aufschreiben und den Zettel dann verstecken. Dann könnte auch mal ne Partition unbrauchbar sein. ;)
.. (was ist, wenn jemand den Stick findet). Die Lösung, den Stick mit einem Passwort zu schützen würde den Sinn des Sticks wiederum zerstörenDer Vorteil des USB-Stcks ist in erster Linie die extreme Stärke des Passworts. Wenn jemandem Rechner und Stick in die Hände fallen hat er es so schwer wie vorher. Wenn der potenzielle Dechiffrierer nur den Rechner bekommt, sind alle sinnigen Versuche definitiv zum Scheitern verurteilt (z.B. Bruteforce Attaken mit Passwortlisten)
Am liebsten würde ich den Mount-Vorgang beim Booten erledigen, es ist also ein init-Script von Nöten. Leider habe ich so gut wie keine Erfahrung mit Scripten im allgemeinen.Grob gesagt muss man nur alle Befehle in eine Datei schreiben und diese dann ausführen ;). Ansonsten braucht man höchstens noch "read" um eine Eingabe in einer Umgebungsvariablen zu speichert. Wenn das klappt, dann ist nur noch ein kleiner Sprung oder eine weitere Frage nötig, damit alles wie gewollt funktioniert. ..alles ganz einfach ..schaffst Du schon ..nur zu! ;)
Gruss..
Man kann sich die anderen natürlich auch merken oder notfalls aufschreiben und den Zettel dann verstecken. Dann könnte auch mal ne Partition unbrauchbar sein.
Merken, ja. Aber ob Aufschreiben die sicherste Art ist ein Passwort zu schützen, sei mal dahingestellt :D
Der Vorteil des USB-Stcks ist in erster Linie die extreme Stärke des Passworts. Wenn jemandem Rechner und Stick in die Hände fallen hat er es so schwer wie vorher. Wenn der potenzielle Dechiffrierer nur den Rechner bekommt, sind alle sinnigen Versuche definitiv zum Scheitern verurteilt (z.B. Bruteforce Attaken mit Passwortlisten)
Stimmt. Wäre es da sinnig, das Keyfile, das die Platten entschlüsselt mit /dev/urandom zu erstellen, oder gibt es spezielle Programme, die Keys ohne eine, wie auch immer, erkennbare Logik erstellen (beim Computer ist Zufall ja niemals zufällig, sondern folgt auch gewissen Gesetzmäßigkeiten; oder habe ich da eine bahnbrechende Entwicklung verschlafen)
Grob gesagt muss man nur alle Befehle in eine Datei schreiben und diese dann ausführen . Ansonsten braucht man höchstens noch "read" um eine Eingabe in einer Umgebungsvariablen zu speichert - ..alles ganz einfach ..schaffst Du schon ..nur zu!
Gut, dann werde ich mich mal an die große Kunst des Scriptens heranwagen :)
Ich weiß nur jetzt schon, dass ich später folgendes Problem haben werde: Laut dem --help von cryptsetup ist es nicht möglich luksOpen ein Passwort mit auf den Weg zu geben - ergo ist es auch nicht ohne weiteres möglich ein Passwort aus einer zuvor definierten Variable einzusetzen. Wie kann ich dieses Problem nun umgehen?
Edit: Ich habe es doch herausgefunden. Ich muss dazu nur mit einem Keyfile arbeiten, da man dies als Parameter mitgeben kann. Also werde ich deinen Vorschlag mit dem USB-Stick befolgen und auf diesem in einer kleinen, verschlüsselten Partition das Keyfile hinterlegen. Ich denke, dass ich jedoch jedem Device dennoch ein Passwort zuteile, falls ich den Stick verliere, jedoch ist damit wieder der Vorteil des sehr guten Passworts durch den Stick verloren. Oder fällt dir eine andere Möglichkeit ein, das Keyfile sicher zu hinterlegen?
/dev/urandom liefert sicherlich ein recht gutes Passwort. Du kannst das erstellte Passwort ja auch mal wild mit einem Editor bearbeiten. Spätestens dann sollte es einmalig sein ;). Mein Vorschlag mit dem RSA-Key rührt daher, dass dieser Key üblicherweise unter Mithilfe von zufälligen Mausbewegungen und Tastatureingaben erstellt wird und daher hochgradig zufällig ist.
Auch wenn "--help" sagt, dass man zwingend ein Passwort benötigt (hier würde mich die genaue Meldung interessieren), glaube ich, dass das Argument "–key-file=/path/to/key" sinnfrei wäre, wenn man wirklich was eintippen müsste. Da musste ich aber auch erstmal googlen - ich verschlüssel nämlich selbst noch(!) gar nicht und kenne die Software nicht. Wenn man nach "cryptsetup RSA mounten" bei google sucht, liefert Hit 1 das hier..
An dieser Stelle wird man nach der Passphrase gefragt, die man beim Formatieren eingegeben hat. Verwendet man ein Keyfile, muss man dieses ebenfalls mit “–key-file” angeben.
Ich glaube du hast mein Problem missverstanden. Ich sagte, dass es nicht möglich ist cryptsetup luksOpen einen Parameter, der das Passwort enthält mitzugeben (z.B. /bin/cryptsetup luksOpen /dev/sda1 data --password "kaesekuchen"). Ein Keyfile kann als Parameter übergeben werden und ist so für eine Automatisierung deutlich einfacher zu realisieren.
Das Script könnte das Passwort lesen und in einer Datei speichern. Die Datei kann dann mit --key-file=/path/to/datei" als Passwort angegeben weden. Statt einer richtigen Datei könnte auch mit FiFo Dateien arbeiten. So könnte das Script dies lösen.
Du wirst einwenden, dass es unsicher sein kann, das Passwort in Dateien auf der Festplatte oder Dateien im RAM oder Variablen oder sonst irgendwo zu speichern. Das ist sicherlich wahr. Deshalb wird das Passwort wohl auch sonst zwingend als direke Eingabe verlangt.
Das ist wahr :) Das Passwort auf eine unverschlüsselte Partition oder in einen Temp Ordner zu schreiben wäre äußerst ungeschickt. Des weiteren besteht die Gefahr, dass das Keyfile geswappt würde und das wäre ebenfalls sehr unsicher (ich möchte meine / und Swap Partitionen gerne unverschlüsselt lassen, der Performance wegen).
Die Bash-Programmierung ist übrigends nicht so schwer, wie ich dachte. Bis jetzt läuft alles recht gut :D
Ich stehe leider immer noch vor dem Problem, dass ich nicht weiß, wie ich mein Keyfile adäquat sichern könnte, für den Fall, dass der Stick, auf dem es sich befindet, den Geist aufgibt.
Also ein Backup muss sein. Das Backup selbst kann man aber auch verschlüsseln. Nimm z.B. jeden dritten Buchstaben deines Lieblingsbuchs bis Du 92 Buchstaben zusammen hast und schreib dein Geburtsdatum dahinter - kommt kein Mesch drauf, aber Du kannst den Schlüssel mühesam rekonstruieren. Mit sowas kann man dann das Backup verschlüsseln.
Danke für den guten Tipp bezüglich des Backups.
Ich stehe aber nun vor einem neuen Problem, das etwas komplexer ist:
Ich habe auf dem USB Stick nun eine kleine Partition erstellt, diese möchte ich encrypten und danach mounten, um mit dem Keyfile die anderen Platten zu decrypten. Das Problem ist nur, dass mein Script das Device vom USB-Stick wissen muss, was ohne Verschlüsselung via ext2/3 labels funktionieren würde. Jedoch wird die Partition ja erst nach dem verschlüsseln formatiert, sodass Linux die Labels der Partitionen erst kennt, wenn diese geöffnet wurden. Nur brauche ich für das öffnen das Device (dev/sd?#). Ich möchte nur ungern komplizierte udev-Regeln formulieren, da das Script möglichst unabhängig von siner Umgebung sein soll (falls ich formatiere o.ä.)
Darum suche ich nun nach einer Variante ein einzelnes File zu verschlüsseln, das sich dann durch ein Passwort wieder entschlüsseln lässt. GnuPG scheint dafür nicht geeignet (jedenfalls verstehe ich es nicht; Private Keys usw. verwirren mich etwas) und das Problem mit LUKS habe ich oben (hoffentlich verständlich) erleutert. Ich habe es auch schon mit einem LUKS Loop Device auf der ext2 Partition des Sticks versucht, was jedoch gescheitert ist und auch nicht sehr elegant wirkt.
Was ich noch besser fände, wäre ein Weg das Device des Sticks herauszufinden, ohne dabei Labels zu verwenden, oder wie schon oben gesagt, udev-Regeln zu definieren, denn dann könnte ich die einfachste und wohl auch sicherste Methode einer verschlüsselten LUKS Partition auf dem Stick verwenden.
Edit: Habe doch eine Lösung gefunden - scheinbar hat der Stick eine eindeutige ID, anhand derer man ihn auch mounten kann (/dev/disk/by-id/xxxxxxx). Jedoch habe ich nun das Problem, was ich schon die ganze Zeit bei dem Stick bemerke: Immer wenn ich versuche die verschlüsselte Partition mit cryptsetup "luksOpen /dev/disk/by-id/xxxxxxx mappername" zu öffnen, kommt wie gewohnt die Passwortabfrage. Nach Eingabe des Passworts erscheint auch die Meldung "key slot 0 unlocked.", jedoch kommt sofort wieder eine Passwortabfrage. Wenn ich das PW erneut eingebe kommt wieder "key slot 0 unlocked." und danach wieder die Abfrage. Nach dem 3. Mal kommt die Meldung: "Command failed: Invalid offset". Ich bin ratlos, habe die Partition schon mehrmals neu verschlüsselt, aber das Problem besteht weiterhin (es bestand sogar, als ich den Versuch mit dem Loop Device unternommen hatte!).
Edit2: Habe auch dieses Problem gelöst. Die Partition auf dem Stick war mit 700kb einfach zu klein für eine LUKS Partition. Ich habe sie mit parted auf 8MB vergrößert und nun funktioniert alles bestens.
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.