BOFH sagt
"PEBKAC (Problem Exists Between Keyboard And Chair)"
Getaggte Artikel
article blackberry blogging blogtk cisco cms coding crunchix crypto database debian del.icio.us encfs firewall freebsd fun google ha hacking hacks honeypot insipid jabber lighttpd linux mail md5 ml370 moblogging network nmap openbsd openvz personal phrack plone portknocking privacy python rant review rootforum security serendipity server spam ssh thinkpad tool tor tutorial ubuntu uni vm vserver wifi wiki work xen zimbra
Blogroll
Rechtliches
Monday, 4. September 2006
Löchriger Käse
Es ist endlich wieder so weit: Passend zum ersten Eintrag hier seit langer langer Zeit ist seit heute (ab Seite 36) des aktuellen Linux-Magazins (Ausgabe 10/06) ein neuer Artikel von mir in Zusammenarbeit mit Peter Gutmann erschienen.
In dem insgesamt knapp 10 Seiten langen Machwerk werden Funktionseise und Sicherheit aktueller Crypto-Filesysteme unter Linux getestet. Angetreten waren das altgediente loop-AES, DM-Crypt sowie TrueCrypt auf Kernelebene, sowie EncFS und CryptoFS im Userspace.
Zwischen all diesen Lösungen gibt es zum Teil recht große Unterschiede in der Handhabung, jedoch vor allem auch in sicherhitstechnischer Hinsicht. Hier hat Peter, mit dem die Zusammenarbeit echt eine Menge Spaß gemacht hat ganze Arbeit geleistet. Jedenfalls werden sich wohl noch einige umschauen, die sich in Sicherheit fühlen.
Sofern es jemand liest, freue ich mich jederzeit über konstruktive Kritik.
In dem insgesamt knapp 10 Seiten langen Machwerk werden Funktionseise und Sicherheit aktueller Crypto-Filesysteme unter Linux getestet. Angetreten waren das altgediente loop-AES, DM-Crypt sowie TrueCrypt auf Kernelebene, sowie EncFS und CryptoFS im Userspace.
Zwischen all diesen Lösungen gibt es zum Teil recht große Unterschiede in der Handhabung, jedoch vor allem auch in sicherhitstechnischer Hinsicht. Hier hat Peter, mit dem die Zusammenarbeit echt eine Menge Spaß gemacht hat ganze Arbeit geleistet. Jedenfalls werden sich wohl noch einige umschauen, die sich in Sicherheit fühlen.
Sofern es jemand liest, freue ich mich jederzeit über konstruktive Kritik.
Trackbacks
Trackback für spezifische URI dieses Eintrags
Keine Trackbacks
Kommentare
Ansicht der Kommentare:
(Linear | Verschachtelt)
Mein Heft sollte die naechsten Tage kommen. Dann kann ich Feedback abgeben. Linuxmagazin hab ich sowieso aboniert 
Finde euren Artikel sehr gut!
Hab nur eine Frage, zu dem Fehler in Enc-FS. Hab versucht, das nachzuvollziehen, kann aber die Funktion RAND_bytes nirgendwo auffinden... Liegt wohl an mir und meinen Fähigkeiten Kannst du mir weiterhelfen? Danke!
Hab nur eine Frage, zu dem Fehler in Enc-FS. Hab versucht, das nachzuvollziehen, kann aber die Funktion RAND_bytes nirgendwo auffinden... Liegt wohl an mir und meinen Fähigkeiten
Kannst du mir weiterhelfen? Danke!
Zwar wäre Peter hier sicherlich der bessere Ansprechpartner, ich versuch's aber trotzdem mal:
RAND_bytes() ist eine Funktion, die extern aufgerufen wird. Am Abschnitt, in dem sie zum ersten Mal eingebunden wird (encfs/main.cpp, Zeile 593 innerhalb des #ifdef HAVE_SSL-Teils) lässt sich vielleicht schon erahnen, dass sie eigentlich aus den (Open)SSL-Headern stammt.
Sofern du die passenden installiert hast (libssl-dev unter Ubuntu) kannst du sie dir mit Hilfe von "man 3 RAND_bytes" mal näher anschauen.
Frage geklärt?
RAND_bytes() ist eine Funktion, die extern aufgerufen wird. Am Abschnitt, in dem sie zum ersten Mal eingebunden wird (encfs/main.cpp, Zeile 593 innerhalb des #ifdef HAVE_SSL-Teils) lässt sich vielleicht schon erahnen, dass sie eigentlich aus den (Open)SSL-Headern stammt.
Sofern du die passenden installiert hast (libssl-dev unter Ubuntu) kannst du sie dir mit Hilfe von "man 3 RAND_bytes" mal näher anschauen.
Frage geklärt?
Ja, das die Funktion von OpenSSL stammt habe ich auch schon herausgefunden, konnte sie dort aber bis jetzt noch nicht finden (hab ein wenig gegrept). Ich schau's mir nachher nochmal an. Vielen Dank!
Hi Christian! Ich hab heute deinen/euren Artikel gelesen, fand ich ziemlich gut und interessant. Hier einige Fragen/Anmerkungen, v.a. zu dm-crypt, da ich das benutze (und mir der Rest relativ egal ist )
Mir ist nicht ganz klar warum dm-crypt als so problembehaftet dasteht, es scheint mir immer noch die beste Alternative zu sein (zu TrueCrypt kann ich nichts sagen, ausser dass ich ein schlechtes Gefühl habe; habs aber noch nicht ausprobiert).
Ich hab mal den Quellcode von cryptsetup/LUKS 1.0.3 (im Artikel behandelt) und 1.0.4 rc1 geholt, beide haben aes-cbc-essiv:sha256 als default cipher+mode+hash, soweit ich das sehe (obwohl zugegebenermaßen die manpage etwas missverständlich formuliert ist was das angeht; ich werd mal einen Patch schicken).
Bleiben noch die Kritikpunkte "irritiert mit der Menge an Optionen" (was jetzt kein wirkliches Kriterium ist um die Sicherheit zu beurteilen - halbwegs intelligente User vorausgesetzt), und "aus Crypto-Sicht müsste jeder Sektor bei jeder Änderung einen neuen IV erhalten" (bezieht sich das auf das alte cryptsetup oder cryptsetup+LUKS? Ist es bei letzterem noch relevant?).
Ein valider Punkt ist dass die Default-Schlüssellänge 128 Bit ist, besser ist es wohl "-s 256" wie im Artikel angegeben zu verwenden. Wäre noch zu testen wie viel Performance-Unterschied das macht (http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio), aber Performance ist eh kein wirkliches Kriterium wenn es um Sicherheit geht - wenn mir Performance wichtiger ist, lass ich das mit der Verschlüsselung halt gleich bleiben
Etwas unterschwellig ist noch das "schwach implementiert" (bezieht sich wohl allgemein auf alle oder fast alle Implementierungen) im Raum, wozu ich nichts sagen kann, hab den Quellcode (noch?) nicht genauer angeschaut. Gab es da konkrete Auffälligkeiten? Zu Enc-FS gabs ja ein konkretes Code-Beispiel im Artikel, aber nicht zu dm-crypt soweit ich das sehe. Falls ja, hast du einen Patch an den Autor geschickt?
Weiter vorne im Artikel noch: "keiner der Testkandidaten nennt ein klares Bedrohungsszenario[...] oder verrät wenigstens die Designprinzipien[...]". Ausnahmen wären laut Artikel TrueCrypt und Enc-FS. Zu LUKS zumindest gibts es doch ein Paper und Doku auf der Website, oder?
Das einzig wirkliche Problem das ich mit dm-crypt sehe ist dass es eben CBC und nicht das wohl bessere LRW verwendet (das einige Typen von Angriffen verhindert oder erschwert). Wer sich da berufen fühlt, bitte hier weitermachen: http://clemens.endorphin.org/patches/lrw/
Kann man den Sicherheitszugewinn von LRW irgendwie quantitativ erfassen? D.h. wie problematisch ist CBC bei dm-crypt in der Praxis?
Uwe.
)Mir ist nicht ganz klar warum dm-crypt als so problembehaftet dasteht, es scheint mir immer noch die beste Alternative zu sein (zu TrueCrypt kann ich nichts sagen, ausser dass ich ein schlechtes Gefühl habe; habs aber noch nicht ausprobiert).
Ich hab mal den Quellcode von cryptsetup/LUKS 1.0.3 (im Artikel behandelt) und 1.0.4 rc1 geholt, beide haben aes-cbc-essiv:sha256 als default cipher+mode+hash, soweit ich das sehe (obwohl zugegebenermaßen die manpage etwas missverständlich formuliert ist was das angeht; ich werd mal einen Patch schicken).
Bleiben noch die Kritikpunkte "irritiert mit der Menge an Optionen" (was jetzt kein wirkliches Kriterium ist um die Sicherheit zu beurteilen - halbwegs intelligente User vorausgesetzt), und "aus Crypto-Sicht müsste jeder Sektor bei jeder Änderung einen neuen IV erhalten" (bezieht sich das auf das alte cryptsetup oder cryptsetup+LUKS? Ist es bei letzterem noch relevant?).
Ein valider Punkt ist dass die Default-Schlüssellänge 128 Bit ist, besser ist es wohl "-s 256" wie im Artikel angegeben zu verwenden. Wäre noch zu testen wie viel Performance-Unterschied das macht (http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio), aber Performance ist eh kein wirkliches Kriterium wenn es um Sicherheit geht - wenn mir Performance wichtiger ist, lass ich das mit der Verschlüsselung halt gleich bleiben
Etwas unterschwellig ist noch das "schwach implementiert" (bezieht sich wohl allgemein auf alle oder fast alle Implementierungen) im Raum, wozu ich nichts sagen kann, hab den Quellcode (noch?) nicht genauer angeschaut. Gab es da konkrete Auffälligkeiten? Zu Enc-FS gabs ja ein konkretes Code-Beispiel im Artikel, aber nicht zu dm-crypt soweit ich das sehe. Falls ja, hast du einen Patch an den Autor geschickt?
Weiter vorne im Artikel noch: "keiner der Testkandidaten nennt ein klares Bedrohungsszenario[...] oder verrät wenigstens die Designprinzipien[...]". Ausnahmen wären laut Artikel TrueCrypt und Enc-FS. Zu LUKS zumindest gibts es doch ein Paper und Doku auf der Website, oder?
Das einzig wirkliche Problem das ich mit dm-crypt sehe ist dass es eben CBC und nicht das wohl bessere LRW verwendet (das einige Typen von Angriffen verhindert oder erschwert). Wer sich da berufen fühlt, bitte hier weitermachen: http://clemens.endorphin.org/patches/lrw/
Kann man den Sicherheitszugewinn von LRW irgendwie quantitativ erfassen? D.h. wie problematisch ist CBC bei dm-crypt in der Praxis?
Uwe.
Hallo Uwe, und danke für deinen Kommentar!
Lass mich hierzu eins vorausschicken: Ich selbst habe mich für den Artikel eigentlich (fast) "nur" auf die praktische Seite der Tests konzentriert. Peter bei der Analyse der Sourcen Arbeit abzunehmen wäre von meinem Standpunkt aus auch eher unsinnig gewesen, da sein Hintergrundwissen in dieser Thematik wohl erheblich weiter reicht als meins jemals reichen wird. Ich würde mich bei meiner Antwort daher gern auch auf diesen Teil beschränken, deine Fragen aber gern an Peter weitergeben. Vielleicht kann er ja auch direkt hier antworten.
Ich für meinen Teil nutze auch (seit längerem) DM-Crypt in Verbindung mit LUKS, und habe mich auch bis dato noch nie "unsicher" damit gefühlt. Ausschlaggebend war die sehr gute Integration ins Gesamtsystem.
Wie du selbst bemerkt hast, ist die Manpage zum Thema default cipher ungenau, wenn nicht sogar falsch. Die mir vorliegende sagt z.B. folgendes:
"Usually, this is "aes-cbc-plain". For pre-2.6.10 kernels, use "aes- plain" as they don’t understand the new cipher spec strings. To use ESSIV, use "aes-cbc-essiv:sha256"."
Da ich selbst sämtliche Parameter ohnehin händisch angebe, habe ich mich bei dieser Aussage an genau diese Aussage gehalten, und wohl auch Peter, der mich extra danach gefragt habe in die Irre geführt. Sollte mir / uns dabei ein Fehler unterlaufen sein, freue ich mich umso mehr, hier eines besseren belehrt worden zu sein.
Deine Meinung dass eine einfache Nutzung kein Kriterium zur Beurteilung der Sicherheit darstellt kann ich allerdings nicht ganz teilen. Wie du sicherlich selbst weißt, hapert es fast immer am Punkt "halbwegs intelligente User vorausgesetzt". Wenn ich eine Software schreibe, die die Sicherheit erhöhen soll, sollte diese nicht nur "sichere" Defaults setzen, sondern es dem User dabei so einfach wie möglich machen. Menschen neigen einmal grundsätzlich dazu, Fehler zu machen.
Wenn ich mir Peters bisherige Publikationen (gerade im Linux-Magazin) so anschaue, und so wie ich ihn kennengelernt habe, wage ich die Behauptung, dass er dir ähnliches antworten würde.
Die anderen Fragen würde ich aus den o.g. Gründen gern an Peter weitergeben. Sofern er selbst nicht hier antworten möchte, werde ich mal versuchen, das stellvertretend zu übernehmen. Wäre das OK für dich?
Lass mich hierzu eins vorausschicken: Ich selbst habe mich für den Artikel eigentlich (fast) "nur" auf die praktische Seite der Tests konzentriert. Peter bei der Analyse der Sourcen Arbeit abzunehmen wäre von meinem Standpunkt aus auch eher unsinnig gewesen, da sein Hintergrundwissen in dieser Thematik wohl erheblich weiter reicht als meins jemals reichen wird. Ich würde mich bei meiner Antwort daher gern auch auf diesen Teil beschränken, deine Fragen aber gern an Peter weitergeben. Vielleicht kann er ja auch direkt hier antworten.
Ich für meinen Teil nutze auch (seit längerem) DM-Crypt in Verbindung mit LUKS, und habe mich auch bis dato noch nie "unsicher" damit gefühlt. Ausschlaggebend war die sehr gute Integration ins Gesamtsystem.
Wie du selbst bemerkt hast, ist die Manpage zum Thema default cipher ungenau, wenn nicht sogar falsch. Die mir vorliegende sagt z.B. folgendes:
"Usually, this is "aes-cbc-plain". For pre-2.6.10 kernels, use "aes- plain" as they don’t understand the new cipher spec strings. To use ESSIV, use "aes-cbc-essiv:sha256"."
Da ich selbst sämtliche Parameter ohnehin händisch angebe, habe ich mich bei dieser Aussage an genau diese Aussage gehalten, und wohl auch Peter, der mich extra danach gefragt habe in die Irre geführt. Sollte mir / uns dabei ein Fehler unterlaufen sein, freue ich mich umso mehr, hier eines besseren belehrt worden zu sein.
Deine Meinung dass eine einfache Nutzung kein Kriterium zur Beurteilung der Sicherheit darstellt kann ich allerdings nicht ganz teilen. Wie du sicherlich selbst weißt, hapert es fast immer am Punkt "halbwegs intelligente User vorausgesetzt". Wenn ich eine Software schreibe, die die Sicherheit erhöhen soll, sollte diese nicht nur "sichere" Defaults setzen, sondern es dem User dabei so einfach wie möglich machen. Menschen neigen einmal grundsätzlich dazu, Fehler zu machen.
Wenn ich mir Peters bisherige Publikationen (gerade im Linux-Magazin) so anschaue, und so wie ich ihn kennengelernt habe, wage ich die Behauptung, dass er dir ähnliches antworten würde.
Die anderen Fragen würde ich aus den o.g. Gründen gern an Peter weitergeben. Sofern er selbst nicht hier antworten möchte, werde ich mal versuchen, das stellvertretend zu übernehmen. Wäre das OK für dich?
Hi Christian,
mein Patch zur manpage wurde heute schon von Clemens Fruhwirth gemerged, die manpage sollte also jetzt auch aes-cbc-essiv:sha256 als default auflisten (siehe dm-crypt Mailingliste).
OK, das Argument mit einfacher Benutzbarkeit im Allgemeinen ist schon richtig, nur ist das für mich persönlich kein Kriterium, weil ich die manpage oder den Code lesen und dann die sicheren Optionen wählen kann Das ist evtl. ein Usabilityproblem, aber zum Glück kein hartes Crypto-Problem (was IMHO schlimmer wäre).
> Wäre das OK für dich?
Klar, das wäre prima!
Uwe.
mein Patch zur manpage wurde heute schon von Clemens Fruhwirth gemerged, die manpage sollte also jetzt auch aes-cbc-essiv:sha256 als default auflisten (siehe dm-crypt Mailingliste).
OK, das Argument mit einfacher Benutzbarkeit im Allgemeinen ist schon richtig, nur ist das für mich persönlich kein Kriterium, weil ich die manpage oder den Code lesen und dann die sicheren Optionen wählen kann
Das ist evtl. ein Usabilityproblem, aber zum Glück kein hartes Crypto-Problem (was IMHO schlimmer wäre).> Wäre das OK für dich?
Klar, das wäre prima!
Uwe.
Hi Uwe!
Mittlerweile habe ich eine kurze Mail von Peter erhalten, und gebe die relevanten Teile einfach mal stellvertretend wieder:
--- schnipp ---
However the key size issue he raises is almost
irrelevant compared to the almost total lack of checking that a lot of the
code does, there's that example that Achim put in the article, but what's
worse is that after it does perform its (broken) error checking it just
continues anyway! So it won't detect half the errors that can occur, and for
the ones it does detect it just keeps going. It was pretty frightening code
.
Peter.
--- schnapp ---
Mittlerweile habe ich eine kurze Mail von Peter erhalten, und gebe die relevanten Teile einfach mal stellvertretend wieder:
--- schnipp ---
However the key size issue he raises is almost
irrelevant compared to the almost total lack of checking that a lot of the
code does, there's that example that Achim put in the article, but what's
worse is that after it does perform its (broken) error checking it just
continues anyway! So it won't detect half the errors that can occur, and for
the ones it does detect it just keeps going. It was pretty frightening code
.Peter.
--- schnapp ---
Hi,
wirklich interessanter Artikel. Gerade für mich als Notebook-Nutzer.
Was ich noch fragen wollte, wie sieht es eigentlich mit der Datenrettung aus wenn der pysikalische Datenträger (Festplatte im Notebook) Fehler aufweist.
Die Chance ist doch dann zumindest geringer wegen der Verschlüsselung noch brauchbare Daten vom Datenträger zu fischen.
wirklich interessanter Artikel. Gerade für mich als Notebook-Nutzer.
Was ich noch fragen wollte, wie sieht es eigentlich mit der Datenrettung aus wenn der pysikalische Datenträger (Festplatte im Notebook) Fehler aufweist.
Die Chance ist doch dann zumindest geringer wegen der Verschlüsselung noch brauchbare Daten vom Datenträger zu fischen.
Jein. Sofern die Datenretter sich darauf konzentrieren, ein spezielles Filesystem zurückholen zu wollen, haben sie natürlich ganz schlechte Karten. Der Inhalt der Platte sieht nun mal (wie gewollt) nach Datenmüll aus.
Sofern du auf das (teils erheblich teurere) aufwändige Wiederherstellen der Daten auf Hardwarebene beauftragsen würdest, hättest du aber vermutlich Glück. Wie in Peters Beitrag vor dem Test zu lesen, fängt sich gerade CBC-Verschlüsselung noch recht gut, sofern ein Sektor defekt sein sollte. Vielleicht könnte die Peter sogar ungefähr sagen, wie viele hintereinanderliegende Sektoren Fehler aufweisen, oder nicht mehr lesbar sein dürfen, bevor es zum GAU kommt.
Sofern du auf das (teils erheblich teurere) aufwändige Wiederherstellen der Daten auf Hardwarebene beauftragsen würdest, hättest du aber vermutlich Glück. Wie in Peters Beitrag vor dem Test zu lesen, fängt sich gerade CBC-Verschlüsselung noch recht gut, sofern ein Sektor defekt sein sollte. Vielleicht könnte die Peter sogar ungefähr sagen, wie viele hintereinanderliegende Sektoren Fehler aufweisen, oder nicht mehr lesbar sein dürfen, bevor es zum GAU kommt.
Hi,
gegen tote Festplatten kann man wenig tun, aber die smartmontools können helfen herauszufinden ob die Festplatte in naher Zukunft den Geist aufgeben könnte. Sehr zu empfehlen, IMHO.
Ansonsten habe ich eben bei einer ext3-over-LVM-over-dmcrypt Laptop-Installation drei mal hintereinanander im Vollbetrieb einfach mal den Stecker gezogen (Strom weg), und das System liess sich jedes Mal problemlos wieder booten...
Was aber nicht heisst dass das immer so sein müsste...
Uwe.
gegen tote Festplatten kann man wenig tun, aber die smartmontools können helfen herauszufinden ob die Festplatte in naher Zukunft den Geist aufgeben könnte. Sehr zu empfehlen, IMHO.
Ansonsten habe ich eben bei einer ext3-over-LVM-over-dmcrypt Laptop-Installation drei mal hintereinanander im Vollbetrieb einfach mal den Stecker gezogen (Strom weg), und das System liess sich jedes Mal problemlos wieder booten...
Was aber nicht heisst dass das immer so sein müsste...
Uwe.
auf linux-crypto@ geht es u.a. aktuell um den Artikel:
http://thread.gmane.org/gmane.linux.cryptography/2038/focus=2038
Vielleicht möchtet ihr dort ein paar Kommentare abgeben?
http://thread.gmane.org/gmane.linux.cryptography/2038/focus=2038
Vielleicht möchtet ihr dort ein paar Kommentare abgeben?
Ich haben den Artikel gelesen und kann mich den anderen anschliessen: Sehr gelungen
Kommentar schreiben
Links des Artikels
Suche
Kalender
|
March '10 | |||||
| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | 31 | ||||
Powered by
Sonstiges
