NSA and GCHQ unlock privacy and security on the internet
Liebe Crypto Experten! Habts ihr zuf�llig einen Artikel der einen Hauch technischer ist zu den aktuellen NSA Geschichten? War immerhin im �1 Morgenjournal heute. NSA and GCHQ unlock privacy and security on the internet http://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryption-codes-secur... Sprich: Was genau wird geknackt und wie. OpenPGP zb wirds ja wohl nicht sein, oder doch? Ich vermute mal das bezieht sich vor Allem auf https bzw ssl. Was meint ihr? Danke! Martin
"They're doing it primarily by cheating, not by mathematics." -- Bruce Schneier https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html Sprich, sie machen genau das was man "eh erwartet". Firmen zwingen Backdoors einzubauen, security Lücken ausnützen, etc. H
naja, selbst wenn es fuer die einfach ist Verschluesselung zu umgehen, ist es doch vermutlich schwieriger als gleich unverschluesselte Mails zu lesen. -- LG Roland GPG Fingerprint: F451 8A1E 3F73 E5BB B1D8 A53D 9A58 9082 F8CC 633C GPG Keyserver: http://pgp.mit.edu On Sep 6, 2013, at 12:19 , Nina Temporär <nina-temp@gmx.de> wrote:
Heißt das jetzt, die Crypto-Parties sind eh für die Katz? N
Gesendet: Freitag, 06. September 2013 um 10:11 Uhr Von: "Harald Schilly" <harald.schilly@gmail.com> An: "Metalab General Discussion List" <metalab@lists.metalab.at> Betreff: Re: [Metalab] NSA and GCHQ unlock privacy and security on the internet "They're doing it primarily by cheating, not by mathematics." -- Bruce Schneier
https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html
Sprich, sie machen genau das was man "eh erwartet". Firmen zwingen Backdoors einzubauen, security Lücken ausnützen, etc.
H
_______________________________________________ Metalab mailing list Metalab@lists.metalab.at https://lists.metalab.at/mailman/listinfo/metalab _______________________________________________ Metalab mailing list Metalab@lists.metalab.at https://lists.metalab.at/mailman/listinfo/metalab
Ich würde meinen, nein. Wenns bei den gängigen CAs ein hintertürdl haben lesens wohl alle https verbindungen on the fly mit wenns wollen. Ich würd davon ausgehen. So wie es aussieht gehts da vor allem um SSL. Und OpenPGP dürfte wohl noch sicher sein, so sicher wie man halt den private key aufbewahrt. lg! M PS ein "lustiger" Witz aus den 90ern: http://www.austinlinks.com/Crypto/break-pgp.html On Freitag, 06. September 2013 13:05:46, Roland wrote:
naja, selbst wenn es fuer die einfach ist Verschluesselung zu umgehen, ist es doch vermutlich schwieriger als gleich unverschluesselte Mails zu lesen.
-- LG Roland
GPG Fingerprint: F451 8A1E 3F73 E5BB B1D8 A53D 9A58 9082 F8CC 633C GPG Keyserver: http://pgp.mit.edu
On Sep 6, 2013, at 12:19 , Nina Temporär <nina-temp@gmx.de> wrote:
Heißt das jetzt, die Crypto-Parties sind eh für die Katz? N
Gesendet: Freitag, 06. September 2013 um 10:11 Uhr Von: "Harald Schilly" <harald.schilly@gmail.com> An: "Metalab General Discussion List" <metalab@lists.metalab.at> Betreff: Re: [Metalab] NSA and GCHQ unlock privacy and security on the internet "They're doing it primarily by cheating, not by mathematics." -- Bruce Schneier
https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html
Sprich, sie machen genau das was man "eh erwartet". Firmen zwingen Backdoors einzubauen, security Lücken ausnützen, etc.
H
On Fri, Sep 06, 2013 at 01:49:47PM +0200, Martin M wrote:
PS ein "lustiger" Witz aus den 90ern: http://www.austinlinks.com/Crypto/break-pgp.html
On Fri, Sep 06, 2013 at 04:12:08PM +0200, L. Aaron Kaplan wrote:
Gute Crypto ist gute Crypto. Das passt schon. Aber a) Menschen machen Fehler bei der Verwendung von Crypto b) wir muessen anfangen Information Assurance [1] zu betreiben (sprich: testen und testen und testen bis die bits einzeln aus dem code rauspurzeln) c) es spricht dafuer, ausschliesslich open source und trusted hardware zu verwenden, weil da kann ich (b) machen.
Jein. Die Source alleine reichen *nicht*, man müsste beginnen von kritischer Software auch die binären Ergebnisse zu auditieren. Der Grund: Der Joke oben hat einen realen Hintergrund. Man kann tatsächlich Schadcode so in einem Compiler verstecken, dass dieser *nicht* im Sourcecode des Compilers sichtbar ist und *trotzdem* beim Neucompilieren des Compilers mit sich selbst wieder eingefügt wird (!), damit könnte man praktisch jedes Backdoor unterbringen und dafür sorgen, dass z.B. GPG einen trivialen Schlüssel generiert (so wie unfreiwillig Debian vor einiger Zeit). Ich sage nicht, dass das tatsächlich passiert oder passiert ist, sondern dass es diese Möglichkeit gibt. Und wenn es entdeckt würde wäre das wohl (zumindest unter Technikern) ein high-profile Skandal. Das ganze ist schon in den 80er Jahren von Ken Thompson bei einer Turing Award Lecture publiziert worden und gilt heute als Klassiker: Ken Thompson, Reflections on Trusting Trust, Communication of the ACM, Vol. 27, No. 8, August 1984, pp. 761-763. http://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf Zitat: """ The moral is obvious. You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code. """ Diese Ergebnisse muss man heute ergänzen, weil man natürlich solche Bugs auch direkt in der Hardware unterbringen kann. Vor ein paar Jahren haben ein paar Studenten ein Paper publiziert wo sie eine Hintertür direkt im Prozessor untergebracht hatten. So ich hoffe ich hab die nötige Portion Paranoia induziert :-) vG Ralf -- Ralf Schlatterbeck email: ralf@zoo.priv.at
On Fri, Sep 06, 2013 at 19:31:01 +0200, Ralf Schlatterbeck wrote:
Diese Ergebnisse muss man heute ergänzen, weil man natürlich solche Bugs auch direkt in der Hardware unterbringen kann. Vor ein paar Jahren haben ein paar Studenten ein Paper publiziert wo sie eine Hintertür direkt im Prozessor untergebracht hatten.
Interessant fand ich dazu auch http://spritesmods.com/?art=hddhack Den dazugehörigen Vortrag haben vielleicht einige von euch auf der OHM gesehen. Mit dieser Methode kann man jedenfalls direkt die von der Festplatte gelesenen Daten (und damit Programme) verändern. Im Fall von Festplattenfirmware und CPUs mit updatebarem Microcode verschwimmt auch die Grenze zwischen Hard- und Software, sodass es teilweise eben garnicht nötig ist, spezielle Hardware mit schwer auffindbaren Sicherheitslücken zu designen, sondern Hardware von der Stange entsprechend zu preparieren. Rein softwareseitig sind auch von der NSA finanzierte oder initiierte Projekte ganz interessant, z.B. SELinux. Ich könnte mir durchaus vorstellen, dass die so etwas nicht aus reiner Nächstenliebe schreiben, sondern mit dem Hintergedanken "wer ein sicheres System möchte, hat auch etwas vor uns zu verbergen" und dann unbemerkt Hintertüren in solche Projekte einbauen. Dazu ist außerdem auch interessant, wie sich die NSA angeblich in Standardkommitees einschleicht und dort wichtige Entscheidungen sabotiert (siehe dazu http://www.mail-archive.com/cryptography@metzdowd.com/msg12325.html ) Grüße, Moritz
On Sep 6, 2013, at 7:31 PM, Ralf Schlatterbeck <ralf@zoo.priv.at> wrote:
On Fri, Sep 06, 2013 at 01:49:47PM +0200, Martin M wrote:
PS ein "lustiger" Witz aus den 90ern: http://www.austinlinks.com/Crypto/break-pgp.html
On Fri, Sep 06, 2013 at 04:12:08PM +0200, L. Aaron Kaplan wrote:
Gute Crypto ist gute Crypto. Das passt schon. Aber a) Menschen machen Fehler bei der Verwendung von Crypto b) wir muessen anfangen Information Assurance [1] zu betreiben (sprich: testen und testen und testen bis die bits einzeln aus dem code rauspurzeln) c) es spricht dafuer, ausschliesslich open source und trusted hardware zu verwenden, weil da kann ich (b) machen.
Jein. Die Source alleine reichen *nicht*, man müsste beginnen von kritischer Software auch die binären Ergebnisse zu auditieren. Der Grund: Der Joke oben hat einen realen Hintergrund. Man kann tatsächlich Schadcode so in einem Compiler verstecken, dass dieser *nicht* im Sourcecode des Compilers sichtbar ist und *trotzdem* beim Neucompilieren des Compilers mit sich selbst wieder eingefügt wird (!), damit könnte man praktisch jedes Backdoor unterbringen und dafür sorgen, dass z.B. GPG einen trivialen Schlüssel generiert (so wie unfreiwillig Debian vor einiger Zeit). Ich sage nicht, dass das tatsächlich passiert oder passiert ist, sondern dass es diese Möglichkeit gibt. Und wenn es entdeckt würde wäre das wohl (zumindest unter Technikern) ein high-profile Skandal.
Das ganze ist schon in den 80er Jahren von Ken Thompson bei einer Turing Award Lecture publiziert worden und gilt heute als Klassiker:
Ken Thompson, Reflections on Trusting Trust, Communication of the ACM, Vol. 27, No. 8, August 1984, pp. 761-763. http://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf
Das gute alte "Trusting Trust" paper :)) Danke fuer die Erinnerung. Ja, gebe dir natuerlich recht, das ist ein Problem. Allerdings glaube ich, war es (soweit mir bekannt) bis jetzt einfach kein realer Angriffsvektor, da alle anderen Angriffe bis heute einfacher zu realisieren sind. Man denke einfach an ein suesses Video mit tanzenden Schweinchen, das ein Nutzer anklicken soll (um jetzt jemand anderen zu zitieren) ;-) Aber natuerlich - wenn wir mal soweit sind, ist das sicher das naechste Problem. Bin da voll bei dir. lg :) Aaron.
On Sep 6, 2013, at 12:19 PM, Nina Temporär <nina-temp@gmx.de> wrote:
Heißt das jetzt, die Crypto-Parties sind eh für die Katz?
Nein!! Gute Crypto ist gute Crypto. Das passt schon. Aber a) Menschen machen Fehler bei der Verwendung von Crypto b) wir muessen anfangen Information Assurance [1] zu betreiben (sprich: testen und testen und testen bis die bits einzeln aus dem code rauspurzeln) c) es spricht dafuer, ausschliesslich open source und trusted hardware zu verwenden, weil da kann ich (b) machen. Cryptoparties sind ein idealer Ort, um von Wissenden an Wissende Know-how in diesem Bereich weiterzugeben. Aber es wird eine permante Lernerfahrung werden. IT Security is a process, not a product. Genauso wie Mathe eine ewige Lernkurve ist. My 2 cents, a. [1] https://en.wikipedia.org/wiki/Information_assurance
Teilnehmer (7)
-
"Nina Temporär" -
Harald Schilly -
L. Aaron Kaplan -
Martin M -
Moritz Wilhelmy -
Ralf Schlatterbeck -
Roland