Master-Key in der Cloud?!

Was bringt der Master-Key in der Cloud in der ich auch die verschlüsselten Daten ablege?
@overheadhunter schreibt ‘This file contains encrypted data, which is needed to derive the masterkey from your Password’.
Aber genau hier liegt ja das Problem! Alle Daten zur Ableitung des Master-Keys sind erreichbar!
Wie handle ich als Hacker (oder ehrgeiziger Student/Azubi bei Mircosoft & Co.):

  1. Ich hole die Open-Source Quellen des Cryptomators
  2. An den Master-Key bin ich als Hacker gekommen.
  3. Ich schreibe eine Engine, mit der ich analog Brute-Force-Methode Passwörter gegen den Master-Key probiere
  4. Somit leite ich per Brute-Force den ach so komplexen Encryption-Schlüssel ab
  5. DANKE für die Kontoauszüge und privaten Bilder

Warum kann ich den komplexen Encryption-Schlüssel nicht lokal pro Gerät speichern und nur dort halten und verwenden? Den kann ich mir über verschiedenste Wege auf die einzelnen Devices bringen, nur eben nicht - auffällig - durch die Cloud, auf der auch meine verschlüsselten Daten liegen.

Das scheint keiner so zu machen - aber dann wäre es sicher(er).

So wie du es schreibst wird es nicht funktionieren, da der Inhalt der masterkey Datei ebenfalls verschlüsselt ist.

Siehe hier: Why is the masterkey stored in the cloud?

Und vor einer bruteforcing Attacke, die du dann auch gleich gegen den vault laufen lassen kannst, wo du ja in deinem Szenario eh schon den online Account gehackt hast, hilft sowieso einzig und allein ein sicheres Passwort.

Ja aber genau so macht es die App doch auch. Wie kann diese die Daten sonst entschlüsseln?

Mit deinem Passwort, welches ja nur du kennst.

na eben dieses probiert meine Engine ja hochfrequent per Brute-Force durch…

Wie gesagt: gegen bruteforcing hilft nur ein sicheres Passwort. Wie bei jeder anderen Verschlüsselung auch.

ja aber dann brauche ich ja kein Master-Key mehr. Dann ersetzt das Passwort diesen ja?!?!
Lediglich ‘man in the middle’ hat es etwas schwerer…

Sorgen machen mir die unterbezahlten Hilfskräfte im Rechenzentrum - die für ein paar Euro mit einem russischen Hobbyhacker sprechen können - oder gab es da in der Schweiz mal eine Steuer-CD???

Nein. Denn deine Dateien werden nicht nur mit deinem Passwort alleine verschlüsselt.
Wenn Du genau wissen willst wie cryptomator verschlüsselt, findest du hier die Infos dazu:
https://cryptomator.org/security/architecture/

habe darüber gelesen - und besteht gegen meinen Vorschlag dennoch nicht. Sofern ich mich mit der Engine verhalte wie eine App, die nur ein relativ kurzes Password entgegen nimmt, dann bilde ich den Rest auch nach.

Und JA - wenn mein Passwort 128 Zeichen lang ist, dann wird es länglich… aber wer macht das? oder ich reiche ein bei Konsorten wie - https://www.heise.de/newsticker/meldung/Passwort-Cracker-als-Bezahldienst-147107.html

Hallo @thoko111! Schön, dass du das kritisch hinterfragst. Lass es mich mal mit einem Beispiel beantworten:

Der Trick liegt in der sogenannten Key Derivation Function (KDF). Wir setzen hier auf Scrypt mit einem Cost Factor von 2^15 (ehemals 2^14). Dies ist eine Funktion, die bewusst mathematisch so konstruiert wurde, dass sie eine gewisse Menge CPU-Zyklen und eine bestimmte Menge RAM benötigt.

Nehmen wir zunächst einmal an, dass der Angreifer einen single-threaded Offlinebruteforceangriff (d.h. er hat alle Daten lokal vorliegen und weiß alles über den verwendeten Algorithmus) startet:

Ein 12 Zeichen langes Passwort aus den 96 printable ASCII-Zeichen (a-z, A-Z, 0-9, $%&… ohne Umlaute und dergleichen). Das sind 96^12 oder 6 * 10^23 Möglichkeiten. Aufgrund der KDF benötigen wir nun mit dem heutigen Stand der Technik zwischen 10 und 200 ms (je nach Rechner), um aus dem Passwort den Schlüssel abzuleiten. Legen wir 10ms zugrunde, würde man für alle Möglichkeiten also 6 * 10^21 Sekunden oder 10^18 Stunden oder 4 * 10^16 Tage oder 116 Billion Jahre benötigen.

Gehen wir nun von einem parallelen Bruteforce-Angriff aus, der das Ziel hat den Schlüssel in einem einzigen Jahr herauszufinden. Benötigen wir also 116 Billion CPUs und das 116 billion-fache an RAM. Unter der Annahme, dass ein finanzkräftiger Angreifer existiert, der diese Ressourcen hat. Jetzt gibt es aber ein weiteres Problem: RAM benötigt Chip-Fläche, Chip-Fläche bedeutet Abwärme, Abwärme bedeutet Energiebedarf. Da sich die Schaltkreise nicht beliebig klein miniaturisieren lassen, da die Strukturen sonst an die Größe einzelner Atome stoßen, kann man den Energiebedarf nach unten abschätzen. Und hier sprechen wir derzeit noch NUR über die Chips, noch gar nicht über die Klimaanlagen.

Du kannst mal nach sogenannten Scrypt-ASICs googlen. Das sind Geräte, die den von uns verwendeten Algorithmus so energieeffizient wie möglich umsetzen, da sie für das Mining von Cryptocurrencies eingesetzt werden. Dort findest du immer die Angabe, wie viele Hashes pro Sekunde bzw. pro Joule diese Geräte schaffen. Hier mal ein weiteres Rechenbeispiel in Bezug auf den Energiebedarf (ohne Kühlleistung):

Laut diesem Blog ist wohl derzeit der Antminer L3+ das beste, was es für Scrypt auf dem Markt gibt. Für ca 1200 $ Anschaffungskosten kann er 504 MH/s bei 1,6 J/MH schaffen.

  • Dauer bei obigem Beispiel mit nur einem Gerät in Sekunden: 96^12 / 504M = 10^15s.

  • Benötigte Geräte, wenn der Angriff in einem Jahr stattfinden soll: 96^12 / (504M * 3600 * 24 * 365) = 38,5 Mio Stück. Anschaffungspreis: 46 Mrd. $

  • Energiebedarf: 96^12 * 1,6J / 1M = 10^18 Joule.

  • Willst du den Angriff in einem Jahr durchführen, sind das 10^18J / (3600s * 24 * 365) = 32,5 GW die ein Kraftwerk kontinuierlich das ganze Jahr lang bereitstellen müsste. Das größte Kraftwerk der Erde liefert 22,4 GW.


Disclaimer: Ich habe in diesem Beispiel angenommen, dass wir sämtliche Passwortmöglichkeiten durchprobieren müssen und erst der letzte Versuch zum Erfolg führt. Das ist genau genommen falsch. Das Beispiel dient eher dazu, ein Verständnis für die Größenordnung zu entwickeln.

Auch habe ich das Birthday Paradox nicht berücksichtigt, da der Schlüsselraum mit 2^256 erheblich größer ist als die im Beispiel genannte Menge an Passwortmöglichkeiten. Ich habe daher für das Beispiel unterstellt, dass keine Kollisionen existieren.

3 Likes

Ich verstehe deinen Vorschlag einen lokalen key zu nutzen.

Meine Gedanken dazu:

Wenn nun die masterkey Datei lokal gespeichert würde, und es z.b. Zu einem Datenverlust Lokal kommt (Festplatte kaputt), dann ist es nicht mehr möglich die Dateien zu entschlüsseln.
Wenn das auf dem Handy gespeichert wird, und dir jemand das Teil klaut ist es das gleiche.
Ich persönlich finde es sinnvoll diese Datei genau da zu speichern, wo auch die verschlüsselten Dateien liegen.

Was ich mir vorstellen könnte ist, dass man optional anstelle eines Password ein keyfile als Schlüssel ermöglicht. (Z.b wie es bei keepass möglich ist.)
Ich habe hier im Forum auch schon den Vorschlag gelesen die Nutzung von Hardware Keys zu ermöglichen.

2 Likes

Gut 10 ms ist eine Ewigkeit - hierzu müsste ich mich mit der sog. KDF auseinander setzen. Der Rest scheint dann nachvollziehbar schwierig zu sein…
Danke übrigens für diese netten und interessanten Antworten hier. Zudem hätte ich hier mal nicht damit gerechnet, dass ich so schnell eine Stellungnahme eines Problems bekomme, dass mich seit Jahren um treibt. :blush:

2 Likes

Ein Keyfile als Lösung wäre ebenso hilfreich, wenn man es an die App ‘teilen’ kann. Das Handling muss meines Erachtens einfacher sein, als ein langes Password einzugeben. Sonst bringt es nichts.

alles gut - nur gelten künftig auch andere Annahmen. Z.B. dass wir stets mit digitalen Computern arbeiten. Künftig übertragen wir ggf. satt zwei Signale (0 und 1) mehrere in einem Takt auf einer Leitung. Dann wird vieles rasant.

Mich erinnert das an eine Diskussion von vor ca. 30 Jahren mit einem E-Techniker und einem Physiker. Diese erklärten mir nachvollziehbar, warum ein Prozessor niemals mehr als 2-3 MHz takten könne… Er würde sonst wie ein Radio senden…

Wie dem auch sei - DANKE für die Chats und vor allem die 10ms - Info. Ich werde KDF mal in der Company mit unserer Expertise diskutieren.

Gute Nacht - Thomas

Ein Keyfile zusätzlich oder anstelle eines Passworts (wie bei Keypass) wäre in der Tat eine Möglichkeit. Ggf. kommt das irgendwann. Die gleiche Sicherheit lässt sich aber auch mit einem langen mit einem Passwortmanager erzeugten Passwort erreichen.

Vorschläge bzgl. der Nutzung von Hardware-Keys über U2F habe ich bereits gelesen. Diese sind aber für die Authentifizierung gegenüber Onlinediensten entworfen. Der Server sendet hierbei bei jedem Login eine andere Challenge an den Client und nur der Hardware-Key kann für diese Challenge ein gültiges Token erzeugen. Für die Herleitung von Schlüsseln ist dieses Verfahren nicht anwendbar. Würde man dieses bei Cryptomator einsetzen müsste man mit einer statischen Challenge arbeiten. Die Eigenschaft, dass das Hardware-Token verwendet werden muss ginge verloren. Somit hätte man dann im Prinzip nur eine kompliziertere Variante um eine Schlüsseldatei zu verwenden.

2 Likes

Long story short: Es gibt schon einen entsprechenden Feature Request.

2 Likes

Ich finde dieses Posting super, weil sehr informativ. Ich habe nur einen einzigen Punkt nicht verstanden:

Warum sind 96^12 = 610^23 Möglichkeiten? Da habe ich einen Schritt verpasst. Ich würde mich über eine kurze Erklärung freuen.

6 * 10^23

Habe ich korrigiert :slight_smile:

Ich finde das Argument, dass eine lokale masterkey-Datei verloren gehen könnte, ehrlich gesagt nicht überzeugend. Diese Entscheidung sollte dem Benutzer überlassen werden, d.h. wenn der Benutzer diese Datei nicht in der Cloud speichern möchte (unabhänging, ob mit einem starken Kennwort geschützt oder nicht), sollte er die Möglichkeit dafür haben, sofern er das Risiko dafür trägt.

Ich habe den Architekturteil nur kurz überflogen, weil er ähnlich aussieht zu anderen Lösungen, aber meine Frage wäre: Sofern ein Angreifer nicht im Besitz der masterkey-Datei wäre, könnte er weder diese trivial erstellen noch den Zugriff auf den Container direkt erhalten, da er dafür jeweils den zufällig gewählten encryptionMasterKey und das Salt ableiten müsste. Ist das korrekt?

Es ist richtig, dass ein starkes Kennwort prinzipiell die masterkey-Datei schützt, aber gerade das Fehlen eines zweiten Faktors sehe ich hier als kritisch. Ich würde deswegen bevorzugen, die entsprechende Datei getrennt von den verschlüsselten Daten aufzubewahren, d.h. verschlüsselte Daten in der Cloud und den masterkey lokal, da der Besitz der entsprechenden Datei (und damit des encryptionMasterKey und des Salts) einen weiteren Schutzaspekt darstellt zu der Wahl eines starken Kennwortes (das u.U. auch durch Social-Engineering oder andere Verfahren erlangt werden kann).

Ist das korrekt, oder übersehe / missinterpretiere ich diesbezüglich etwas? Vielen Dank!

Edit: Ich hatte ursprünglich übersehen, dass es sich hierbei um einen Thread handelte, der schon vorJahren erzeugt wurde. Ich bitte um Verzeihung, dass ich diesen wieder aus der Versenkung holte.
Ich habe auch gesehen, dass diese Diskussion auch schon an weiteren Stellen geführt wurde (z.B. Is it possible to keep the masterkey.cryptomator file offline?).

Ich kann die Designargumente und das Prinzip “möglichst einfache Benutzung” nachvollziehen, aber ich finde, hier wurde ein Trade-Off zwischen Sicherheit und Benutzerfreundlichkeit gewählt, den ich für mich persönlich eigentlich nicht ideal finde bzw. idealerweise gerne selbst bestimmen wollen würde.

Mit dem ursprünglichen Argument könnte ich z.B. auch einen Kennwort-gesicherten SSH-Private-Key verteilen. Dies kann man machen, aber ich würde dies für meine Schlüssel nicht machen, weil nun die Zugriffsbeschränkung mehrheitlich von der Stärke des jeweiligen Kennwortes abhängt.

Frage: Wenn ich es richtig sehe, werden die verschlüsselten Daten im Verzeichnis d gespeichert. Würde hier ein Softlink (unter Windows) ) funktionieren, d.h., masterkey bleibt lokal, während d ein Softlink ist, der auf den Cloud-Speicher zeigt? Theoretisch sollte das klappen, aber hat jemand Erfahrung damit?

Edit2: Scheint nicht zu klappen und führt zu einem Fehler :frowning:

Edit3: Man kann die masterkey-Datei aus dem Originalverzeichnis entfernen und separat (lokal) speichern. Die Vault-Datei wird in die Cloud synchronisiert und kann korrekt geöffnet werden. Man muss anschließend die korrekte masterkey-Datei (von der lokalen Festplatte) auswählen.
Ich sehe jedoch nicht, dass ein Backup der masterkey erzeugt wird? - Das wäre in diesem Fall ja auch das gewünschte Verhalten, d.h. alles sensiblen Inhalte verbleiben ausschließlich lokal.