LUKS - und was die Verschlüsselung schwächt

[spiralnebelverdreher]

Hallo zusammen,
hier ein wissenschaftlicher Artikel https://eprint.iacr.org/2016/274.pdf über LUKS und welche Faktoren sich auf die Widerstandsfähigkeit (gegen Brute-Force-Angriffe) von mit LUKS verschlüsselten Daten auswirken.

-------------------------------------------------------------------
Cryptology ePrint Archive: Report 2016/274
What users should know about Full Disk Encryption based on LUKS
Simone Bossi and Andrea Visconti

Abstract: Mobile devices, laptops, and USB memory usually store large amounts of sensitive information frequently unprotected. Unauthorized access to or release of such information could reveal business secrets, users habits, non-public data or anything else. Full Disk Encryption (FDE) solutions might help users to protect sensitive data in the event that devices are lost or stolen. In this paper we focus on the security of Linux Unified Key Setup (LUKS) specifications, the most common FDE solution implemented in Linux based operating systems. In particular, we analyze the key management process used to compute and store the encryption key, and the solution adopted to mitigate the problem of brute force attacks based on weak user passwords. Our testing activities show that unwitting users can significantly reduce the security of a LUKS implementation by setting specific hash functions and aggressive power management options.

[wanne]

Kurtz: Ein weiterer Bullshit Aufsatz.
Lang:

• Die haben Passwörter mit 18Bit (Entspricht etwa 3 stelligen zufälligen alphanumerischen passwörtern.) geknackt.
• Der Angreifer kann nachdem er das Passwort gebruteforced hat unter umständen schneller feststellen, ob es auch richtig ist. Defakto kann man sich zwei hash-Funktionsdurchläfe sparen und stattdessen ein mal AES machen. Bei mir hat luks die gesamtzahl auf 463769 gestellt. (Angezeigt werden 463767 weil die letzten zwei eigentlich nie so für die Sicherheit gedacht waren. Sie sind nur für den Komfort eingefügt worden, dass dir dein passwort promt mit Sicherheit sagen kann, ob dass pw falsch oder richtig ist. IN plain waren die noch nicht drin.)
• LUKS lässt wirklich auch dreistellige Passwörter zu. Wer so dämlich ist, sowas zu nutzen kann das. (Die lassen sogar leere zu. Der Sinn davon ist, dass man das später austauschen kann.)
• LUKS passt sich der Leistungsfähigkeit des Gerätes an. Ist das System leistungsfähiger wird das öffnen (und damit das bruteforcen) rechen aufwändiger (langsamer). => Es werden nur kürzere Passwörter gebraucht.
  Entsprechend längere Passwärter werden benötigt, wenn das System in Energiesparmodi versetzt wird. Das ist so gewollt und absolut sinnvoll. Auf einem Gerät, dass in irgend welchen Hardcore Energiesparmodi läuft, die nicht schnell genug hochtakten ist offensichtlich, dass man sich nicht den halben Akku für das öffnen des crypto devices verbrät.
  Früher hat man aus den Gründen eben sogar absichtlich darauf geachtet, dass crypto eben nicht rechenintensiv ist und auf entsprechend starke passwörter verbraucht. Heute fahren fast alle Systeme wie luks halt Kompromisse aus schnellem und energiearmen öffnen und Stärkung des Passworts.
  LUKS Setzt das immer so fest, dass das aktuelle Gerät bei aktuellen Einstellungen ca. 1s unter vollast braucht
  Das ist etwas ungewöhnlich aber absolut sinnvoll. Man will nicht dass ein PI mehrere Minuten zum hochfahren braucht. Auf einem aktuellen x86 Rechner kann man sich ein mehr an Rechenaufwand zum schutz schlechter Passwörter durchaus leisten.
  (Stellt man fest, dass die aus dem Paper nicht mal mit 4stelligne zufälligen Passwörtern zurecht kommen ist da auch entsprechend Marge.)
• Die behaupten, dass neuere Algorithen auf LUKS effizienter laufen und schließen darauf, dass man alte nutzen soll, weil die langsamer sind (und langsamer bruforcen). Das luks entsprechend auch die Anzahl der Wiederholungen anpasst schreiben sie nicht.

[wanne]

Gibt gerade massenhaft so Papers, die einen Rechner hinstellen 5 Schlüssel ausprobieren und am ende feststellen, dass man die Verschlüsslung geknackt hätte, wenn sich der Schlüssel unter diesen befunden hätte.
Insbesondere zu wpa2-psk gabs auch ein paar von der Sorte.
Und weil unter dem bullshit am Ende meist sogar irgend eine renommierte Universität drunter steht, schreiben und keiner mehr als die Überschrift ließt schrieben die Zeitungen irgend was sei kaputt. Und wenns mal in der Zeitung stand kann man das auch nicht mehr aus der Wikipedia raus zu halten.
Wenn sowas drin vorkommt, braucht man eigentlich nicht mehr weiterlesen.

weak user passwords

Die Quintessenz von all den Artikeln ist: Schwache passwörter sind schwach.
Ein anderer extremer Hinweiß ist der:

reduce the security

Solange da nicht steht, wie lange ein angriff tatsächlich braucht ist das in den aller meisten fällen bullshit. Die schreiben am ende irgend was von Faktor 3.
Zum Vergleich: Bei DES war wissentlich Beschleunigung von 512 möglich. AES256 ist ein rlated key um den Faktor 91343852333181432387730302044767688728495783936 schneller als ein dummer. Trotzdem erachtet den keiner für unsicher. Nicht nur weil das "nur" rlated key ist sonder schlich und einfach weil 1267650600228229401496703205376 Durchläufe halt immer noch meilenweit von dem entfernt ist, was irgend jemand rechnen kann.
Und selbstverständlich nutzt AES gar keine key stretching. Mann will, dass der schnell läuft. Ist die Idee davon.

[whisper]

Wanne,
Ich verstehe von Verschlüsselung nicht viel, kann aber deinen Ausführungen folgen
Ps: Hier fehlt ein Danke Button oder sowas.

[spiralnebelverdreher]

Die haben Passwörter mit 18Bit (Entspricht etwa 3 stelligen zufälligen alphanumerischen passwörtern.) geknackt.

Das ist korrekt. Der Autor des Papiers schreibt selbst dazu, dass es sich um ein "toy example" handelt. Wenn ich es recht verstehe, verwendet er dieses Spielzeugszenario um (mit seiner ihm zur Verfügung stehenden Hardware) in endlicher Zeit seine Messungen zu machen. Messen will er, welche Faktoren die Schlüsselableitungsfunktion PBKDF2 wie stark beeinflussen.

[*]LUKS lässt wirklich auch dreistellige Passwörter zu. Wer so dämlich ist, sowas zu nutzen kann das. (Die lassen sogar leere zu. Der Sinn davon ist, dass man das später austauschen kann.)

Da bist du mit dem Autor des Papiers ja ganz einer Meinung.

[*]LUKS Setzt das immer so fest, dass das aktuelle Gerät bei aktuellen Einstellungen ca. 1s unter vollast braucht
Das ist etwas ungewöhnlich aber absolut sinnvoll. Man will nicht dass ein PI mehrere Minuten zum hochfahren braucht. Auf einem aktuellen x86 Rechner kann man sich ein mehr an Rechenaufwand zum schutz schlechter Passwörter durchaus leisten.

Ich habe das mit der circa einen Sekunde auch immer als gegeben hingenommen, aber die Messergebnisse des Autors des Papiers legen nahe, dass dem nicht so ist: Er verwendet eine Passwortliste (Wörterbuch) mit 250.000 Einträgen, die er stumpf durchprobiert. Im Schnitt sollte der Angriff also nach 1/2 * 250000 Sekunden erfolgreich sein, das wären 2083 Minuten. Der Autor behauptet aber, dass es nur 800 Minuten gedauert hat. Diese Diskrepanz kann an der geringen Anzahl von 6 Wiederholungen des Experiments liegen. Das hätte genauer untersucht gehört und an dieser Stelle wird das Paper IMHO wissenschaftlichen Ansprüchen nicht gerecht.
Man kann aber (davon ausgehend dass hier kein statistischer Ausreßer vorliegt) darüber spekulieren, ob die LUKS Entwickler hier bewusst eine deutlich kürzere Laufzeit als 1 Sekunde für einen einzelnen Keyslot festgelegt haben um für den Fall, dass alle acht Keyslots belegt sind, noch zu erträglichen Laufzeiten zu kommen.

Stellt man fest, dass die aus dem Paper nicht mal mit 4stelligne zufälligen Passwörtern zurecht kommen ist da auch entsprechend Marge.

Sagen wir mal so: Der Student mit einem einzigen Rechner mit i7 Prozessor ohne GPU ist mit den von dir erwähnten 4-stelligen zufälligen Passworten heute faktisch ausgesperrt. Andere Gegner verfügen über deutlich mehr Rechenleistung (LUKS Header sind schnell kopiert und die Aufgabe ist parallisierbar) und Rechenleistung wird durch die technische Entwicklung immer billiger. Zudem sind technisch und finanziell gut aufgestellte Gegner u.U. in der Lage, durch technische Spezialisierung (Einsatz von GPUs, ASIC oder FPGA) deutlich höhere Durchsatzraten zu erzielen.

[wanne]

[Im Schnitt sollte der Angriff also nach 1/2 * 250000 Sekunden erfolgreich sein, das wären 2083 Minuten. Der Autor behauptet aber, dass es nur 800 Minuten gedauert hat.

Und genau das zeigt das massive kryptografische Unverständnis der Autoren.
Ein Faktor 2 oder 3 hat sich in ein Monaten durch schnellere Rechner eh erledigt. Alternativ kann man auch einfach doppelt so viele Rechner nehmen. Außerdem ist insbeondere in der Anfangszeit dauernd jemand mit einem Effizienteren Algorithmus vor Ort.
Ich habe absichtlich mal gezeigt mit was für Margen da normalerweise gerechnet wird.
Aus diesem Grund werden die immer fallen gelassen und immer nur Größenordnungen angegeben. Es werden auch keine Prozessoren oder so ein Humbug angegeben. Die ändern sich dauern und spielen doch wieder in der gleichen Größenordnung.
Deswegen hat er auch immer nur mit LUKS auf ein und der selben Maschine verglichen. Hier mal der Bruteforce verglich von LUKS auf meinem PC und anderen sachen:
Truecrypt: 232 mal schneller zu Bruteforcen.
wpa2-psk 113 mal schneller zu Bruteforcen.
debian 8 passwörter: 63 mal schneller zu Bruteforcen.*
Vera-Crypt 1.413 schneller zu Bruteforcen.
…


* sha1 läuft bei mit 1.461 mal schneller als SHA512

Nochmal ein Paar sachen woran man merkt, dass die keien Ahnung haben wovon sie schreiben:

Surprisingly, even small changes in software, such as choose a
different function of the SHA family, may considerably decrease the
iteration count values.
[…]
18,567 and 7,019 (Intel Atom z520, SHA256 vs SHA512)

SHA512 ist eine Hash mit 64Bit word size. den auf einem 32Bit system auszuführen ist eher ineffizient. SHA256 hat dagegen 32Bit word size und passt entsprechend super auf das System. Ist genau der Grund warum man die beiden Familien innerhalb von SHA-2 geschaffen hat. Siehe dazu auch: https://en.wikipedia.org/wiki/SHA-2
Jemand der nur annähernd Ahnung von Hash Funktonen hat findet das nicht "surprisingly"

Hier mal ein schönes Beispiel: 8 Stelliges Alphanummerisches Passwort:
#53459728531456 Möglichkeiten. => 18014398509 mal mehr als die genannten 250000
Der i7 4710MQ hat laut SETI@home 27.44GFLOPs.[1] der aktuell schnellste Supercomputer Tianhe-2 (Hatten die Chinesen nicht einen neuen?) hat 33862TFlop. Ist also 1234037 mal so schnell. (Das sind flops und keine Iops aber da wird das Verhältnis ähnlich aussehen.)
Wenn der i7 für die 250000 800minuten bräuchte, sind das für den Tianhe-2 96.2688 statt 327 Tage.
Die Chinesen müssten also ihr schnellstes Rechenzentrum 3 Monate lang beschäftigen um dein dämliches 8 Stelliges pw zu knacken. Wenn das dein Treadmoddel ist, dann solltest du dich echt fragen, ob 8stellen wirklich sinnvoll sind.
Und die LUKS Leute empfehlen mindestens 12stellige Passwörter. Dann wären wir selbst wenn alle Rechner der Top500 mitrechnen über 14.200 Jahre.
Noch irgend welche fragen ob da der Faktor 3 da irgend etwas ausmacht?


[1] https://setiathome.berkeley.edu/cpu_list.php(Kommt mir etwas viel vor)
[2] https://www.top500.org/lists/2015/11/

[spiralnebelverdreher]

... Und genau das zeigt das massive kryptografische Unverständnis der Autoren.
...
Es werden auch keine Prozessoren oder so ein Humbug angegeben. Die ändern sich dauern und spielen doch wieder in der gleichen Größenordnung.
Deswegen hat er auch immer nur mit LUKS auf ein und der selben Maschine verglichen.

Das Thema der Arbeit ist halt LUKS und wie sich welche Faktoren auf dessen Widerstand gegen Brute-Force Angriffe auswirken. Deswegen die Beschränkung auf LUKS.

Den Autoren wegen der Beschränkung auf LUKS und dem Herausarbeiten von Unterschieden kleiner als eine Zehnerpotenz "massive kryptografisches Unverständnis" zu unterstellen halte ich ehrlich gesagt für anmaßend. Die herausgearbeiteten Unterschiede sind für die praktische Anwendung aus Sicht des Endanwenders absolut nicht besorgniserregend. Das Ergebnis der Arbeit, dass die Stromsparfunktion (heruntertakten) des Rechners beim Anlegen des LUKS Containers einen deutlichen Einfluß auf die Widerständigkeit gegen Brute-Force_Angriffe hat finde ich ehrlich gesagt schon erstaunlich. Denn das ist ein Hinweis, dass in LUKS der Algorithmus zur Bestimmung eines vernünftigen Iteration-Counts nicht immer gut arbeitet.

Eine Frage an dich, da du ja eigene Laufzeitmessungen zu Brute-Force-Angriffen gemacht hast: Kannst du bestätigen, dass der Default-Wert des Iteration-Counts bei LUKS bei der Einrichtung des ersten Keyslots so gewählt wird, dass die Zeit zum Öffnen des Containers deutlich unter einer Sekunde liegt?

[DeletedUserReAsG]

Vielleicht OT, aber interessiert mich gerade: LUKS passt also die Parameter beim Erstellen des Devices den Gegebenheiten der Hardware an? Das bedeutet quasi, dass ein Container, der etwa auf einem Pi angelegt wurde, auf einem entsprechenden Rechner(-verbund) viel schneller aufgemacht werden könnte, als ein Container, der auf einem High-End-Rechner erstellt wurde?

[wanne]

Das bedeutet quasi, dass ein Container, der etwa auf einem Pi angelegt wurde, auf einem entsprechenden Rechner(-verbund) viel schneller aufgemacht werden könnte, als ein Container, der auf einem High-End-Rechner erstellt wurde?

Ja. Das kennen PI Nutzer vor allem in die andere Richtung. Hat man sein Device auf seinem high-end PC erstellt hat braucht das wirklich Minuten zum öffnen.

[wanne]

Eine Frage an dich, da du ja eigene Laufzeitmessungen zu Brute-Force-Angriffen gemacht hast: Kannst du bestätigen, dass der Default-Wert des Iteration-Counts bei LUKS bei der Einrichtung des ersten Keyslots so gewählt wird, dass die Zeit zum Öffnen des Containers deutlich unter einer Sekunde liegt?

Jaein.
Zuerstmal Signifikant im Sinn von Wichtigkeit sowieso gar nicht.
Ansonsten hier ein im RAM angelegtes device:

Code: Alles auswählen

time cryptsetup luksOpen --key-file=/tmp/pw /tmp/bla test

real    0m1.144s
user    0m1.128s
sys     0m0.004s

Das ist auch relativ zuverlässig und schon immer so um die 1.1s.
Das Ding ist, dass während der Installation wohl andere nicht so effiziente Kernel Module zum Einsatz kommen. Deswegen öffnen sich Devices, die zur Installationszeit angelegt werden schneller.

Den Autoren wegen der Beschränkung auf LUKS und dem Herausarbeiten von Unterschieden kleiner als eine Zehnerpotenz "massive kryptografisches Unverständnis" zu unterstellen halte ich ehrlich gesagt für anmaßend.

Doch. Ist wie wenn ich beim Physikpraktikum sehe, dass Studenten bei irgend was die zehnte signifikante stelle angeben, aber vorher Längen mit ihren Wurstfingern eingestellt haben. Das zeugt einfach von absolutem Unverständnis.
Oder wenn jemand die Auto Strecke zwischen Hamburg und Wien auf den Meter genau angibt. Sorry, ein paar Spurwechsel mehr und das Ergebnis ist im Eimer. Das hat nichts mit sinnvollem Arbeiten zu tun.
Wenn du, wie in diesem Fall, bei 5stelligen Zahlen um zwei hin und her lamentierst, brsauchst du verdammt gute Gründe, warum das wichtig sein soll.
Auch hier wird jeder, der nur mit etwas anderen Hardware oder Softwareimplementierungen arbeitet, Ergebnisse haben wird die um ganz andere Faktoren anders sind als die von den Leuten gemachten.
John (jumbo edition) kann mittlerweile auch LUKS brutforcen. Wie ich die kenne holen die hier und da, wenn sie sich anstrengen mal den Faktor 10 oder 100 raus. Selbst zwichen verschiedenen Kernel Versionen liegt gerne mal ein Faktor 2 oder 4. (Deswegen hatte ich da mal Truecrypt oder so daneben gestellt.) Da einen Faktor 3 zu erwähnen ist absolut schwachsinnig. Viele andern implementierungen kannst du aus dem Grund sogar immer nur auf Zweierpotenzen genau einstellen. SUSE und Mandriva hatten Passwort hashes ebenfalls an die Rechenleistung angepasst aber eben nur auf 2er potenzen genau. Genau um sowas gehts den LUKS Leuten wäre die gebräuchliche Zeiteinheit 100ms lang, hätten sie vermutlich das genommen. Entsprechend ungenau sind die Messungen die hatten die den Anspruch da irgend was exakt zu bestimmen.
Zumal bruforce ja nur Statistik ist. Mit etwas Glück bist du auch gerne doppelt der vier mal so schnell.