Aktualisierungen gibt es im Changelog, als RSS-Feed
oder im [matrix] Raum #prhdb-changes:nitro.chat

Privacy-Handbuch

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 und im Adressbuch speichert, 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:

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:
  1. 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.
  2. 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.ä.
  3. 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.
  4. 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.
  5. Google-freie Installation (beispw. via F-Droid) und Nutzung sollte möglich sein (Android).
  6. 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.
  7. 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.

    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.ä.)

  8. 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.
Einen idealen Messenger, der alle Bedingungen erfüllt, gibt es nicht. Man muss abwägen, was wichtig ist und welche Schwerpunkte man bei den Anforderungen setzt. 

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.

Schutz gegen Angriffe, die ein zusätzliches Gerät für einen Account registrieren wollen:

  1. Bei vielen Multi-Device fähigen Messengern kann man eine zweistufige Bestätigung bzw. Registrierungssperre für das Hinzufügen neuer Geräte aktivieren. Damit ist für die Anmeldung eines neuen Gerätes eine zusätzliche Passphrase bzw. PIN erforderlich, die sich vom Account Passwort unterscheiden sollte. Die oben genannten Angriffe sind dann nicht mehr möglich.

  2. 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/XMPP) und MTProto 2.0 (Telegram) sind nicht Multi-Device fähig und daher von diesen Angriffen nicht betroffen. 

Multi-Device-Support als Mini-Cloud

Der moderne Mensch nutzt heutzutage oft mehrere Geräte (neben dem Smartphone noch einen Desktop PC zuhause und/oder einen Laptop für die Reise). Damit steht man vor dem Problem, das man Daten (Fotos, Urlaubsdokumente, Passwörter… usw.) auf mehreren Geräten braucht.

Man kann auch den Multi-Device-Support moderner Messenger dafür nutzen. Dabei profitiert man von der Ende-zu-Ende Verschlüsselung der Daten. Bei wirklich guten Messenger wie Signal App oder Threema werden die Daten ausschließlich verschlüsselt auf den eigenen Geräten gespeichert und liegen nicht unverschlüsselt auf Servern von Dritten rum. Außerdem können neben beliebigen Dateien und Notizen auch Sprachmemos unkompliziert genutzt werden.

Für die Messenger-Mini-Cloud richtet man sich einen oder mehrere private (verschlüsselte) Gruppenchats ein, zu denen Dritte keinen Zugang haben und die man für "Selbstgespräche" nutzt.

Alle Dateien, Notizen oder Sprachmemos, die man hier ablegt, stehen auf allen Geräte zur Verfügung, auf denen ein Client für den Messenger installiert ist. (Funktioniert mit allen Messengern.)

In den Desktop Clients von Signal App oder Telegram ist ein Chat für die "Selbstgespräche" schon vorbereitet. Man kann sie in den Desktop Clients (nicht auf den Smartphones) aktivieren.


Harte und weiche Verifikation von Kommunikationspartnern

Auch wenn die Krypto nicht gebrochen werden kann, sind verschiedene Angriffe möglich:

Gegen diese Angriffe schützt eine Verifikation der Kommunikationspartner:

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: Oder Signal App:

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. Oder ohne Bild:
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: