staging.inyokaproject.org

Durch nen Zufall bin ich nun draufgekommen wodurch der Bug zustande kam.
Wurde wohl dadurch verursacht das die Partition auf dem Datenträger gemountet war. Ist sie ausgehängt funktionierts ohne Probleme.
Interessanterweise wird die vorhandene Partition aber trotzdem zerstört wenn der Fehler auftritt, er lässt sich nur nachher nicht mit luksOpen öffnen da das Passwort nicht akzeptiert wird. Außerdem beschwert sich gparted über einige Fehler in den Partitionstabellen die ich auch nur durch mehrmalige Versuche die kaputte luks-crypt Partition zu löschen hinbekommen hab.
Ich werd das in den Baustellen Artikel auch noch einarbeiten das man darauf achten soll.

Würd mich aber mal interessieren ob das in den älteren Versionen auch so der Fall ist ? (Kernel 2.6 oder kleiner)

Der Baustellenarikel ist soweit fertig und kann von meiner Seite aus übernommen werden ☺

Geändert ist nun (von oben nach unten):

• getestet +oneiric

• "Zum Verständnis dieses Artikels sind" +Formatieren (hat einfach gefehlt find ich, hab zuerst selbst wie ein dummer die Kommandos zum formatieren gesucht)

• Absatz "Erstellen", zweites "Achtung!" +unmount

• neuer Absatz am Ende "Workaround bei Problemen"

Den neuen Absatz am Schluss hab ich versucht so kurz wie möglich zu hallten, ich denke mal das sollte damit jeder der schonmal einen verschlüsselten Datenträger bei der Installation erstellt hat hinbekommen.

Hi thyriel81,

ein Einrichten ueber die Kommandozeile hat dann doch funktioniert? Ich habe das so aufgefasst und ein wenig den Text abgeaendert, schaue bitte drueber, ob du damit zufrieden bist. Ansonsten imho in Ordnung. Vielen Dank schonmal fuer den Zusatz und das Testen.

Gruss Lasall

Passt perfekt ☺

Lasall

ein Einrichten ueber die Kommandozeile hat dann doch funktioniert?

Ja das funktioniert nun, war nur das Problem das die Partition gemountet war... muss man auch erstmal draufkommen wenn die Fehlerroutine im cryptsetup das nicht abfängt *g*

Hi thyriel81,

warten wir noch ein paar (ca. 3) Tage. Wenn bis dahin keine Anmerkungen kommen, wird der Artikel ins Wiki verschoben.

Gruss Lasall

Hi thyriel81,

vielen Dank fuer deinen eingebrachten Verbesserungsvorschlag! Artikel nun wieder im Wiki.

Gruss Lasall

allerdings ungetestet! Kann Jmd bitte eine aktuelle Version eintragen? Danke

Hallo,

ein Fall für RvD😉

Gruß, noisefloor

Im Wiki-Eintrag steht folgendes unter dem Punkt "Beim Startvorgang":

Zum Öffnen eines abgeleiteten LUKS-Geräts beim Systemstart wird die folgende Zeile in angepasster Form ^[4] an die Datei /etc/crypttab angehängt ^[5].

Das hat mich etwas verwundert, da an dieser Stelle doch gar nicht mit abgeleiteten LUKS-Geräten gearbeitet wird.
Abgeleitete Schlüssel werden doch im Artikel LUKS/Schlüsselableitung behandelt und dort steht der oben zitierte Satz ebenfalls. Allerdings sieht der Eintrag für die /etc/crypttab jeweils anders aus.

Kann es sein, dass der oben zitierte Satz hier einfach kopiert wurde und nicht ganz richtig ist, da es ja hier um Schlüsseldateien geht?

Hi MKay,

das sieht alles korrekt aus. Und die 2 Zeilen in der crypttab unterscheiden sich ja auch. Bitte verlinke mal direkt auf die Abschnitte und formuliere das Problem neu, da ich es leider nicht verstehe.

Gruss Lasall

OK, ich versuche mich etwas verständlicher auszudrücken ☺

Im Artikel LUKS/Schlüsselableitung geht es ja darum, dass der Schlüssel für ein LUKS-Gerät aus einem bereits entschlüsselten LUKS-Gerät abgeleitet wird.
Entsprechend steht unter LUKS/Schlüsselableitung (Abschnitt „Beim-Startvorgang“) folgendes:

Zum Öffnen eines abgeleiteten LUKS-Geräts beim Systemstart wird die folgende Zeile in angepasster Form ^[3] an die Datei /etc/crypttab angehängt ^[4].

Und die angegebene crypttab Zeile verweist auch auf das decrypt_derived-Skript.
Das passt also alles soweit.

Im Artikel LUKS/Schlüsseldatei geht es jedoch nicht um abgeleitete Schlüssel.
Unter LUKS/Schlüsseldatei (Abschnitt „Beim-Startvorgang“) steht aber der gleiche Satz:

Zum Öffnen eines abgeleiteten LUKS-Geräts beim Systemstart wird die folgende Zeile in angepasster Form ^[4] an die Datei /etc/crypttab angehängt ^[5].

In der crypttab-Zeile darunter wird richtigerweise die Schlüsseldatei angegeben und kein decrypt_derived-Skript.
Ich finde es jetzt nur verwirrend, dass hier wieder "abgeleiteten LUKS-Gerät" steht, da hier ja keine Schlüsselableitung von bestehenden LUKS-Geräten stattfindet.
Oder ich interpretiere hier die Begriffe o.Ä. falsch 🙄

Hi MKay,

danke für den Hinweis ☺ , done.

Gruss Lasall

archiviert, da st >6 Mo ungetestet

Ich habe ein paar Fragen:

1. Ist es während des entschlüsselns des Geräts mit dem abgeleiteten Schlüssel möglich diesen mitzuschneiden? Damit würde ein Sicherheitsrisiko enstehen auf welches hier nicht eingegangen wird.

2. Wie genau funktioniert der Sicherheitsschlüssel? Kann ich das Gerät dann manuell mit dem luksOpen-Befehl und dem Sicherheitsschlüssel öffnen?

crazy-biscuit schrieb:

1. Ist es während des entschlüsselns des Geräts mit dem abgeleiteten Schlüssel möglich diesen mitzuschneiden? Damit würde ein Sicherheitsrisiko enstehen auf welches hier nicht eingegangen wird.

Das unverschlüsselte /boot könnte jemand modifizieren, der sich Zugang zu deinem Rechner verschafft. Dann können alle Keys die in der Bootphase aufgemacht werden auch mitgeschnitten werden, das System ist kompromittiert. Wenn dein Rechner in einer Umgebung steht auf die andere Zugriff haben oder du fürchten mußt daß sich jemand Zugriff in deine Wohnung verschafft, wäre eine Möglichkeit, /boot auf einen USB-Stick zu verlegen den du am Schlüsselbund immer bei dir trägst. Als zusätzliche Sicherheitsmaßnahme könntest du dann auch mit verschlüsselten Keyfiles auf dem USB-Stick arbeiten. Der Angreifer braucht dann eine Kopie des USB-Sticks sowie das Passwort für die Keyfiles auf dem USB-Stick. Ohne Keyfiles reicht ein einfacher Keylogger.

2. Wie genau funktioniert der Sicherheitsschlüssel? Kann ich das Gerät dann manuell mit dem luksOpen-Befehl und dem Sicherheitsschlüssel öffnen?

Ja, LUKS unterstützt bis zu 8 Keys/Passwörter, solltest du für ein dir bekanntes zusätzliches Passwort nutzen für den Fall daß die Schlüsselableitung mal nicht mehr funktionieren sollte.