Frage:
Verschlüsselung mit Passwörtern - Verschlüsselung von Schlüssel und Daten
Iszi
2015-05-11 20:05:16 UTC
view on stackexchange narkive permalink

Viele kennwortbasierte Verschlüsselungsprogramme (z. B. KeePass, TrueCrypt) tun etwas in der Art von ...

  1. Daten mit einem superstarken, zufällig generierten Schlüssel, "Datenschlüssel", verschlüsseln.
  2. Verschlüsseln Sie den Datenschlüssel mit einem anderen Schlüssel, "Benutzerschlüssel", basierend auf dem vom Benutzer angegebenen Kennwort.
  3. Wenn ein Zugriff erforderlich ist, gibt der Benutzer das Kennwort an. Das Kennwort wird verwendet, um den Benutzerschlüssel neu zu erstellen, der den Datenschlüssel entschlüsselt und die Daten entschlüsselt.
  4. ol>

    Vermutlich lautet die Logik dahinter:

  • Vom Benutzer bereitgestellt Passwörter sind zum Kotzen, daher benötigen wir einen besseren Schlüssel zum Schutz der Daten.
  • Benutzer benötigen weiterhin Zugriff auf die Daten, daher benötigen wir eine Möglichkeit, dies mit einem Passwort zu tun.

Das Fazit ist jedoch, dass der Schutz der Daten immer noch auf die Stärke und den Schutz des vom Benutzer angegebenen Kennworts hinausläuft. Was ist der eigentliche Sinn des zusätzlichen Overheads bei der Verwendung eines separaten Schlüssels?

Sieben antworten:
#1
+47
Thomas Pornin
2015-05-11 20:16:38 UTC
view on stackexchange narkive permalink

Der Hauptvorteil der Verwendung eines Zwischenschlüssels besteht darin, dass Sie Ihr Kennwort ändern können, ohne alle Daten erneut verarbeiten zu müssen.

ZB. Sie haben eine große Datei (Gigabyte ...), die mit dem Zufallsschlüssel K (einem 128-Bit-Wert) verschlüsselt ist, und K ist selbst mit P verschlüsselt em> (der vom Passwort abgeleitete Schlüssel). Wenn Sie Ihr Passwort ändern, erhalten Sie einen neuen, vom Passwort abgeleiteten Schlüssel P '. Um die Einstellungen anzupassen, müssen Sie K mit P entschlüsseln und mit P ' erneut verschlüsseln. Dies erfordert keine erneute Verschlüsselung oder gar keinen Zugriff auf die große Datei.

Abgesehen von diesem Vorteil entkoppelt die Verwendung eines Zwischenschlüssels den Vorgang, der flexibler ist. Beispielsweise ist der Prozess, mit dem das Kennwort in einen symmetrischen Schlüssel umgewandelt wird, möglicherweise nicht der Aufgabe gewachsen, einen Schlüssel mit der für die Massenverschlüsselung gewünschten Länge zu erstellen (z. B. erzeugt bcrypt einen 192-Bit-Schlüssel, keinen 256-Bit-Schlüssel). Bitschlüssel).

Ein weiterer Vorteil des Zwischenschlüssels besteht darin, dass Dateien angezeigt werden können. Zum Beispiel haben Sie Ihre große Datei und möchten sie Bob zeigen. Sie möchten Bob jedoch nicht Ihr Passwort geben. Sie möchten, dass Bob diese einzelne Datei sehen kann, nicht alle anderen Dateien, die moralisch mit demselben Passwort verschlüsselt sind. Mit der Zwischenschlüssel ist dies einfach: Sie zeigen Bob einfach K . Solange jede Datei ein eigenes zufälliges K hat, funktioniert dies.

Beachten Sie, dass sich das Modell auf asymmetrische Verschlüsselung erstreckt: eine Datei, die an n Empfänger gesendet wird wird einmal mit einem zufälligen Schlüssel K verschlüsselt, und K wird mit den öffentlichen Schlüsseln jedes Empfängers verschlüsselt. So funktioniert es in OpenPGP. Die entsprechenden Vorteile sind auch auf die passwortbasierte Situation zurückzuführen.

Es geht also (meistens) mehr um Komfort und Leistung als um zusätzlichen Schutz? Typischer Kompromiss zwischen Sicherheit und Benutzerfreundlichkeit?
Es ist nicht wirklich ein Kompromiss, da die Sicherheit nicht sinkt, aber die Benutzerfreundlichkeit steigt.
@JanFabry: Die Sicherheit geht nicht verloren, solange der Benutzer noch die Möglichkeit hat, den Datenschlüssel zu ändern, wenn er dies tun möchte. Dies ist jedoch nicht immer möglich ...
"moralisch verschlüsselt" mit derselben Datei? (Tippfehler erraten)
Nein, so wollte ich es schreiben. Ich stelle mir vor, dass Sie mehrere Dateien haben, die alle in Ihrem Kopf "mit Ihrem Passwort verschlüsselt" sind. und Sie möchten in der Lage sein, eine oder mehrere dieser Dateien anzuzeigen, ohne Zugriff auf die anderen zu gewähren, ohne Ihr Kennwort tatsächlich anzuzeigen.
@ThomasPornin Ich sehe immer noch nicht, wie das Wort moralisch in diesen Satz passt. Übrigens, gute Antwort
@WhiteWinterWolf: Der Benutzer kann die Daten jederzeit selbst entschlüsseln und erneut verschlüsseln. Danach wird der Datenschlüssel geändert.
Eine Einschränkung, die Sie beachten sollten: Ein Benutzer verschlüsselt möglicherweise einige Daten mit einem Schlüssel und speichert die Verschlüsselung des Schlüssels unter einem schwachen Kennwort. Wenn der Benutzer das Kennwort später in ein stärkeres Kennwort ändert, sodass der Schlüssel erneut verschlüsselt wird, kann ein Gegner möglicherweise weiterhin eine Kopie der alten Verschlüsselung erhalten. Das heißt, wenn zusätzliche Daten später mit demselben Schlüssel verschlüsselt werden, sind sie nicht sicherer als wenn sie unter dem schwachen Passwort verschlüsselt worden wären. Dies ist nicht ganz das, was Benutzer erwarten würden.
@kasperd: Genau aus diesem Grund habe ich einige Sicherheitsvorkehrungen getroffen, wenn der Benutzer den Datenschlüssel nicht effektiv ändern kann. Tatsächlich gibt es sogar einen Vorrang bei bekannter Software, bei der der Datenschlüssel [überhaupt nicht zufällig] (https://support.microsoft.com/fr-fr/kb/955417/en-us) und derselbe war für alle Benutzer von einem definierten Ziel ...
@SiyuanRen: Das Auffordern des Benutzers, in zwei verschiedenen Schritten erneut zu entschlüsseln und zu verschlüsseln, ist nicht dasselbe, als würde diese Funktion von der Software in einem einzigen Schritt bereitgestellt. In der Tat würde dies im Fall von verschlüsselten Dateien bedeuten, dass die Datei höchstwahrscheinlich zu bestimmten Zeiten in klarer Form auf die Festplatte geschrieben wurde (selbst das Löschen kann einige Fehler aufweisen).
Der verschlüsselte Verschlüsselungsschlüssel wird neben den Daten gespeichert, die er schützt, oder?
#2
+10
WhiteWinterWolf
2015-05-11 20:11:16 UTC
view on stackexchange narkive permalink

Der Benutzer kann das Kennwort ändern, ohne alle Daten erneut verschlüsseln zu müssen.

Wenn Sie das Kennwort direkt zum Verschlüsseln der Daten verwendet haben, kann eine Kennwortänderung möglicherweise sehr lange dauern, da Die gesamten Daten müssen mit dem alten Passwort entschlüsselt und mit dem neuen erneut verschlüsselt werden. Und was ist, wenn dieser Prozess in der Mitte unterbrochen wird, wenn die Hälfte der Daten mit dem neuen Kennwort verschlüsselt wird, während die andere noch mit dem alten Kennwort?

Vielen Dank an das von Ihnen beschriebene System, wenn die Benutzer Wenn Sie sein Passwort ändern möchten, müssen Sie lediglich den Datenschlüssel mit dem neuen Passwort verschlüsseln. Einfach schnell, einfach und zuverlässig.

#3
+1
user70990
2015-05-11 20:10:25 UTC
view on stackexchange narkive permalink

Vermutlich ist dies eine Annehmlichkeit. Wenn ich mein Passwort ändern möchte, wird ein separater Schlüssel abgeleitet. Dann muss ich den Schlüssel nur mit meinem vom Passwort abgeleiteten Schlüssel verschlüsseln.

Wenn Sie jedoch keinen separaten Schlüssel hatten Schlüssel, müssten Sie die gesamte Datenbank entschlüsseln und neu verschlüsseln. Angesichts der Tatsache, dass es sich um Passwörter handelt, die wahrscheinlich nicht sehr groß sind, ist für andere Implementierungen (Dateisysteme) das Design mit mehreren Schlüsseln sinnvoll.

#4
-1
Fernando
2015-05-11 20:11:09 UTC
view on stackexchange narkive permalink

Was tatsächlich passiert, ist, dass ein vom Benutzer bereitgestelltes Passwort in einer mathematischen Einwegoperation namens SHA-256 in einen Hash mit festgelegter Länge umgewandelt wird.

"SHA-256 wird als Passwort-Hash verwendet. SHA- 256 ist eine kryptografisch sichere Einweg-Hash-Funktion mit 256 Bit. Ihr Hauptkennwort wird mit diesem Algorithmus gehasht und seine Ausgabe wird als Schlüssel für die Verschlüsselungsalgorithmen verwendet. "

Grundsätzlich geben Sie ein Kennwort ein und es wird generiert Ein eindeutiger SHA-256-Hash mit einer Länge von 256 Bit. Die Sicherheit des Passworts beruht auf seiner Zufälligkeit. Die Sicherheit bei der Verwendung des Hashs hängt von seiner Länge und der Einbahnstraße seiner Generierung ab.

Die Logik hierfür erfordert immer noch ein sicheres, vom Benutzer bereitgestelltes Passwort, aber ja, der andere Punkt ist, dass Sie Benutzer sollen sich ein Passwort merken können, kein zufälliger 256-Bit-Hash.

Lesen Sie hier mehr .

Dies klärt das Problem der Frage immer noch nicht: Warum nicht einfach diesen Hash verwenden, um alle Daten zu verschlüsseln, anstatt einen anderen Schlüssel vollständig zu erstellen?
Planen Sie, den zufälligen 256-Bit-Hash auswendig zu lernen?
Nein, aber der Hash kann leicht reproduziert werden, wenn der Benutzer das Passwort angibt. Auf diese Weise wird der "Benutzerschlüssel" neu generiert, um den "Datenschlüssel" zu entschlüsseln.
Verstanden, ich glaube, ich habe die Frage falsch verstanden, als ich sie anfänglich las.
#5
-1
SEJPM
2015-05-11 20:11:28 UTC
view on stackexchange narkive permalink
  1. Hohe Entropie. Wenn Ihr Datenschlüssel zufällig ist, ist er höchstwahrscheinlich nicht das schwächste Glied.
  2. Schlüsseltrennung (nicht sicher, ob er so heißt ...): Ein Angreifer muss sich entscheiden, entweder den Header mit dem "schwachen" anzugreifen. Schlüssel oder um die Daten mit dem starken Schlüssel anzugreifen, für den möglicherweise Gigabyte an Beispieldaten vorhanden sind. So werden kryptoanalytische Angriffe verteidigt.
  3. Bequemlichkeit. Ein Benutzer kann einfach sein Passwort ändern, ohne Gigabyte an Daten neu verschlüsseln zu müssen. (was Stunden dauern kann)
  4. ol>
#6
-1
DRF
2015-05-12 13:14:39 UTC
view on stackexchange narkive permalink

Ich denke, hier besteht ein wenig Verwirrung zwischen zwei verschiedenen Anwendungen, der vollständigen Festplattenverschlüsselung (d. h. Truecrypt) und den Schemata zur Generierung und Speicherung von Passwörtern (d. h. KeePass). Diese beiden Situationen haben sehr unterschiedliche Ziele und Sicherheitsmodelle.

Die erste Anwendung Full Disk Encryption verwendet einen mehrschichtigen Schlüsselansatz, um einen einfachen Schlüsselwechsel, die Minimierung von Daten, die unter Schlüsseln mit niedriger Entropie verschlüsselt sind, und (in einigen Fällen zumindest) zu ermöglichen ) Mehrere Methoden zur Datenwiederherstellung.

Wenn Sie einen zufälligen Schlüssel mit hoher Entropie für die Datenverschlüsselung verwenden, geben Sie dem Angreifer viele P / C-Paare, aber der Schlüssel ist auch stark. Der untere Entropieschlüssel wird dann nur für einige P / C-Paare verwendet (möglicherweise 2-10 Blöcke oder so). Dies ist heutzutage wahrscheinlich kein großes Problem, da wir glauben, dass es genauso schwierig ist, auch nur einen Teil eines Schlüssels oder dessen Parität zu finden, wie alle zu finden, aber es fühlt sich immer noch besser an, dem Angreifer eine kleinere Angriffsfläche für den schlechteren Schlüssel zu geben.

Bei vielen FDE-Anwendungen möchten Sie möglicherweise, dass mehrere Personen mit unterschiedlichen Kennwörtern / Schlüsseln auf die Daten zugreifen können oder dass ein Administrator eine andere Zugriffsmethode als ein Benutzer hat. Da die zugrunde liegende Verschlüsselung identisch sein muss, verwenden Sie einen anderen Schlüssel, um sie zu verschlüsseln.

Bei der zweiten Anwendung unterscheidet sich das Angriffsmodell erheblich. Während Sie bei Truecrypt-ähnlichen Anwendungen davon ausgehen, dass jemand gleichzeitig auf alle Daten und Header zugreifen kann (sie haben Ihre Festplatte gestohlen), gehen Sie bei KeePass normalerweise davon aus, dass sich der Ort befindet, an dem sich die verschlüsselten Schlüssel (Ihr KeePass-Container) befinden gespeichert ist anders als die Orte, an denen die Schlüssel verwendet werden (die Websites / Server / Kreditkarten / was nicht). Dies bedeutet, dass Sie im Allgemeinen davon ausgehen, dass es für den Angreifer erheblich schwieriger oder kostspieliger ist, die verschlüsselten Schlüssel (Ihren KeePass-Container) anzugreifen und dann einen Angriff gegen den Ort zu starten, an dem die Schlüssel verwendet werden.

Stellen Sie sich das so vor: Wenn Ihr Passwort für Ihren KeePass-Container "Princess" lautet und alle darin enthaltenen Schlüssel zufällig generiert wurden, bevor der Angreifer mit dem Schreiben von E-Mails beginnen kann, muss er zuerst den KeePass-Container von unserer Festplatte beziehen und stellen Sie fest, dass "Princess" Ihr Passwort ist, da ein Angriff auf den zufällig generierten Schlüssel, mit dem Sie sich beim E-Mail-Konto anmelden, nicht möglich ist.

Wenn das Passwort für Ihr E-Mail-Konto andererseits "Princess" lautet "Der Angreifer muss nur die ersten 10 beliebtesten Passwörter ausprobieren und kann sich in Ihr E-Mail-Konto hacken.

Als zusätzlichen Bonus, wenn aus irgendeinem Grund alle Passwörter in Ihrer E-Mail-Anbieter-Datenbank vorhanden sind Alle Ihre Systeme sind gefährdet, da die von Ihnen verwendeten Passwörter zufällig sind und nicht mit Ihrem E-Mail-Passwort zusammenhängen (KeePass hat sie generiert). Wenn Sie dagegen "Hard2h4ck" für Ihr E-Mail-Passwort und "h.ard2H4ck" als Administratorkennwort für den Server verwenden, den Sie verwalten, bietet das E-Mail-Leck einem Angreifer einen guten Ausgangspunkt, um Ihren Server anzugreifen.

Der Angreifer würde den "zufällig generierten Schlüssel, mit dem Sie sich bei Ihrem E-Mail-Konto anmelden" nicht angreifen. Sie würden (wenn nicht Ihr Passwort) den zufällig generierten Schlüssel angreifen, der * alle * zufällig generierten Passwörter, die Sie in KeePass gespeichert haben, verschlüsselt / entschlüsselt - die beiden Modelle (KeePass / TrueCrypt) sind in dieser Hinsicht genau gleich . Sobald ein Angreifer Ihr KeePass-Passwort * oder * den Datenbankverschlüsselungsschlüssel knackt, hat er alle Ihre gespeicherten Passwörter auf einmal.
@Iszi Sie sind in dieser Hinsicht nachdrücklich nicht gleich. In einem Fall (TrueCrypt) wird der Schlüssel, der die Daten schützt (Ihre Festplatte), am selben Ort wie diese Daten gespeichert (d. H. Auf Ihrer Festplatte). Im anderen Fall (KeePass) wird der Schlüssel (dh das zufällig generierte Passwort in Ihrem ** lokalen ** Speicher), der die Daten schützt, an einem völlig anderen Ort gespeichert als die Daten (die sich in Ihrem E-Mail- / Dropbox- / Systemkonto auf einem befinden) andere Maschine).
@iszi Die beiden Ansätze versuchen, deutlich unterschiedliche Bedrohungsmodelle zu schützen. Im Fall von KeePass schütze ich mich vor der Verwendung einer großen Anzahl leicht zu erratender Anmeldeinformationen (Kennwörter für die 10er oder Hunderte verschiedener Systeme) und der Wiederverwendung von Anmeldeinformationen (da nur wenige Personen tatsächlich unterschiedliche Kennwörter für unterschiedliche Systeme haben). Im anderen Fall (truecrypt) versuche ich, viele lokale Daten vor einer Gefährdung zu schützen, vorausgesetzt, ein Angreifer hat physischen Zugriff auf das betreffende Gerät erhalten, was ich auch auf andere Weise zu mildern versuche.
@iszi Wenn der Angreifer Zugriff auf Ihren KeePass-Container erhält, greift er natürlich das Kennwort / die Passphrase an, die zum Entschlüsseln des Hauptschlüssels zum Verschlüsseln der Schlüssel verwendet werden. Aber er muss bereits die ziemlich bedeutende Hürde überwinden, den Container überhaupt zu gewinnen. (Bedeutend im Vergleich zu dem Versuch, einen Vermutungs- und Überprüfungsangriff gegen frei zugängliche Dienste durchzuführen oder einen Datenverstoß zu missbrauchen, um einen Angriff zur Wiederverwendung von Anmeldeinformationen zu versuchen).
Mir ist immer noch nicht klar, wie unterschiedlich KeePass & TrueCrypt Ihrer Meinung nach in Bezug auf die Funktion sind. Beide arbeiten im Wesentlichen gleich. | 1. Der Zufallsschlüssel wird generiert und zum Verschlüsseln der Datendateien für TrueCrypt, der Kennwortdatenbank für KeePass, verwendet. 2. Der Benutzer gibt das Passwort ein. 3. Das Passwort wird einer Schlüsselableitungsfunktion (KDF) zugeführt, um einen Schlüsselverschlüsselungsschlüssel (KEK) zu generieren. 4. Mit dem KEK wird der Schlüssel zum Schutz der Daten verschlüsselt. 5. KEK wird zerstört, verschlüsselter Datenschlüssel wird neben Daten gespeichert. ...
... 6. Wenn der Benutzer Zugriff auf Daten wünscht, gibt er ein Kennwort ein. 7. Das Passwort wird an KDF weitergeleitet, um den KEK neu zu generieren. 8. KEK wird zum Entschlüsseln des Datenschlüssels verwendet und anschließend zerstört. 9. Der Datenschlüssel wird zum Entschlüsseln von Daten verwendet. | In dieser Hinsicht unterscheiden sie sich nicht wirklich, und der Angreifer hat zwei Möglichkeiten: | 1. Drücken Sie den KEK brutal, um das Passwort zu bestimmen. 2. Erzwingen Sie die Daten brutal, um den Datenschlüssel zu bestimmen. | Ersteres wäre sicherlich viel einfacher. Es bleibt jedoch der Punkt, dass es jetzt zwei Schlüssel gibt, die jeweils effektiv Zugriff auf dieselben geschützten Ressourcen bieten, wobei stattdessen nur ein Schlüssel vorhanden sein könnte.
Lassen Sie uns [diese Diskussion im Chat fortsetzen] (http://chat.stackexchange.com/rooms/23769/discussion-between-drf-and-iszi).
#7
-1
Dano
2016-01-10 14:26:24 UTC
view on stackexchange narkive permalink

Die Antwort liegt darin, wie wir verschlüsseln. Wenn wir nur ein Kennwort oder einen 128-256-Bit-Schlüssel zum Verschlüsseln großer Datenmengen verwenden würden, wären die Daten anfällig für Angriffe, da sie größer sind als der Schlüssel, der sie verschlüsselt. Ein Angreifer könnte die verschlüsselten Daten leicht auf Muster analysieren und den Klartext ableiten. Um sicher zu sein, müssen Daten mit einem RANDOM-Schlüssel verschlüsselt werden, der mindestens so groß ist wie die Daten selbst (großes K).

Da das große K selbst statistisch zufällig ist, gibt es keine zu analysierenden Muster. Daher können wir sicher einen viel kleineren Schlüssel (128-256 Bit kleines k) verwenden, um großes K zu verschlüsseln und zu verhindern, dass es versehentlich ausgesetzt wird. Da big K bereits statistisch zufällig ist, ist es durch die Verschlüsselung mit einem viel kleineren Schlüssel einem sehr geringen Risiko durch Kryptoanalyse ausgesetzt, was von der Ausnutzung von Mustern in aussagekräftigen Daten abhängt. Zufällige Daten enthalten per Definition keine Muster.

Somit verbirgt der kleinere Schlüssel sicher den größeren Schlüssel und eröffnet Annehmlichkeiten wie die oben erläuterten, wie die Verwaltung von Benutzerkennwörtern.

Ein Kennwort entschlüsselt kleines k, kleines k entschlüsselt großes K, und großes K entschlüsselt die Daten.

Die erste Schlüsselgröße spielt keine Rolle. Im Allgemeinen sind sowohl der Schlüsselverschlüsselungsschlüssel als auch der Datenverschlüsselungsschlüssel 128 bis 256 Bit lang. Zweitens ist angesichts des ersten Punktes die Behauptung, dass "ein zufälliger Schlüssel mit der gleichen Länge wie die Daten verwendet wird", einfach falsch.


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...