Vorratsdatenspeicherung in den USA

[Toska]

Heute auf Welt Online:

05.09.13
Codename "Bullrun"
NSA knackt die meisten Internet-Verschlüsselungen

Der US-Geheimdienst NSA kann Medienberichten zufolge sogar einen Großteil der verschlüsselten Daten im Internet mitlesen. Die Behörde habe mit Supercomputern, technischen Tricks, Gerichtsbeschlüssen und einiger Überzeugungsarbeit bei IT-Unternehmen die Mehrheit der bekannten Verschlüsselungssysteme geknackt oder umgangen, berichteten die "New York Times" und der "Guardian" in ihren Onlineausgaben.

Das milliardenteure NSA-Programm mit dem Codenamen "Bullrun" gehöre zu den größten Geheimnissen der Behörde und sei nun durch die Enthüllungen des Whistleblowers Edward Snowden ans Tageslicht gekommen. Nur sehr wenige Mitarbeiter hätten Zugang zu den Top-Secret-Informationen – und nur die Partnerbehörden in Großbritannien, Kanada, Australien und Neuseeland wüssten davon. So sei auch der britische Geheimdienst GCHQ beim Code-Knacken sehr erfolgreich. Seine Analysten hätten es zuletzt besonders auf Ziele wie Google, Yahoo, Facebook und Microsoft abgesehen.

Laut den Papieren kommen die Spionagebehörden auf vielen unterschiedlichen Wegen an die geknackten Daten, auch unter aktiver Mithilfe großer Technikfirmen, die allerdings namentlich nicht genannt werden. Die NSA habe sogar sicherstellen können, dass verbreitete Verschlüsselungssysteme bestimmte Schwächen aufweisen.

Quelle: http://www.welt.de/politik/ausland/arti ... ungen.html

Oder direkt den besseren Artikel beim Guardian lesen: http://www.theguardian.com/world/2013/s ... s-security

TrueCrypt ist da auch mit dabei. Passwort mit weniger als 20 Zeichen? Knacken die fast im Vorbeigehen.

[Lord_Vader]

Die knacken nicht, die umgehen. Die mathematischen Verfahren selbst sind sicher. Ist ein feiner aber wichtiger Unterschied.

http://www.zeit.de/digital/datenschutz/ ... luesselung

http://m.heise.de/newsticker/meldung/NS ... 50935.html

Die gute Nachricht ist: Die Veröffentlichungen liefern keine Hinweise darauf, dass es NSA oder GCHQ gelungen wäre, aktuell als stark eingestufte Verschlüsselungsverfahren wie AES mit ausreichend langen Schlüsseln zu kompromittieren. Im Gegenteil: In einem Interview mit dem Guardian bestätigte auch Insider Edward Snowden: "Verschlüsselung funktioniert. Sauber implementierte, starke Verschlüsselung ist eines der wenigen Dinge, auf die man sich noch verlassen kann." (ju)

Und noch etwas zu Truecrypt:

https://blog.fefe.de/?ts=acd45af3

... Ich habe mir in den letzten Tagen angefangen, Sorgen zu machen, dass die NSA dieses ganze Bruhaha für PSYOP nutzt. Wenn sie nur genügend häufig Truecrypt erwähnen und dass sie da Spezialhardware haben, dann kriegen die Leute vielleicht Angst und wechseln zu einem anderen, weniger sicheren System. Solange da nicht noch weitere, krasse Details rauskommen, würde ich Truecrypt weiterhin für so sicher halten, wie eure Passphrase halt ist.

[Toska]

Die knacken nicht, die umgehen. Die mathematischen Verfahren selbst sind sicher. Ist ein feiner aber wichtiger Unterschied.

Das momentane Resultat ist unterm Strich das gleiche. Dazu gleich noch ein bisschen mehr.

... Ich habe mir in den letzten Tagen angefangen, Sorgen zu machen, dass die NSA dieses ganze Bruhaha für PSYOP nutzt. Wenn sie nur genügend häufig Truecrypt erwähnen und dass sie da Spezialhardware haben, dann kriegen die Leute vielleicht Angst und wechseln zu einem anderen, weniger sicheren System.

Ja, da sprichst du einen sehr guten Punkt an und darüber hab ich mir auch schon den Kopf zerbrochen.

Hab gestern oder heute gelesen, das GCHQ hat indirekt bestätigt, dass die meisten HTTPS-Verbindungen für sie ein Klacks sind, da sie die RC4 Cypher geknackt haben.

Da wirds dann richtig geil. Ganz egal, ob das stimmt, oder eine PSYOP-Meldung ist. Wenn der Webserver HTTPS kann und von einem Browser auf dem HTTPS-Port kontaktiert wird, findet eine Verhandlung statt, um das beste gemeinsame Protokoll und die beste gemeinsame Verschlüsselungsmethode zu etablieren.

Wenn der Server mies konfiguriert ist, kann die Cypher TLS_RSA_EXPORT_WITH_RC4_40_MD5 sein, welche lachhaft schwach ist.

TLS_RSA_WITH_RC4_128_SHA und TLS_RSA_WITH_RC4_128_MD5 sind am weitesten verbreitet und das können alle Browser. Deshalb ist es oft der kleinste gemeinsame Nenner, der sicher genug scheint. Daher sind diese beiden Cypher halt bei HTTPS-Kommunikation oft vertreten. Wenn RC4 (wird hier für die Daten-Payload der Kommunikation verwendet) geknackt ist, gäbe es genügend Alternativen, die andere Cypher.Kombinationen verwenden. Unter anderem auf AES256 basierend und von recht vielen Browsern unterstützt - mit geringster Verbreitung in alten Microsoft Browsern. Laut Experten sollte man allerdings nun Symmetrische-Verschlüsselung und jene Cypher, die auf elliptischen Kurven basieren, meiden, da diese am ehesten manipuliert worden sein könnten.

Der Gag dabei: Die meisten nicht auf RC4 basierenden Methoden sind gegen die sogenannte "Beast"-Attacke verwundbar. Siehe: https://community.qualys.com/blogs/secu ... ack-on-tls

Die ist zwar bislang angeblich nur theoretischer Natur, aber man weiß ja nie. Hier jetzt komplett auf RC4 zu verzichten, oder sich ggf. der "Beast"-Attacke zu öffnen ist dann die Wahl zwischen Pest und Cholera. Man kann nicht abschätzen, was schlechter ist, oder was die größere Bedrohung darstellt.

Das Protokoll TLS1.2 oder die Verwendung von "Perfect Forward Secrecy" (PFS) würde das verhindern und auch deutlich mehr sichere Cypher zur Verfügung stellen. Bei PFS tauschen Client und Server zusätzlich noch Session-Cookies aus, die auf Diffie-Hellman beruhen und ein nachträgliches Auswerten mitgeschnittener SSL-Verbindungen verhindern sollen. Aktuelle RHEL6 und Derivate sind jedoch schon schon zu alt, um ohne großen Aufwand ein neueres OpenSSL zu nutzen, mit welchem PFS möglich wäre. Selbst dann ist TLS1.2 immer noch nur durch Umwege möglich.

TLS1.2 gibt es seit Jahren und TLS1.1 noch länger. Aber weder OpenSSL noch Apache haben beide voll implementiert und so stehen oft nur TLS1.0 und SSLv3 zur Verfügung. Ein Schelm, wer böses dabei denkt.

OpenSSL hat einen knapp 40%-tigen Marktanteil bei SSL-Verbindungen im Webserver-Bereich und recht viele kommerzielle Sicherheits-Anwendungen greifen letztendlich auch auf OpenSSL zurück. Die Anzahl der Spezialisten weltweit, die den Source-Code von OpenSSL (inklusive Crypto-Code und Stack) komplett genug verstehen, um wirklich den totalen Durchblick zu haben, passt vermutlich in ein Großraumtaxi oder einen Kleinbus. Ich will da nicht unnötig spekulieren, aber wenn "man" die Finger in OpenSSL hätte, wäre das der Honig-Topf der Kryptografie.

Im Zweifelsfalle dürfte es reichen "bessere" Standards zu verhindern, madig zu machen oder Distributoren dazu überreden, die schwächeren Standards in der Standard-Konfiguration nach oben zu rücken. Alleine damit ist schon viel erreicht.

Die Mathematik der guten Crypto-Verfahren mag stimmig sein, aber die Frage ist halt auch, in wieweit man seinen Tools noch trauen kann. Die Antwort darauf wird sicherlich ausbleiben.

[Toska]

Truecrypt:

https://blog.fefe.de/?ts=acd45af3

Du, da passt noch mehr nicht zusammen: Angeblich hatte der Kurier das TrueCrypt-Passwort doch aufgeschrieben (vor oder nach der "Befragung") und hat den Zettel dann unter Druck an die Beamten übergeben. So war es auch (recht kleinlaut) im Guardian zu lesen. Warum müssen die dann erst noch mühsam "zu Fuß" entschlüsseln?

Und wie Fefe sagt: Entweder haben sie den Schlüssel und kommen an alles ran, oder sie können bestenfalls durch Hörensagen wissen, dass da 58.000 Dokumente auf der Platte sind.

Zum Thema TrueCrypt knacken: http://www.heise.de/security/meldung/oc ... 43377.html

Mit zwei Radeon HD6990 und im günstigsten Fall sollen bis zu 451.000 Kombinationen pro Sekunde möglich sein, was bei ausreichender Entropie und Länge des Passworts aber noch immer 'ne ganze Weile dauern kann. Und es klappt halt derzeit auch nur bei AES-verschlüsselten Daten. Serpent, Twofish oder Kombinationen aus den zwei bis drei Verfahren werden noch nicht unterstützt. Das gibt einem dann schon mal Hinweise, was derzeit geht.

[Lord_Vader]

https://blog.fefe.de/?ts=acd52294 schönes Statement dazu.


Das ganze Bohei um https beunruhigt mich auch nicht so. Abgesehen von den Punkten die du ansprachst, ist eines der wichtigsten Probleme eben das die NSA immer direkt auf den Server zugreifen kann und damit jede Transport Verschlüsselung witzlos wird. Klar muss man die Absichtlichen Probleme abschaffen, aber zusätzlich sollten wichtige Daten immer selbst verschlüsselt sein.
An Truecrypt wird sich die NSA noch lange die Zähne ausbeissen.

[Herr Rossi]

Zum Thema ssl gab es mal einen Chaos Radio Express Podcast, der das Thema recht gut abgehandelt hat. Neu ist das alles nicht. Das Thema NSA bringt es nur mal wieder in den Focus. Das Kernproblem war eigentlich schon immer die Notwendigkeit von CAs, denen man mehr oder weniger blind vertrauen muss. Das ist kein wirklich guter Ansatz. Es gibt aber wohl auch Versuche das Vertrauensproblem in die Hand der User über eine Art Peer-Vernetzung/Ranking zu legen...

[Toska]

https://blog.fefe.de/?ts=acd52294 schönes Statement dazu.

Das ganze Bohei um https beunruhigt mich auch nicht so. Abgesehen von den Punkten die du ansprachst, ist eines der wichtigsten Probleme eben das die NSA immer direkt auf den Server zugreifen kann und damit jede Transport Verschlüsselung witzlos wird.

Ja, Fefes Blog lese ich mittlerweile auch jeden Tag und er fasst das gut zusammen. Das die NSA draufkommt, wenn sie will? Klar, davon kann man ausgehen. Ich würde das dennoch nicht so ganz von der Thematik abkapseln und sehe da auch einen Zusammenhang mit der HTTPS-Problematik.

Wie Fefe geschrieben hat, braucht man selbst für das Dechiffrieren von HTTPS noch eine Menge Klartext und viel Zeit. Im Eigentlich mindestens soviel Klartext, wie man entschlüsseln will. Weniger geht nur, wenn man z.B. Insider-Wissen um schwache Zufallszahlen hat, die bei der verwendeten Chiffre Einfluss genommen haben können. Das kann den Zeitfaktor der Verschlüsselung signifikant verkürzen. Aber selbst wenn du von 2^70 bit so an die 2^40 bit in der Tasche hast, dauert das noch immer ewig und drei Tage.

Lass mich aber nochmal auf OpenSSL zurückkommen: Mich betrifft das Thema eher, da ich für meine Linux-Distri halt mal einen Audit gemacht habe, was bei uns denn auf HTTPS-Ebene so abgeht. Ist das alles stimmig und griffig? Oder kann man da noch optimieren? Die Ergebnisse waren überraschend. Eine alte Schulweisheit aus dem Sysadmin-Handbuch: Überlass Apache und den Browser die Verhandlung von Protokoll und Chiffre. Dabei bekommst du die besten Ergebnisse.

Falsch.

Bei uns wurde dann bei fast allen Browsern die schwächsten Schlüssel ausgewählt. Ich weiß definitiv, dass das 2008 mal anders war. Da hatte ich diesen Aspekt das letzte mal genauer unter die Lupe genommen. Bei der Nachforschung bin ich dann auf das hier gestoßen:

https://bugzilla.redhat.com/show_bug.cgi?id=319901#c36

Bug aus 2007. Viel Text in dem Kommentaren. Ich geb' mal ein TL;DR: Sowohl RedHat als auch Fedora (und damit auch alle Ableger wie CentOS und Scientific Linux) setzen verkrüppelte Versionen von OpenSSL ein. Aus rechtlichen Gründen hat man alle auf Elliptic Curve basierenden Verschlüsselungen deaktiviert. Andere Distributionen tun das nicht, aber RedHat beharrt seit sechs Jahren darauf, dass sie es nicht geschafft haben, das rechtlich sauber hinzubekommen. Ohne diese Verfahren geht kein Perfect Forward Secrecy. Das führt zu so absurden Situationen, dass du auf einem Fedora einen Firefox hast, der zwar Perfect Forward Secrecy kann (denn Firefox hat die passende Lib dafür drin!), aber kein Webserver auf RHEL (und Klone) Basis kann das von Hause aus.

Also zwei Dinge, die mir sauer aufstoßen: Entgegen früheren Verhalten wählt Apache auf RHEL6 und Klonen nun extrem schwache SSL-Verfahren aus UND OpenSSL wurde absichtlich so verkrüppelt, dass Perfect Forward Secrecy nicht geht. Selbst wer hier Hand anlegen will, um das zu fixen, stößt bei dem zweiten Punkt auf eine schwer zu überwindende Hürde. OpenSSL selbst zu kompilieren ist nicht trivial, da alles mögliche dagegen gelinkt ist. Eine separate Installation eines neueren OpenSSL in ein separates Verzeichnis setzt dann voraus, dass alle Dienste, die es verwenden sollen, dann ebenfalls neu kompiliert werden müssen. Das macht ein Upgrading und zukünftige Installation von Systemupdates zu einem Vabanquespiel.

Wie gesagt: Ein Schelm, wer böses dabei denkt.

In dem Zusammenhang lesenswert: http://www.technologyreview.com/news/51 ... ty-crisis/

Man geht davon aus, dass Fortschritte in der Kryptographie dafür sorgen, dass Diffie-Hellmann und RSA bald deutlich leichter zu knacken sind. Chiffren auf Elliptic Curve werden hier als "Heilmittel" angesehen, auch wenn andere wie Bruce Schneier davor warnen. Elliptic Curve sind im Prinzip vorberechnete Primzahlen. Sie lassen sich schnell erstellen, aber die Mathe dahinter könnte für einen Angreifer auch zu berechenbarer sein. Wenn man dann noch bedenkt, dass die NSA möglicherweise einen Technologie-Vorsprung von 5 Jahren gegenüber dem freien Markt haben könnte, sind sie vielleicht schon recht nahe dran, oder haben es geschafft. So oder so geht das dann wieder in die Richtung PSYOP.

Wie du schon richtig gesagt hast: Das ganze schreit nach einem unabhängigen Audit von Krypto-Verfahren. Derzeit kann keiner genau sagen, was sicher(er) ist und was nicht. Und erschwerend kommt hinzu, dass sich manche Distributoren wohl leider auch zum willfährigen Helfer gemacht haben. Patentrecht hin oder her.

[Lord_Vader]

Willfährig nicht unbedingt. Gerade die in den USA ihren Sitz haben, werden wohl schlicht dazu gezwungen.