Vollständige Version anzeigen : [Smartphones] End-to-End Encryption & NSA und co.


Targa
12.09.2013, 15:08

Guten Mittag,

viele/manche haben evtl. schon was von diversen Messengern gehört die End-to-End Encryption anbieten oder anbieten werden.

Als Beispiel mal Hemlis (;heml~is/). Wird unter anderem vom Peter Sunde entwickelt der ja für Pirate Bay und Flattr verantworlich war/ist.
Das Problem - wenn man mal die Sicherheit außen vor lässt - war meiner Meinung nach bisher die Tatsache, dass die bisherigen Messenger die so was oder ähnliches angeboten haben, bei der breiten Masse keinen Anklang gefunden haben. Da aber der Name, die Funktionen und das Design vielversprechend aussehen habe ich Hoffnung das in Zukunft evtl. was drauß wird.

Nun denn weiter im Text. Meine Frage bezieht sich auf die "Tatsache", dass theoretisch die End-to-End Encryption sicher sein sollte allerdings nur wenn das Smartphone nicht manipuliert ist?!?!?!

Bezieht sich auf NSA soll Zugriff auf Smartphones haben (;;;sueddeutsche~de/digital/internet-ueberwachung-nsa-soll-zugriff-auf-smartphones-haben-1;1765042)

Falls das wie im Artikel beschrieben zutrifft, was kann man dagegen tun, wie kann man sich schützen?

Und los.

Hardware Preisvergleich | Amazon Blitzangebote!

Videos zum Thema
Video Loading...
eax
12.09.2013, 16:18

Kein Smartphone nutzen oder das Beste hoffen. Momentan sitzen einige/viele daran Linux Systeme auf Lücken zu untersuchen um die Sicherheit zu erhöhen und da werden sicherlich ein paar auch Android anschauen.

Ansonsten nur das was man sowie so machen sollte um sich vor Datendieben zu schützen.


theQuest
12.09.2013, 16:34

Wie man sich schützt? Cutting Edge sein ;)

Aber der Reihe nach.

Zuerst zu Heml;is: Nette Idee. Sieht für mich, also nur von den Informationen der Website her, wie ein Jabber-Client aus. Natürlich etwas ausgebohrt und umgestaltet. Aber im großen müsste es das sein. Da der Source nicht öffentlich ist, kann man auch nicht sagen, wie genau jetzt dort die "Sicherheit" hergestellt werden soll. Ich selber nutze Threema und dort werden Zertifikate zwischen Nutzern direkt ausgetauscht und wirkliche sichere Kommunikation erreicht man nur, wenn man sich einmalig mit dem Nutzer trifft, um die Keys auszutauschen und die Identität des anderen zu bestätigen. Quasi ein PGP-Ansatz ;) Zurück zu Heml;is: Eine SSL-Verbindung zum Server muss absolut nichts bedeuten. Auf Golem war neulich ein interessanter Artikel über die Schwachstellen der SLL-Kommunikation, selbst wenn man diese via AES als Algo betreibt.

Wie man sich schützen kann? Natürlich kann man nicht auf ein Handy verzichten (also man könnte schon, ist aber nicht zielführend). Daten die auf einem Gerät clear abgelegt sind, sind immer potentielle Ziele von Angreifern. Also muss schon dort ein Schutz vorliegen (True Crypt zum Beispiel - wobei dort die Unterstützung nur rudimentär auf den Smartphones ist, APG kann auch nur Inhalte verschlüsseln, die ich vorher auswähle). Da also ein clientseitgier Schutz nicht möglich ist (zZ), hat man nur die Kontrolle darüber, welche Daten auf dem Gerät lagern. Also keine sensiblen* Daten auf das Handy klatschen und gut ist.

Gegen das Tracking von Bewegungen kann man nicht viel machen. Hier wäre es das beste. wenn man Prepaid-Karten nutzt und diese regelmäßig austauscht (auch nicht unbedingt zielführend).

(*Sensibel: Dinge die andere nicht erfahren sollen - können Bankdaten, Handynummer vom Dealer, Pornofilme oder auch einfach nur die 'normale' Kommunikation mit freunden sein. Im Endeffekt ist eigentlich alles schützenswert. Abstufungen individuell möglich;)


TuXiFiED
12.09.2013, 19:41

PGP-Ansatz ;) Zurück zu Heml;is: Eine SSL-Verbindung zum Server muss absolut nichts bedeuten. Auf Golem war neulich ein interessanter Artikel über die Schwachstellen der SLL-Kommunikation, selbst wenn man diese via AES als Algo betreibt;

Gehen wir doch darauf mal genauer ein.
Erstens ist es immer noch SSL-Kommunikation (wenn man schon den alten Namen nimmt), aber nennen wir das Kind doch mal beim aktuellen Namen: TLS, auch Transport Layer Security (in Anlehnung an die OSI-Schicht 4, Transport Layer, auf dem/der die Sicherung abläuft) genannt.
TLS ist die Weiterentwicklung von SSL (Secure Sockets Layer), TLS 1;0 entspräche quasi SSL Version 3;1, TLS 1;1 3;2 und TLS 1;2 Version 3;3.

Es gibt im Wesentlichen zwei Angriffsmöglichkeiten, die ein aktiver Angreifer derzeit (teilweise) hat:

- SSL Downgrade Attacks.
Die SSL-Version 3;0 und TLS 1;0 bieten, zumindest, wenn alte Server- oder Clientsoftware verwendet wird (wodurch die Angriffe nicht reflektiert oder codeseitig behoben werden) diverse Angriffe.
Die zwei, dir mir grad aus dem Stehgreif einfallen sind die Lucky Thirteen Attacke (;blogs;rsa~com/secure-crypto-lucky-thirteen-attack/) (ein Timing-Angriff), und die BEAST (;;;schneier~com/blog/archives/2011/09/man-in-the-midd_4;html)-Attacke (Angriff auf Algorithmen im Chain-Block-Ciphering-Modus).
Beide Angriffe sind in neueren Implementierungen inpraktikabel geworden, da entweder clientseitig und/oder serverseitig zusätzliche Schutzmaßnahmen eingebaut wurden, selbst, wenn noch TLS 1;0 verwendet wird.
Die bessere Möglichkeit ist aber, sobald von allen wichtigen Clients unterstützt, auf TLS 1;2 und den authentifizierten Galois-/Counter-Mode umzusteigen.
Ebenso sind die CBC-Modi mit TLS 1;2 verbessert worden.

- Diebstahl des privaten Schlüssels vom Server, womit im Nachhinein aufgezeichneter Traffic entschlüsselt werden kann.
Dies ist ausschließlich bei Verfahren, die nur statische Schlüssel verwenden möglich.
zum Beispiel:
TLS_RSA_WITH_AES_256_CBC_SHA
oder
TLS_RSA_WITH_AES_256_CBC_SHA256
Letzterer Algorithmus ist ein TLS 1;2-Algorithmus, da dort andere Hashfunktionen als nur MD5 oder SHA1 als Hashalgorithmus verwendet werden kann.

Nun gibt es aber Möglichkeiten, die Möglichkeit des zweiten Angriffs zunichte zu machen.
Es wird per Diffie-Hellman, welches auch ohne diesen Zufallswert bei TLS eingesetzt werden kann (am DH oder ECDH statt DHE oder ECDHE im TLS-String zu erkennen), noch ein Zusatzwert berechnet, den selbst ein aktiver Angreifer nicht berechnen kann, und dieser ist im Idealfall für jede Sitzung einzigartig, womit selbst das Stehlen des privaten Schlüssels zu keinem signifikanten Vorteil mehr führt.
Diffie-Hellman ist selbst theoretisch anfällig für Man-in-the-Middle-Angriffe - wie man dies bei TLS verhindert (vermutlich durch den Zufallswert?), weiß ich gerade auch nicht.
Es besteht auch noch die Möglichkeit, dies mit elliptischen Kurven zu realisieren.
Mehr dazu findet sich unter Elliptic_Curve_Cryptography und Diffie-Hellman.
Downgrade-Angriffe lassen sich in Zukunft vermeiden, indem man die Protokollunterstützung für die alten Protokolle deaktiviert, derzeit aber noch nicht effektiv.

Das nur, um die Möglichkeiten und tendenziell existierenden Probleme und Lösungen mal anzureißen.
Ich erhebe keinen Anspruch auf Vollständigkeit.


Targa
12.09.2013, 21:15

Zusammenfassend und vereinfacht kann man sagen wenn die Verschlüsselung richtig konfiguriert und auch richtig verwendet wird ist die Übertragung der Nachrichten etc. sicher?!

Bezüglich des Problems, des Eindringen auf die Geräte selber kann man aber nicht viel machen, nehme ich an. Somit liegt da die gewaltige Schwachstelle des Ganzen?!


eax
12.09.2013, 22:07

Es besteht auch noch die Möglichkeit, dies mit elliptischen Kurven zu realisieren.
Mehr dazu findet sich unter Elliptic_Curve_Cryptography und Diffie-Hellman.
Downgrade-Angriffe lassen sich in Zukunft vermeiden, indem man die Protokollunterstützung für die alten Protokolle deaktiviert, derzeit aber noch nicht effektiv;
Fefes Blog (;blog;fefe~de/?ts=acceb732)

Zusammenfassend und vereinfacht kann man sagen wenn die Verschlüsselung richtig konfiguriert und auch richtig verwendet wird ist die Übertragung der Nachrichten etc. sicher?! Ja, solange der PrivateKey nicht komprometiert wurde ist die PGP Verschlüsselung momentan noch sicher.

Bezüglich des Problems, des Eindringen auf die Geräte selber kann man aber nicht viel machen, nehme ich an. Somit liegt da die gewaltige Schwachstelle des Ganzen?!Da lag auch schon im WWII die Schwachstelle, wenn man ein Agenten einschleusen oder jemanden Anwerben konnte war die Verschlüsselung hinfällig. ;)


Sticky_Haze
28.09.2013, 12:31

Es ist mittlerweile Bekannt, dass nicht die Smartphones kompromittiert sind, sondern die Computer es sind mit denen die Smartphones Synchronisiert oder mit Backup gesichert werden. Dort wurden dann die Daten geklaut. Da war die Presse mal wieder Sensationsgeil.

Edit: Was auf jedenfall bei Smartphones zu Empfehlen ist, ist die vollvererschlüsselung der SD-Karte und des internen Speichers, dies ist so sicher wie das Passwort welches du wählst;( heise~de (;;;heise~de/security/meldung/Androids-Verschluesselung-angreifbar-1936181;html) dies ist mittlerweile gefixt) Bei Android ist es, wenn ich mich recht erinnere, ab version 3;x;x von haus aus dabei


Targa
02.10.2013, 17:19

Auch recht interessant.

BitTorrent entwickelt abhörsicheren Chat (;de;engadget~com/2013/10/01/bittorrent-entwickelt-sicheren-chat/)


Ähnliche Themen zu [Smartphones] End-to-End Encryption & NSA und co.
  • [Linux] (K)ubntu 8.04 Partition Encryption
    Hi Jungs, Ich bin gerade dabei mein Kubuntu zu HardyHeron upzugraden und les da hier folgendes unter Encryption : (;wiki;kubuntu~org/HardyHeron/RC/Kubuntu) hat das schonma jemand ausprobiert und kann Erfahrungen teilen ? Wäre ja ma ne Alternative zu Truecrypt für Partitionsverschlüsselun [...]

  • Instant Messenger mit End-to-end encryption
    Hallöchen, Aufgrund eines bekannten Skandals ..;, suche ich einen Instant Messenger mit End-to-end encryption. Wenn ich danach suche finde ich nur noch Apps fürs Handy, aber ich möchte logischerweise nen Programm für PC. Sozusagen ein Skype mit End-to-end encryption, der Videoübertragu [...]

  • Welche Encryption?
    Hi, wollte fragen welche Encryption es ist. Jeder dieser Strings (pro Zeile) ist gleich verschlüsselt (aber nicht der gleiche Inhalt) "ep9jDlsn4NDPLU1ycIwlQQ==" ep9jDlsn4NAWWmPmvxCeZt9c+8p0oFDu "ep9jDlsn4NAWWmPmvxCeZhfFswJdi+vzHG6b3hHOu+Y=" "ep9jDlsn4NAWWmPmvxCeZhfFswJdi+vz7hOQJxCN59AoAQ9SpTvZYw= [...]



raid-rush.ws | Imprint & Contact pr