Die Übernahme von WhatsApp durch Facebook zeigt, dass es einfach Sch.... ist, sich das Adressbuch klauen zu lassen. Irgendwann landet es in den Datensammlungen von Facebook (oder Google, Microsoft oder...), die alle als PRISM-Partner der NSA gelistet sind.
Juristisch kann man es DSGVO-konform so formulieren (AG Bad Hersfeld Familiengericht):Wer den Messenger-Dienst "WhatsApp" nutzt, übermittelt nach den Vorgaben des Dienstes fortlaufend Daten in Klardaten-Form von allen in dem eigenen Adressbuch eingetragenen Kontaktpersonen an das hinter dem Dienst stehende Unternehmen (Facebook).
Wer durch seine Nutzung von "WhatsApp" diese andauernde Datenweitergabe zulässt, ohne zuvor von seinen Kontaktpersonen aus dem eigenen Adressbuch hierfür jeweils eine Erlaubnis eingeholt zu haben, begeht gegenüber diesen Personen eine deliktische Handlung und begibt sich in die Gefahr, von den betroffenen Personen kostenpflichtig abgemahnt zu werden.
Wenn man als WhatsApp Nutzer die Telefonnummern mit Bekannten austauscht, dann müsste man also eigentlich um die Zustimmung bitten, Name, Telefonnummer und Freundschaftsstatus an Facebook zu schicken. Das Gespräch könnte so ablaufen:
- Anton: "Du hast doch nichts dagegen, wenn ich Facebook Deinen Namen und die Telefonnummer schicke und das wir Freunde sind?"
- Beatrice: "Eyhh - alles ok - mache ich auch."
Anforderungen an einen guten Messenger
Unter Berücksichtigung der massiven Überwachung von Instant Messaging, welche durch Edward Snowden bekannt gemacht wurde, und des Crypto War 3.0 ergeben sich folgende Anforderungen an einen guten Messenger Dienst:- Sichere Ende-zu-Ende Verschlüsselung nach dem aktuellen Stand der Technik, die durch unabhängige Experten evaluiert wird. Die Auswertung von 160.000 Überwachungsberichten aus dem Snowden-Fundus zeigt, dass Geheimdienste die Messenger massiv überwachen.
- Sichere Transportverschlüsselung (SSL/TLS) für die notwendige Kommunikation der Apps mit den Servern und zwischen den Servern. Dabei sollten alle Best Practice Empfehlungen umgesetzt werden inklusive Certificate Pinning u.ä.
- Der Account sollte frei wählbar und nur optional mit einer Telefonnummer verbunden sein. Telefonnummern sind im Gegensatz zu E-Mail Adressen ein eindeutiges Identifizierungsmerkmal und nicht so einfach austauschbar wie (Wegwerf-) E-Mail Adressen. Das ermöglicht die Verknüpfung verschiedener Accounts bei unterschiedlichen Messaging Diensten und die Zuordnung zu einer Person. Außerdem schützt die Weitergabe eines Pseudonyms statt Telefonnummer gegen Stalking.
- Es sollte keine unerwünschten Uploads (Datenklau) ohne ausdrückliche Zustimmung geben. Der Dienst sollte komplett ohne Datenklau nutzbar sein und nur optional auf Daten wie das Adressbuch zugreifen, wenn es als Komfort- oder Sicherheitsfeature gewünscht wird.
- Google-freie Installation (beispw. via F-Droid) und Nutzung sollte möglich sein.
- Die Nutzung auf dem Desktop PC sollte möglich sein. Oft lässt es sich auf dem PC oder Laptop mit Tastatur und Bildschirm besser arbeiten als mit einem Smartphone.
Die Infrastruktur des Dienstes sollte dezentral verteilt sein und nicht von einem einzelnen Betreiber kontrolliert werden. Dezentrale Strukturen sind nur schwer von Regierungen durch Gesetze kompromittierbar, um Geheimdiensten die Überwachung zu ermöglichen.
Anmerkung: Im Gegensatz zu einigen Open Source Dogmatikern bin ich nicht der Meinung, dass eine dezentrale Infrastruktur "freier Messenger" gegen die Installation von Backdoors auf den Servern schützt. Während bei Threema oder Signal App immer wieder angezweifelt wird, ob dort wirklich die auditierte Software auf den Servern läuft, werden die Admins von [matrix] oder XMPP Servern per Definition zu Heiligen erklärt, die niemals etwas anderes installieren würden als die offizielle Software oder neugierig die Metadaten beschnüffeln.
Für diese Glorifizierung der Open Source Admins gibt es keinen Grund. Als wir vor einigen Jahren noch Jabber/XMPP mit OTR-Verschlüsselung verwendeten, haben wir gehofft, das die Admins der Server nicht mit dem Modul mod_otr: man-in-the-middle module for Off-the-Record spielen oder es zumindest nicht gegen uns anwenden.
Man musste vertrauen, so wie man heute Threema oder Signal App vertrauen muss.
Die Gründe für Vertrauen sind sehr individuell. Manch einer sagt sich "Ich vertraue dem Admin, weil es ein Bekannter ist." und ein anderer denkt "Ich vertraue dem Admin nicht, weil es ein Bekannter ist, da die Neugier und Verführung zu einer kleinen Schnüffelei unter Bekannten am größten ist." (Stichwort Love-INT o.ä.)
- Es wäre schön, wenn die Bedienung so einfach wäre, dass auch meine Tante und ihre Kaffeekranz Freundinnen ohne lange Erklärungen damit umgehen können.
Multi-Device-Support als Sicherheitsrisiko
Multi-Device-Support ist ein heutzutage ein häufig gewünschtes Standardfeature für Messenger. Man möchte via PC und Laptop online sein, um eine vernüftige Tastatur und einen großen Bildschirm zu nutzen, und man möchte via Smartphone unterwegs erreichbar sein. Dieses Feature erschwert es aber, eine sichere Ende-zu-Ende Verschlüsselung zu realisieren.
Ein potenter Angreifer kann den Multi-Device-Support ausnutzen, um ein weiteres Gerät im Namen des Opfers zu registrieren. Damit können alle Unterhaltungen mitgelesen werden und es sind auch Ende-zu-Ende verschlüsselte Chats betroffen. Das betrifft alle Multi-Device fähigen Protokolle.
Das BKA hat in den Jahren 2015/16 insgesamt 43x Telegram Nutzer überlistet. Das Team von Prof. Fedderath demonstrierte wie: die Behörden gaben die Telefonnummer der Zielperson in der Telegram Web-App eingeben und die SMS zur Authorisierung des Zugriffs abfangen. Dann konnten die unverschlüsselten Gruppenchats unbeobachtet mitgelesen werden. (Inzwischen werden Codes zur Authorisierung zus. Geräte nicht via SMS versendet sondern via Telegram.)
Die verschlüsselten, geheimen Chats von Telegram konnten damit nicht geknackt werden, da die Verschlüsselung MTProto nicht Multi-Device fähig ist.
- Außerdem hat das BKA durch Registrierung eines zusätzlichen Gerätes für den WhatsApp Account von Magomed Ali-C (ein Terrorverdächtiger aus dem Umkreis von Anis Amri) die Ende-zu-Ende verschlüsselten Chats mitlesen können. Dafür brauchte das BKA allerdings kurzeitig unbeobachteten Zugriff auf das entsperrte Handy von Magomed Ali-C, um das zusätzliche Gerät zu aktivieren. (Das würde auch mit Signal App u.a. funktionieren.)
- Im Iran wurden seit 2014 wesentlich elegantere Angriffe staatlicher Hacker auf Telegram und WhatsApp eingesetzt. Mit der Zusendung eines bösartigen Dokumentes wurden die Smartphones der Opfer kompromittiert und dann die Account Credentials von WhatsApp oder Telegram ausgelesen. Mit diesen Credentials konnten die Angreifer ein weiteres Gerät im Namen des Opfers registrieren und den Multi-Device Support exploiten.
-
Ein Test von Riot ([matrix]) zeigte ebenfalls erhebliche Hürden in der Usability beim Schutz gegen das Einschleusen eines bösartigen Gerätes. (Wobei man noch hinzufügen muss, dass beide Teilnehmer in dem Chat als Krypto-Experten gelten und wirklich verstanden haben, wie sichere Krypto funktionieren könnte.)
- Anton: "Ok - habe Riot installiert und bin drin!"
- Beatrice: "War doch ganz einfach - oder?"
- Anton: "Aber der Chat ist unverschlüsselt. Sollte das nicht E-2-E sein?"
- Beatrice: "Du musst die E-2-E Verschlüsselung erst aktivieren."
- Anton: "Habe ich in den Einstellungen aktiviert."
- Beatrice: "Nee - DU musst es für JEDEN Chat einzeln aktivieren."
- Anton: "Wie? Wo? Finde nix."
- Beatrice: "Chat Settings, ganz runter scrollen, unten die letzte Option."
- Anton: "Ok - hab's gefunden."
- Beatrice: "Ist halt BETA, kann man noch verberssern."
- Anton: "Hmmm - sehe gerade, dass Du hier mit 6 Geräten chattest!!! 2x Linux, 3x Ubuntu und ein seltsames Phone. Bist Du sicher, dass die alle von Dir sind - oder...???"
- Beatrice: "Kann schon sein, keine Ahnung - ich nutze Riot schon länger..."
- Anton: "Arrrghhhh..."
Das Audit der OMEMO Verschlüsselung für Jabber/XMPP (PDF) beschreibt einen möglichen Man-in-the Middle Angriff auf die Verschlüsselung, der ebenfalls die Multi-Device Fähigkeiten des Protokolls ausnutzt. Ein Angreifer (Eve) veranlasst Alice, ein neues Gerät mit einem eigenen Key für Bob in die Liste aufzunehmen. Alice sendet in Zukunft alle Nachricht verschlüsselt mit den Schlüsseln für Bob+Eve. Eve kann die Nachrichten mitlesen ohne die Krypto brechen zu müssen. Um unentdeckt zu bleiben, entfernt Eve ihre Geräte-ID, bevor sie die Nachricht an Bob weiterleitet. Diese Manipulation ist bei OMEMO möglich, weil die Nachrichten nicht kryptografisch authentifiziert werden. (Hat man das einfach vergessen?)
Es ist eine alte Weisheit, dass eine Kommunikation erst dann wirklich vertrauenswürdig ist, wenn man die Schlüssel verifiziert hat und sicherstellt, dass nur diese verifizierten Schlüssel verwendet werden. Alle Messenger bieten die Möglichkeit, bei einem Treffen oder out-of-band über einen unabhängigen Kanal die verwendeten Schlüssel zu verifizieren.
Außerdem kann man bei vielen Multi-Device fähigen Messengern eine zweistufige Bestätigung für das Hinzufügen weiterer Geräte aktivieren. Damit ist eine zusätzliche Passphrase erforderlich, die sich vom Account Passwort unterscheiden sollte, wenn ein neues Gerät angemeldet wird.
Als Schutz gegen Angriffe bei (kurzzeitigem) physischem Zugriff auf ein entsperrtes Smartphone bieten hochwertige Messenger eine zusätzliche PIN-Sperre für die App, die man bei hohem Schutzbedarf aktivieren kann. Damit wird verhindert, dass ein Angreifer die App auf dem Smartphone starten kann und damit die Rechte erlangt, um ein zusätzliches Gerät anzumelden.
Anmerkung: Die Krypto-Protokolle OTR (Jabber) und MTProto (Telegram) sind nicht Multi-Device fähig und daher von diesem Angriff nicht betroffen.
Harte und weiche Verifikation
Auch wenn die Krypto nicht gebrochen werden kann, sind verschiedene Angriffe möglich:
- Social Attacks greifen nicht die Krypto an. Stattdessen versucht ein Angreifer (Mallory) sich das Vertauen zu erschleichen, z. B. indem er sich als eine bekannte Person ausgibt:
- Mallory: "Hi Anton, ich bin Beatrice und wollte nochmal über das geheime Ding..."
- Anton: "Hallo Beatrice - schön dass Du Dich meldest - also..."
- Mallory: "Hi Beatrice, ich bin Anton. Also zu diesem geheimen Ding..."
- Beatrice: "Ohhh - Anton, schön dass Du Dich meldest. Tja also..."
Angriffe auf die Schlüssel attakieren den Schlüsseltausch. Um eine einfache Kontaktaufnahme zu ermöglichen wenn der Gegenüber offline ist, stellen viele Messenger die public Keys der Nutzer auf den Servern zur Verfügung. Ein bösartiger Betreiber könnte prinzipiell die Keys austauschen und den Datenverkehr umleiten, so dass Mallory wieder in der Mitte sitzt und als "Reflektor" agieren kann, der die Nachrichten umschlüsselt und mitliest.
Ob man derartige Angriffe für wahrscheinlich bzw. möglich hält, hängt vor allem vom Vertrauen in den Provider ab. Da Ende-zu-Ende Verschlüsselung auch gegen bösartige Provider schützen soll, ist es aber legitim, diese Angriffe in Erwägung zu ziehen und zu diskutieren.
Weiche Verifikation schützt gegen Social Attacks. Man könnte den Account des Gegenüber via Audio- oder Videocall anrufen (viele Messenger unterstützen es) und wenn man den Gegenüber erkennt und die Verschlüsselung prüft, chattet man mit der richtigen Person.
Wenn der Account des Gegenüber mit einer Telefonnummer verknüpft ist, dann ist auch eine Verifikation via Adressbuch möglich. Einige Messenger können die Telefonummer des Gegenüber mit dem Adressbuch abgleichen und schützen damit gegen simple Social Attacks.
- Bei Signal App ist das standardmäßig der Fall, so dass diese Social Attacks unter Bekannten, die die Telefonnummern ausgetauscht haben, nur schwer möglich sind.
- Bei Threema kann man einen Account optional mit einer Telefonnummer verknüpfen (und damit die Anonymität teilweise aufgeben). Threema speichert Hashwerte der verknüpften Tefonnummer oder E-Mail Adresse auf dem Server und zeigt eine schwache (weiche) Verifikation an, wenn der Client die verknüpfte Telefonnummer im Adressbuch findet.
- Bei Telegram wird die Telefonnummer aus dem Adressbuch unter dem Account angezeigt, die man vergleichen könnte. Aufgrund der Implikationen für die Privatspäre ist es aber nicht empfehlenswert, Telegram den Zugriff auf das Adressbuch zu erlauben.
- [matrix] bietet keine weiche Verifikation. Man eine E-Mail Adresse auf dem Homeserver hinterlegen für einen Passwort-Reset (bezüglich der Telefonnummer sagt die FAQ: "Not anymore - sorry!") oder auf einem Identitässerver Telefonnummer und/oder E-Mail, um besser gefunden zu werden. Da die Daten werden dabei in Plain-Text gespeichert werden.
(Es ist nicht grundsätzlich verwerflich, wenn Messenger Accounts mit Telefonnummern verknüpft werden. Es kommt darauf an, ob man den Messenger vor allem für die private Kommunikation mit Bekannten verwenden möchte oder ob man in erster Linie anonym irgendwo "rumtrollen" will.)
Harte Verifikation überprüft die verwendeten Schlüssel. Ein universelles Verfahren zur Überprüfung der Schlüssel ist ein Vergleich der Fingerabdrücke der Schlüssel bei einem Face-2-Face Treffen oder out-of-band über einen unabhägigen, sicheren Kanal.
Der Fingerabdruck muss dabei nicht unbedingt anhand kryptischer Zeichenfolgen verglichen werden sondern könnte auch anhand bunter Bildchen erfolgen, was intuitiver ist.
- Bei Face-2-Face Treffen scannt man i.d.R. gegenseitig einen angezeigten QR-Code.
- Bei einem unabhängigen Kanal muss man natürlich sicher sein, dass am anderen Ende des Kanal wirklich die gewünschte Person sitzt. Der Kanal muss also verifiziert sein.
- Messenger, die für hohe Sicherheitsanforderungen optimiert sind wie Briar oder Tox, haben auch einen sicheren Schlüsseltausch implementiert, der eine harte Verifikation einschließt.
Signal App setzt nicht nur bei Verschlüsselung der Daten Maßstäbe sondern auch beim Schlüsseltausch. Beim X3DH Schlüsseltausch liegen nicht die public Keys auf dem Server sondern abgeleitete Schlüssel, die nur in Kombination mit den echten privaten Keys auf den primären Endgeräten der Nutzer sinnvoll genutzt werden können.
Bei X3DH könnte ein bösartiger Provider die Verbindsaufnahme blockieren. Es ist aber (nach aktuellem Stand) nicht möglich, modifizierte Keys einzuschleusen.
- WhatsApp verwendet mit dem ECDH Schlüsseltausch ein ähnliches Verfahren, dass ebenfalls von den Signal Entwicklern entwickelt wurde.
- Die meisten anderen Messenger publizieren einfach die public Keys auf den Servern und weisen mit bunten Icons darauf hin, dass die Schlüssel verifiziert werden sollten.
Notifications und Notificaton History
Beim Eintreffen neuer Nachrichten kann man sich Beanchrichtigungen anzeigen lassen. Die Anzeige ist auch auf dem Sperrbildschirm möglich. Damit könnte ein Angreifer, der physisch Zugriff auf das Smartphone hat, Informationen über Inhalte erlangen, die verschlüsselt sein sollten. Die angezeigten Daten werden außerdem in der Notification History gespeichert und bleiben auch dann erhalten, wenn man die eigentliche Nachricht löscht. Ein Beispiel:
Diese Anzeige der Nachrichten könnte im Freundes- oder Familienkreis für Verwirrung sorgen, wenn beispielsweise der Ehemann auf dem Smartphone seiner Frau öfters Nachrichten von anderen Männern mit Küsschen und Herzchen Smilies sieht.
Deshalb bieten gute Messenger die Möglichkeit, die angezeigten Inhalte zu konfigurieren und keine (verschlüsselten) Inhalte in Notifications zu leaken. Beispielsweise Threema:
Link Previews in Messengern
Einige Messenger bieten ein Link Preview, wenn man eine URL in das Eingabefeld tippt oder kopiert. Man kann den angebotenen Preview mit versenden oder vor dem Versand löschen.
Voraussetzung für einen Link Preview ist, das die Webseite im HTML Header die Open Graph Metatags enthält. Anhand dieser Metatags wird der Preview generiert (mit oder ohne Bild): <HTML>
<HEAD>
...
<meta property="og:title" content="Ein Beispiel">
<meta property="og:description" content="Das ist nur ein sinnloses Beispiel">
<meta property="og:image" content="https://beispiel.tld/images/preview01.png">
... Um einen Link Preview zu generieren, kontaktiert der Messaging Client den Webserver und versucht die Webseite zu laden, sobald eine URL im Eingabefeld erkannt wird. Wenn die Webseite im Header die Open Graph Tags enthält, wird ein Preview generiert und evtl. das Bild vom Webserver geladen. Diesen Ablauf kann man sehr unterschiedliche implementieren:
WhatsApp hat die einfachste Implementierung gewählt. Der WhatsApp Messenger kontaktiert den Webserver direkt und hinterlässt damit Einträge in den Logs.
Anhand der IP-Adresse kann damit die Verknüpfung zu einer Person erfolgen, wenn man beispielsweise den Link zu einer Facebook Seite versendet und dabei gleichzeitig bei Facebook eingeloggt ist. (Aber das stört WhatsApp Nutzer wahrscheinlich nicht.)
Signal App generiert Link Previews für Webseiten, die via HTTPS erreichbar sind. Signal App kontaktiert den Webserver ebenfalls direkt und tarnt sich als "WhatsApp".
In den Datenschutz Einstellungen von Signal kann man Link Previews abschalten.
Telegram hat eine andere Lösung implementiert. Die Link Previews werden auf dem Telegram Server generiert. Das verhindert Implikationen wie bei WhatsApp, da nur der Server die Webseiten kontaktiert und das Abrufen der Informationen keinem Nutzer individuell zugeordnet werden kann.
Bei unverschlüsselten Chats kann man das als brauchbare Lösung betrachten. Bei geheimen Chats, die Ende-zu-Ende verschlüsselt sind, sollte der der Telegram Server aber keine Informationen über die Inhalte der Chats sammeln können. Deshalb sollte man die Link Previews für geheime Chats abschalten. Die Option findet man in den Einstellungen unter "Privatsphäre und Sicherheit" -> "Dateneinstellungen".
Matrix/Riot macht es ähnlich wie Telegram. Bei unverschlüsselten Chats werden die Link Previews vom Matrix Server generiert. Dieses Feature kann in den Einstellungen von Riot deaktiviert werden. Bei Ende-zu-Ende verschlüsselten Chats sollen laut Spezifikation keine Link Previews generiert werden.