
Ich kann eine meiner LUKS-Partitionen auf Raspberry PI aufgrund der Speicherbeschränkung nicht öffnen. Ich habe bereits herausgefunden, dass der Vorschlag in diesem Fall lautet:Erstellen Sie die Partition auf dem langsamsten Gerät neu, das darauf zugreifen kann(in diesem Fall der Raspberry PI).
Bedenken bereiten mir allerdings die möglicherweise geringere Sicherheit (wahrscheinlich wird bei geringerer Rechenleistung ein schwächerer Schlüssel verwendet).
Dies ist, was die Dokumentation von Cryptsetup zu diesem Problem sagt:
Hinweis: Die Iterationszeit der Passphrase wird von cryptsetup abhängig von der CPU-Leistung bestimmt. Auf einem langsamen Gerät kann dies niedriger sein als gewünscht. Ich habe dies kürzlich auf einem Raspberry Pi getestet und es kam auf etwa 1/15 der Iterationszahl eines typischen PCs. Wenn Sicherheit an erster Stelle steht, sollten Sie die Iterationszeit erhöhen, auf Kosten einer langsameren Entsperrung später. Für den Raspberry Pi verwenden Sie
cryptsetup luksFormat -i 15000 <target device>
gibt Ihnen eine Iterationszahl und Sicherheitsstufe, die einem durchschnittlichen PC für Passphrase-Iteration und Master-Key-Iteration entspricht. Wenn Sie Zweifel haben, überprüfen Sie die Iterationszahlen mit
cryptsetup luksDump <target device>
und passen Sie die Iterationszahl entsprechend an, indem Sie den Container mit einer anderen Iterationszeit erneut erstellen (die Zahl nach „-i“ ist die Iterationszeit in Millisekunden), bis Ihre Anforderungen erfüllt sind.
Nun bin ich nicht sicher, was passieren wird, wenn ich den obigen Rat befolge.
- Ist die Partition so sicher wie auf einem PC?(wenn die Iterationszahl korrekt ist), nur langsamer?
- Wenn es langsamer ist, ist dann nur das Entsperren langsamer oder sind spätere Lese-/Schreibvorgänge genauso schnell wie ohne die zusätzliche Iteration? (Wenn ja, warum? Liegt es daran, dass wir durch das Entsperren nur den Schlüssel entschlüsseln, der später zum Entschlüsseln des Inhalts in der Partition verwendet wird?)
- Verbraucht sie trotzdem weniger Speicher als die auf einem schnellen PC erstellte Partition? (Mit anderen Worten: Ich möchte die Partition neu erstellen, um sie mit Raspberry PI verwenden zu können. Mit den Standardwerten ist sie zwar verwendbar, aber weniger sicher. Ist sie mit der erhöhten Iterationszahl noch verwendbar oder würde sie wieder zu viel Speicher verbrauchen?)
Antwort1
Beachten Sie zunächst, dass die LUKS-Dokumentation, die Sie gelesen haben, für LUKS1 geschrieben wurde und mittlerweile etwas veraltet ist. Alles, was Sie zitiert haben (z. B. Iterationsanzahl), ist spezifisch für den PBKDF2-Algorithmus, den Ihre Partitionnutzt es eigentlich nicht.
LUKS2 unterstützt zwei Algorithmen zur Umwandlung Ihrer Passphrase in einen Schlüssel: den traditionellen PBKDF2 sowie den neueren Argon2. Letzteren verwendet LUKS jetzt standardmäßig und er ist der einzige, der eine (einstellbare) Mindestspeichermenge benötigt. Das ist nicht dasselbe wie „Iterationsanzahl“.
Bedenken bereiten mir allerdings die möglicherweise geringere Sicherheit (wahrscheinlich wird bei geringerer Rechenleistung ein schwächerer Schlüssel verwendet).
Sie passen nicht die Tastenstärke an, sondern dieSchutz.
Die Parameter, die Sie optimieren, sollen davor schützen, dass jemand versucht, die von Ihnen eingegebene Passphrase anzugreifen. Sie verhindern Brute-Force-Angriffe (d. h. das Ausprobieren mehrerer Passphrasen nacheinander), indem sie den Prozess der Schlüsselableitung unglaublich langsam machen.
Der erstellte Schlüssel ist jedoch für sich genommen immer gleich stark (er ist genauso gut wie jeder andere AES-Schlüssel) und niemand würde sich die Mühe machen, ihn direkt anzugreifen.
Wenn es langsamer ist, ist dann nur das Entsperren langsamer oder sind spätere Lese-/Schreibvorgänge genauso schnell wie ohne die zusätzliche Iteration? (Wenn ja, warum? Liegt es daran, dass wir durch das Entsperren nur den Schlüssel entschlüsseln, der später zum Entschlüsseln des Inhalts in der Partition verwendet wird?)
Jedes Mal, wenn Sie das Volume entsperren, konvertiert LUKS Ihre Passphrase mithilfe einer „Schlüsselableitungsfunktion“ (KDF) in einen Verschlüsselungsschlüssel, damit der Vorgang widerstandsfähiger gegen Brute-Force-Angriffe wird. LUKS1 verwendete immer „PBKDF2“, das aufgrund seiner langsamen Rechenleistung widerstandsfähig ist (aber keine Speicheranforderungen stellt), während LUKS2 zusätzlich „Argon2“ unterstützt, das stattdessen eine bestimmte Menge an RAM erfordert.
Die Schlüsselableitung erfolgt nur einmal beim Entsperren; für den Rest (die eigentliche Datenverschlüsselung) sind überhaupt keine Passphrasen erforderlich.
(Mit anderen Worten: Ich möchte die Partition neu erstellen, um sie mit Raspberry PI verwenden zu können. Mit den Standardwerten ist sie verwendbar, aber weniger sicher. Wird sie mit der erhöhten Iterationszahl immer noch verwendbar sein oder würde sie wieder zu viel Speicher verbrauchen?)
Sie müssen die Partition überhaupt nicht neu erstellen, da selbst der aus der Passphrase abgeleitete Schlüssel nicht zum direkten Verschlüsseln Ihrer Daten verwendet wird: Er verschlüsselt nur dieMeisterSchlüssel, der im LUKS-Volume-Header gespeichert ist.
Aus diesem Grund ist es möglich, die Passphrase schnell zu ändern, ohne die gesamte Festplatte neu verschlüsseln zu müssen (oder sogar mehrere Passphrasen zu haben), und ebenso können Sie mit LUKS die KDF-Parameter genauso einfach ändern.
Wenn die Standardparameter von Argon2 zu viel Speicher verbrauchen, teilen Sie das einfach LUKS mit:
cryptsetup luksConvertKey --pbkdf "argon2i" --pbkdf-memory <num_kilobytes> <device>
Wenn Sie Argon2 überhaupt nicht verwenden können, können Sie LUKS trotzdem anweisen, stattdessen PBKDF2 zu verwenden:
cryptsetup luksConvertKey --pbkdf "pbkdf2" --iter-time <milliseconds> <device>
Anstelle von Millisekunden (die geräteabhängig sind) können Sie direkt die Anzahl der PBKDF2 angebenIterationendie Sie möchten (was immer das gleiche Ergebnis liefert, egal auf welchem Gerät Sie es tun) – der Standardwert auf einem PC liegt irgendwo bei einer Million:
cryptsetup luksConvertKey --pbkdf "pbkdf2" --pbkdf-force-iterations <count> <target>
Die gleichen Optionen werden akzeptiert luksChangeKey
(beim Ändern der Passphrase), tatsächlich scheint es, als ob siebrauchenmuss bei jeder Änderung der Passphrase angegeben werden.